Reading the tea leaves on app sandboxing in OS X

Apple has pushed back, for the second time, the date by which all apps submitted to the App Store must be sandboxed in OS X. While the original deadline was moved from Nov. 1, 2011, to March 1, it has now been pushed forward again to June 1. Sandboxing, a security measure that isolates applications from the rest of the systen they’re running on, has been a controversial measure because it imposes rather strict limitations on what Mac software is allowed to do that runs against long-held traditions.

The delay itself has been greeted with mostly positive reactions from developers, who are thankful for the additional time to adapt to this new approach even if they are still anxious about the long-term implications. Chris Foresman wrote a great summary of sandboxing, Daniel Jalkut of Red Sweater Software covered some of the issues that face developers of Mac software, and Manton Reece, developer of Clipstart, explained why he is dropping out of the Mac App Store to avoid sandboxing entirely. Most discussion of sandboxing has focused on the security implications of the new approach. However, I think that Apple may be playing a long game here that goes far beyond incremental improvements to the security of OS X.

Sandboxing: Security is not the end game

I don’t mean to imply that security is not an important consideration. It is. The problem is that sandboxing is only partially effective as a technique to improve security simply because outright malicious software won’t use it anyway. Wil Shipley of Delicious Monster wrote an excellent essay on the limitations of sandboxing as a security measure. Gatekeeper is likely to be s more effective security measure. So if sandboxing is not the last word on the future security of the Mac platform, what else might be going on?

What use could there be for a shift in programming conventions that requires apps to assume that all their files and settings are held in their own isolated container? That requires developers to carefully document when, where and why they need to reach out of their sandbox. That puts the OS in charge of allowing apps to access shared resources instead of unfettered access to the whole filesystem. What use is there in breaking long-held traditions of using arbitrary file access to enable shared settings? Why remove the ability to talk to other apps through Apple events?

It is not a far stretch to consider that this shift in approach might have a connection to Apple’s long-term plans to make iCloud the center of their strategy for the next decade. Apple intends for developers to move away from reliance on direct access to all of the nooks and crannies of the local filesystem on the computer and instead package up their files using the container approach. Self-contained sandboxes are more easily copied and moved between machines and are easier to back up. More and more, applications interact with online services across multiple devices. If your digital “stuff” is strewn about the cloud and across a couple of Macs (work, home, desktop, laptop) as well as multiple mobile devices like your iPhone and iPad, a dotfile on your computer might not be the best place to store settings anyway. Sandboxing could be a step towards abstracting away the local filesystem in favor of cloud-based storage.

The long game of sandboxing

While we don’t have answers now, there are a few areas to pay close attention to over the coming months as Mountain Lion moves closer to release and iOS is updated as expected later this year. (WWDC this summer will be interesting.)

The first feature to watch is entitlements, which are the list of permitted actions apps are allowed to perform from within the sandbox. Apple has expanded them a bit in Lion 10.7.3, but developers would like more. Daniel Jalkut thinks it is urgent that Apple address the current scope of entitlements. “The number one broken thing about sandboxing as it stands today, is the list of entitlements is simply too limited.” Further refinement of the available entitlements is likely, but it will be more interesting to watch where Apple expands the access granted to sandboxed apps. Will there be more direct access to places in the filesystem? More access to hardware features like serial ports? Or just more refinement to the iCloud APIs? Entitlements will be a clear indication of Apple loosening up on app restrictions or sticking to their guns.

The second area to watch is to see what Apple will do to explain sandboxing to users. If this is truly a security-focused measure, I would expect to see more prompts in OS X about what applications are asking to do (or which entitlements they have requested). If sandboxing isn’t meant to keep users better informed on what apps can and can’t do, then I would suspect that sandboxing is more about corralling developers to interact with the system in ways that can be abstracted or redirected to iCloud.

The big question in my mind, is what will be done with inter-process communication? URL schemes, as we have in iOS, are certainly much more limited than Apple events, even with call-backs. However, URL schemes also provide an abstraction where they could be made to work in different contexts, such as on a computer, on an iPhone or in a web app. Surely, something else is coming to meet the need for automation, workflow scripting and sharing between apps if the Apple events system is being phased out. This will be a key area to watch over the next few months to see where the wind blows out of Cupertino.

I can’t shake the feeling that sandboxing is part of a much bigger play by Apple and that it connects to their strategy for iCloud. While all we can do at the moment is speculate, I feel certain that developers that can suss out the larger meaning here and see a few steps ahead of the rest of us have a real opportunity. We saw companies that pulled ahead of the pack with the first generation of mobile, connected, and social apps for the App Store. There is a similar opportunity here with sandboxing and iCloud to try and skate to where Apple is looking to send the puck, to borrow a phrase from Wayne Gretzky, instead of simply complaining that the puck is not where it’s been.

Tea leaves thumbnail used courtesy of Flickr user xJason.Rogersx

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.