What Apple's sandboxing means for developers and users

Recently Apple announced to developers that beginning in March 2012, all applications submitted to the Mac App Store will require support for Apple's sandboxing routines.

Since Apple initially scheduled to implement this requirement in November of this year, this announcement is nothing new and is more of a timeframe shift than anything else; however, it still raises questions and concern over what this means for developers and end users.

What is sandboxing?
Sandboxing is a security technique that acts as a last line of defense against exploited, buggy, or otherwise compromised applications, which Apple is implementing to ensure programs distributed through the Mac App Store are as safe and secure as possible.

The way this works is a virtual barrier called a "sandbox" is set up around a running program that isolates it from the rest of the system. The system cannot do this itself, so the developer voluntarily turns on sandboxing for its program. When enabled, the program will by default have no access to the system resources, including the network, user documents, the ability to open and save files, access to peripherals such as printers and cameras, and access to locations, address books, calendars, and similar central services.

To then meet the program's needs, the developer includes a sandbox rule called an "entitlement," that allows the program to access the needed resource defined in that entitlement. The entitlements are managed by Apple, and thereby allow Apple to centralize how sandboxed programs can access resources in OS X. The developer can add as many entitlements as he wishes to give his program as much system access as is necessary; however, the idea is the developer only enables the entitlements that are needed to allow his program to run.

Sandboxing of a program is done by the developer for the benefit of the community, to prevent his program from inadvertently accessing files it was not built to access (which may happen with bugs, or if the program is exploited by a hacker). The developer does not have to do this, but if not then errors in the program may result in a larger problem than a merely hung or crashed process.

While normally a voluntary procedure, Apple's will now make sandboxing mandatory if the developer wants to distribute its application through the Mac App Store. As part of this mandate, Apple will review all of the entitlements that the developer has implemented, to ensure the scope of the program's entitlement access is not too broad for its purposes. If the scope of the entitlements is too large, then the developer's application may be rejected.

The benefits of sandboxing

The benefit of sandboxing applications is that it protects programs from each other in addition to protecting user data. If someone develops a program for OS X that does not need to access the calendar, then having access to the calendar poses a potential security risk. If the program has bugs in its code, then without proper sandboxing there is a possibility that the program may access and corrupt the calendars. In the event that the program were hacked, then the calendar data would be at risk of being accessed by the attacker.

In addition to protecting user data, sandboxing will also help prevent applications from interfering with each other, and thereby increase the stability of a user's applications as a whole.

What sandboxing means for user experience

For the user, sandboxing should be completely transparent with the exception that some applications may lose a function or two, or require a little more interaction from the user for certain tasks.

In addition to restrictions on program features, there may also be some potential bugs and conflicts with sandboxing that may impact a user's experience. We have seen with Safari showing block-A characters when rendering Web pages for some users when Safari's sandboxing prevented interaction with font management tools, and more recently corruption in sandbox containers preventing Preview from sending PDF documents to Mail. While these problems are likely to happen here and there, they are just bugs that will likely be fixed once found, as opposed to being a long-term issue.

Luckily, sandboxing means that troubleshooting problems for a sandboxed application will be easier to do for the user. Many times when programs act oddly it's because caches, databases, and preference files for the program have become corrupted. With sandboxed applications, all of these files for an application are stored in a separate directory called a "container," which is located in the Containers folder within the user library. At the very worst, removing this container will force the program to rebuild its resources from scratch, which was recently a solution for Preview not being able to send PDF documents to Mail at a user's request.

Overall, despite the potential for bugs and some missing features, the customer should benefit from knowing sandboxed applications will ensure that their systems are more secure and stable using a method that will not burden them with warning messages and errors.

Burdens for developers

While sandboxing benefits the customer with little change to his or her experience, it does put a bit of a burden on the developers, especially those who have well-established and complex code for accessing system resources. These developers may now have to alter their code to perform tasks in ways that fall in line with Apple's sandboxing rules.

In most cases developers will just need to implement the entitlements and be done; however, in some instances novel approaches to programming and system access may need to be reworked so they will function properly within the rule set. To help developers in this process, Apple has implemented temporary entitlements that allow some current functions to still work even when sandboxing is mandatory; however, these entitlements will soon be phased out and require the developer's code to be updated.

Even though the use of sandboxing should not affect most programs' functions, there is valid concern that Apple could implement changes to the entitlements at any time. If Apple changes or revokes entitlements, then program functions will break working code, and even potentially cause applications to lose the ability to perform certain tasks altogether if a workaround in the new rule set cannot be found.

Some developers fear this will limit innovative programming approaches that have defined the Mac experience over the years, and turn Mac applications into relatively bland one-purpose tools similar to how applications run on iOS. There is also fear that the sandboxing rules will prevent interaction with a program via long-standing technologies like AppleScript, which have been a part of the Mac experience for decades.

While these concerns are legitimate, my suspicion is that Apple will provide ample support for alternative approaches and allow the Mac experience to remain relatively untouched. As one example, even with sandboxed applicaitons like TextEdit and Preview in Lion, Apple still allows for incoming "Apple Event" interaction with these programs via AppleScript that should allow control to these applications; however, the one difference is outgoing Apple Events are restricted so some programs may need to implement workarounds. As a result, applications that could, for example, tell the Finder to perform certain tasks will no longer be able to do so when sandboxed.

The Bottom Line

Overall, the end result of this development is that programming for distribution through the Mac App Store is more restricted and requires developers to adhere to more rules rather than simply punching out an application and distributing it. To an extent, it may be best to view Apple's sandboxing requirement similar to a mandatory helmet law--some may be concerned about Apple enforcing the use of it, but overall despite its burdens its purpose is to ensure safety and stability.

While Apple is going to start enforce sandboxing next year, do keep in mind that this requirement is only for applications distributed through the Mac App Store and is not a requirement for the Mac OS. If developers and users want programs that are not sandboxed, then they can still be installed on the Mac, but will have to be obtained from other sources besides the Mac App Store. Some of these include the developer's sites (which can be accessed by online software repositories like CNET's Download.com) and other App Store services like the Amazon Mac App Store.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.