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

[chinpokomon]

True, but that is just performing the same data mocking that the ADB method uses. It really doesn't change my statement.

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

[micampe]

As I said, your conjecture is proved wrong by reality.

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

[Karunamon]

That doesn't clash at all. It's maximal freedom on both sides - you decide under what terms the developer's program runs. If the developer doesn't like those terms, the app doesn't run.

Either the user accepts the developers desired TOS on their device, and they get to run the app, or they do not.

I'd go a lower level than the legal contract. If the app says it wants X to run, and you deny X, the app is under no obligation to run. Your back yard, their code.

[jljljl]

It's not constraining the behavior of the user's device, it's constraining the functionality of the app. If an app needs certain permissions to function, and the user denies those permissions, why should the app be forced to run with falsified data?

Imagine that the use case is not ad targeting, but rather emergency weather broadcasts based on your location. Do we still want the app to receive randomized data?