6 ms·

This page has more detail on Android's permissions model: http://developer.android.com/guide/topics/security/permissions.html#perm-groups http://developer.andro

This page has more detail on Android's permissions model: http://developer.android.com/guide/topics/security/permissions.html#perm-groups http://developer.android.com/guide/topics/security/permissio... I don't really understand the point of having fine-grained permissions (like READ_CONTACTS), when the user only sees broader permission groups. Can someone shed light on this?

theoduino 11y ago
"Simplified Permissions" is a relatively new feature of the Play Store and only gives you general permission categories. It was probably changed from the older specific permissions to make it less complex for people who didn't care as much. Note that PackageInstaller still shows all permissions, which is used when clicking on an apk or using a 3rd party app store (like F-Droid). Due to backwards compatibility, this can't be changed easily at the OS level.
tadfisher 11y ago
It wasn't always this way. The individual permissions used to be displayed to the user directly; newer releases of the Play Store have "streamlined" this permissions prompt so that users see general permissions "groups", and some permissions (such as INTERNET) are considered "not dangerous", requiring a click on the "See all permissions" button to view everything the app requests. I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates. Then they threw the whole system out with Android 6.0, moving to a much more sane flow for everyone involved, where the user is able to grant or deny individual permissions at runtime.
- profeta 11y ago
  > system is broken and UI is confusing, protect nothing from user even if working right. > leave system broken but hide UI so nobody cares. hopefully, it is just incompetence, not evil.
  - newjersey 11y ago
    When it comes to Uber, I think the default is to assume malice unless we can prove it is incompetence.
    - chris_wot 11y ago
      Yeah, I'm afraid that in Uber's case this is what you must assume. Normally I don't default to such a state, I honestly feel that most times it's just incompetence within an organization, but in Uber's case they have been a bad actor for a long time now so they just can't be trusted. I won't be using Uber, ever.
      - Spare_account 11y ago
        I'm a latecomer to this situation, what have Uber done in the past to earn that reputation? Genuine question.
        grogenaut 11y ago
        http://www.theverge.com/2014/11/18/7240215/uber-exec-casually-threatens-sarah-lacy-with-smear-campaign http://www.theverge.com/2014/11/18/7240215/uber-exec-casuall... http://www.businessinsider.com/an-uber-exec-brought-up-the-idea-of-spying-on-journalists-2014-11 http://www.businessinsider.com/an-uber-exec-brought-up-the-i... to start... theres more
        frostymarvelous 11y ago
        Uber us quite literally a supervillain! They've done almost every despicable thing in the tech industry. Sabotage, illegal practices etc al. That's why this is actually big on HN. With uber, shoot first then ask questions later!
    - garrettgrimsley 11y ago
      GP was talking about the Android permissions system, not Uber.
- wfunction 11y ago
  Do you happen to know in which version of the Play Store this change was made?
- taneq 11y ago
  > I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates. Because the way to fix "apps can demand a laundry list of permissions and users can only take it or leave it" is to sweep it under the rug? A sane way to do it would be the way browsers deal with location data: "App [appname] is requesting permission to access [resource]. Allow always / allow / deny / deny always?"
  - dlitz 11y ago
    That's how it works in Android 6.0 (Marshmallow) and above.
    - anowlcalledjosh 11y ago
      Kind of, but you still get the situation where an app wants to get your IMEI to identify the device, but is forced to ask for permission to 'phone', which the user promptly denies because that also allows the app to make phone calls.
      - xorcist 11y ago
        What does an app want my IMEI for? How do they work on non-cellular tablets (and PCs) which doesn't have one?
        mderazon 11y ago
        Lots of apps use IMEI as a unique device identifier on Android. A practice that is discouraged by Google. Anyway, since 6.0, developers should find a different way to udid. One alternative is Advertising ID which doesn't require any special permissions but is resettable by the user (though not easily found in the system's settings) http://developer.android.com/google/play-services/id.html http://developer.android.com/google/play-services/id.html
ross-life 11y ago
> Can someone shed light on this? Whoever is in charge of the permission system is absolutely nuts. Or it's designed by the committee from hell. Those are the only reasons I can think of. No one sane would create this. They actually wanted to "simplify" the permissions system and let the user have more control/understanding. You could argue they've done the first... at the expense of everything else. Half of it seems to have been introduced so "it bugs you less", which is not the point, I want to be bugged (by default) so I know what applications are actually doing. If users wants to "not be bugged" let them manually set it, don't make it default. I've meant to write a post titled "Android 6 permissions: Still pants" after buying a Nexus 5X and being happy with the phone/camera but utterly disappointed with the "revamped" permission systems: - Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose... - Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict? - You get an Internet, you get an Internet, every application gets an Internet. Because every application needs Internet right? It's not like I'd maybe want to install an application to manipulate a specific file type right now but don't want it connecting all over the net right? Maybe I don't have time to verify it's not nefarious. Maybe I just want control over what applications can actually phone home from my device? - "Runtime permissions" is hit and miss. Some applications ask and then respect the answer. Others will just pop up the dialog over and over and over again until you accept it... which was not the point. - READ_PHONE_STATE is still terrible. It's used by app/games to pause tasks when the user gets a phone call but... also gives away the number that's calling you! Of course, nearly every application then requests this. I don't get it, it's yet another obvious use case ("Let the application know the user is busy without leaking any data") that seems to have been glossed over. I thought by this point they'd have a proper IS_USER_BUSY permission that tells applications that you're in a phone call/whatever but doesn't leak any of your personal data *whatsoever". At this point my next phone will be an iPhone/iOS, even though I don't particularly like them as at least security/sane permissions seems to mean something over there...
- 11y ago
curt15 11y ago
The permissions system does not exist only for the user. In fact, as described here (https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html https://developer.apple.com/library/mac/documentation/Securi...), the primary purpose of sandboxing apps is to help developers secure their apps. "By limiting access to resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data if an attacker successfully exploits security holes in your app or the frameworks it is linked against." As such, from the developer's perspective the ideal permissions system should actually be as fine grained as possible to let the developers minimize the exposure of their apps. Android's permissions system was probably designed from this point of view.
- LeoNatan25 11y ago
  Let's be cynical but real here, how many developers care or are even security aware? Here on HN, maybe most are, but out there, most people don't really have a clue or care about the user's data. As long as there is some revenue, all is "well". This is why such things should be enforced in the OS, with a strict security model, and such shady permission overreach should be frowned upon.
on_and_off 11y ago
That's because the permission model is back compatible. Instead of creating a new 'access contact permission', the permissions are now bundled automatically. That way the same manifest (where you declare a bunch of things about your app, including its permissions) can be used for both old and new devices. As far as the manifest is concerned, it would have been easy to automatically generate the old permission list from a new permission list like {Contacts, Calendars, ...} but you would also have to create a new library to translate these new permissions to the old ones in the code (since old OS versions still only understand the permissions that existed with them) ... It is probably easier to just keep the old permissions.

theoduino 11y ago

"Simplified Permissions" is a relatively new feature of the Play Store and only gives you general permission categories. It was probably changed from the older specific permissions to make it less complex for people who didn't care as much. Note that PackageInstaller still shows all permissions, which is used when clicking on an apk or using a 3rd party app store (like F-Droid). Due to backwards compatibility, this can't be changed easily at the OS level.

tadfisher 11y ago

It wasn't always this way. The individual permissions used to be displayed to the user directly; newer releases of the Play Store have "streamlined" this permissions prompt so that users see general permissions "groups", and some permissions (such as INTERNET) are considered "not dangerous", requiring a click on the "See all permissions" button to view everything the app requests. I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates. Then they threw the whole system out with Android 6.0, moving to a much more sane flow for everyone involved, where the user is able to grant or deny individual permissions at runtime.

profeta 11y ago
> system is broken and UI is confusing, protect nothing from user even if working right. > leave system broken but hide UI so nobody cares. hopefully, it is just incompetence, not evil.
- newjersey 11y ago
  When it comes to Uber, I think the default is to assume malice unless we can prove it is incompetence.
  - chris_wot 11y ago
    Yeah, I'm afraid that in Uber's case this is what you must assume. Normally I don't default to such a state, I honestly feel that most times it's just incompetence within an organization, but in Uber's case they have been a bad actor for a long time now so they just can't be trusted. I won't be using Uber, ever.
    - Spare_account 11y ago
      I'm a latecomer to this situation, what have Uber done in the past to earn that reputation? Genuine question.
      - grogenaut 11y ago
        http://www.theverge.com/2014/11/18/7240215/uber-exec-casually-threatens-sarah-lacy-with-smear-campaign http://www.theverge.com/2014/11/18/7240215/uber-exec-casuall... http://www.businessinsider.com/an-uber-exec-brought-up-the-idea-of-spying-on-journalists-2014-11 http://www.businessinsider.com/an-uber-exec-brought-up-the-i... to start... theres more
      - frostymarvelous 11y ago
        Uber us quite literally a supervillain! They've done almost every despicable thing in the tech industry. Sabotage, illegal practices etc al. That's why this is actually big on HN. With uber, shoot first then ask questions later!
  - garrettgrimsley 11y ago
    GP was talking about the Android permissions system, not Uber.
wfunction 11y ago
Do you happen to know in which version of the Play Store this change was made?
taneq 11y ago
> I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates. Because the way to fix "apps can demand a laundry list of permissions and users can only take it or leave it" is to sweep it under the rug? A sane way to do it would be the way browsers deal with location data: "App [appname] is requesting permission to access [resource]. Allow always / allow / deny / deny always?"
- dlitz 11y ago
  That's how it works in Android 6.0 (Marshmallow) and above.
  - anowlcalledjosh 11y ago
    Kind of, but you still get the situation where an app wants to get your IMEI to identify the device, but is forced to ask for permission to 'phone', which the user promptly denies because that also allows the app to make phone calls.
    - xorcist 11y ago
      What does an app want my IMEI for? How do they work on non-cellular tablets (and PCs) which doesn't have one?
      - mderazon 11y ago
        Lots of apps use IMEI as a unique device identifier on Android. A practice that is discouraged by Google. Anyway, since 6.0, developers should find a different way to udid. One alternative is Advertising ID which doesn't require any special permissions but is resettable by the user (though not easily found in the system's settings) http://developer.android.com/google/play-services/id.html http://developer.android.com/google/play-services/id.html

ross-life 11y ago

> Can someone shed light on this? Whoever is in charge of the permission system is absolutely nuts. Or it's designed by the committee from hell. Those are the only reasons I can think of. No one sane would create this. They actually wanted to "simplify" the permissions system and let the user have more control/understanding. You could argue they've done the first... at the expense of everything else. Half of it seems to have been introduced so "it bugs you less", which is not the point, I want to be bugged (by default) so I know what applications are actually doing. If users wants to "not be bugged" let them manually set it, don't make it default. I've meant to write a post titled "Android 6 permissions: Still pants" after buying a Nexus 5X and being happy with the phone/camera but utterly disappointed with the "revamped" permission systems: - Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose... - Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict? - You get an Internet, you get an Internet, every application gets an Internet. Because every application needs Internet right? It's not like I'd maybe want to install an application to manipulate a specific file type right now but don't want it connecting all over the net right? Maybe I don't have time to verify it's not nefarious. Maybe I just want control over what applications can actually phone home from my device? - "Runtime permissions" is hit and miss. Some applications ask and then respect the answer. Others will just pop up the dialog over and over and over again until you accept it... which was not the point. - READ_PHONE_STATE is still terrible. It's used by app/games to pause tasks when the user gets a phone call but... also gives away the number that's calling you! Of course, nearly every application then requests this. I don't get it, it's yet another obvious use case ("Let the application know the user is busy without leaking any data") that seems to have been glossed over. I thought by this point they'd have a proper IS_USER_BUSY permission that tells applications that you're in a phone call/whatever but doesn't leak any of your personal data *whatsoever". At this point my next phone will be an iPhone/iOS, even though I don't particularly like them as at least security/sane permissions seems to mean something over there...

11y ago

curt15 11y ago

The permissions system does not exist only for the user. In fact, as described here (https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html https://developer.apple.com/library/mac/documentation/Securi...), the primary purpose of sandboxing apps is to help developers secure their apps. "By limiting access to resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data if an attacker successfully exploits security holes in your app or the frameworks it is linked against." As such, from the developer's perspective the ideal permissions system should actually be as fine grained as possible to let the developers minimize the exposure of their apps. Android's permissions system was probably designed from this point of view.

LeoNatan25 11y ago
Let's be cynical but real here, how many developers care or are even security aware? Here on HN, maybe most are, but out there, most people don't really have a clue or care about the user's data. As long as there is some revenue, all is "well". This is why such things should be enforced in the OS, with a strict security model, and such shady permission overreach should be frowned upon.

on_and_off 11y ago

That's because the permission model is back compatible. Instead of creating a new 'access contact permission', the permissions are now bundled automatically. That way the same manifest (where you declare a bunch of things about your app, including its permissions) can be used for both old and new devices. As far as the manifest is concerned, it would have been easy to automatically generate the old permission list from a new permission list like {Contacts, Calendars, ...} but you would also have to create a new library to translate these new permissions to the old ones in the code (since old OS versions still only understand the permissions that existed with them) ... It is probably easier to just keep the old permissions.