Understanding The Debate Over Apple’s Mac App Store Sandbox

Sandboxing was very much in the news last week. I tripped over a half-dozen articles on the topic without even searching.

No, I’m not talking about play areas for toddlers. I’m talking about an OS X feature that Apple will require all apps sold in the Mac App Store to implement.

Sandbox

At its core, sandboxing is a security enhancement. A sandboxed application is confined to its own container (i.e., sandbox), unable to access any resources or perform any actions that would necessitate going beyond its walls. Most especially, this prevents one application from affecting another one in some malicious way. Without such protections, for example, an application could theoretically issue UNIX commands to delete files on your drive without your knowledge or intent. Or it might attempt to extract passwords from other applications and send them to a pirate server. The sandbox restrictions similarly protect you from unintended non-malicious conflicts that may occur between applications.

This all sounds great except that many applications need at least some outside access to carry out their primary functions. A photo editing app, to take one obvious example, would be useless if it were blocked from accessing the photos in your iPhoto Library. To solve this conundrum, Apple has created a list of explicit “entitlements” that an app can request when it is submitted for approval to the Mac App Store. Entitlements include actions such as read-only or read/write access to user folders (Music, Pictures, etc.), interaction with USB devices, and ability to print. Apple decides whether or not to approve the requested entitlements for each app.

In addition to increasing security, Apple believes that sandboxing will simplify the user experience in the same way that fences can “simplify” interactions between neighbors. This is important as Macs move more and more toward being “consumer” devices. If all this sounds vaguely familiar, it’s because it is very much how things already work for iOS devices. Sandboxing on the Mac is yet another example of Apple’s iOS-ification of OS X. 

Apple made it clear months ago that sandboxing was coming to the Mac App Store. In fact, some apps in OS X Lion (notably Preview and TextEdit) are already fully sandboxed.

[Pro tip: To see whether a particular app/process is currently sandboxed, launch Activity Monitor and select Columns > Sandbox from the View menu. A new column will indicate Yes or No for each open process.]

So why the recent flurry of activity on this topic? Because Apple sent an email to developers last week, postponing the looming deadline for mandatory implementation of sandboxing from this month to March 2012. Writers (including myself as of this article) took this as an occasion to reconsider the pros and cons of sandboxing.

Before I offer my opinions, I want to give you an sense of what all those other writers have been saying. The overriding point in almost every article is that the advantages of sandboxing come with a cost. The big question is whether or not the trade-off is worth it.

Everybody’s talking

Pauli Olavi Ojala [Naming Things] warns: “By default, the sandboxed app doesn’t really have anything of its own. Even files in its own Application Support subfolder may be deleted by the operating system if it wants to e.g. reclaim some disk space.” Further, “the sandboxed app binary contains an encryption signature inserted by Apple that tells Mac OS X that this code is safe to execute. Third party plugins wouldn’t have this signature, so they wouldn’t run.”

As noted by several articles, Apple’s own apps (Final Cut Pro X, Motion and Aperture) currently support plug-ins — something not permitted with sandboxing. Will Apple continue to allow its own apps to violate the rules come March? Apple isn’t saying yet.

Andy Ihnatko [Macworld] worries that one “impact of sandboxing on automation is that apps that want to control other apps via AppleScript are kind of hosed.”

Wil Shipley [Call Me Fishmealargues “One problem with entitlements is that there are still many actions for which their is no entitlement available as yet. And it’s not a perfect security system anyway. [Sandboxing] has no effect on non-App Store apps or apps that disguise the reason they are asking for entitlements.”

Wil would prefer that, instead of focusing on sandboxing, Apple use certificates (another security mechanism that already exists in both iOS and OS X). Apple should “allow each developer to sign her applications with the certificates Apple provides. Lion should only run applications with Apple-provided certificates, and Lion should have a control panel that says, ‘Here’s a list of applications you (the user) will allow to be run that don’t have trusted certificates from Apple.’”

Chris Foresman [ars technica] talked to several developers, most of whom offered positive assessments of sandboxing. For example, “Agile Bits was quick to add sandboxing support to its popular password locker app 1Password in anticipation of the original November deadline. While it took some work on the company’s end, including a removal of some functionality and flexibility from the software, Agile Bits believes it was the right way to go.”

This loss of functionality to meet the demands of sandboxing was a concern echoed several times: “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.” Bare Bones Software’s Rich Siegel added: “[Bypassing the Mac App Store] 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.” [ars technica]

Lex Friedman [Macworldsimilarly noted that “customers will be surprised and confused if their Mac App Store purchases get updates that remove prior functionality to comply with sandboxing rules.” Peter Maurer and Rob Griffiths (of Many Tricks) added: “As of now, entitlements for the core features of many of our apps don’t even exist, which means we cannot make them compliant at all.” While sandboxing can help keep Macs safer, they compare it to “saying that by keeping your laptop plugged in at all times, you’ll never run out of battery charge: It’s true, but it doesn’t mention the tradeoffs involved.”

Still, several postings (as well as numerous readers comments) stressed that developers can choose to market their apps outside the Mac App Store — thereby avoiding sandbox concerns. Apple does not have an absolute requirement for sandboxing in OS X. At least not yet. “The obvious counterargument is that it’s Apple’s store, they make the rules, and nobody forces developers to submit their apps.” [Naming Things]

While acknowledging potential problems with sandboxing, Topher Kessler [C|Net] concluded: “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.”

My turn

When I first heard about sandboxing coming to OS X, my reaction was a resigned sigh. I was not surprised by the move but I did not look forward to the change.

I don’t have any anti-virus installed on my Mac. I use only minimal firewall protection. I regularly download software from the web. Maybe I’m flirting with disaster, but (despite my laxity) I have not had a single security-related problem of any sort in over a decade. In fact, I can’t recall ever being the victim of a malicious attack that sandboxing would have prevented. Based on conversations I’ve had with others, I believe my experience is fairly typical. Yes, sandboxing will make things safer. But, given the overall safety of the Mac, the likely minimal benefits don’t seem worth the cost to me. If we really need to do something beyond the status quo, perhaps Wil Shipley’s idea of using Apple-approved certificates would work better.

In any case, sandboxing does not mean the end of trouble for users. Sandboxing can lead to problems of its own. For example, as covered in a MacFixIt article, if Mail’s option to “mail a selected PDF document,” stops working, the recommended fix is to delete likely corrupt files in a sandbox-related folder in the now-hidden-in-Lion Library folder of your Home directory.

Yes, if you want to avoid sandboxed apps, you still have the option of going outside the Mac App Store. But I believe this will be a less and less viable option over time, as the Mac App Store becomes the dominant source of all Mac software. Eventually, Apple may prohibit non-App Store software from loading on a Mac. That’s the way things are now on iOS devices. Apple has to be at least thinking in this direction for the Mac as well.

I concede that there is value to sandboxing. Without doubt, sandboxing offers increased security. That’s always a good thing. From a business perspective, sandboxing may almost be required for Apple. When users buy software from an Apple App Store, there is a sense in which users believe that Apple has put its “stamp of approval” on the app. Indeed, it has. Apple has reviewed the app prior to accepting it into the Store. If things go maliciously wrong with an approved app, Apple will (rightly so) bear part of the blame. Sandboxing is one way Apple can protect itself here.

Still, I keep coming back to the trade-offs not being worth it. If nothing changes between now and March, and sandboxing is implemented as is, I believe there will be more complaints than kudos from the Mac community (although I suspect the majority of Mac users will hardly notice the change and say nothing).

All of that said, I believe there is reason for hope — hope that things will change between now and March. The fact that Apple has delayed the implementation of sandboxing by four months tells me that, at the very least, Apple recognizes that the technology is not yet fully baked. It may also mean that Apple wants more time to listen to feedback from developers, possibly resulting in concessions that loosen the present restrictions.

In the end, sandboxing, in whatever form it ultimately takes, is just the proverbial tip of the iceberg. It’s one piece of Apple’s overall plan for the iOS-ification of OS X. This is a major strategy shift that will play out in a variety of contexts over the next few years. For better or worse, I don’t see Apple backing away from this shift. Users and developers had better get on board or get left at the station. There’s no other choice.