Posted by robogeek
on November 20, 2007 at 12:10 PM PST
A couple weeks ago I jailbroke my iPod Touch and had this strange epiphanette looking at a root shell prompt on a fracking iPod . This morning I allowed iTunes to update it to v1.1.2 and now my iPod is trapped again as being just an iPod. All the extra icons went away, I can't play Pig Shooter, Labrynth, can't use Stumbler to see nearby WiFi access points, etc. Hurm. And I did a bit of yahoogling this morning and see there's some methods available to keep the iPod jailbroken, it seems I have to revert it back to 1.1.1 however.
One interesting aspect of this has to do with the method used to jailbreak the thing. At jailbreakme.com they host a tiff file which contains a security exploit which causes Safari to crash, and once crashed they are able to squirt into the iPod (or iPhone) an installer which then loads up other software. So.. um.. while it's cool they've done this, it's a security concern, right? That exploit could be used by nefarious folk to do nasty things via a broken iPod. It's fortunate that jailbreakme.com is run (I hope) by honest people who (I hope) didn't do anything nefarious with my iPod.
While you might think "what's on an iPod that could be dangerous" .. ah, let's see, iPods get sync'd to a desktop computer regularly and a nefarious bit of software could be transferred into the desktop when sync'd. Also iPod Touch's are Unix systems (remember that shell prompt) and that means the software capabilities are just as endless as Unix allows.
Which just makes me think of this IcedTea bug , 'Bug 78: Use pure Java implementation of zlib from Classpath instead of zlib for java.util.zip' related to a native zlib being embedded in the OpenJDK implementation. It's even an old version of zlib. In the bug discussion they refer to the sort of buffer overrun bugs that is used by jailbreakme.com to crack into an iPod/iPhone. Generally they suggest C code is unsafe, and Java code is safe(r).
Native code can have buffer overrun attacks which can trigger a security problem in a JVM using that native code. In Java code on the other hand it's really hard (if not impossible) to have buffer overrun attacks and in general there is an excellent security model in Java. Hence if things like zlib or image codecs were implemented in Java rather than native code, the code would be safer. The question of course is accuracy (can we reimplement with quality equal to the existing native libraries) and performance (will the JIT do a good-enough job) and would the implementation perform well in an embedded device (JavaME)?
Maybe for security sake it would be good to remove dependencies on native libraries and reimplement them as Java code. But the bug report shows a little investigation - namely, a Java zlib implementation is shown to have less performance than the existing native zlib implementation.
I can't help but also think about the gphone (android) now that I have an iPod that's been put back in jail. The last two weeks has seen a lot of hype regarding the android (gphone) platform. But the reality of what Google has delivered didn't live up to the hype.
It seems the hype was a lot of wishful thinking and that there was similar hype before the iPhone was launched. So in the hope of building some hype around Sun's product line, hey everybody, we have a cell phone platform we announced a few months ago. JavaFX Mobile is supposedly going to be the neatest thing since sliced bread, supposedly gonna have an iPhone-like UI, but be written in Java(JavaFX) and be available on cell phones and as a stack for cell phone makers. Many of the ideas attributed to the gphone before Google revealed Android could also be said of JavaFX Mobile. But we also haven't revealed our concrete plans, so those sentences were an exercise in building hype rather than revealing actual reality.
I think the gphone/iphone hype was related to a freedom that some people desire. Since cell phones are becoming more powerful they "ought to" be more like generalized computing devices rather than single-function devices whose featureitis is tightly controlled. My iPod Touch was more useful as a generalized computing device than it is right now as an iPod.
It's been said that cell phone makers haven't been allowing this to happen. Instead that cell phones have been generally tightly controlled walled gardens. It remains to be seen whether any company will be able to make this dream come to reality. The most interesting article I've seen about this, Yes, Google is trying to take over the world. - By Tim Wu - Slate Magazine , suggests that the U.S. communications infrastructure has been trapped in a multigenerational lock perpetrated by AT&T and GTE (Verizon). The article gives me a whole new perspective on the network neutrality debate of the last couple years.
Cell phones need to be a reliable service. Whatever nefarious things one might say about AT&T and other telecomm companies, they are offering a service which provides a critical communications infrastructure. When there's a disaster don't you want to call for help? The fire dept, police dept, etc, all provide essential services and your way to ask for those services is by placing a phone call. I think part of this tight control stems from their need to provide such reliable service. Or is that just an excuse?
Remember that in the old days AT&T refused to allow third party telephones to be sold, and held us in a lock of having to rent our phones. Their claim? That a third party phone might damage the network. I think it's the same claim they trot out concerning flexible cell phones, so it seems like a suspicious claim, on the other hand cell phone which are really generalized computing devices can truly do more damage if nefarious software gets installed. Think of the damage a Windows virus can do in terms of denial of service attacks. A cell phone virus could launch a denial of service attack which could block cell phone service.
I believe the sweetspot is somewhere in between the shackles of todays walled gardens, and the utopia represented by platforms like OpenMoko.