ArsTechnica on Sandboxing

Chris Foresman:

Sandboxing is designed to prevent apps from doing things that users do not intend—e.g., an exploited app taking over the network and being used for a denial-of-service attack. “Where this runs into trouble, though, is the case of ‘implicit user intent,’ in which there are things that the user does want to do, but they didn’t directly request action,” Siegel explained. Bare Bones’ BBEdit editor, if sandboxed, would not be able to do a multifile search and replace, show live folder views of complete programming projects, or integrate with version control systems.

[…]

The problem, as many see it, is that developers will either be forced to remove functionality that users have come to rely on or simply not sell their software via the Mac App Store. “The choice that you’re given, as a developer, is a Hobson’s choice,” Siegel said. “The answer seems to be not selling through the Mac App Store, which really isn’t an answer at all, because not being in the Mac App Store is not an option unless you’re willing to walk away from a majority of your audience. And no sane businessperson would do such a thing.”

Here’s a simple way to look at it: if BBEdit and Transmit, two of the most popular and respected Mac apps, can’t work with the sandbox, the problem doesn’t lie with the apps.

I disagree, however, with Jonathan Zdziarski’s points at the end of the article. I think the sandbox is basically a good idea, but with an incomplete design/implementation and very poor policy and communication. Apple’s Ivan Krstić seems to be listening, but I’m sure he already heard plenty at WWDC, no changes are in evidence, and he’s unable to talk specifics.

Mac Sandboxing

1 Comment RSS · Twitter

Leave a Comment