Dogfooding the Sandbox
Does Apple sandbox their own apps? -- Not those sold in the Mac App Store. And, to be honest, it would really help their case with developers if Apple would follow their own rules. It would also help Apple better understand developer concerns and improve entitlements if their own teams had to work within the same restrictions. Perhaps they are moving this direction internally, but the current versions of Apple’s major applications in the Mac App Store (like Aperture, Final Cut Pro, iLife, and iWork) are not sandboxed.
This reminds me of Twitter. When Twitter forced third-party clients to move to OAuth, but didn’t change their own app to use it, many developers said it was a double standard. Twitter’s response: the official Twitter app was part of the service, not really a separate app, so it didn’t need to use OAuth.
Indeed, after the June 1 deadline, Apple issued non-bug-fix updates such as iPhoto 9.3 and Aperture 3.3, yet they remain unsandboxed. Meanwhile, I’ve heard from at least one developer that Apple deemed a third-party 0.0.1 bug-fix update to not be a bug-fix, and so rejected it for not being sandboxed.
7 Comments RSS · Twitter
I think there's an easy argument that could be made against Apple, if they do indeed do what Manton suspects, and go with the "these apps don't need to be sandboxed because they are part of the operating system" argument.
After all, the whole point of sandboxing is to make apps more secure, and to restrict the trouble that hackers can cause once an app is compromised. The fact that Apple's apps come preinstalled with the OS means that it is *more* important for them to be sandboxed, not less. A security issue with one of those apps is, after all, something that potentially affects every single Mac user.
@Lukas That’s a good point. Apple talks a lot about apps being compromised, but I’m not sure that’s actually what they’re worried about. I think they mainly want to ensure a safe buying experience from the Mac App Store. That is, they’re worried about nefarious or incompetent developers, but they don’t want to say that outright. You have to look at what they say vs. what they do. If the problem is exploits, it seems to me that the answer is not (only) to sandbox Preview but to sandbox PDFKit, thus protecting every app that uses PDFs. This would actually be safer because the PDF-reading component wouldn’t need any entitlements. And it would work with non-sandboxed apps!
@Michael That makes a lot of sense. Never occurred to me that this might be (at least in part) about incompetent programmers accidentally doing damage.
"That is, they’re worried about nefarious or incompetent developers, but they don’t want to say that outright."
This is supposed to be the job of the review team to filter these applications out.
"If the problem is exploits, it seems to me that the answer is not (only) to sandbox Preview but to sandbox PDFKit, thus protecting every app that uses PDFs."
I'm not sure how they would be able to protect something that is already sandboxed by design.
@bob Yes, but I think it’s impossible for the review team to do that accurately. I’m not sure what you mean by “already sandboxed”; I’m suggesting a multi-process architecture like they have with QuickTime X.
By "already sandboxed", I meant that when you create a framework, it's to perform a specific task. For instance, the PDFKit framework probably doesn't use the microphone, AppleScript, etc.
@bob You’re right, but currently the sandboxing technology works at the level of processes, not frameworks. When you load the PDFKit framework into your app it inherits the privileges of the app. However, the framework could be redesigned so that the bulk of its work is done in a helper process that has no privileges.
