8 ms·

The problem with permissions on Android is that it is an all or nothing choice. You either grant all the permissions an app asks for or you decline, in which yo

by pan69 12y ago

The problem with permissions on Android is that it is an all or nothing choice. You either grant all the permissions an app asks for or you decline, in which you can't use the app. Is it really that difficult to have a list of fine grained permissions presented to the user with on/off selections? They can all be on by default but it at least gives the user the option to have an app NOT to access your contacts if it clearly has no business doing so in the first place (some dumb game or something). If an app is not granted a permission it's up to the app to deal with that.

mrgriscom 12y ago
The likely result though is that the app will simply refuse to run if not granted the permission.
- pan69 12y ago
  If so, it clearly illustrates the nature of the app. I.e. it's a bunch of fluff designed to harvest peoples contacts or whatever. Or maybe just lazy developers. At least it gives me as a user a choice (which I guess I already had with the blanket permissions scheme) but it also gives me as an app developer the opportunity to create a better app that's more trust worthy.
  - ossreality 12y ago
    How the hell does that make any sense? I designed my app to request a permission (and if the user rejects it, at install time, my code will never run). So now you've rigged it so that it returns bad data. And given TazeT's comment above, and scenario, now, you've broken some piece of functionality that will never breakf for any other user anywhere. But your assumption is, "must be spyware". Gimme a break.
- barrkel 12y ago
  The app doesn't need to know that it hasn't been granted permission. (I.e. stub the api, have it return mock data.)
  - regecks 12y ago
    Exactly. I do this with XPrivacy for every single application I download: deny access to contacts, Google/Facebook Account, Phone Serial Number, deny access to network if the application doesn't need it. I've never had an application refuse to run because of it, and I'll never use a phone without XPrivacy again (it's scary what some apps request).
  - MBCook 12y ago
    That could have negative consequences. Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear. Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures? If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life. Just seems like you're likely to create situations that are confusing/suboptimal for users. Let the app know what's going on. If the app doesn't behave well in that circumstance it should be removed from the store or punished by users with poor reviews.
    - barrkel 12y ago
      The best is the enemy of the good.
    - biotech 12y ago
      True, it could have negative consequences. But aren't the negative consequences of the current system even worse? Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear. So the phone uses more CPU and battery. It's not that big of a deal. Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures? Yes, Android can tell the app that there are no photos. If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life. We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?
- gizmo686 12y ago
  That depends on your model for the developer. If the developer is trying to exploit the user, then he may make the app refuse to run. Or if the developer is to lazy to handle not having the permission, he may allow the app to crash. However, there are also cases where the developer wants to add a useful, but not necessary, feature which requires additional permissions.
dragonwriter 12y ago
> Is it really that difficult to have a list of fine grained permissions presented to the user with on/off selections? Difficult to do at all? No. Difficult to do without horrible UX? Yes. Fine grained permissions means apps that do useful things need lots of them, and presenting all of them with "on/off selections" is likely to be both ugly and confusing for most users.
- StavrosK 12y ago
  You'd think, but the Blackphone's Security Center manages to do that very easily, with great UX. I use XPrivacy on my HTC One and the UX is a mess of mystery buttons and weird, technical options. Blackphone has a on/off switches for things like "Camera & Audio", "Record audio", "Read contacts", etc. There's also a tab for non-privacy-related permissions, e.g. vibrate, notification, keep awake, etc, which are on by default, to make sure the app isn't unnecessarily limited by default. It's miles better than the default Android permissions system, and one of the features I like best about the phone. Android could very easily implement something like that, with a dialog asking if the user wants to grant the permission, with perfect backwards compatibility (since there are devices/software that does it now), and I hope they do.
- userbinator 12y ago
  With a hierarchical UI, the permissions can be controlled easily as finely or coarsely as desired. Something like this: - [*] Phone | |--[ ] Make outgoing calls | |--[ ] Answer incoming calls | \--[X] Read call log | + [X] Access Location Services | - [ ] Network | |--[ ] Outgoing connections | \--[ ] Incoming connections (listen) ...
SnacksOnAPlane 12y ago
I think that presenting a list of toggleable permissions isn't the problem. The problem is that all the apps out there right now depend on having all the permissions that they ask for, and you'll end up with random crashes all the time when users deny permissions. I think that eventually app coders would change their code to degrade gracefully when denied access to something, but in the short-term, people would think that Android was unstable.
- x1798DE 12y ago
  I've been using App Ops for a few months now on a rooted phone and I've turned off a good deal of permissions for various apps. I haven't had any force crashes from that so far. I expected it to be a bigger problem than it is.
  - SnacksOnAPlane 12y ago
    That's good to hear, but how representative of a sample are your apps? I think more tech-oriented people gravitate towards well-coded apps that deal with exceptions well. There's lots of poorly-coded apps that don't.
    - x1798DE 12y ago
      You may certainly be right on that front. I have no idea how well-coded most of the apps are, but my most heavily-used apps tend to be stable ones just by virtue of the fact that when apps become unstable, I find replacements. My guess is that many people have the same workflow. That said, I don't use any social networks, I don't play very many games on my phone, and I don't have any children, so I don't have any of these apps where you interact with a cartoon cat, or that show you arbitrary colors and play noise or otherwise distracts children, so there are certainly large subsets of the app ecosystem that I really am not taking advantage of.
- pan69 12y ago
  I think this would only work with a new "advance" permissions sub-system. Introducing a new permissions sub-system has three benefits; 1) old apps will continue to work 2) the old system can be deprecated at some point in time giving developers ample time to upgrade their apps 3) new apps can start to use the new system creating more trust between the developer and the user.

by pan69 12y ago

mrgriscom 12y ago

The likely result though is that the app will simply refuse to run if not granted the permission.

pan69 12y ago
If so, it clearly illustrates the nature of the app. I.e. it's a bunch of fluff designed to harvest peoples contacts or whatever. Or maybe just lazy developers. At least it gives me as a user a choice (which I guess I already had with the blanket permissions scheme) but it also gives me as an app developer the opportunity to create a better app that's more trust worthy.
- ossreality 12y ago
  How the hell does that make any sense? I designed my app to request a permission (and if the user rejects it, at install time, my code will never run). So now you've rigged it so that it returns bad data. And given TazeT's comment above, and scenario, now, you've broken some piece of functionality that will never breakf for any other user anywhere. But your assumption is, "must be spyware". Gimme a break.
barrkel 12y ago
The app doesn't need to know that it hasn't been granted permission. (I.e. stub the api, have it return mock data.)
- regecks 12y ago
  Exactly. I do this with XPrivacy for every single application I download: deny access to contacts, Google/Facebook Account, Phone Serial Number, deny access to network if the application doesn't need it. I've never had an application refuse to run because of it, and I'll never use a phone without XPrivacy again (it's scary what some apps request).
- MBCook 12y ago
  That could have negative consequences. Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear. Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures? If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life. Just seems like you're likely to create situations that are confusing/suboptimal for users. Let the app know what's going on. If the app doesn't behave well in that circumstance it should be removed from the store or punished by users with poor reviews.
  - barrkel 12y ago
    The best is the enemy of the good.
  - biotech 12y ago
    True, it could have negative consequences. But aren't the negative consequences of the current system even worse? Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear. So the phone uses more CPU and battery. It's not that big of a deal. Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures? Yes, Android can tell the app that there are no photos. If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life. We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?
gizmo686 12y ago
That depends on your model for the developer. If the developer is trying to exploit the user, then he may make the app refuse to run. Or if the developer is to lazy to handle not having the permission, he may allow the app to crash. However, there are also cases where the developer wants to add a useful, but not necessary, feature which requires additional permissions.

dragonwriter 12y ago

> Is it really that difficult to have a list of fine grained permissions presented to the user with on/off selections? Difficult to do at all? No. Difficult to do without horrible UX? Yes. Fine grained permissions means apps that do useful things need lots of them, and presenting all of them with "on/off selections" is likely to be both ugly and confusing for most users.

StavrosK 12y ago
You'd think, but the Blackphone's Security Center manages to do that very easily, with great UX. I use XPrivacy on my HTC One and the UX is a mess of mystery buttons and weird, technical options. Blackphone has a on/off switches for things like "Camera & Audio", "Record audio", "Read contacts", etc. There's also a tab for non-privacy-related permissions, e.g. vibrate, notification, keep awake, etc, which are on by default, to make sure the app isn't unnecessarily limited by default. It's miles better than the default Android permissions system, and one of the features I like best about the phone. Android could very easily implement something like that, with a dialog asking if the user wants to grant the permission, with perfect backwards compatibility (since there are devices/software that does it now), and I hope they do.
userbinator 12y ago
With a hierarchical UI, the permissions can be controlled easily as finely or coarsely as desired. Something like this: - [*] Phone | |--[ ] Make outgoing calls | |--[ ] Answer incoming calls | \--[X] Read call log | + [X] Access Location Services | - [ ] Network | |--[ ] Outgoing connections | \--[ ] Incoming connections (listen) ...

SnacksOnAPlane 12y ago

I think that presenting a list of toggleable permissions isn't the problem. The problem is that all the apps out there right now depend on having all the permissions that they ask for, and you'll end up with random crashes all the time when users deny permissions. I think that eventually app coders would change their code to degrade gracefully when denied access to something, but in the short-term, people would think that Android was unstable.

x1798DE 12y ago
I've been using App Ops for a few months now on a rooted phone and I've turned off a good deal of permissions for various apps. I haven't had any force crashes from that so far. I expected it to be a bigger problem than it is.
- SnacksOnAPlane 12y ago
  That's good to hear, but how representative of a sample are your apps? I think more tech-oriented people gravitate towards well-coded apps that deal with exceptions well. There's lots of poorly-coded apps that don't.
  - x1798DE 12y ago
    You may certainly be right on that front. I have no idea how well-coded most of the apps are, but my most heavily-used apps tend to be stable ones just by virtue of the fact that when apps become unstable, I find replacements. My guess is that many people have the same workflow. That said, I don't use any social networks, I don't play very many games on my phone, and I don't have any children, so I don't have any of these apps where you interact with a cartoon cat, or that show you arbitrary colors and play noise or otherwise distracts children, so there are certainly large subsets of the app ecosystem that I really am not taking advantage of.
pan69 12y ago
I think this would only work with a new "advance" permissions sub-system. Introducing a new permissions sub-system has three benefits; 1) old apps will continue to work 2) the old system can be deprecated at some point in time giving developers ample time to upgrade their apps 3) new apps can start to use the new system creating more trust between the developer and the user.