Blog Post

Reading the tea leaves on app sandboxing in OS X

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Apple(s AAPL) 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

7 Responses to “Reading the tea leaves on app sandboxing in OS X”

  1. Weldon,

    Just wanted to comment on something specific you wrote:

    “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).”

    This is the exact opposite of Apple’s own expectations. The brains behind Apple’s Sandboxing tech (Ivan Krstic of OLPC Bitfrost fame) has a well-known aversion to dialogue prompts (Bitfrost doesn’t even request a password…) He used the political maxim of “if you’re explaining you’re losing” to expose some of his thinking behind this in his 2011 WWDC talk (available via ADC). As he saw presented it, he thinks that dialogue-box driven security is analogous to your car asking for permission to deploy its airbags…

    You should really take a look if you have an ADC account. It’s a great talk (“Introducing App Sandbox”, WWDC 2011 track 203).



  2. Apple wants to eventually get to a Mac app store only distribution system. It can’t do that untill most mac developers are in the store. So far the big boys are holdouts. It also needs to be able to shut out apps on a whim, hence the sandboxing, so when that door shuts to third party software on the mac, it’ll be easy. That day will come, don’t kid yourselves. Once mac software completely behind the walled garden, the merger of OSX and IOS can begin. One unified platform, completely controlled by Apple.

    • H. Murchison

      That’s not the point of the article at all Sam. The point was that the reliance of applications to the local filesystem are becoming more tenuous because of sandboxing. This is not necessarily for security but maybe able to usher in an era where I can walk up to any OS X device and log in and suddenly not only are my documents available but so are my apps. Walled gardens have nothing to do with it.

  3. Brilliant piece–covers key issues. I agree with your instincts… it’s to herd the cats into the iCloud corral. Alas, for those of us who want local, and nearly all local, actions, storage, programs, etc.

    Sandboxing, which, if I understand this properly, is the default and controlling system in the iOS on the iPhone and iPad. And it does limit inter-species (I mean, inter-app) communication. Which is often a shame.

    In any event, appreciate the thought and effort that went into writing a carefully crafted piece. Thanks!