14

The Android documentation on Permission Groups states that

If an app requests a dangerous permission listed in its manifest, and the app already has another dangerous permission in the same permission group, the system immediately grants the permission without any interaction with the user. For example, if an app had previously requested and been granted the READ_CONTACTS permission, and it then requests WRITE_CONTACTS, the system immediately grants that permission.

Isn't this a security risk? Reading contacts so the app lets me share something with friends is less risky than altering existing contacts, which can be maliciously used, for example, to change every contact's email address to something resembling the original email, but actually leading to the attacker's account, which can continue forwarding the email exchange, unbeknownst to both parties.

The documentation emphasizes the point farther below:

Once again, the system just tells the user what permission groups the app needs, not the individual permissions

The PHONE group includes CALL_PHONE and also READ_CALL_LOG.

Again, a Yelp-like app should be allowed to call a business, or an ordering app can legitimately place a call to the delivery person, but that means the app can also silently read the user's private call logs and send them to whatever adware is bundled with it, since INTERNET is a normal permission that doesn't require user consent. Call logs to certain numbers can be used as basis for blackmailing the user, or (probably more commonly) can serve as very valuable information for advertisers to figure out the user's demographic profile and social network.

Various reports have shown that a staggering number of apps phone home with data the user did not expect. Why then are Android permissions so coarse?

The user's convenience (i.e. not bugging the user too much, in Android M's runtime permissions system) seems like a weak reason. Legit apps without a reason to read the call log, won't ask for the permission, so all of the choices below will only ask the user once, but have different security results:

  1. "Can this app make a phone call" (individual permission)
  2. "Can this app access the phone, redirect outgoing calls (!), and read your contacts list" (current group permission with accurate wording, but unnecessarily scary as most apps will only make calls)
  3. "Allow [this app] to make and manage phone calls" (wording for group permission in Android M, unnecessarily vague)

Same for CALENDAR - the write-only permission to create events is relatively innocuous, but reading the user's private events far less so. Etc.

Are there good reasons why permissions don't need to be more granular?

Improve this question
2
  • I share your concern, but most likely too many requests will drive the user crazy and either avoid using apps altogether, or switch to PRESS_YES_ON_EVERY_CQUESTION mode, therefore Android needs a compromise. On the side note, normal applications don't need to CALL_PHONE, the user expects them to use Intent and launch the default dialer app.
    – Alex Cohn
    Jan 1, 2016 at 8:03
  • The set of NORMAL permissions that don't require user consent are deemed germane to the common app developer process. So basically anything that wants to use the device with an elevated privilege has to have explicit permission from the user. Most users, because of the former behavior of approving all permissions at install time, are unaware that elevated permissions exist in the list. I suspect that more granular permissions were not possible at the time of the M release to allow things like create event vs. read and modify existing calendar events but would that actually make a difference?
    – Bron Davies
    Jan 20, 2016 at 5:39

1 Answer 1

Reset to default
2

They don't want to scare users from using apps - if an app needs to use the phonecall ability it will probably need some more permissions for regular use (getting too much permissions requests from an app will concern users). So to compensate - they put the permissions in groups.

This also effect the usability of the OS - the overall UX is better with less permissions requests: If you look at what is written in developer.android.com about providing explanation for permissions:

Keep in mind that you don't want to overwhelm the user with explanations; if you provide too many explanations, the user might find the app frustrating and remove it.

In paraphrase: they don't want to overwhelm the user with permissions requests - and it also effects the OS ability to explain the permission riskiness to the user: "access contact" instead of read/write contacts and get accounts. Not every user will understand what is SIP - but every one knows what is a phone call.

Improve this answer
2
  • Keeping the UX simple is what I suspected the reason was; which is why I pre-empted this answer by explaining (in revision 2 of my question) how asking for precisely how the phone group permission would be used, would still require only one user permission request dialog.
    – Dan Dascalescu
    Jan 3, 2016 at 1:40
  • 1
    I did try to make the point that keeping the UX simple is also done for security reasons - to make sure a user will get a clear short explanation of what can be done by the group permissions (I do not think they hide the implications from users that are aware enough of their own data potential missus). But I do think that general UX is important enough from their perspective - It is not an OS made for the Pentagon, and as such it can compromise some securities in favor of usability (it is not an accident that they didn't found it important enough until now to add runtime permission).
    – John ingmar
    Jan 3, 2016 at 2:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .