[Zigurd]

This is about the easiest change for developers to accommodate. All they need to do is handle one exception.

Most of the permission bloat on Android comes from ad network libraries that do a crappy job of behavioral targeting anyway. Turning off that kind of obnoxious data exfiltration isn't going to hurt anyone, least of all the user.

I don't recall there being an outcry over how painful it was to use permission revocation.

[madeofpalk]

> This is about the easiest change for developers to accommodate. All they need to do is handle one exception.

But apps didnt have to handle that exception before.

If permissions are rejected, it should just return empty data.

[Karunamon]

Random dummy data would be even better - if you return blank, you give the app a way to know that it's being blocked.

Apps are guests in the user's back yard, not the other way around.

[jljljl]

How do you provide random dummy data for a Contact List permission without a) running the risk of crashing the app, or b) making it obvious to the app that it's receiving dummy data?

Is android supposed to return a well structured list of fake names and emails? Would instagram show me a list of made up names and user id's if I faked my contacts?

[userbinator]

If Android has a way of faking location data, I don't see why a contact list would be any different:

https://developer.android.com/training/location/location-tes...

[chinpokomon]

Considerably different. Mock location data simply provides the location you want over ADB. It is a supplied value.

[userbinator]

It doesn't need ADB. There's an app for that: https://play.google.com/store/apps/details?id=com.lexa.fakeg...

So it is similar in that you could conceivably have an app that manages fake contact lists' data.

[Karunamon]

http://www.fakenamegenerator.com/

This exists. Something similar is hardly out of Google's reach.

[jljljl]

Think about the experience for a second:

1. An app asks for permission to access my contacts 2. I decline to give permission 3. The app churns for a few seconds, then suddenly returns a list of names that i have never seen before, including fake numbers and addresses (a list of fake names would be too easy to detect as a fake response).

We're probably better off just returning nothing

[madeofpalk]

Apps should be able to know what permission they currently have - there's very little (if any) breach of privacy from that.

I'm just talking about preventing apps from crashing if they don't handle revoked permissions properly.

[mindslight]

Erm, no they should not. The same breach of privacy will occur when an app just re-implements the demanding of a permission. "This camera app will not run without access to your list of contacts. Enable Contact List Access and restart to proceed".

If the phone is mine, then I should be able to easily set it to lie on my behalf to protect my interests.

[micampe]

On iOS you can disable any permission at any time for any application and it's plainly explicit in the API. I've never seen any application do what you describe.

The typical example people make is Facebook, which they assume would block you if denied your location but instead works just fine when you remove access to location, camera, photos, and contacts. I don't see why they would behave differently on Android.

[mindslight]

For the straightforward example I gave there would be a backlash, especially for the bigger names. But that doesn't mean it's a stable situation, or that other examples wouldn't escape outrage in a different context - "This video can only be played if you enable Location Permission so that we can verify you are in the correct region."

The goal when designing an interface should be to get it right, not to make something that works for now but will just have to be patched up again later. For many permissions, it would be advantageous for the user to not even outright deny, but to return a subset or otherwise modified data - only one contact group, fixed location data, filtered Internet, etc. This of course sounds like heresy to app developers, and that's exactly the point - it's the user's device.

[Karunamon]

That's not a breach of privacy. That's the developer enforcing their TOS. It is within my right to say that if you won't give me location information for (ad targeting/basic functionality), you can not use my app.

Which is fine, but I'd also expect one-stars for that kind of behavior.

[mindslight]

> It is within my right to say that if you won't give me location information for ad targeting, you can not use my app

I disagree. That question is exactly what we're discussing here. What you just said clashes with what you said earlier:

> Apps are guests in the user's back yard, not the other way around.

Either a developer is able to enforce their desired "TOS" on the user's device, or they cannot.

I am on the side of cannot, because attempting to define morals through simple rules ("right to contract") and then asserting that all emergent behavior from those rules is just, fails extremely hard with complexity-induced contradictions. The whole idea behind saying that a user owns the device is to make it clear that the Schelling demarcation point is the protocol, with each party carrying out such in their own best interest. Assuming an ambient authority (a legal contract, in this case) that constrains the behavior of the user's device runs directly counter to this.

[veeti]

> This is about the easiest change for developers to accommodate. All they need to do is handle one exception.

One exception, possibly in hundreds of different places in the code. What a ridiculous assumption to make: "just about the easiest change"? Seriously?

Adding real permission revoking into Android at this point is a total no-go. The real solutions to this issue are App Ops (which transparently stubs out API's by returning blank data or simply ignoring calls) and optional permissions (for developers) in cases like temporary access to contacts.

Both already exist in the AOSP codebase in one way or another. Only the settings UI for app ops is gone, and optional permissions are under work [1].

[1] https://android.googlesource.com/platform/frameworks/base/+/...