More on iPhone sandboxing

| Comments (3) | SYSSEC
Nick Weaver suggests that the real "security" motivation for the sandboxing in the iPhone is to preserve the security of Apple (and Cingular's revenue stream):
The sandboxing depends on the objective...

Since the objective is to allow the cellphone company to keep charging discrimatory pricing based on traffic intent (EG, ~80 Mb/$ for bulk best-effort data, but .2 Mb/$ for SMS messages which can actually be worse-than-best-effort), the same origin sandboxing is the perfect policy.

After all, an IM client, at 80 Mb/$ would really hurt the income of the phone company when they could have you sending SMS instead.

Admittedly, this is a fairly plausible-sounding theory (though it's worth noting that AT&T does seem to offer an unlimited messaging plan), unifying, as it does, the sandboxing, and the various pieces of functionality (IM, Flash, turning MP3s into ringtones, etc.) that Apple seems to have decided to omit. But let's imagine for the moment that Apple isn't just trying to extract maximum revenue, but merely to make the iPhone work as well as possible. What sort of sandboxing would be most appropriate then?

In that case, you'd be mostly looking to ensure that 3rd-party apps (henceforth 3PA) interfere with the smooth functioning of the phone native apps (NAs). At minimum, you want 3PAs not to be able to crash the phone. Of course, this functionality is provided by pretty much any modern multiprocessing operating system, and is all you'd really need for most of the apps one the iPhone (Web browser, address book, maps, etc.) But for real-time apps (especially telephony), you probably want better guarantees. In particular, you want to avoid:

  • 3PAs interfering with NA's access to the processor.
  • 3PAs interfering with NA's access to the network.
  • 3PAs interfering with NA's access to the speaker and microphone.

Note that in all of these cases you don't want to deny the 3PA access to the network, just to ensure that the NA gets priority when it needs it. This can be sort of a tricky engineering problem at times but is far from insoluble.


I keep seeing people use IM as an example of something you can't do on the iPhone, but there are several webby Jabber clients - e.g.

Tony, yes there are a bunch of web XMPP clients. The best ones are probably going to be in Flash (no iPhone support). To work *well* as an IM client, though, you would really want a real application running on the device. You'd want to be able to hook into the address book, phone on- and off-hookedness, camera, and GPS (which it might have one day).

I don't think the resource allocation problems are really terribly tricky here, since you have a known upper bound on the amount of system resources the phone system itself might need, and I'd imagine those are relatively small. A trivial solution would be for the scheduler to reserve some percentage of all time quanta for phone operations, and let non-RT applications all compete on equal ground for the remaining timeslices and pages.

Apple really should have already solved this problem anyway - would you want your phone quality to suffer if you decide to open an large web page on the browser and it takes a lot of time/memory to render? Just because Apple wrote it and included it in the OS image doesn't imply that it is not capable of interfering with calling.

(Do you mean to write "do not" before "interface with the smooth functioning ..."?)

Leave a comment