Earlier this month, Apple sent an email out to its developers delaying the implementation of sandboxing to Mac App Store submissions, stating:
The vast majority of Mac users have been free from malware and we’re working on technologies to help keep it that way. As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing. Sandboxing your app is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users’ systems.
Simply put, sandboxing serves as a security enhancement. It’s a container in which an application is allowed to function–unable to perform any tasks or access any resources that would mean transcending the container’s boundaries. Essentially, one application is prevented from affecting another in any malicious way (i.e. its prevented from potentially/theoretically using UNIX commands to delete files on your hard drive without your knowledge, or attempting to extract passwords and share them, etc). I think, conceptually, this sounds fantastic and a great deal for the end user, but there are other consequences that should also be taken into account when it comes to sandboxing and its implementation. Often the case is that applications need a certain level of outside access in order to perform whatever they have advertised to do. For example, a photo editing app, wouldn’t be of much use if it wasn’t even able to access your iPhoto library. To address this, Apple allows for “entitlements” that app developers can request for the application they submit for Mac App Store approval. A quick glance shows that the complete list is fairly straightforward (there are a couple temporary exemptions) …although if you happen to need access to hardware from something other than USB (e.g. Thunderbold, Firewire, or Bluetooth), you’ll be hard-pressed to find a way to do so.
The mobile world has generally always had sandboxing. Apple’s move to apply it to the Mac world seems to imply that engineers thus far have found it such a great idea that they wish to see Mac users benefit from it as well. Yes, as I said earlier, on the outset sandboxing presents a method for furthering security–unfortunately, as we’ve seen in the jailbreaking community time and time again, code isn’t perfect and it’s only a certain amount of time before someone finds a loophole and continues the constant game of cat and mouse. Just to think of a few areas where sandboxing may fall through:
- Apple seems to be relying on its ability to implement the entitlement limited code perfectly. If Apple could write in perfect code, then it would have, I would think, been able to immediately fix the PDF & TIFF submodules so that they were exploit/bug-free. Unfortunately, code is imperfect.
- For apps not sold in the Mac App Store, there’s nothing requiring them to use entitlements. And if there even was such a requirement, malware could just be distributed in applications with entitlements including basically everything the system could do.
- This brings us to the following: Apple has mentioned that it will look closely at apps requiring a lot of entitlements. And again, I can see how that might make sense as it might look suspicious if an app requests sixteen entitlements…but at the same time, looking closely at such applications in some ways can be seen as an admission that entitlements do not work since it leads to what many may consider as code auditing.
To further emphasize the idea that sandboxing is far from full proof: earlier this year, security researcher Charlie Miller submitted an application to the iOS App Store, which was audited and approved. The application allowed Apple’s iOS software to run arbitrary code and therefore download new, unapproved commands onto the device and execute them at will. For example, he demoed the phone being able to vibrate or produce sounds, steal user photos, read contacts, etc. In response to this news, Apple revoked Miller’s developer account.
At this point, I think the real question this comes down to is whether Apple’s latest move has to do primarily with security or Apple’s intent on further exerting control on what’s installed on users’ desktops. To many, sandboxing is seen as the beginning of locked down desktop machines similar to iPhones and iPads, where any development not sanctioned by Apple is effectively diminished.
After Apple sent out the updated timeline for sandbox implementation on applications, Jonathan Zittrain, the author of The Future of the Internet and How to Stop It, tweeted:
Zittrain: Apple one step closer to locking down PCs as predicted in The Future of the Internet at http://t.co/yYhvdrEE ; see http://t.co/e4kmgQWi
What Zittrain is referring to here is the predictions found in The Future of the Internet, where he begins by discussing the concept of generativity–or the openness of a system to new and unplanned changed from its users. Today we have open internet and open computers where you can run any programs and protocols you want and connect to anyone you want. This has been tremendous in establishing what he describes as a generative system. It is important to note, however, that what may seem as a strength can also serve as as weakness for the very same system. Computers can get viruses and crash. They can start to slow down. Thus, the very same force that attracted so many users in the first place can now lead users to go for the safer options available, systems they can be assured will work reliably. 
Hence Zittrain’s tweet.
One can argue that Apple seems to be closing off the Mac App Store and forcing users to choose between the “open” and “closed” worlds that Zittrain mentions. Apple justifies sandboxing by appealing to users wanting their Macs to run more smoothly. From their perspective, any users that want to run unsandboxed applications found outside of the Mac App Store, can still do so. Thus, Macs can function as computers that support safe and unsafe modes–one focusing on increased security, and the other for increased generativity. Because of this, there have been mixed reviews when it comes Apple’s choice to implement sandboxing: some fully support Apple 100%, while others fear the dumbing down of the Mac store.
Furthermore, if you look at this situation of sandboxed applications in the Mac App Store vs. unsandboxed applications found outside of the Store from the developer’s perspective, then I think it’s highly unlikely, that over time, those developers that are at all concerned with market share will choose to create at least two different versions of an app–with one including extra features that the sandboxed version could not have. This therefore brings us back to the concern that sandboxing maybe dumbing down the set of features available to even those who choose not to purchase through Apple. Hence, at this point, there seems to be a lot of uncertainty surrounding what a sandboxed future means for both the distribution of, and applications themselves.
Overall, Apple’s decision to postpone till March, I think is reason to be somewhat hopeful that developers may play a greater role between now and then in the final implementation of sandboxing; Apple seems to recognize that the concept isn’t exactly ready yet. At the end of the day, however sandboxing is executed, I dont think there is any doubt amongst both developers and users that this is just the beginning of Apple’s overall plan to “IOS-ify” OSX.
Yale Law Tech 