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.
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.
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.
If the only goal was to preserve privacy in 2014, then you would be correct. However, the actual goal is to preserve privacy in the future, so the current state is not the final word. Instead, we must use our intelligence to predict what can happen in the future, so that we may preempt those problems before they become widespread.
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.
> 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.
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.
As soon as it is on your device, it is no longer the developer's program, but your copy.
Ownership (as opposed to renting) enables distributed rights instead of centrally-granted privileges. Hoping that competition between centralized privilege-granters will compensate for a lack of true rights is an error based in the fallacy of efficient markets.
In reality, competition/enforcement is not perfect and defaults matter. To expand on the example I just gave, Honda could indeed require me to sign a contract saying I will not use the car to drive to a Toyota dealer. But with no way of stopping me, their only recourse is to exert resources bringing me to court. To be motivated to do so, they must be actually suffering real harm rather than a mere general desire of trying to prevent competition. So ridiculous ideas like that end up laughable non-starters rather than ever present niggling restrictions that are too numerous to fight.
Which is fine and dandy, just don't expect Google's or the developer's help to do so. I'll say it again - if one of the terms I license (sell a license) my app under is that it must have location data, you are entitled to either provide that data or not use the app.
Yes sure, but you're just referencing the knows-best authoritarian thought that has gotten us into this mess in the first place. The current state of the "art" doesn't change what is right, so you're merely pointing out that Google's developers are not working to preserve users' freedom.
I'll say it to be clear - regardless of what you think your "terms" are, they're irrelevant to the functioning of my computational devices.
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?
If the user configures the emergency weather broadcast app to receive randomized data, yes obviously.
The app should be "forced" to run with modified data, because that is what the user explicitly chose. The whole point of an app is that it runs on the user's device, meaning it should be ultimately acting in the user's best interest, despite any post-facto desires of the developer. That is the whole idea of ownership - I can drive my current Honda to browse for new cars at the Toyota dealership, etc.
What would happen when the aforementioned emergency weather broadcast app fails to notify users of a tornado coming their way, because it was given the wrong locations? What would that do to the app's reputation? How many people would believe it's user's fault as oppose to blaming the shitty app?
By your logic, a laptop with li-ion battery can be "forced" to keep running in an 140F degree environment, because that's what user "explicitly chose". When it explodes, who's getting the blame?
There's something call operational envelope, which applies to software too. And believe it or not, that is for user's "best interest".
Or when the user's location reporting is off, or their network has been firewalled, or they're 60 miles away at work but really would have liked to know that a storm was coming for their house?
I mean sure, you may face some public outrage. On the other hand, you may have to deal with a twitstorm for any number of other ridiculous reasons. Should the ideal really be to give everyone safety scissors because you're worried about the rare dolt that doesn't know which end to hold? That's the kind of attitude that dumbs the whole of society down and fuels the entitled mob who blames everyone else for their own mistakes.
What you called the user's "best interest" is based on know-it-all paternalism. For 90% of things it will agree, but don't mistake your model user's utility function for actual individuals'.
(And for your li-ion example, there's a reason that's done with a thermal fuse instead of software, which means that the design is fixed. But to the extent that it is done in software instead, then yes it should be end-user adjustable, even if it seems like a really bad idea for them to do so)
I'm not sure denying an app permission to use your data is the same as explicitly choosing to provide that app with randomized data.
If you want to ensure that the system is only doing what the user explicitly chose to do, you need to provide prompts that let the user explicitly choose to provide randomized data.
And at that point, we're probably better off just returning nothing.
It's not really hard.. one choice with a multitude of options:
Choose Level of Location Access:
1. Full access (exact location)
2. Nearest [major intersection, city, state]
3. Fixed location [home, work, present location, choose from map]
4. Random walk [choose area from map]
5. Ask me every time
6. Deny
Go ahead and default/emphasize the most-desired and least-confusing options so that fewer mistakes are made. But treating users like children and restricting their options in the name of 'usability' is downright wrong. Your average person seems quite dumb due to disinterest, but give them options and abilities they didn't know they could have, and watch as their interest perks up.
If the phone is mine, then I should be able to easily set it to lie on my behalf to protect my interests.