Sunday, November 6, 2011

The Controversy Around Sandboxing

To understand the controversy around Mac App Store Sandboxing, it helps to compare and contrast the problem Sandboxing was designed to solve for some Apps, with the problems it creates for others.

First, consider the problem sandboxing was designed to solve. For a web browser or Email client that handles many kinds of complex media downloaded from the web, how do you protect yourself against deliberately malformed data that uncovers a program vulnerability? With sandboxing, even if an attacker finds a vulnerability in your XYZ media code, it's much harder for them to access other parts of the system. Voluntary sandboxing is a good solution for protecting systems against unknown data from unknown sources.

Next, consider a program like Phone Amego which doesn't download media from untrusted web sites. Its reason for being is to provide Mac to phone integration by working with many other tools (including Bluetooth connectivity to iPhone). It wants to integrate with Apple's Address Book, iCal, Mail, iTunes, Daylite, Contactizer Pro, Launch Bar, Finder, Dropbox, FileMaker, EagleFiler, Skype, be scriptable and use AppleScript to drive other applications. Forcing an application like Phone Amego to be sandboxed puts the developer in the awkward position of choosing between dumbing down the application by removing features, or abandoning the Mac App Store version including the thousands of customers who have already paid for the application and expect future updates and support.

Mandatory sandboxing without careful attention to the needs of 3rd party developers is not always helpful.

The Mac would be a much weaker platform without the hundreds of System/Utility products that are not in the Mac App Store. If these products cannot thrive, they will cease to exist.

I think there's a case to be made for "expanding what the platform allows" instead of dumbing down or excluding System/Utility products from the Mac App Store.

Is Apple prepared to announce that hundreds (or even thousands) of existing Apps in the Mac App Store will no longer be fully supported?

What should we tell customers who are not sure whether to buy the Mac App Store or "Website" version of our Apps? Is the Mac App Store a good venue for buying system/utility software?

On the whole, I think 3rd party developers want Apple to do the right thing for our mutual customers. If Apple can't sandbox Xcode, Finder, iTunes, Disk Utility, and Time Machine, and has just announced a 4 month schedule slip, is it not reasonable to infer that their sandbox model might not be ready, or some exceptions are needed?

In my view, Apple should be moving in the direction of allowing more Apps into the Mac App Store, helping them to be more secure (through vetting, signing, sandboxing, and entitlements), and making a distinction between Apps intended for General Audiences (G), and Apps signed by a reputable developer but requiring more extensive system access. Sandboxing could be big win for users, but only if it's applied judiciously.

The alternative sends a message that the Mac App Store is the best place to go for family entertainment, but independent developers offering system/utility products are not welcome.