Sandboxing in Practice
Lots is being written about Apple’s new sandboxing requirements: Is it secure? Is it the best way? Is it too soon? All good questions. It’s good that someone’s thinking about that stuff. A bit theoretical for my needs, though.
I just need to know the constraints, so I can build the best app possible within them. That sounds easy enough, right?
Sandboxing makes each app work in a safe restricted space. Safe because nothing dangerous is allowed, except what you specifically request that your app will do. And even then only very limited things.
To help ease the transition, many unsafe things are still possible by requesting “temporary entitlements”. This will allow unsafe things to continue working, but as the name suggests, temporary entitlements will end someday, probably someday soon.
The odd thing is that lots of simple stuff that we expect our Macs to do is only possible with temporary entitlements. What happens when these entitlements are removed? Will they be replaced by something else? If so, what?
OK, we’re getting too theoretical again, let’s reel it in a bit.
What does this mean for YourHead Software? We make Stacks, a plugin for RapidWeaver, which will be sandboxed since it’s in the app store. That means we’ll be running in RapidWeaver’s sandbox.
When you drag a giant image into Stacks it would be nice to store a link to the image rather than copying it into the RapidWeaver file. In the past we’ve done this with a path; or better, a file-URL; or better still, a file reference (called a Bookmark File URL in Cocoa). This is a fast and efficient way to connect with things like your iPhoto library without copying 50MB images around the file system. Obviously, this is something we’d love to keep doing.
The problem is that this is only possible with a temporary entitlement that allows read access to all files. Lucky for me RapidWeaver will probably need this entitlement too, so I’m all set — for a bit.
But then what?
At some point the temporary entitlement will go away. The folks in charge of sandboxing know being able to read all files is dangerous. I guess that makes sense. But really, that’s not what Stacks needs to do. Stacks just needs to read files the user specified a while ago, when they last used Stacks. That doesn’t sound very dangerous to me. It seems like that should be allowed, but will it be? No one is saying.
There are hints from some at Apple that this is being working on. But there are other hints that suggest that some things deemed too dangerous simply won’t be possible, and that’ll just be tough luck for the apps that currently do them: cut the feature or get out.
This feature plays a more prominent role in Stacks 2, which is nearing completion. Should I play it safe and cut it out of Stacks 2? Should I risk it, perhaps enraging users when I have to cut it later? Or is there some other way I should be building this so that it’s inline with the Apple’s goals? What are Apple’s goals?
Practically speaking, there are a lot more questions than answers.
Answers to obvious questions: Yes, I’ve submitted radars about this. Yes I’ve talked with Apple engineers directly about this, even in person. Yes, the engineers working on sandboxing. Great guys, but muzzled by NDA, so not as helpful as I’m sure they’d like to be.
Also: Just wanted to say thanks to the RealMacSoftware guys who do build RapidWeaver. We’ve been figuring this out together since June. Those guys are awesome.
