Solipsism Gradient

Nearly a month ago I wrote:
Rainer Brockerhoff wrote:

So, I’m a 100% percent sure nobody will be able to unlock the iPhone or run third-party applications on it unless Apple opens it up. Here’s why: ARM’s TrustZone…

It’s hard to believe Apple didn’t want to take advantage of TrustZone at all, unless the intention was to publish a complete SDK later. Or perhaps only parts of the hardware are protected; the radio and the camera are possibilities.

A SIM hardware unlock hack was published a few days ago, and today Engadget wrote about two software unlocks. There’s no real confirmation on these yet but I no longer doubt it’s possible. I gather that people managed to write software to clear certain parts of the firmware flash RAM.

To me, this shows conclusively that Apple elected not to use TrustZone at all – just as they, in the past, elected not to use the TPM chips on the first Intel Mac motherboards to lock down Mac OS X to Apple machines. About the latter question, of course we’ll have to wait until the Leopard GM release comes out to be absolutely sure, but I haven’t heard anything about Leopard breaking new grounds regarding such protection. On the other hand, while there are groups of people still busily adapting every new Mac OS X release to run on “generic” PCs, they still seem to be very much in the minority – and for a reason. Normal users want support and Apple hardware quality without having to do complicated hacking and installing.

Coming back to the iPhone, on reflection it makes some sense for Apple to not do an unbreakable protection. Under the current situation, every iPhone software update is a single package; I understand that all apps are updated at the same time and everything except the user’s data is wiped and reset. This allows Apple to ensure that all versions of official software mesh with each other and also gives them the freedom to radically change the system, if necessary, without anybody noticing. Also, this means that the first item in any support procedure will be a reinstall, meaning Apple doesn’t need to worry about what the user may have installed; they’ll have to re-hack again later.

I’ve also heard from people who know people close to the iPhone team that all these efforts are closely watched. No doubt Apple saves some time and money, even if indirectly, by the current situation; it would make securing some future version easier should they deem it necessary.

I also think that not having an iPhone SDK available immediately will have been good in the long term. It’s helping Safari gain browser- and mindshares, and it’s allowing the iPhone’s OS X and built-in applications to become more fully debugged without Apple having to worry about keeping legacy APIs around for prematurely released 3rd-party applications. Yes, those apps will be released with a larger delay than people expected, but they’ll rest on a better foundation. With the hacker’s development toolchain becoming more polished there are now some 3rd-party GUI apps being released, and of course Apple will be adopting some ideas for its own apps and SDK (even in the negative sense of making sure they’ll be doing something differently).

From what I’m seeing, AT&T will be the loser in this situation. Apple will sell some more iPhones – probably not in statistically significant numbers at first – but AT&T will lose some contracts. Apple can demonstrate that they did a reasonable effort to prevent that, and it may not even be illegal for someone to unlock their own phone (it’s probably illegal to set up a business unlocking other people’s phones though). So, AT&T will lose some business to other carriers, as they do with other phones.

I usually don’t believe in sinister Apple agendas, but this may qualify…

So, I’m a 100% percent sure nobody will be able to unlock the iPhone or run third-party applications on it unless Apple opens it up. Here’s why: ARM’s TrustZone. Ehrm, make that 90%. I mean, it’s still quite unlikely. Well, OK, they can hack the serial interface in the connector but that can’t write to the screen. Well, let’s say 50-50. Of course, they can run stuff but not touch the network interface – OK, it seems they can. But never run a GUI app! Oh, they can now? But aren’t the binaries signed? No. Heh…

That’s about how I felt while writing an article for MAC+ (the upcoming print issue, which went to the printer a few days ago, around the “but never run a GUI app” phase. Well, today I see they (“they” don’t want people to link to their Wiki, but it’s easy to find on Google) succeeded in building a standard GUI app and display a screen on the iPhone. Must be Clarke’s Law in action – even though I’m not that elderly, hmpfh. Writing about moving targets is hard.

So what’s left? Of course I don’t have an iPhone myself here and I don’t have any privileged info on its architecture. I did hear over the grapevine that the Apple iPhone is following these issues with great interest and is working on updates – whether they’ll make a point of plugging these hacks is anybody’s guess. At the time I’m typing this, accessing the cellphone radio and unlocking the SIM card mechanism is still not possible.

Does that mean Apple didn’t bother to implement the TrustZone technology? I still maintain it’s impossible to crack from outside using present technology. The firmware is contained on the CPU chip itself, the implementor can restrict access to certain peripherals, decryption can happen entirely within the trusted zone, and the firmware can elect to run only signed binaries. There are some 1024-bit RSA keys in the iPhone which supposedly are still a few years away from being cracked, and in any event could be switched to 2048 or 4096. The barrier is even stronger than it was on the first Intel Macs, which had a TPM chip onboard (the last versions don’t and it seems Apple never used them) but separate from the CPU.

It’s hard to believe Apple didn’t want to take advantage of TrustZone at all, unless the intention was to publish a complete SDK later. Or perhaps only parts of the hardware are protected; the radio and the camera are possibilities. For sure they didn’t implement the usual Unix protection, where the root account can do everything; all processes on the iPhone run as root anyway. Looking at the current iPhone libraries there’s a “lockdown” library which most applications link against. It seems to check the aforementioned keys and confer privileges to access some likely-sounding sectors of the system. Having a non-standard security system is obviously an attempt to throw off people who expect 99% of the cracking to involve getting root privileges. I don’t have the tools to ascertain whether the lockdown library does in fact invoke TrustZone at a lower level, and much of this may change anyway for the next software update.

Speaking of which, from what we can see of the iPhone software the update process will involve a complete replacement – no partial updates here. My guess is that updating will also be mandatory, with iTunes updates being published simultaneously. Replacing all software at once of course makes sure that everything works together, but it would also allow Apple to change everything at once. We’ll know in a few months, I’d say.

Just found time to read John Gruber’s first impressions of the iPhone. Worth a read, but the most interesting part is where he says that iTunes showed him a crash report, which he posted.

Several interesting items are evident in the crash report, the most interesting is the following line:

OS Version:      OS X 1.0 (1A543a)

which sort of answers my previous question; how is Apple planning to handle the Mac OS X/”OS X” division? So unless this is just a stopgap or beta version of “OS X”, version numbers of that aren’t tracking their Mac OS X counterparts at all. We’re back at 1.0.

Elsewhere, Gruber says, referring to some limitations in the iPhone’s “Notes” application:

…Both problems with Notes seem to me an indication that it was designed under the assumption that iPhone would debut alongside Leopard. Mac OS X Leopard includes a system-wide “notes” feature, exposed through Apple Mail, and as you can see in the screenshots, it looks a lot like iPhone Notes – Marker Felt text on a yellow legal pad background. Presumably, some sort of synching is coming eventually, at least with Leopard.

This makes sense to me – I always thought that iPhone and Leopard were originally supposed to come out on the same day, and that by that time we’d see the “Mac” taken out of Mac OS X – OS X 10.5 would be the new version across all Apple products. But apparently this was a little too much for the Apple folks to chew, and Leopard had to be delayed so the iPhone could still come out in the nick of time.

Well, the iPhone seems to be fully capable of being easily updated, and this version convergence may still happen in November (?) when 10.5 Golden Master should be out. Meanwhile, the crash reports yields some other nuggets. There are frameworks with suggestive names like UIKit, Celestial, CoreTelephony, MeCCA and CoreSurface. We can also see that the iPhone uses many known frameworks, but Cocoa’s AppKit is conspicuous in its absence – the Objective-C, BSD and C++ runtimes are there, however. I also see sqlite (backing store for CoreData) and OpenGLES (OpenGL for Embedded Systems) in there.

With all this, I suppose next year’s WWDC will be extremely interesting…

Update: Fraser Speirs has more comments on the crash log.

Update#2: rereading the crash log, I just noticed two more important lines:

Code Type:       0000000C (Native)
Effective UID:   0

The first one probably implies that it’s running the ARM native instruction set instead of the Thumb 16-bit instructions – although that specific ARM CPU also supports Jazelle, which is a hardware-assisted Java virtual machine. The second one indicates that the MobileMail application (and no doubt the other apps) are running as userID zero, also known as “root”. No doubt this will be received with extreme dismay and derision by Unix-savvy folks. While it’s not unsurprising in an embedded device with no user-installable software, I doubt this will be retained when the next major software update comes out – probably together with Leopard.

One significant announcement (some say the only one) at WWDC is the Safari 3 Beta, which includes Safari for Windows; at least it’s the one I’ve seen the most varied interpretations of, so far.

Considered as a beta release, Safari 3 is so-so. The Mac version needs a reboot because it also substitutes the Dock (which runs Dashboard widgets) and the system-wide webkit. It also substitutes the standard Safari installations. I had to reinstall Flash afterwards to get some sites to work. For my usual sites, it performed quite well although I had one crash. I don’t have a XP machine to test the Windows version on, but I hear it’s unusable on non-English versions, and very flaky on most English systems as well.

Steve Jobs stated the primary intention was to widen Safari’s marketshare, and the demo concentrated on a supposed serious speed advantage on Windows – “more than twice as fast as Internet Explorer”. And then, in the “one last thing” section, he refers to a “very sweet solution” for developing apps for the iPhone : the full Safari engine, no SDK needed allows Web 2.0/AJAX applications. (The entire section was received with silence by the crowd.) Steve’s statement that this is “a very modern way to build applications” somewhat contradicts what he said at D5:

…I love Google Maps, use it on my computer, you know, in a browser. But when we were doing the iPhone, we thought, wouldn?t it be great to have maps on the iPhone? And so we called up Google and they?d done a few client apps in Java on some phones and they had an API that we worked with them a little on. And we ended up writing a client app for those APIs. They would provide the back-end service. And the app we were able to write, since we?re pretty reasonable at writing apps, blows away any Google Maps client. Just blows it away. Same set of data coming off the server, but the experience you have using it is unbelievable.

…

And you can?t do that stuff in a browser.

So people are figuring out how to do more in a browser, how to get a persistent state of things when you?re disconnected from a browser, how do you actually run apps locally using, you know, apps written in those technologies so they can be pretty transparent, whether you?re connected or not.

But it?s happening fairly slowly and there?s still a lot you can do with a rich client environment.

So here we have at least two apparent intentions: get more penetration in the global browser “market” (maybe “mindshare” would be a better term as they’re nearly all free for the end-user), and open up iPhone development for Windows owners. Both sound logical.

More market penetration would surely be good for Apple. As John Gruber notes, Apple gets income from the Google search bar – tens of millions of dollars per year isn’t bad. And having Safari available on Windows removes one lame excuse for webmasters that build sites that don’t render properly (or at all) on Safari; it’s no longer necessary to own a Mac for checking that out.

Speaking of rendering properly, Safari for Windows, or rather WebKit, includes the Lucida fonts and several low-level frameworks, among them CoreGraphics, ColorSync, ImageIO and CoreFoundation. Some people believe this is a first step towards reviving the Yellow Box for Windows idea, but Cocoa is much larger than that… Safari is just a relatively thin shell around WebKit, and the Windows version shows no signs of being written in Objective-C, for one. Of course many people are once more complaining that Safari for Windows renders fonts differently. Joel Spolksy explains:

Apple and Microsoft have always disagreed in how to display fonts on computer displays. Today, both companies are using sub-pixel rendering to coax sharper-looking fonts out of typical low resolution screens. Where they differ is in philosophy.

– Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

– Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface.

I’ve talked to several people about this issue. Beyond the expected bias of familiarity – everyone is used to their main working platform and finds the other’s rendering strange – I found that most graphic artists and font designers prefer the Mac rendering, while most web designers and IT people seem to prefer the Windows rendering.

But beyond that, the fact that Safari for Windows tries to reproduce exactly the Mac rendering is important (and not a bug, as many Windows users are claiming). I’ve seen this myself on my site; tweaking font size etc. so the page looks good on the Mac often produces quite different layout when you view it on a Windows browser, and it’s impossible to get it to look exactly the same, down to line breaks and text heights. This is doubly important when you’re viewing the page on a small screen like the iPhone has. Zooming the page display like the iPhone does seems to mandate the Apple rendering engine: Windows’ pixel alignment is counterproductive there.

Coming back to the “zero-cost iPhone (non)SDK” idea. Reactions in the developer community seem fairly mixed. At WWDC itself, of course, most developers aren’t web app developers, but were looking forward to doing Cocoa on the iPhone. And of course that implies that everybody thought that, when Apple would come out with an iPhone SDK (or even a generic OS X SDK, as I thought before the conference) Cocoa/OS X developers would have a monopoly… after all, they already own the development hardware and software. Nobody seriously believed that Apple would invest in doing a separate iPhone SDK that would include a simulator or even a compiler for one of the existing Windows IDEs, as Palm used to do when their products were still 68K-based (no idea what they do today).

Instead, so “real” Mac developers think, every newbie with a few weeks JavaScript under their belt are now free to declare themselves “iPhone developers”. It’s the same thing that happened with typographers when the original Mac 128K came out, and what will happen with animators when the final Leopard will come out – look for the equivalent of tags or impenetrable DVD menus in most of the new iPhone and Leopard apps. We’ll be pretty sick of moving GUI elements soon, and there’s no hope of standardizing web apps anyway. It’s the millennium of the amateurs… head for the hills!

Well, while I think some of it will be that bad – just as ransom-note typography was in the 80s, and garish pages assaulted us in the 90s (and still do, come to think of it), it’s won’t be all that bad. Apple will have new category for its Design Awards and there will be some cool, well-designed apps out. Let Darwin take care of the rest.

Leopard is delayed for 4 months – until October. John Gruber has a good analysis, as does Daniel Jalkut.

A couple of weeks ago I wrote:
Rainer Brockerhoff wrote:

Even so, people who have not seen anything of Leopard beyond some leaked screenshots wrote excitedly about a MacWorld release, then about a March release, then when their wild predictions aren’t confirmed start to moan that “Apple’s been having trouble getting Leopard out” and now, even, that “Leopard had reportedly been delayed until October”. I really hope that Apple will show more details before WWDC, but I won’t be too surprised if they don’t.

The reference was to this DigiTimes story, which I didn’t even want to link to at the time because it sounded so absurd. Well, looks like they got it right, although the excuse for the delay is the iPhone, not Boot Camp. Although this is not stopping some people arguing that one of things apple will do during the extra months is converting Boot Camp into a Parallels-style virtualizer – something I’d previously described as likely to be implemented in firmware, until they took the TPM out of newer Intel Macs.

In retrospect, it’s not too surprising. Unusually, Apple is releasing 3 major products this year – TV, iPhone and Leopard – and all run some form of OS X despite having very different target markets and form factors. (Also unusually for Apple, all 3 were pre-announced.) So far, only the iPhone hasn’t been delayed, and clearly Apple felt that delaying all 3 would be a serious PR loss. Ergo, putting people to work on the iPhone makes some sense, supposing Apple managed to avoid the mythical man-month effect.

It’s still difficult to assess what this means for the upcoming WWDC. Sure, a feature-complete build will be available there, but unless something revolutionary new thing is revealed, it may not have much impact. Launching the iPhone there won’t be a big thing for developers unless a SDK is announced. I won’t be able to go this, so it seems I won’t miss much…

Now that the waves around the iPhone have mostly died down, and we’re in a “silent period” between announcements, some further musings.

My earlier ideas about OS X in other products and a second-generation “tablet” device have percolated into the punditosphere. The trigger seems to have been the recent surge in larger or faster solid-state memory devices, as well as shipment of the first hybrid flash/disk drive. See, for instance, Jason D. O’Grady commenting about another analyst’s write-up:

There are numerous reasons why a diskless MacBook (or nanoBook) is the next logical progression of the notebook computer…

What’s interesting about the Reuters piece is that [it] claims that the nanoBook would run the stripped down, multi-touch version of Mac OS X that will ship with iPhone as opposed to the full-blown version…

In an included poll, however, 76% of voters said they’d want such a sub-notebook to run the full version of Mac OS X, and only 10% claim to accept with OS X (Lite). Others are skeptical of wider use of flash memory, even for larger iPods:

There is one brutally limiting factor to flash, though: cost. Flash is almost ten times more expensive than hard-disk memory. Although significant adoption of flash over the last 12 months has seen prices drop enormously, it’s still too costly to buy in the quantity needed for video iPods. Apple has a good relationship with its flash manufacturers though, and may secure a helpful price reduction it can pass on to consumers. But will that be enough to justify vanquishing the hard disk completely?

Still, I agree that prices are falling fast and that such a device may well be pre-announced at WWDC in June for shipment before the end of 2007. On the other hand, when so many financial analysts agree that such a device is in the works, it makes me suspect that they must be wrong…

Speaking of WWDC, only some radical holdouts (and a few financial analysts) still believe in an end-of-March launch of Leopard. I can’t say much about it because of NDAs; but to put Leopard on the market by the end of this month – meaning that, because of manufacturing and shipping times, it would be have to be ready about today – is impossible. Yes, some of the aforementioned radicals say that Apple has secret advanced builds in their labs and all the seed versions they sent out since last were just a cover. Hah. I’ll believe that when I see it; maybe not even then.

I just heard the news; it seems the rumors were right. This year’s WWDC is now officially set for June 11 to 15, 2007. As I said below, this further reinforces my belief that the availability of Leopard and of the iPhone will be announced simultaneously by Steve Jobs at the keynote – June 11 – and, very probably, that the Leopard DVD will be distributed to every developer after the keynote. Let’s hope an iPhone developer’s kit will be thrown in… and that I will be able to attend.

An Italian newspaper article quotes Dario Bucci of Intel Italia as saying that the iPhone uses Marvell‘s Xscale-derived CPUs. (Curiously enough, the current version of this article doesn’t show this part of the interview anymore…)

Well, who cares? Indeed, by now I agree with HiveLogic that the CPU is irrelevant. Marvell bought Xscale from Intel about 6 months ago. Xscale, in turn, uses some of the ubiquitous ARM cores that were rumored to be the iPhone’s CPU (as well as, probably, powering some other chips in there). But as the HiveLogic article says:

And now the iPhone uses yet another CPU, and we should still expect OS X to feel like OS X. Apple seems to be pushing the idea that the CPU shouldn’t matter to the user of an Apple product. And I think that?s why Apple isn’t talking about the iPhone?s CPU.

Right. With Leopard, Apple’s development tools support building apps for any combination of 32-bit, 64-bit, PowerPC (big-endian) or Intel (little-endian) CPUs. Since the gcc compiler supports ARMs and many other architectures, and the major stumbling block (the endian issue) has been solved, by now OS X can be safely assumed to run on nearly any modern CPU.

Now, in the past, I’ve been as prone as any to argue endlessly about the superiority of the PowerPC architecture (or of the 68K architecture for that matter) over x86, but for most practical purposes I have to admit all that has become a non-issue – especially for a device like the iPhone. I for one welcome our new <your architecture here> overlords, and that’s that.