The Sandbox, Pro and Contra

By uliwitness

Blog sandbox


With Lion, Apple has introduced the “Sandbox”. Essentially, it is a way to un-break the unix permission model for the internet age. In ye olde days, user accounts and permissions were designed to prevent one user on a big mainframe from screwing with the files of another working on the same mainframe.

But in this internet age, our user account runs a lot of code that doesn’t come from us: Scripts from web sites, applications a distant acquaintance e-mailed us … While we should be careful to not run untrusted software, the matter of the fact is that we often have no choice, and when we do, we might not have enough information to make an educated decision.

When we run a screen saver, we run it with certain expectations: It should save our screen, not access our address book. It is time that these expectations get formalized in code and property lists, so the computer can enforce them for us. That way, even beginners can be protected.

How does it work?

In short, your application gets locked out of a number of “sensitive” areas. That includes the file system (except for a few places like your Preferences file and your Application Support folder), and also inter-application communication (e.g. AppleScript and other ways of accessing/talking to other applications). However, this happens transparently to the user. If the user drags a file on your application or its icon, or selects a file in an open panel, a temporary exception for this file is made.

It becomes part of your application’s sandbox (at least for a while — a restart of your application will exclude it from the sandbox again). Similarly, while your application can not communicate with other applications, the user can run an AppleScript in script editor, and *that* will be able to access all the applications it likes.

This means that, if a fake screen saver wants to e-mail your address book to an e-mail harvester, it will not be able to.

But my application uses AppleScript to …

This is a problem for those developers who want their application to run a script (e.g. automatically to import data from elsewhere). While I agree that’s annoying, a lot of the things developers do with AppleScript are workarounds for other issues (like the folder path example here). Chaining together applications is an engineer thing to do, and often causes bad usability. Users prefer a complete solution.

I hope many developers will consider banding together with developers of related tools, and do something not unlike Coda (Panic’s Transmit engine, The Coding Monkeys’ SubEthaEdit text engine). That avoids all the inter-application communication, gives you better control over the user experience (including sensible error messages instead of cryptic messages from AppleScript), and will probably make you Apple’s favorite child.

I can understand how Apple might want to bolt down security and instead provide dedicated API. Of course, if you’re the only one who needs the clicked Finder window’s folder, they might just not spare the manpower and you’re screwed. But I can understand their priorities, even if I only partially share them. And the above usability arguments may work as an encouragement for Apple to continue down this path.

Applications as entitlements

However, I do think that Apple should be flexible. Sandboxing will be mandatory to get applications approved for the Mac App Store in a few months. While you will be able to get exemptions for some of these restrictions, they are called “temporary”, which means what Apple giveth, Apple taketh away again. If they giveth at all.

Therefore, it would be great to have applications as entitlements: I.e. someone who needs to AppleScript the Finder could just add a entitlement, and then the user would get notified of that on installation. That way, if I install a screen saver and I get asked if this may access the address book, I know something is wrong. If it doesn’t ask for the address book entitlement, the address book API just wouldn’t work. Security. (Of course, there needs to be more granularity for the address book in particular, I would give applications access to my “Me” card, but not the rest of my address book – bad example).

The advantage of this approach is that Apple’s reviewers would just have to look at the entitlements to find out whether someone is doing something freaky. And if you used an unusual entitlement, Apple could request clarification, and then either require the use of better API, or reject, or accept.

It may still leave us at Apple’s approval mercy, but it is at least flexible enough to allow for many utilities to be re-added to the app store.

What can we do?

File bugs. If you like one of my suggestions above, feel free to request such behaviour from Apple. It will probably be marked as a duplicate, but it will get counted. But make sure you file the bug not just as a general mechanism, but in what way it applies to your application. When I talked to some Sandbox engineers at WWDC, they seemed very interested in accommodating our needs. Whether they will be able to do probably depends on what their superiors decide, but we have the engineers on our side. Even if you just write a short bug report, it will help. Besides, you can’t complain if you haven’t at least put your opinion on record.


2 Comments Leave a comment

  1. Nice write up. I agree that the ability to specify apps as entitlements could be very handy. I’ll be filing my own bug on this shortly with some suggestions on how my apps could make use of it.

    There’s a couple of points I think should be clarified in your text though:

    1. Sandbox permissions for recently opened documents do persist across app restarts. I think it’s limited to the contents of the “Open Recent…” menu item.

    2. Because the sandbox is invisible to users, an app (or to use your example a fake screensaver) could easily harvest your address book if it isn’t sandboxed. In this sense, it gives users a false sense of security. Up until sandboxing is mandatory across the system anyway.

    • Well, 1 is not a general-purpose persistence mechanism, so I left this out on purpose. 2 is a valid point. But you’ll agree it will probably be fixed with time. Even if just by adding a scary warning alert saying: “This application is not sandboxed, and could possibly damage your computer.”

Share your thoughts