Apple pushes back sandboxing deadline as devs struggle with tradeoffs

Apple has given developers a few extra months to move their apps to use Lion's …

Apple has given developers a few more months to either come to grips with its new app sandboxing requirements or say goodbye to the Mac App Store. Apple originally set a November deadline for apps sold through the Mac App Store to use Lion's new sandboxing framework for increased security, but the company told developers on Wednesday that the deadline had been pushed back to March 1, 2012.

Still, while some developers were already prepared for the November deadline, others are struggling with what they see as imposing limitations or reduced functionality in the sandboxing APIs. Ars spoke to a few experts in order to understand the tradeoffs Apple's sandboxing implementation will cause both developers and end users.

Every app its own sandbox

iOS has, from the beginning, required all apps to run in their own "sandbox," partitioned off from other apps and part of the operating system. This increases overall security, as apps can't run roughshod over other parts of the system—they can only, in the worst case, ruin their own sandbox.

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.

As Siracusa noted, Apple has slowly added sandboxing facilities into Mac OS X over the last few versions, but added APIs to allow third-party apps to use sandboxing as part of Mac OS X Lion. To encourage developers to adopt the sandboxing APIs, Apple first set a deadline that all apps approved for distribution via the Mac App Store would be required to implement sandboxing by November of this year.

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.

"We're on board with the approach that customers shouldn't have to care about things like where their files are," Agile Bits spokesperson David Chartier told Ars. "Now that we've implemented it, down the road it's going to eliminate a ton of customer service problems for us, such as people putting their password store in a nonstandard place and then end up accidentally putting it in the trash or deleting it."

For instance, sandboxed apps can't open and close files in arbitrary locations on a user's disk without using the standard open/save dialog boxes. So, for 1Password to automatically open and write to its password database, it has to keep it in a special file system location that only it can use. This is similar to the restricted file system access imposed on iOS apps.

"A small portion of our power users are upset [about the change]," Chartier said, "and I think there are a few things Apple could do better to make things easier on both sides. But in general, we like the idea of sandboxing because its advantages in general security and simplifying things for the end user are worth it."

Bare Bones Software's Rich Siegel agreed that, in principle, sandboxing will benefit a majority of users. "Sandboxing is an excellent solution for the security issues that would otherwise cause Mac OS X to turn into a malware cesspool," he told Ars, "and without subjecting users to a numbing progression of 'Cancel or Allow' dialogs that habituate the user to click 'Allow' in order to get useful work done."

"For 99.44 percent of the applications out there, sandboxing is a workable technology, whose adoption curve is very flat and low-friction, and whose users won't notice any functional difference," Siegel said. "Our Yojimbo largely fits in to that category, I think. It's more of a consumer-level product of the sort that I believe was in mind when Mac OS X sandboxing was designed."

The problem, however, is the remaining 0.56 percent of apps and use cases where certain functionality has been expected and used for many years. For instance, apps that can arbitrarily browse the file system, or tell other apps to do something via AppleScript or other means, violate the sandboxing principle.

Losing control

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.

Another popular app that could not be translated to Apple's sandboxed environment is Panic's Transmit FTP app. "Directly displaying or interacting with disk contents is verboten," according to Panic's Cabel Sasser. Developers can request specific exemptions from Apple for various restrictions on a case-by-case basis, but Apple told developers that exemptions would only be granted for a limited time and quickly phased out after the new March 1 deadline.

Apple could mitigate some of the problems with improved APIs for developers to use. "I think Apple has a long way to go to provide equivalent new APIs for all the stuff Mac apps currently do the 'old, insecure' way," Siracusa said. "One can image a set of file system access APIs that also go through some trusted intermediary, but it might be a pain for developers and Apple."

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."

So, developers can keep making apps that have full functionality, at least for now, but due to the popularity of the Mac App Store, they may only reach a shrinking audience. Or they could limit functionality and gain a wider audience, but the app may not sell well if it doesn't work as well.

Beyond that, the limitations that Apple imposes via sandboxing may not even bring the intended security benefits, either. "I don't think this will benefit security," Jonathan Zdziarski, a computer forensics and security expert, told Ars. "Apple already has a fairly decent security implementation incorporating FileVault 2, address space layout randomization (ASLR), and of course all of the security that's found in the Unix operating environment that's worked just fine for the past 30 years."

The ultimate downside, then, could be complete Apple control over which applications can be run on your system. "Sandboxing will severely limit the functionality of Mac applications, and may even make some applications impossible to use," Zdziarski warned. "The question really is, whether this has to do with security, or Apple's intent to exert control over what's installed on the desktop. This paves the path to lock down desktop machines in the same way that the iPhone or iPad are locked down, essentially eradicating any development that isn't sanctioned by Apple."

While we have grown accustomed to accepting these limitations on our iPhone and iPads, are we ready to give up that control on the desktop? Less technical users may welcome the improved security and simplicity without thinking twice about being able to arbitrarily browse the file system or cross-app scripting. We're just as sure most Ars readers would emphatically say "no way!"