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.

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.

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.

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.

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.

This is a solvable problem - the trouble is that the various platforms are competing for developers and for app-ecosystem size.

It's extra work for a developer to handle a "permission denied" exception for each external call, but they can do it. A changeover could be done by grandfathering old apps, but requiring all new apps and updated apps to accommodate fine-grained permissions.

If customers had fine-grained control, many apps could no longer be monetized without direct payment from the consumer. An example: The free 2048 app surely doesn't need internet access to run, but it needs it to serve ads.

Extra work and loss of revenue --> grumpy developers switching to other platforms.

It's solvable but it would lead to a lot of short-term pain that Google's not willing to put up with. Who do you think would get blamed when all the apps stopped working correctly?

> 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.

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.

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)
      ...

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

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.

The app doesn't need to know that it hasn't been granted permission.

(I.e. stub the api, have it return mock data.)

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).

In web development there is this notion of Progressive Enhancement [1]. It basically means that if certain functionality is not available you either disable the features that make use of it or you implement an alternative means of making the functionality work.

I understand that permissions are a little bit different but I believe that a similar approach would work with permissions as well assuming that Android would supply a new advanced permissions sub system. With this, if an app isn't granted a specific permission it can either disable the feature (maybe making clear to the user that this is the case) or implement some other alternative functionality.

E.g. an app hasn't been given the permission to read a user's current geo-location. In that scenario the app could ask the user to manually enter a location (e.g. by selecting a position on a map).

Within the current permissions system you could only doing with mocking, as you stated, which I personally find a bit of a hack and probably very confusion to the user.

http://en.wikipedia.org/wiki/Progressive_enhancement

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?

"Give apps everything" and "lie to apps" is not a binary choice. There is a third option, the one iOS takes. Inform the program they don't have access to that information.

> So the phone uses more CPU and battery. It's not that big of a deal.

Battery life is very important in a phone.

> Yes, Android can tell the app that there are no photos.

It could also tell the app "You have been denied the GPS permission."

> We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?

Really? I'm not. And what if turning off GPS was accidental? I'm used to apps telling me "X won't work because GPS access has been disabled." Just breaking the experience with no way of notifying the user why their run logger stopped logging runs is not acceptable design.

It's not an all-or-nothing choice. You could easily have a 3-way toggle between "Allow - Refuse Permission - Send Mock Permission". By default you refuse any permissions you don't want the app to have. If it starts behaving badly, you send the mock permission.

Plus, as others have said, there's nothing wrong with giving users the option.

The best is the enemy of the good.

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.