I own a Google Nexus 7, on which I have CyanogenMod installed. I use Google Play for apps. By and large, the permissions that an app 'requires' can make sense. However, sometimes they don't:


So, an app for getting news wants information on my identity, my location, my personal files, my camera and microphone, the wifi connections my tablet records and what uniquely identifies my tablet.

What could RTÉ want with this information? I asked them:


I didn't get an answer. Not really surprising. In the meantime, I still haven't updated the app, and will probably remove it: I can see no good reason for a news-broadcasting app to have access to those private resources on my device.

Here are two changes to the app-permissions architecture that I think should be implemented:

Require apps to state what the resource access will be used for, and allow reporting of abuse.

Apps should be required to provide a specific reason related to the functionality of the app for requiring a 'permission'. Examples would include…

  • "Camera and microphone access required for capturing videos"
  • "Access to personal files required to upload photos"
  • "Location access required to identify relevant service providers near to you"
  • and so on.

This would allow users to decide whether these are valid functions for the app they're installing (e.g. I can't think of a valid use a news app would have for access to my location).

This would also be backed up by a "Report Abuse" mechanism, which would have at least two purposes:

  • To allow users to report apps to the relevant app store that don't provide sufficient information on what the "permission" is required for.
  • To allow users to report apps to the app store that make use of the permissions that were not flagged to the user (e.g. requesting location information to identify shops close by, which the user knows about, but also to track the user's location on an ongoing basis (a la Whisper), which the user is not informed about).

Allow users to decide which permissions to grant and which to deny

For some reason, access to the device's location information can be denied independently – you can install apps that claim to "require" this resource, but still turn it off separately, and grant the access on an ad-hoc basis.

This seems not to be something you can do with the other resources. So, if an app claims to want access to my contacts list on my device, I can't install it and then turn off that access at the device level.

App stores should require applications to allow users to decide, on an ad-hoc basis, what resources on the device the app can use. In the example of the RTÉ News Now app above, I would like to install the app, and then control what it can access on my device.

It's true that not allowing access to certain resources on the device would result in certain functions of the app not performing well – or at all – but if the above requirement for the app to state the specific purpose of the "permission" is implemented, then the user is fully informed of this.

Some app developers would complain that they can't predict how their app would behave if not all of the "permissions" it requires have been granted. I don't accept this for two reasons. Firstly, most apps that require location information are aware of this resource being denied to them and can behave accordingly (e.g. with a message like "Your device does not permit access to its location information. As a result, we cannot provide the following functionality…"). Secondly, app developers are required to set certain configurations on the app in order to access the device's APIs. When setting these configurations, it's not a great step to require the developer to implement exception handlers for those occasions when the resources are not available.

Finally, a step to join these two features would be to allow the user to decide a the time of installation which permissions to grant and which to deny.

You can't add any comments to this post. If there is something you would like to bring to my attention, please use the contact mechanisms below to get in touch.