Apple’s Walled Garden: Secure Playground Or Crystal Prison? – The ‘Book Mystique

Application sandboxing, which restricts default access to all system resources except those allowed under specific Apple-defined conditions, became mandatory for software sold on the Mac App Store last Friday, a development that likely won’t be noticed by most casual Mac users, but was greeted with a chorus of boos from the productivity-oriented, power users, and those who philosophically resist arbitrary measures that diminish their control over their computing environment.

Personally I fall into the latter camps. I’ve never really considered myself a power user, but I guess that in the current definitional context I sort of have become one by default. I don’t like arbitrary restrictions. I can understand Apple’s rationale for imposing them in this instance, although I’m not entirely in agreement. What Apple is about seems to be phasing in the tight sort of lockdown on OS X software applications that has been in place from the get-go with their iOS mobile operating system — the famous or infamous “Walled Garden” depending on your point of view on such matters. Their intent is to protect the Mac OS user experience, especially for the mass of consumer users, more and more of whom are being drawn to the Mac platform under the iPhone/iPad halo effect. That’s a commendable objective within context, but not so much for those of us who prefer to operate outside of it.

It’s not just mandatory sandboxing of software sold through the Mac App Store, but also a new feature called “Gatekeeper” coming in OS X 10.8 Mountain Lion that will default to an iOS-style locked-down mode, but at least will be user defeatable. With Mac App Store sandboxing there’s no such choice available. It’s either Apple’s way or the highway.

It remains to be seen how this will play out in practice. Various commentators more knowledgeable than I have weighed-in on the topic recently. Kirkville’s Kirk McElhearn says that those of us who use more advanced software tools to save time and improve productivity and efficiency will find ourselves bumping up against the new limitations, and that as currently implemented, sandboxing is likely to stifle innovation, causing developers to dumb down their apps, or give up trying to introduce innovative features that need to go outside the box, and predicts that overall, at least for the advanced user cohort, the effects of sandboxing will be negative. Collateral dumbing-down of functionality is a big part of what I dread about sandboxing.

MacFixIt’s Topher Kessler observes that many programs available through the Mac App Store are standalone single-purpose tools, and as such will not be affected by Apple’s sandboxing requirements, but others will be forced to limit or lose functionality in order to conform to the new policy, which is too restrictive for some applications to function as intended by developers. Kessler notes that in its current implementation, Apple’s sandboxing breaks some common application features and introduces burdensome additional steps to others, and that there are likely to be some instances where it may greatly affect the user experience with some programs and the ability of some developers to continue offering certain features currently available in their programs.

Veteran Mac commentator Andy Ihnatko notes that while the objective of Apple’s sandboxing restrictions isn’t a bad goal in the abstract, in practical terms many Mac software apps use techniques that are perfectly harmless, but impossible to implement under sandboxing, while others are specifically designed to deliver system-wide functionality that is fundamentally incompatible with the sandboxing concept.

From a philosophical perspective, the Electronic Frontier Foundation’s Micah Lee and Peter Eckersley note in a major essay on the topic that no less than Apple co-founder Steve Wozniak recently made a public call for the company to open its platforms for those who wish to “tinker, tweak and innovate with their internals.” The EFF supports Wozniak’s position say Lee and Eckersley, acknowledging that while Apple’s products have many virtues, they are increasingly compromised by “an ugly set of restrictions on what users and programmers can do with them” observing that as yet, this is most especially true of the mobile iOS platform, although other Apple products are increasingly beginning to be likewise afflicted.

In their analysis, Lee and Eckersley delve into the kinds of restrictions that Apple, phone companies, and Microsoft have been imposing on mobile computers; examine the rationalization these corporate entities make for imposing such restrictions; and warn of the dangers this is creating for open innovation with a special emphasis on Apple in particular which they contend should lead the way in fixing this mess. They also propose a bill of rights that needs to be secured for users of smartphones and other pocket computers, the provisions of which are:

1. Installation of arbitrary applications on the device. If the user wishes to, they should not be limited to what is included in one particular proprietary “app store.”

2. Access to the phone OS at the root/superuser/hypervisor/administrator level. If consumers wish to examine the low-level code that is running in their pockets, to check for invasions of privacy, run the anti-virus software of their choice, join VPNs, install firewalls, or just tinker with their operating systems, phone and device companies have no legitimate basis for preventing this.

3. The option to install a different OS altogether. If people want to install Linux on their iPhones, Boot to Gecko on their Windows phones, or just run a different version of Android on their Android phones, the company that sold them the hardware must not prevent them. Using a cryptographic bootloader to defend against malware is a fine idea, but there must be a way to reconfigure this security mechanism to (1) allow an alternative OS to be installed; and (2) to offer the same cryptographic protections for the alternative OS.

4. Hardware warranties that are clearly independent of software warranties. Apple denies warranty coverage to users who have jailbroken their iPhones. While nobody is asking Apple to support jailbroken or modified software, it is inexcusable that the company threatens not to cover, say, a faulty screen, if the customer has chosen to modify the software on their device.

Not everyone agrees with that manifesto. Another longtime Apple pundit, Steve Wildstrom, writing in a Tech.pinions blog, expresses satisfaction that “fortunately, there’s no reason to believe that Apple is listening to the siren song of openness coming from places like EFF, the Free Software Foundation, Harvard’s Berkman Center, and the Software Freedom Law Center.”

Wildstrom acknowledges that completely open systems do enable anyone with programming skill to get at the guts of any device and see what he or she could do with it, and that it’s conceivable that some wonderful things might result, that openness comes at a cost, clearing a pathway for the malicious or the merely incompetent. “I don’t care if people want to mess up their own systems, but I don’t want their badly written or downright evil software corrupting mine,” says Wildstrom, arguing that Apple has created one of the best user experiences ever, and that he can download software from Apple’s App Stores with confidence that it is not going to make a mess of his phone or tablet, or presumably his Mac either with sandboxing now in place.

However, that sense of security comes at a cost too. Jonathan ‘Wolf’ Rentzsch, president of Red Shed Software Company, writing in a blog picked up by Macworld last week, notes that since Apple launched of the Mac App Store, most third party software developers have been vaguely equivocal on the matter of whether it’s advantageous to buy apps directly from the developer’s Website (when that option is available) or through the Mac App Store. With Apple’s mandatory sandboxing, that ambiguity is now removed Rentzsch contends, advising that “Customers should buy Mac apps directly unless there’s a good reason not to.”

That pretty much conforms with what has been my assessment from the get-go. I’ve endeavored to avoid using the Mac App Store to download software if there’s been any alternative available. Examples that come to mind are Bare Bones Software’s excellent TextWrangler text editor and the Sleipnir Web browser, both of which are available in deeper-featured versions directly from the respective developer’s Website, compared with somewhat dumbed-down, sandboxed versions available on the Mac App Store. Too bad not all developers make similar alternative provisions.

My provisional policy on this is consistent with my having long kept Software Update disabled in OS X, and selectively downloading standalone installers for whatever updates I choose to go with and installing them at my own convenience. Unhappily, beginning with OS 10.7 Lion that level of control is no longer available for OS X system installs and incremental version upgrades, which is one of several reasons why I’m still running OS 10.6 Snow Leopard.

In Rentzsch’s estimation, reasons why it’s preferable to buy non-sandboxed apps directly from developers rather than through the Mac App Store include a better app user experience, more features (viz. the examples I mentioned above), better data integrity — for instance he notes that document-based Core Data apps are incompatible with Sandboxing, more and faster updates, less risk of losing your software investments, observing that generally speaking it’s safer to buy direct from the developer rather than risk being cut off from your own software based on some arbitrary Apple policy change, and finally, more money goes to the developer, since Apple takes 30 percent off the top from Mac App Store purchases.

On the balance, Rentzsch concedes that buying through the Mac App Store does offer a few compensatory benefits, including a better purchasing experience (I would say that depends on how you define “better”), a better maintenance experience, ergo, if you buy a new Mac, the App Store.app will provide a list of apps you’ve purchased from the store ready to reinstall (again, the appeal of this depends on how much of a hands-on machine management control freak you are), and iCloud access (not relevant for me since I use Dropbox and Box.net by preference). According to Rentzsch, Apple has decreed that only Mac App Store apps (ie: now sandboxed apps) can access iCloud. As noted, I’m a non-iCloud user as yet (requires OS X Lion), but wasn’t previously aware of that restriction, which just further solidifies my affinity for Dropbox and Box.net, and pretty much ensures that I’ll not become an iCloud user anytime soon. Software sold through the Mac App Store is vetted By Apple, if that’s important to you.

However, in Rentzsch’s view (and mine), the takeaway is that sandboxing has effectively eliminated ambiguity and in general he recommends that Mac users now purchase apps directly from developers if possible instead of through the Mac App Store.

That’s certainly what I will continue to do when the option is available, and at whatever point I upgrade to OS X Mountain Lion or later, I’ll be keeping GateKeeper disabled as long as Apple gives us a choice. What worries me is that at some point they may not.

How about you? Content to play in Apple’s sandbox, or do you chafe at being walled-in?

Some of the links above are affiliate links to the retailer's site. That means we may earn a small commission from any sales (Thank you!).


Boost Infinite
Apple Store