Thursday, 30 July 2015

Android Updates with New Permissions

Permissions, the system by which apps declare which hardware or special functions they wish to use, are getting a huge overhaul in the next version of Android, codenamed 'M'. Full details can be found here, with a slightly more palatable version here. This may or may not make developers more aware of the impact of the APIs they use, declare, and how users view, care or don't care about how apps use the hardware and special functions of their Android devices. Certainly a recent published vulnerability within Stagefright (an Android component) has given Android security the unwanted spotlight yet again, so both enterprise and home users alike may be getting more wary, we can only hope. I wrote about the need for a better security patching system for Android 15 months ago, and nothing has changed, it is still a problem given the Stagefright vulnerability.

However, with the current system of permissions declaration in play for a number of months yet before 'M' is released, and perhaps even longer given the slow roll-out of new versions of Android across manufacture and carrier variants, here's some examples of how permissions should and shouldn't be dealt with! Android users will know that in some app updates, developers add features which require them to use extra permissions, and these are displayed to the user at update time.

Case 1

Here's an example from a voicemail app, which for some reason now wants extra permissions from no less than 9 different categories:

When developers publish app updates, they are encouraged to give proper release notes, explaining what has changed in the new version. Here is the accompanying text:

They seem like mainly fixes, improvements to existing features, and that's about it. So why all the new permissions? Why should I be happy, as a user, to suddenly allow this app to get much more of the content and functionality within my device? I contacted the developer, and the response below seems to suggest they were forced into declaring all these permissions just to add badge support for the app's icon in the various launchers.

"Unfortunately we had to add them in order to set the badge counters but they are ALL related to that and are specific to different launchers from various manufacturers and third parties."

This may or may not seem appropriate to you. most apps asking for further permissions are usually legitimate, and sometimes Android will put developers in a corner with certain APIs and permission. However, it would have been far better to include reference to this in the release notes.

Case 2

Here is an altogether better example. This is a password management app, which itself was in the news for a breach last month, but takes a different approach. Here's the app update, and the new permissions it wants to declare:

Not as many as the voicemail app, granted, but still permissions I might be interested in if the privacy of my location is very important to me. Let's see what the release notes say:

A full list of new features, with new permissions called out where they are needed. Much better, more transparent, and the users understands why they are required. Furthermore, for extra credit there is a link at the bottom which follows through to their website, where every single permission used by the app is described in detail, not just the new ones.


Now, if I didn't want the app to use the new permissions, I only have one choice; don't install the update. This becomes tricky if I want other new features of fixes, as a user I can't be granular. However, as previously described, the new version of Android, 'M', is due to make significant improvements to the granular control and to the user experience of being notified that apps are using certain hardware or software functions.

And finally...

Whilst we're on the topic of app updates, a special mention has to go to Shifty Jelly for their Pocket Casts release notes. They do the job of describing new features and permissions required, but also include some great humour at the same time, always amusing!

No comments: