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.