Solipsism Gradient

So, half a dozen softwares are now out there that unlock the iPhone in various ways. In the simpler case, they allow the installation of various third-party applications and/or twiddling details. In the more complex case, they mess around with the various phone/SIM settings to allow the iPhone to be used with other provider’s SIM cards.

As I wrote before, Apple has apparently allowed this to happen by not implementing strict security measures. Now that the various unlocking techniques have stabilized, Apple has announced that an upcoming software update might cause “modified” iPhones to become “permanently inoperable”. Just a few days later, the iPhone update to version 1.1.1 came out; it featured the same warning in bold on its installation screen; and it did, indeed, cause some modified iPhones to lock up – the new vernacular is “bricked”, which I think somewhat of an exaggeration. Furthermore, the new software seems as tamper-resistant as the iPod touch software, indicating that Apple has checked out current unlocking techniques and implemented harder locks.

So far, all that was to be expected. What was, to me, unexpected was the reaction of some sectors of the press and of some users – mostly the same people who opposed the iPhone price cut, it seems.

Legally, it seems Apple is in the clear. The warranty and license agreement clearly say that any such tampering is at the phone owner’s risk. Surprisingly, some people seem to feel “entitled” to get warranty support even if they completely disobeyed the license! (Just as they felt “entitled” to have the price kept constant for a long period after they bought it, I suppose.)

The core of the argument seems to be “I paid for the machine, therefore I have the right to do whatever I want with it…” (I completely agree so far) “…and Apple has the obligation to give me full support, warranty and updates no matter how I mess with it!” Now here is where we part company. Sure, I suppose current consumer protection legislation may sometimes be interpreted that way (note I’m not a lawyer and less familiar with US legislation than with the Brazilian one); but you surely can’t pretend that Apple is a public utility or a non-profit charity.

Even from the technical standpoint, these expectations are unreasonable; allow me to explain this in more detail. The problem is one of “state“, in this case defined as ” unique configuration of information in a program or machine”.

In the first computers, the state of the computer was completely predictable when it was turned on: if it had Core memory, it was in essentially the same state it had when it was last turned off, and if the computer had reasonable power supply sequencing, you could just press the start button and continue. For more complex machines this was too hard to do, and the manufacturers declared that the machine was in an undefined/unreliable state after power-on, and that therefore you had to reload the software. For newer machines with semiconductor memory, everything was of course lost during power-off, and software reloading became equally necessary. To do so, you had to enter a short program in machine language using the front-panel toggle switches; this program, in turn, would read the actual software you wanted to run from a peripheral. This was the direct consequence of the machine coming up in a “null state”.

It wasn’t long before people thought of several ingenious ways to make this process more convenient. On the IBM1130, for instance, the hardware was set to read a special card from the punched-card reader, interpret the 80 columns (12 holes each) as 80 16-bit instructions, and execute them. The most commonly used of these cards simply repeated the process with the built-in cartridge disk drive, reading the first sector on the cartridge and executing it. Later on, the falling cost of ROM led to the boot software simply being built into the machine – the Apple II had a complete BASIC interpreter built-in, for instance. The apex of this evolution was the original Mac 128, where most of the system software was in the boot ROM – the system disk simply contained additions and patches. (The QI900 microcomputer I helped design in the ’80s had all system software, with windowing, multitasking and debugging, built into its ROM.) Here we had a well-defined “state” when the machine came up – it would execute a well-known program, and do predictable things, until external software came into play.

In the ’90s the limitations of this became apparent. OSes grew to a size beyond what could be stored in ROM, and no single Boot ROM could do justice to all models and peripherals (*cough* BIOS). Flash memory came up, the built-in software was renamed to “firmware”, and updates to that became commonplace. It was easy to “brick” a system if power went out or if you otherwise interrupted a firmware update before it was complete. In that event, a motherboard swap was usually the only solution, because the interruption left the firmware in a partial, nonworking “state”.

Consider now the iPhone. Its entire system (OS X 1.x) is built into firmware, mostly in a compressed state. This is expanded and run by the main ARM processor, obeying a built-in boot ROM. Supposedly, there are at least two more processors, taking care of network communications and of the cellular radio; each of these has its own boot ROM, and the radio processor has separate flash memory to hold state information regarding the SIM card, cellular system activation and so forth. One of these processors no doubt controls the USB interface to allow the main processor’s flash memory to be reloaded externally. Furthermore, every SIM card also has flash memory on it, containing the IMSI number, network identity, encryption keys and so forth, bringing one more source of complexity to the process.

In other words, you have a complex system of at least 3 processors interacting, each one with a boot ROM, two with flash memory containing state information. Powering up such a beast is a complex dance of each one waking up, testing its peripherals, checking its own state, then trying to talk to each other, then communicating to bring the entire system into a working state. Furthermore, the necessities of the cellphone system and of testing out such a complex piece of hardware mean that the iPhone must decide, on each power-up, in which of several states it’s in: factory testing, just out of the box, activated, reloading the main firmware, working, “plane” mode, and so forth. This is usually done by writing special values to reserved sections of the various flash memories, and of making sure they are always consistent with each other by checksumming and other technical arcana. Should they be found inconsistent, the system will probably try to regress to a simpler state and start over there, in the extreme throwing up its metaphorical hands and plead to be returned to the factory. Ideally, firmware writers strive to make it impossible to “brick”, unless an actual hardware defect occurs, of course; in practice, it’s rarely possible to envision all possible combinations of what could happen, and too few designers do assume a malicious agency is trying to trip them up at all times.

So, what do these various hacks do to unlock the iPhone? They rely upon bugs in the communications software, firstly, to make the system fall back into a state where it pleads for an external agency to reload its main firmware; cleverly substituted instructions then make it do new things. After several, progressively more complex, phases of this, new applications can be installed. Up to this point, only the main flash memory has been affected and installing a new software update will just bring the system back to the standard state. Now, one of the new applications may try to mess with the radio firmware; it will clear or set regions of it to bring the radio processor’s state out of step with reality, or even write bogus activation data into it.

Now, of course, the system’s state has been moved completely out of the state space envisioned by its designers. When it powers up, the state is sufficiently consistent – the various checksums check out OK, for instance – for the various processors to confidently start working. However, a few actual values are different from the intended ones – enough to let a different SIM card work, say. Now, if the hackers had the actual source code and documentation available, all this could be done in a reliable way. But this not being the case, they had to work by testing changes in various places and observing what happened, clearly not an optimal process.

Consider, now, the software update process. It assumes that the iPhone’s various processors and firmware(s) are in one of the known states – indeed, this is required for the complex cooperation required for uploading new software. If this cooperation is disrupted, the update may not begin – leading to an error message – or, worse, it may begin but not conclude properly. At this point, one or more of the iPhones processors may try to enter a recovery routine, either wiping the flash memories or to reinitialize them to a known state. No doubt this will be successful in most cases, and the new update will then be installable on a second attempt. However, the recovery may fail – since the exact circumstances couldn’t be foreseen – or it may be assuming false preconditions (like, a valid AT&T SIM card being present). The system will probably try to recover at successively lower states until falling back to the “can’t think of anything more, take me back to the factory” mode; or it may even lock up and “brick”.

Should Apple’s firmware programmers have tried to prevent this from happening? Well, up to a point they certainly did, as many problems other than hackers can cause such errors – electrical noise, badly seated or marginally defective SIM card, low battery, for instance. The system has to fail gracefully. However, it’s certainly not reasonable to expect them to specifically recognize and work around (or even tolerate!) the various hacks; after all Apple’s contract with AT&T certainly requires them to evidence due diligence in preventing that.

Firmware for such a complex system evolves continuously. The new 1.1.1 iPhone software seems to do many things differently from the original version, even though much of the UI is the same; same goes for the iPod touch software. Neither has been hacked as I write this. Did they now put TrustZone into operation? No idea; time will tell. My hunch is that Apple will eventually come out with an SDK for third-party applications sometime; the question is when. Perhaps after Leopard, perhaps at the 2008 WWDC. Does Apple need AT&T, or any partner carrier, at all? Maybe for now they do, and the unlocking wrangle will continue. In the long run, Apple will be better off with a universal phone that will work anywhere; possibly we’ll have to wait for the current generation of carriers to die before this happens. Interesting times.

Apple has announced a $100 credit to most (perhaps all) customers who paid the old prices for the iPhone and who are not entitled to a full $200 rebate. Previously there had been much whining and reports of uneven treatment for customers who bought iPhones more than 14 days before the announcements.

No wonder some customers and most analysts are confused. First the iPhone comes out at $599 (I’m talking always about the 8GB model, of course). Early adopters rush off to buy it while others say it’s way too expensive. 66 days later the price goes down over 33%. While most people reacted negatively to this, not all did.

Steve Jobs is right, in the technology business prices always go down fast and faster, and most people forget this is true on the component side too. With the first 700,000 iPhones sold, Apple did an excellent job of balancing costs, supply and demand. Now that the first rush is over, and with a second device coming out using many of the same components, their costs go down sharply and this has to be reflected in the pricing, especially in view of the holiday season. Had the iPod touch come out at $499 just to appease early adopters, it might have flopped in the season, and people would have complained as usual about Apple gouging customers with high margins.

PS: Of course, the geeky thing would have been to make the rebate proportional to days elapsed between purchase and announcement – $3 per day or so, but averaging this out to $100 for everybody is no doubt easier to do and is a good thing PR-wise…

Not that I’ve been overly interested in the new iPod announcements – my current G3 iPod (40GB), which I bought at the Paris Apple Expo exact 4 years ago, still works fine and still has some empty space. Battery life, even, is still a reasonable 6-7 hours. Can’t see myself buying a new iPod anytime soon; at least not for music.

Announcements like new colors and form factors are therefore not really relevant to me; Starbucks (huh?) and ringtones, meh. What’s interesting is the new iPod touch, despite the somewhat silly name. The base model is essentially an 8GB iPhone, but without the microphone, camera, BlueTooth and phone radio parts – it remains to be seen if they also took the speakers out. It’s also a little smaller in all dimensions, though the screen resolution is the same. At $299 this would cannibalize a significant part of iPhone sales, but this has been neatly counterbalanced by the 8GB iPhone price reduction from $599 to $399. And with the disappearance of the 4GB iPhone this should keep iPhone sales going well as before.

There’s also a $399 model with 16GB. Though Apple didn’t think it necessary to say so, the iPod touch of course is based on the same hardware/platform as the iPhone, running OS X and all. I suppose that all of the recent tricks to install extra applications will work on it. There’s certainly plenty of space for extra icons on the main screen, and the somewhat inexplicable omission of Google Maps will probably be the first thing to be corrected by users.

All this is certainly very positive to Apple stockholders, though the stock fell back to last week’s levels, as usual after announcements. In the long run, the new iPod will probably be seen as the first of the OS X tablets. The next generation should have a 640×480 or 1024×576 screen, and hopefully a built-in GPS device. Indeed, from all accounts, the only thing still holding such a device back is the unavailability of such a touchscreen at a reasonable price.

Finally, there’s no more excuse of “phone network security”; the new iPod should be the hardware part of the (hopefully) upcoming OS X development SDK. I expect that it will be announced at the end of October when Leopard and Xcode 3 come out.

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…

This is the latest (and, I hope, final) post about my hard drive heat problems. (All in a 2G iMac G5, 20″ – the last one without a built-in iSight camera.)

By a fortuitous coincidence my friends at Deltatronic offered me a 400GB Samsung HD400LJ SATA drive at a reasonable price, and I bought it. Reviews on this drive indicated that it was quieter and ran a little cooler than my previous Seagate drive, at the expense of being slower in some situations; well worth it for me.

After mounting it, I saw that the new drive has no convenient smooth surface on its face to mount the temperature sensor, so I took advantage of the cable length (which I had increased in the previous installment) and tacked the sensor onto the part opposite from the connectors, just for testing. It turns out that this is also conveniently out of the fan’s airstream, so chances were this would be the hottest part of the drive.

And indeed, after 10 days of testing the temperature sensor tracks consistently 4-5C higher than the internal SMART temperature – remember that, with the standard sensor mounting, this was the other way around. As a result, the drives were usually hovering right near their upper limit of 60C; not a desirable situation. With the new placement the SMART temperature oscillates between 48 and 52C, still not ideal but much better. The tradeoff is increased fan noise, which I don’t mind much – although I must be one of the few iMac G5 owners who doesn’t. I was hoping the new iMacs, which have a larger fan directly below the drive, would run lower temperatures, but from what people say, they decided to lower fan speeds at the expense of maintaining the 58C operating point.

The Google paper (pdf) about drive reliability did conclude that temperatures weren’t a significant factor, but the majority of their drives ran in the 25-40C range, with almost none over 50C. Their graph does show that failures begin to rise when you get over 45C, so I prefer to err on the side of caution here. I couldn’t find a single working fan control program for the iMac G5 but there seem to be several for the Intel iMacs – I’ll certainly get one when I upgrade, perhaps next year.

Currently, I have a G3 iBook/600MHz which can run any Mac OS X between 10.0 and 10.4; a PowerBook G4/1GHz; the iMac G5/2GHz, which is my main working machine; and a Core Solo Mac mini with 512MB. I only lack a Core 2 Duo machine to have all CPU platforms of the last 10 years for compatibility testing. (Justifying all these Macs to my wife is, as yet, an unsolved problem…)

Since I now have two left-over SATA drives without a convenient external case to use them in (not to speak of several older PATA/IDE drives), I also bought a Cables Unlimited USB-2110 drive adapter. This is a small cable header which plugs into both 3.5″ and 2.5″ IDE drives and also (over two extra short cables) into SATA drives, with an external power supply. Works quite well and I now can switch among my old drives for backups, and easily test others that come in.

After Leopard comes out with Time Machine in a few months we’ll probably see a boom in external RAID or NAS drive cases, and then I’ll have a place to put the two SATA drives. None of the solutions currently on the market quite fill my requirements. Ideally I’d like a drive case that has USB2, FireWire and gigabit Internet interfaces and with space for at least 3, ideally 4, internal SATA drives…

Wow, over 20 days without a post, and I didn’t notice. Yes, I’m still here… though not that much “here”, but offline. Here’s some of what happened.

About 5 months ago I posted about my temperature problems with the hard drive inside the iMac G5. I’d solved them somewhat preliminarly by buying a new (and supposedly less-hot) drive and putting some heatsink paste under the thermal sensor. Here’s the sensor picture again:

Well, about 3 weeks ago I left the iMac overnight, downloading some large file. I came back to it in the morning and it had frozen, and I heard some faint beeping which appeared to come from the UPS I keep just behind the machine. I turned everything off, waited half an hour or so, and restarted – everything worked fine but in two hours it froze again when the faint beeping started. This time, I could ascertain that

1) the beeping was actually a buzzing coming from the hard drive

2) the hard drive sensor said a reasonable 53.5C

3) the hard drive SMART sensor said the drive was actually at 61C!

Whoa. Something clearly had changed since February, when I said the average difference between the two sensors had shrunk to 4C. I did some cautious testing over the next week. Indeed, the external sensor never went over 53.5C – and the fan begins to rev up only at 54C, but it never got there. The sensor actually tracked the SMART value reasonably well – to 1C below 50C, to 3-4C until 53C, but then the internal temperature just soared. As soon as that went to anywhere over 59C, the drive froze and started buzzing. After cooling off everything started working again.

Up until last weekend, I tried changing the heatsink paste – no change. I tried out several fan control programs, none worked with the iMac. I tried finding out some software way to kick the fans up, but didn’t have too much time to really study the problem. A friend gave me a small flat fan from a laptop which I tried to mount inside, but there’s no space available anywhere near the drive.

About the only thing that helped a little was mounting a couple of other small fans blowing into the air intakes below the iMac – I glued them in place with some gaffer tape and ran them off a spare 12V supply. But it clearly wasn’t a definite solution; it sort of worked for a few hours as long as I kept the CPU speed on “reduced” and didn’t open too many programs at a time. I suppose someone should make a supplementary fan unit sucking air out of the iMac, like we had for the MacPlus… I wonder if the current Intel iMacs also overheat?

Anyway, last weekend I gave up and performed minor surgery on the sensor cable, making it about 10cm (4″) longer. The main trick was to convince it to part company with its original mounting place – people who’d performed this procedure before recommended using a “thin blade”, but none I had were thin enough. The optimum solution is a length of dental floss. If you try this, work it under the double-sided white tape that glues the sensor board to the metal bracket, so the tape stays stuck to the board. I got it off cleanly with its adhesive properties still intact.

I experimented with a few locations, but the only easy one was a small flat space between the drive spindle and the PC board. In that location, so far as I can see, the two temperatures track each other to 2C – usually even to 0.5C. One shouldn’t check the SMART temperature too frequently or the drive never sleeps; 20 minutes seems OK. The temperature hovers between 52C and 57C under normal workload… still not ideal. But the fans kick in and the iMac now sounds louder, much like it did when it was new. I suppose I’m the only iMac G5 owner who’s glad to hear loud fan noises…

However, today, just when I was finally ready to start working on my usual stuff again, the @#$%^& thing froze again – and while both temperatures were at 52C, where it should work. So either I need to reformat, or install air conditioning, or get a new drive while the current one is under warranty. Or all of these. There goes another weekend…

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.