Apple will start insisting that applications distributed via the Mac App Store are sandboxed on Friday 1 June. Some developers have already prepared their apps for the changes, while others are unclear about what changes will be required. Many developers are not happy that the changes are being implemented at all.
When we asked Mac developers for their thoughts on the matter many agreed to share their concerns with us, although of those, only a few were happy to have their names associated with their comments. In fact, we had so much feedback from developers that this article will be the first in a series outlining the issues with readying software for the new sandboxing regulations on Apple’s Mac App Store.
There is much confusion and even more frustration exacerbated by the fact that Apple is not responding to developer’s questions or requests for help.
Some developers are concerned because they believe that Apple has made it clear that applications that are not sandboxed will not be removed from the App Store on 1 June. Others told us that they believed only new apps, or updates to existing apps, would be affected by the change. There is even an element of disbelief that Apple would really implement sandboxing. One developer pointed to Apple Scrips and Automator, and expressed their surprise that once a “champion of end-user automation,” Apple would implement such strict measures.
According to one developer: “There is a huge amount of uncertainty about the whole process as Apple has provided very little information and guidance in terms of what developer can expect. There is no reference persons to contact to clarify and discuss alternative sandboxing strategies, so we are all going into this blind.”
Even worse: “Pre-sandbox screening of submissions has been shockingly arbitrary and Apple staff are frequently either unwilling or unable to understand detailed technical arguments,” said one anonymous developer.
Developers looking to Apple for guidance about sandboxing their apps have been disappointed, not least because of Apple’s own failure to sandbox its apps. So far only TextEdit and Preview have been sandboxed.
“A great source of irritation for developers is Apple’s own failure to sandbox its own programs,” noted one developer. “Apple has sandboxed some of its applications, but the vast majority remain outside of the sandbox and will still be available via the Mac App Store.”
“The reason that they can’t sandbox their own applications is because they experience the very same problems as third party developers: appropriate entitlements do not exist, the APIs are buggy and the sandbox model makes no sense for many applications,” the anonymous developer added. “In order to sandbox their own applications they would need to remove features that users have come to rely upon. For no reason. They don’t want to do so. They don’t want to irritate their users.”
He claims that Apple is resort to “cheats” that third party developers would “never get away with.” He suggested: “Apple should first have sandboxed its own applications and made sure that the sandboxing works properly. Then they could legitimately have asked us to join them.”
“The sandbox doesn’t really make sense and Apple knows it,” another developer, told us, anonymously.
“Something has clearly gone very wrong when Apple imposes changes that require a large proportion of non-game apps on the Mac App Store to be feature crippled. Nobody knows what the real motivation behind it is,” he noted.
“I suspect that Apple’s new found love for the sandbox has more to do with exercising greater control over third party developers and streamlining their review process than with any end-user benefits,” suggested one developer, noting that Apple’s reviewers can now “just look at the entitlements to see what the application can do,” rather than “checking what an application does do.”
What is sandboxing?
Sandboxing requires applications to only use the very minimum of system requirements and APIs. By limiting the access to the system to only the areas which the application actively requires access to, users’ data is safer – and should any malware attempt to ‘hijack’ a sandboxed application the damage this hijacked application could do is limited.
Right now, every application has full access to sensitive information on your Mac: for example, Address Book has access to your entire filesystem. All that access isn’t really needed in most cases.
New applications with the basic sandbox applied have no access to the filesystem, and every time a feature of the Mac is required, it has to be explicitly opted into – this could be network access, USB access, printing, Photos folder access, and location services.
Requesting the ability to use location services from within the sandbox still enforces the OS X prompt asking the user if they’d like to grant the application access to location data. The difference is that, by default, sandboxed apps don’t have the ability to ask the system to prompt the user.
Keith Blout from Schrivener developer Literature & Latte explained: “Under sandboxing, you have to request certain entitlements – saving and loading from file, access to the camera, access to the internet and suchlike.”
Many developers are happy to support Apple in the changes. Scott Marc Becker of IGG Software, developer of iBank, said: “We’re equally committed to three things that all come into play here: the Mac platform; security; and the user experience. Given those considerations, we’re supportive of Apple’s changing requirements – not just Sandboxing, but Gatekeeper and all of the other features or demands of OS X, iOS or the Mac App Store that protect users from the wide variety of threats encountered on other platforms.”
Public Space’s Frank Reiff agreed, to an extent: “Theoretically, there is a real, measurable increase in security for the end-user and as a developer as well as Mac user, I’m of course fully supportive of this.”
Open Planet Software’s Karen MacLean told us: “Sandboxing is a ‘last line of defence’. It will not prevent malware or attacks but is designed to limit the possible damage that can occur should our app, or a system component we use, be compromised. It’s a bit like the airbag in your car – it wont stop you having an accident but you will sustain significantly less damage than you would have without the airbag.”
Cognito’s Grant Cowie agreed that the measures aren’t really enough to combat malicious software. “For our users, it won’t make any real difference (apart from loss of functionality). Apps that deal with sensitive data still need to make their own security provisions to protect that data from exploits. Sandboxing does nothing in that regard.”
“Sandboxing limits damage from compromised applications (such as from remote exploits), and it guarantees that an app that a user installs does only what it says it does. Widespread adoption of sandboxing would effectively stop the Trojan horse threat if customers only ever install sandboxed applications,” added Cowie.
“There is no question that it is, long term, a good thing. On the iOS platform, sandboxing provides customers with the confidence to buy and install apps from the store without worrying that it is going to compromise their device or personal data. Obviously providing the same confidence when it comes to buying Mac software must ultimately be good for that software market too,” said Cowie.
However, he added: “Apple is in a position to apply considerable pressure though simply by making it scary for customers to buy non-sandboxed apps in the store.”
Is there really a Mac security threat?
Some developers question the diversion of resources into a security measure on a platform that rarely sees any security threats. CEO of Boinx Software Oliver Breindenbach told us: “Historically, security threats on Macs have always been very low, so I am really not sure if this significant investment of money and resources by the third party developers will pay off.”
Breindenbach isn’t the only developer who thinks that sandboxing addresses a problem that doesn’t really exist. Scrivener’s Blout told us: “I’m perhaps not as convinced as many people about the necessity for all of this extra security, at least not in the form of sandboxing. Or rather, extra security is often good, but there’s always a trade-off, and I’m not a fan of the way sandboxing buries all the user files about ten layers deep in the user’s hidden Library folder. One of the things I’ve always loved about Macs is how open they are, and how so many different applications can interact with one another, and I’m slightly concerned that sandboxing is beginning to encroach on that.”
Kosta Rozen from Apparent Software told us: “We think that Apple has taken this security issue too far. Rarely do we hear Mac users worrying about lack of security of Mac OS X. In any case, any system is just as secure as it weakest link: if a user has just one piece of software without sandboxing his system will still be vulnerable, and no amount of sandboxing of his other applications will help.”
Reiff noted: “Sandboxing is a necessary technology on a smart phone as carriers do not want to see their networks ‘abused’. Sandboxing is necessary in a browser-based environment as random code downloaded as part of a web page cannot be trusted to have full access to the file system or other system resources.”
However, Reiff added: “In a desktop (or laptop) environment sandboxing makes much less sense. Here the productivity benefits of working in a seamlessly integrated work environment clash directly with the sandbox emphasis on isolating programs. Achieving better integration requires the sandbox to be opened wider thus reducing its effectiveness, so there’s a trade-off between user experience and security.”
BeLight Software’s Ray East told us: “Sandboxing requires a lot of work and the actual benefit is a bit unclear at the moment. For now it seems like the solution to a problem that doesn’t really exist.”
“Then again, Apple has been successfully identifying consumer needs for many years now. Perhaps a couple of years from now it will all make sense and we’ll be thanking Apple for the push towards sandboxing,” East added.
Another anonymous developer, noted that sandboxing won’t necessarily stop malicious apps getting through Apple’s review process: “It’s quite easy to craft an app that adheres to sandbox guidelines and still does harm,” he said.
The case of the evolving sandbox guidelines
Speaking of the sandbox guidelines, many developers are frustrated by the way Apple has kept changing the guidelines for sandboxing.
Keith Blout from Literature & Latte told us: “One technical challenge is that because sandboxing has been consistently evolving over the past few months, it works differently on different versions of Lion. For that reason, our sandboxed App Store version will only be able to run properly on versions of Lion from 10.7.3 and above (it will still run on Snow Leopard, which will ignore sandboxing, but not 10.7.0 – 10.7.2). This is because earlier versions of Lion were missing several entitlements and features in sandboxing that are crucial to Scrivener’s usability.”
Blout suggested that it would have been wise for Apple to “drop sandboxing from Lion altogether and only start enforcing it, fully formed, in 10.8”. Apple has already moved the deadline for Sandboxing back, initially the transition was supposed to happen in March.
Rozen also noted the moving deadline: “Apple has pushed sandboxing enforcement deadline several times – so they understand that this feature was not implemented well enough. They mean business this time, but there hasn’t been significant changes in Sandboxing since its announcement – so it looks like Apple is just trying to force the issue, without real attempt to solve the problem, which is unfortunate.”
Blout outlined the following issues with the process: “There are still certain things that are up in the air – there are several entitlements that are labelled by Apple as ‘temporary’, and developers currently have no idea whether these will one day be revoked or not. We don’t know what the future for some features will be until Apple clarifies what this means. Are ‘temporary entitlements’ temporary in that they are there to give developers time to find some other way of doing these things (in which case we have no control over the integration requirements of third party products), or are they temporary in that Apple is looking for a better way of properly sandboxing difficult features such as Apple Events?”
However, Blout admitted: “Fortunately, Apple seems to have worked hard over the past few months to iron out many of the issues with sandboxing.”
One developer, who asked to remain anonymous, was less forgiving: “Sandboxing is a mess. Apple’s approach to it was to disallow everything and then figure out what doesn’t work anymore. I have no problem with how they do things internally, I couldn’t care less. The problem is that they force us (all developers) to be their testers. Therefore, they simply make changes without even thinking about the implications and then they wait for bug reports from us. My approach to sandboxing is to refuse to be Apple’s beta tester. My idea of development does not include writing bug reports to Apple to help them do their job.”
He added: “A check of the Apple developer forums shows issues even with simple stuff like opening the standard Open/Save panel. Furthermore, they fixed and tuned sandboxing incrementally. So, sandboxing in 10.7.3 is different from 10.7.4, and sandboxing and some things that work in 10.7.4, do no longer work in Mountain Lion. They have no idea what they’re doing.”
Another developer, who wished to remain anonymous told us: “Sandboxing is a lot of work and most seasoned developers realize that there’s little security benefit. The API is buggy, badly documented and incomplete.”