Entitlements

Yesterday, Apple announced that they will require every App submitted to the App Store for Mac to contain entitlements, starting March 2012. This means that the developer of the App has to include a (cryptographically secured) file in the application bundle that lists the resource types it is about to use. Things like:

• Accessing user’s files (separated by music, pictures, movies, all and by read-only/read-write),
• Accessing address book data,
• Accessing calendar data,
• Connecting to the internet,
• Waiting for connections from the internet,
• Accessing USB devices,
• Printing,
• …

At first it might not be clear what this is good for but once you think about it, it becomes obvious: Even if there is a bug in the application that allows others to send you a corrupted file, this file might take over the application context but it is not allowed to take over your whole computer. Think of an image viewer that brought the rights to read all files and to print: Even if there is a image file that is sent to you by your government that triggers a security hole in the application, the payload in this file will never be able to send any of your data to the internet or save and compromising data on your hard drive. All it could do is read your data and print them.

Sounds like a good idea, doesn’t it? Well, it is a mixed blessing.

While the basic idea is good (but not new, Android was using it from the beginning), there are some problems: First of all, if you want your App to be secured by entitlements, you have to sell it over the Mac App Store. As we all know, not all Apps are entitled to be sold on the App Store. For some of them the problem is the nature of the App, for some the problem is the 30% of the revenue that Apple takes.

So, Apple should really think about a way to use the entitlements in Apps that are sold outside the App Store. Let’s face it: At some point in the future, there will be a version of Mac OS X that requires entitlements for every App run on the system. This means there has to be a way – and I would say there has to be a way that is free of charge – to include entitlements in your custom made apps without selling it through the Mac App Store.

The second problem – and I think it is as big as the first one – is that the current list of entitlements is way too short. Your App wants to send Apple Events to other Apps? There’s a temporary entitlement that is about to be removed soon. Your App needs to access a Firewire device? No way. Your App needs to access files without the user approving every single file? Nope. In my opinion, there needs to be one very special entitlement that these Apps are allowed to include: allow-everything-else. While this sounds ridiculous at first, you should consider that a) this entitlement is for Apps only that could not use entitlements at all if it was not there and b) this would allow the system to refuse all activity that is covered by existing entitlements. Think of an App that has the following entitlements:

• Read images
• Print
• Everything else

This App would be allowed to read images, print them, control other Apps by AppleScript, use Firewire devices (etc.) but not to access your calendar data. Or your address book. Of course, the entitlements would have to be versioned to allow the App to continue to work once there is a Mac OS X version that has an entitlement for sending AppleScript events.

Conclusion

Entitlements are a good thing. They won’t fix any bugs, they even might introduce new bugs. But the bugs will be restricted in the harm they potentially do. If Apple requires you to use entitlements (as they do for Apps on the Mac App Store), they better have entitlements for everything an App might want to do. I think this can only be done by an everything-else-entitlement.

If entitlements are a good thing, everyone should be enabled to use them. This means Apple should establish a free-of-charge-way to entitle your custom made Apps.