Apple's sandboxing restrictive for some applications

Starting June 1, the Mac App Store will be adopting a new policy that requires applications distributed through it to be sandboxed -- a feature that restricts default access to all system resources except those allowed by specific Apple-defined entitlements. The sandboxing and entitlements are generally voluntarily set up and elected by the developer, but in the case of the App Store, are both mandatory and also scrutinized and approved by Apple. While sandboxing is a great option for protecting users' systems and should offer seamless functionality for most programs, Apple's implementation is too restrictive for some applications to function as intended by developers.

In the past few months and weeks following up to the June 1 deadline, the Apple developer community has been working to get its programs working with the App Store sandboxing mandate, and while many have worked seamlessly with it, others contain features that simply will not work. Recently MacWorld covered a number of these concerns, and in recent weeks similar frustrations and discussion have also surfaced among Apple's developer community as some developers are finding the sandbox breaks their current approaches to their programs.

While compensating for the sandboxing requirement is ultimately up to the developer and in many cases there is a workaround or two that developers can implement, unfortunately in some prominent cases there are no workarounds available. For example, image management programs often include features to open an image in an "external editor" where the primary program passes the image information directly to the secondary one, creating a seamless workflow that is appealing to users. With sandboxing, this ability is restricted and users must first save the file and then open it directly from within the second program.

Other areas where we have seen sandboxing result in limited functionality is with scanning and monitoring tools such as Symantec's new free iAntivirus tool for OS X. In most AV scanners there is an option to scan user-selected files and folders, or to scan presets such as the home folder or the entire system; however, with sandboxing the program's ability to directly access the entire system for scanning (even if no edits are made) is restricted and requires direct selection of the desired resource by the user through an the system's generic "open" dialog box. As a result, when scanning the entire system, iAntivirus must first present the same "open" window as it does for user-selected file scanning, and have the user select his or her hard drive to scan -- an extra step that seems pointless to users but is required by the sandboxing restrictions.

Beyond direct user interaction, developers are also concerned about the ability to schedule tasks using the system's launch daemons, or build programs that piggy-back on others. Some such programs include the popular Evernote citation manager for various word-processing suites, or the MoneyWorks financial reporting features that the program appends to Excel or Numbers.

In addition to concerns about sandboxing, the current implementation on some of Apple's built-in applications has had its own share of quirks. In TextEdit and Preview, users have experienced odd file quarantining flags being appended to files, bizarre crashing of duplicated application instances as child processes, and the inability to print or mail PDF documents from print dialogs. Though these are bugs that should not be present in the sandbox, they signify the type of frustrations that might happen as applications adopt the current sandboxing implementation.

Sandboxing is intended to be a last line of defense against buggy programs and compromised or hacked code that could result in a running program inadvertently (or even purposefully) used to access and alter unintended resources on the system. As such, the sandbox rules and implementation should prevent such unwanted behavior, but should only do so by having minimal impact on application function. In its current implementation, Apple's sandboxing breaks some common application features and introduces burdensome additional steps to others.

The sandboxing implementation in OS X is still in its infancy, and hopefully Apple can implement changes that allow for the reimplementation of these lost functions, and overall better manage sandboxing to offer users and developers more options for a seamless experience while still maintaining a secure default sandboxing implementation.

One approach to this might be a notification service in the OS X sandbox that warns the user if or when the program is requesting resources beyond the scope of its sandbox, and then supply an option to confirm or deny. Apple currently has similar notices with its file quarantining and application firewall security features.

With a notification system, applications could run by default within the restricted sandbox and still contain code that requires breaking the sandbox rules. If this code is invoked, the sandbox would block it by default and prompt the user to either confirm or deny the application access with a basic "yes/no" dialog box. The programmer could then implement routines to contend with the choices made by the user. Such a notification feature would only implement one additional step in managing sandboxed applications, and would greatly cut down on the cumbersome requirement for an "open" dialog box.

In addition to a notification system, Apple might also benefit from a sandbox manager that could provide exceptions to specific programs of the user's choice, though the overall utility and benefit of such a feature might be questionable.

Overall, even though Apple's sandboxing features will for the most part enhance the security of the OS X experience, there are some instances where it may greatly affect the user experience with some programs and the ability of some developers to offer features currently available in their programs. While one might argue that the Mac App Store and its sandboxing requirement is not a requirement for these developers, this puts them in a catch-22 of sorts where they either drop desired features features and burden users' workflow, or lose a major distribution opportunity by pulling their apps from the store.

Hopefully Apple will recognize these shortcomings and offer a solution of sorts that will ease the use of sandboxing with these programs, but for now it appears users and developers will have to contend with them.

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.