The Sandbox and the Playground: Changing Rules for Software and Developers
November 29th, 2011 | by Kendra Albert | Published in Future of the Internet | 8 Comments
Update on 2/23/2011: Apple has pushed back its deadline for OSX sandboxing to June 1st, 2012. The deadline was originally November, 2011, but was pushed to March 1st in early November. Although Apple claimed that this change was to give developers time to integrate new permissions from an update, it does follow the announcement of Gatekeeper, which might be a partial substitute for sandboxing.
During the 1990s, PCs ran whatever software was installed on them. Users bought software (not yet called apps) from physical stores or got a copy from their friends. They stuck the CD in the drive, and went through the installation process, or dragged the application to their application folder. The code was “signed” by the developer (by being from a box), or not at all. The operating system didn’t stop and ask “are you sure,” no one typed in a root password, and the applications were limited only by what their programmers had decided when coding. Those were the days of the playground, not the sandbox.
The playground had problems. Software with malicious code or bugs could hijack your PC. Other users could tamper with your files. So sandboxing (although not known yet by that name) was born. Starting as far back as creating separate user directories, to as recent a development as cloud data storage, steps have been taken to make the user’s personal data and computing cycles safely under lock and key – sometimes with the key held by the user, and other times by the operating system maker. When Windows Vista was released in 2009, it tried to solve this problem with “allow” dialogs, which would pop up when an application tried to take actions without the user’s permission. This solution was mostly considered an annoyance, not a feature, as the parameters that caused a dialog were broad and users just clicked through to allow instinctually. Mac OSX’s requests for passwords before installing applications are just another step down this road – meant to put users in control of their own computing destinies, and less dependent on the good will of developers.
On smartphones, things have gone a different way. We take for granted that applications haven’t been able to access all the features of the phone. Android users view a permissions screen that tells them exactly what to expect from an application – whether it can take photos with the camera, keep the phone from sleeping or access GPS. Apple screens its applications on the way into the iOS App Store, making clear what parts of the phone they can get to, and limits users to apps from the store. All of the app’s files are required to stay in their own little corner of the file system. This process of requiring developers to encapsulate their applications within one folder – and to clear with someone for access to things outside – restricts the potential for harm. This is one version of the phenomenon known as sandboxing. Sandboxing, on the most basic level, is a security measure used to run code that’s not trusted. Rather than allowing software or applications to play freely across the machine, sandboxes restrict them to very specific resources, mitigating the damage they can do.
For years, it’s been a standard on mobile platforms and web applets. For example, the Bejeweled game that you’re playing in one of your Chrome tabs doesn’t have any way of accessing the Word document you are supposed to be working on. In fact, your Chrome tabs can’t even access each other, preventing badly coded webpages from crashing your entire browser. These apps can play in their own sandboxes – but not all over your phone or PC. The same wouldn’t be true for Bejeweled if it were a regular PC app – it’d be free to rummage through everything on the hard drive, surveilling, modifying or deleting at will. Knowing that, it’s a marvel that serious viruses didn’t appear sooner and more often.
For phones and web applets, sandboxing is ideal. After all, even you, the user, don’t interact with the underlying file structure of your iPhone or Android device (without jailbreaking), and you certainly wouldn’t want to open an online game and have it be able to make changes to your Word document. Sandboxing has serious security advantages – if programs have to lay out in advance what kind of access they get to a device, and are limited to only specific actions, an app that “goes rogue” or is compromised by malware can no longer cause the same harm to the rest of the user’s data. Similarly, a piece of compromised software can’t run processes in the background that it wouldn’t be able to run anyway – limiting potential damage.
Sandboxing usually also includes signed code, or code that is cryptographically linked to a specific developer license. Not only do Apple and Google know exactly what parts of your phone the code can access, they also know which developer produced the code. Apple’s signature program is run through its developer program, which is tied to a yearly fee, where as Google’s requires some information from the developer, but not a specific license as such.
Enter the Mac App Store
So as things stood previously, most PCs had some steps towards protection against rogue software, but hadn’t taken the sandboxing route. Browsers and smartphones sandbox processes, but different smartphone platforms have different ways of involving the user. Apple’s iOS doesn’t involve the user, and all permissions are handled at the App Store level. Android apps can either be downloaded from the Android Market or from third parties directly. In both cases, a list of permissions are visible to the user and the applicatiosn are sandobxed where they are still sandboxed.
In early November, Apple announced to developers that it was pushing back its deadline for Mac Store Apps to implement sandboxing to March 1st, 2012. This makes the Mac App Store platform much like the Android Market – users have the option to install applications from elsewhere, but all applications that go through the market must be sandboxed. Although the requirements were supposed to take effect earlier this week, the pushed-back date reflects some of the serious problems MacOS developers were running into in making their applications compatible with Apple’s new rules.
Apple’s change marks a huge departure from the way development and code has operated in the past. As discussed above, software on the PC of the past had access to a playground, controlled only by the user’s discretion. Although Apple’s new OSX Lion has supported sandboxing since its release, Apple is using its distribution platform to require that apps follow their new security rules. The App Store push will certainly increase the amount of applications secured.
Although there may be net gains for users who are concerned about the security of applications downloaded from the Internet, there is the potential to limit the types of applications that companies will bother trying to distribute. Programs as widely used as antivirus software and backup utilities are not distributable through the App Store platform, due to the rule against root access, and in the larger scheme of things, Apple’s concerns about security. This means no Norton Anti-Virus, no Dropbox and no MacZip. At this time, distribution outside the store is not problematic; in fact, most large-scale developers seem to not be early adopters. However, as customers become more comfortable with the App Store process, that might change.
OSX Sandboxing in Depth
The sandboxing requirements make applications downloaded through the Mac App Store limited to a very specific set of actions. Ars Technica offered an in-depth discussion of OSX Lion’s sandboxing procedures in its review of the platform, and here are the basics
To play outside the sandbox, applications need “entitlements” that represent permission to access outside tools. Entitlements can include taking photos with the camera, responding to mouse gestures or creating network connections. Lion has about thirty built-in entitlements for applications to request, created and managed by Apple.
When submitting their software to the app store, developers lay out each process that an application might run, and then explain the privileges each one might have. For example, an application like QuickTime decodes video, runs audio, and accesses closed captions from a folder at the same time. Each of those different tasks is split into a sub-process with a different set of permissions – laid out by the developer before submission to the App Store. So the video decoding sub-process of Quicktime has access to the user’s screen and graphics card, but not audio settings. The audio sub-process doesn’t have access to the video card. These divisions keep the software from using system resources without permission. Unlike platforms like Android, users won’t see these processes or entitlement – they’re just for the purpose of Apple approving the software.
Users do have special powers for sandboxed applications – any action that is specifically initiated by a user doesn’t need to be okayed by Apple in advance. They can initiate special, non-entitled actions, like opening a list of recent files or saving documents elsewhere in the file system. Apps can build in these requests without asking for entitlements for them, knowing that the user is going to activate and oversee the process.
Concerns from Developers
Pushback from the development community has come from many fronts. Some developers, such as Recent Redux creator Tim Schroeder, feel that the entitlements that the apps can have do not represent the full spectrum of developers’ needs. There are two very specific use cases that are no longer possible for App Store apps – using AppleScript and file system management
Most users probably don’t interact with AppleScript on a regular basis, but it allows for many of the processes that make software work. Notification systems like Growl, which standardizes user notifications across multiple applications use AppleScript, as do hundreds of apps that allow for better music management in iTunes. On its most basic level, AppleScript is a tool developers use to exchange information between applications, and can produce Apple Events, which make programs take actions. It can run repetitive tasks, print from one application to another, or open applications. However, it also can automate file transfers or photo editing – and will no longer be usable by sandboxed applications. Instead, AppleScript will theoretically be replaced by APIs (application programming interfaces) that allow developers (and Apple) to have better control over application interaction.
Matthias Gansrigler, a developer responsible for applications including ScreenFloat and Yoink, explains how sandboxing could, without a new API, destroy one of his existing pieces of software. GimmeSomeTune (GST) downloads lyrics and album covers, as well as displaying iTunes info in a customizable window. To do those things, GST depends on a connection to iTunes via AppleScript – it extracts information about songs that are playing and uses it to download lyrics and cover art back to iTunes. Without an API, and with Apple eventually sandboxing iTunes, GimmeSomeTune will no longer be able to access the song titles it needs. Gansrigler notes that Apple has not sandboxed iTunes yet, but with it on the horizon, he’s stopping development on the software now.
File system management is the second big field that developers are concerned about. There are many existing systems used by corporations or developers that support version control or sorting of code – and they work in the background in the file system without the user’s consent. Similarly, SSH clients or FTP apps can no longer show real time file trees – which means that all moving of files or downloads must go through the open dialog. To paraphrase an Apple ad, there’s no entitlement for that.
And to make things worse, some of the entitlements are currently temporary, leading developers to be concerned that their software might break after said entitlements are revoked. Apple has promised to provide APIs to replace the temporary entitlements, but it’s not clear when those will be available. In the mean time, developers are in a terrible state of flux – trying to decide whether to continue to put time into applications that may not be able to exist by March.
Independent of the concerns about APIs and entitlements is the uncomfortable truth of the App Store as a completely new way for developers to interact with customers. Although in previous years an OS upgrade or an update could break software, those were rare to the extreme. If an application worked on a computer, it would continue to work. Now, Apple’s role in the development process means that developers have to actively coordinate with Apple to keep their software from breaking – and a slight change in the entitlement system could destroy all of the tethered software. Apple had made itself a controlling party in the application wars – and the consequences of that are still unknown. This sandbox is under the baleful eye of Apple as playground monitor. Given Apple’s willingness to ban security researchers like Charlie Miller from developer programs for publishing security holes, this increased control might not be the security boon anyone hoped for. As if that wasn’t enough, flaws in the sandboxing system have already been reported.
Trading Generativity for Security
Sandboxing represents a true security/generativity trade off. As Jonathan Zittrain said in Chapter 7 of The Future of the Internet and How to Stop It, “Most fundamentally, many of the benefits of generativity come precisely thanks to an absence of walls. We want our e-mail programs to have access to any document on our hard drive, so that we can attach it to an e-mail and send it to a friend.” Applications downloaded from the Mac App Store, in contrast to ones from the generative Internet, may not have these capabilities.
Sandboxing can prevent some damage from an app bound and determined to wreak havoc, but sandboxing is a phenomenon independent of the App Store: Mac OS could implement it with or without Apple screening the software up front. Certainly, not all software that runs on Mac OSX is downloaded through the app store. But as The Unofficial Apple Weblog (TUAW) put it, “There’s also the fact that any discussion that begins with ‘The Mac App Store isn’t the only way to get apps on a Mac’ inevitably ends with the ominous pronouncement ‘yet.’”
Furthermore, there are issues on the development side of generativity. It seems unlikely that developers who are concerned about the market share will develop two versions of the app – (one that’s sandbox safe for the App Store and one that includes extra features that won’t work in a sandbox). As a result, sandboxing might dumb down the feature set available to even those who choose to grab their applications from the Internet. Once programmers are playing in the sandbox, there’s little reason to develop for playground-level access again. Reactions have been slow but scared – app-makers are uncertain as to what a sandboxed future means for their applications and for their distribution.
Even in the short term, where both the App Store and regular distribution methods co-exist, Apple’s sandboxing requirements are a big deal. The uncertainty about the existence of longstanding Mac programming methods like AppleScript and Apple Events, combined with the fact that no one is sure exactly how much business the App Store will do means that the impact is totally unknown. It seems unlikely that Windows 8 or other OSs will follow suit, given that Microsoft hasn’t been pursuing the same sort of distributional model, but the new tethered nature of these applications is a significant change from the way PCs have previously operated. The only thing that’s sure is that Apple would like the future of the Mac platform to be a sandboxed one, and consumers and developers will have to adapt.
12/7/11: Edited to incorporate corrections from the comments re: Android code signing and permissions.



November 30th, 2011 at 11:32 am (#)
[...] Security is also a factor—consumers are willing to consign control over their code to OS vendors when they see so much malware out in the wild. There are a variety of approaches to dealing with the security problem, some of which include a phenomenon called sandboxing—running software in a protected environment. Sandboxing is soon to be required of Mac App Store apps. More information on sandboxing, and a discussion of its pros and cons, can be found here. [...]
November 30th, 2011 at 2:46 pm (#)
What’s better for the user, an unsandboxed app bought/found in the wild, or a digitally signed application, also unboxed.
Obviously its better for security to have applications signed. Sandboxing adds another level of security.
Put another way, Sandboxing stops other malware from taking over an app and using it for bad things, while signing an app makes it far less likely that the app itself is a baddie.
There are no? cases of any third party software hacked to get into the OS. Its not a big win, unless almost everyone has and runs some popular title. (e.g. Chrome).
There are cases of unsigned third party software that has turned out to be actual malware.
On the March 2012 deadline: It does not even make logical sense. As far as Apple says only updates will need to be sandoxed. So old, buggy apps can stay as long as they don’t update themselves.
Also as others have pointed out, there is no way to sandbox something like Xcode, offered on the App Store.
Total disaster.
November 30th, 2011 at 3:28 pm (#)
Chillax, all the creative types will go to Linux and then because all the best apps (And sane permissions management) are on Linux the rest of the world will follow.
November 30th, 2011 at 5:55 pm (#)
I understand the security/generativity tradeoff. But as tech becomes more and more integrated into our lives, shouldn’t we be fine adding more security?
Let’s say that the iPhone 6 can integrate with my car and my apartment. I want my iPhone apps carefully sandboxed so that some program I downloaded can’t access my car’s engine, or my house’s thermostat, for instance.
December 1st, 2011 at 12:59 pm (#)
Applescript is still usable. It’s more that you can’t have an application that sends general Applescript (that is to arbitrary programs). But you can have an application that just sends Applescript to iTunes. This is more a problem for macro or scripting services like iKey, Quickeys, or Fast Scripts.
Modifying applications in a more robust fashion though is problematic, although apparently people are finding ways to hack around this. I believe that’s what Default Folder X does to work with sandboxed apps. Although I’m honestly not sure how they exactly got it to finally work with sandboxed programs.
December 7th, 2011 at 10:09 am (#)
The statements:
“Of course, apps distributed through the Internet and not through the Android Market are not signed, which is one of the reasons why Android platforms have more malware.”
and
“Android apps can either be downloaded from the Android Market, in which case, a list of permissions are visible to the user, or from third parties directly, where they are still sandboxed, but the code is unsigned and permissions are not visible.”
are simply wrong.
All Android apps must be signed. The OS will not run an unsigned app, even if it is downloaded directly through ADB (a tool for developers to communicate with the phone over USB) or built in to the firmware.
Of course, there is no rule for an app to be signed by a certificate issued by some central authority that verifies the app makers identity. This is true even for apps in the Android Market, and it is up to every developer to make his own certificate for signing.
As for displaying permissions, it can only be avoided by installing the app via ADB.
This is something regular users rarely do. It involves installing the Android SDK and using command line tools, or having the app sources and running it from Eclipse IDE.
If a regular user downloads an app through the browser, or tries to install an app from the SD card via an on device file manager, he is still prompted with the permissions screen and can choose not to install the app, in a way almost identical to installing an app from the market.
December 7th, 2011 at 7:59 pm (#)
Lev,
Thanks so much for your comments. A lot of the information I found about Android signing and permissions was unclear and or sketchy, so I appreciate your corrections – and have edited the piece to reflect them.
Kendra
December 11th, 2011 at 5:48 pm (#)
[...] La sécurité est également un facteur à prendre en considération. Lorsqu’ils voient tant de logiciels malveillant dans la nature, les consommateurs peuvent vouloir déléguer le contrôle de leurs programmes aux vendeurs de systèmes d’exploitation. Il existe une grande variété d’approches pour gérer la question de la sécurité, certaines impliquant l’utilisation d’un bac à sable, c’est à dire d’un environnement protégé à l’intérieur duquel s’exécute le logiciel. L’exécution dans un bac à sable sera bientôt obligatoire pour les application de la boutique pour Mac. On trouvera plus d’informations sur le sujet et une discussion sur ses avantages et ses inconvénients, ici. [...]