Sandboxing divides Mac App Store developers

Apple told Mac OS developers that all applications submitted to Apple’s Mac App Store must implement sandboxing by March 1, 2012.

Sandboxing is akin to what Apple enforces in iOS. Developers are only allowed to use a prescribed set of APIs that exist in a sandbox, and there's no data permanence nor the ability to access resources or data outside of that sandbox. The advantage is security and stability (there's no way for a malicious app to delete your home folder, for example) but the disadvantage is limited application functionality (a sandboxed app can't directly access to any files or frameworks on the system, nor can it access the network or any devices.)

Ars Technica's John Siracusa described sandboxing in his epic Lion review:

Running an application inside a sandbox is meant to minimize the damage that could be caused if that application is compromised by a piece of malware. A sandboxed application voluntarily surrenders the ability to do many things that a normal process run by the same user could do. For example, a normal application run by a user has the ability to delete every single file owned by that user. Obviously, a well-behaved application will not do this. But if an application becomes compromised, it may be coerced into doing something destructive.

[Ars also published a deeper dive on Mac OS X's particular implementation of sandboxing, which is worth a read.]

Pauli Ojala, developer of Conduit, a realtime video and graphics compositing tool is afraid of what could happen if Apple disallowed independent software distribution and required developers to distribute their Mac OS X applications exclusively via the Mac App Store.

Since the Mac isn’t a phone, most apps need to do something more persistent than e.g. rendering a nice image of a collapsing sand castle. To enable these apps to perform their job, Apple has created a list of permitted capabilities called “entitlements”

Apple hasn't indicated that it plans to do this, but what if it did?

Ojala feels "slightly queasy" about a future as described in this 3-year old blog post by Tim Bray:

I don’t want to write code for a platform where there’s someone else who gets to decide whether I get to play and what I’m allowed to sell, and who can flip my you’re-out-of-business-switch any time it furthers their business goals.

While some developers are spooked by sandboxing, some don't think that sandboxing is necessarily a bad thing. Developers will have to do more work to request entitlements, but it will increase security for App Store users as a result.

Will Shipley, developer of Delicious Monster, is clearly in the pro-sandboxing camp, blogging recently that "the Mac needs to be as secure as the iPhone." Shiply goes on to say that although Apple has the tools, "they are forcing developers to use the wrong ones."

There are three primary ways Apple increases security of applications running on the Mac and the iPhone: Sandboxing, Code Auditing, and Certification. While all these are incrementally valuable, none is perfect on its own.

The problem Mac developers are facing is that the two that Apple is enforcing on the Mac App Store (Sandboxing and Code Auditing) are implemented currently to be actively bad for developers and not particularly good for users. And the method that would provide the most benefit for developers and users (Certification) isn’t enforced broadly enough to be useful.

Where do you fall on the Sandboxing issue? Is it evil incarnate or high-security Windows differentiator?

Chart: Pauli Ojala