On Android's Application Permission Systems

I'm a big fan of Android's permission model. To recap, it's a system where you're told, in advance, the rights that an application requires to run. A simple calculator, such as the excellent RealCalc Scientific Calculator, should demand no permissions at all.

It can't send or receive data on the internet. Nor can it read my phone number, SMS messages, make calls, etc. I know, by the rights system, the "surface area" exposed to it.

Other applications, such as the ZXing Team's Barcode Scanner, have a much broader rights demand (click on the permissions tab). I originally put off installing that application after seeing that it demanded the right to read and write contact data. I later learned that it uses that to turn contacts into barcodes, and to import contact barcodes.

Angry Birds Screws Up

As ideal as the Android security model is, it was widely panned as being too complex for an average user. That users would simply click past the warnings, as they tend to do when it comes to security matters.

This past week Angry Birds pushed an update that added a new right request: the ability to read and send SMSs on your device. Such a right change disables auto-update for the application, forcing the user to approve or deny the new version. Many users denied the update, many taking to the comments to raise the warning bell about this disturbing change in permissions.

People were paying attention. Rovio quickly attributed it to human error (?) and pushed out a new version that retracted that permission escalation.

It was an excellent example of the permission system working brilliantly, and perhaps an example of a small subset of users acting as the sheepdogs, looking out for wolves.

How The Permission Model Can Be Improved

Aside from the third-party curation of the market that I described previously, whereby a third party could validate appropriate permission sets relative to the functionality of the application, one huge improvement would be the addition of optional permissions.

In the case of Barcode Scanner, it has access to a large surface area despite the fact that I have no intention of ever using that functionality of the application. Ideally I should have been able to deselect contact access, for instance, and the application simply, through discovery, disables that aspect of the application.

Optional permissions would stop the "kitchen sink" element of permissions that is growingly common.