Suppressing Android Permissions

A week ago this Android issue was closed as WorkingAsIntended by an unidentified Google engineer I’ll refer to as “N”, as that appears to be the first letter in the engineer’s email address.

That issue pertained to allowing users to grant permissions on an individual basis, rather than the “thumbs up” or “thumbs down” users are left with today.

Personally, I’m more interested in this issue, basically calling for android:required on <uses-permission>, so that developers can declare the permissions that they can live without but would like to have. That issue, at least, is not yet closed.

However, what I found fascinating about the issue closure by “N” is the rationale that was given.

The first argument is that this only benefits “power users”. That’s entirely possible. OTOH, there are lots and lots and lots of things in Android that only benefit “power users”, like tethering and “live folders” and VPN and user-configurable inter-activity animations and SafeSearch for voice recognition and so on. Tossing out a security enhancement because it only benefits those who take advantage of it, quite frankly, is insulting.

The second argument is that developers would have to test all combinations of individually-granted permissions, which “N” feels would be problematic. Given the right adaptations to the test harness (e.g., “run this test suite with these permissions”), it might not be bad, though that might not work on hardware. Besides, this problem is why I’m a fan of developer-declared optional permissions, as a middle ground between “all or none” and “every possible combination”.

It’s the third one, though, that really got me thinking, and it’s worthy of quoting here:

We want to encourage application developers to minimize the permissions their app requires. When an application asks for more permissions than necessary, we want users to complain. For example, when Angry Birds added the SMS permission, users complained loudly and forced them to remove the permission (http://www.androidcentral.com/rovio-explains-why-angry-birds-update-needs-sms-permission). Market feedback and application uninstalls provides a powerful incentive for the application developer to request only the permissions they need. Allowing user selectable permissions neuters that feedback loop. Rather than focus on user selectable permissions, we try to provide tools, like market reviews and feedback, to help the user understand exactly what they’re sharing with the app. We believe this is a better way to improve the security of applications for everyone, not just the few people who opt into these protections.

First, this runs completely counter to the previous argument. The “it’s too tough to test the permissions” is pressure to use fewer permissions, due to the complexity involved.

In fact, that’s really the key here. Making permissions optional or user-revocable is relevant mostly because Android developers have been asking for too many permissions on the whole. That’s my opinion, of course, though some users, security researchers, and members of the media seem to agree.

The “feedback loop” that “N” describes is really only effective for large apps — as somebody else points out in a comment, Angry Birds is a wee bit more popular than the average Android app. The fact that this “feedback loop” had to involve the media is testament to the fact that you just don’t get such feedback through the Android Market (or, from what I can tell, any other major market). So, relying on user or potential user outrage to pressure developers to use fewer permissions really is not holding much water, IMHO.

So, what can be done to get developers to use fewer permissions?

As with everything in life, there are carrots, and there are sticks.

The primary carrot on this topic is the plugin architecture. Apps that rely on plugin apps to extend capabilities only need the permissions in the main app that pertain to the main app’s operations. The plugins would request the additional permissions as part of delivering the features related to that permission.

For example, if using the camera is a useful but non-essential feature of your app, you could relegate it to a plugin. The main app would not need the CAMERA permission. But, if the main app detects the plugin is there, it can link to the plugin’s activities, where the plugin holds the CAMERA permssion and can use the camera.

In effect, a well-implemented plugin mechanism gives us the optional permissions that I’m seeking, at least at a coarse level.

The key is “well-implemented”. While it is technically possible to distribute plugin APKs, as Locale amply demonstrates, there’s little around to make that process easy. Finding out what plugins are installed, helping users identify and install available plugins, and having plugins detect when they are installed but the main app is not, are just three of the housekeeping chores developers have to deal with. Fortunately, that sort of stuff is something that the community can solve.

Ideally, markets would have plugin-related hooks, mostly to help the user experience (e.g., not installing a plugin if the main app is not there).

Then, there are the sticks. These are all brainstorms, with not a lot of brain behind them…

Android could log all uses of permission-encumbered operations, allowing them to be reviewed by users in light detail or exported in greater detail for analysis by security researchers. Some things might be logged with relatively little detail (e.g., the app shook the phone via the VIBRATE permission) or, for more troublesome permissions, with a bit more (e.g., the app sent N bytes of data to www.thissiteoverhere.com). This would make it easier for users and experts to gauge the real effects of having the app around.

Google could elect &mdash and might already elect — to have Market rankings take permissions into account. All else being equal, an app asking for more permissions, or troublesome permissions, might rank lower than an equivalent app that skips those permissions. As a suppression mechanism, this will only work if Google would publicly state that this is going on, so developers take notice.

Google could elect to charge a fee for apps listed in the Android Market based on the raw number of permssions or the use of permissions that are particularly troublesome. The fees could be low for few permissions, increasing significantly, to inhibit developers from asking for the sun, moon, and stars in terms of permissions.

Android could open up more permissions to SDK developers, ones that could enable more security-related functionality (e.g., a third-party app to do some of the permission-based logging mentioned earlier). These permissions would be “curated”, meaning that apps requesting them would be manually reviewed by Google before they could be listed on the Market. And, if the app were installed by other means, the permissions screen might call special attention to these permissions. There might be a fee involved here as well, to help pay for the curation process.

By whatever the means, I think a bit more pressure on Android developers to use fewer permissions would be a good thing. I suspect that the plugin mechanism will be an itch that I will be scratching later this year or early next, if nobody comes up with a good support framework before then.