Those same poor excuses have been responsible for so much loss of privacy and freedom elsewhere, not just by Google. To me, they're deliberately preventing users from having too much power to control their devices, so they can better persuade them in the direction they want. Then they accidentally gave the users too much, so of course they would say it wasn't intended, but the reaction certainly says that it's precisely what the users want...
http://pocketnow.com/2013/12/17/app-ops
Something something malice stupidity. But no, let's bring out the torches and pitchforks...
...this stuff is critical! Give the user the control, let them break the apps that are over-using permissions, and let the apps update to fix.
You can do this in a pretty intuitive, nice way too -- include a flag in apps that says they've been updated to handle partial permissions correctly, and then if an app that hasn't been updated crashes w/ reduced permissions, throw up a dialog explaining that (1) the devs need to update the app (2) if the app not crashing is critical for the moment, the user should lift the permissions restrictions.
Arguments for "simplicity" seem unconvincing to me -- you want to avoid non-essential complexity to achieve simplicity, but this stuff is important to all users.
What happens today if an app requires calendar access but the user has never added anything to the calendar?
What happens today if an app requires location but the user is out of both GPS coverage and wi-fi range?
App Ops should simply be passing apps the results of the above cases when denying them to a an app built for the current Android permissions system.
Throw nulls (or better yet, exceptions) where an application expects parseable data (and given the current permission paradigm, has every right to expect usable data) and you can very reasonably expect breakage.
This is why the feature needs to cook for longer, not some malice aforethought on Google's part as GP claims.
Yes, throw nulls if the APK identifies itself as supporting App Ops. If it doesn't, well, of course it's going to break when you throw nulls at it. Build a compatibility layer as I described above, and the app will continue to get parseable data when it requests parseable data.
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.
But apps didnt have to handle that exception before.
If permissions are rejected, it should just return empty data.
Apps are guests in the user's back yard, not the other way around.
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?
https://developer.android.com/training/location/location-tes...
So it is similar in that you could conceivably have an app that manages fake contact lists' data.
This exists. Something similar is hardly out of Google's reach.
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
I'm just talking about preventing apps from crashing if they don't handle revoked permissions properly.
If the phone is mine, then I should be able to easily set it to lie on my behalf to protect my interests.
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.
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.
Which is fine, but I'd also expect one-stars for that kind of behavior.
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.
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.
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.
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.
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?
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.
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".
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.
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
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/+/...
Unfortunately, with the waning and sobering infatuation with iPhones and iOS, I have a sense that iOS will start and maybe even has made concessions that it otherwise would not be willing to. We have to realize that as long as network carriers are not what they should be, dumb pipes for data who make their money simply on competitive network performance, we are all subject to a protection racket type dynamic.
A nice middle ground would be to keep App Ops, but hidden away somewhere, much like the Developer Tools are.
If you can assume that location data would be available, you can also assume that users will be sentient.
The request for location data implies the usage of the location feature, so the Android package manager won't let you install it on devices without a coarse location provider.
Therefore, like most Android apps which lookup location information, it just assumed that it could do location lookups. No point testing for a feature which will always be present, right?
Now guess what would happen if you used AppOps to turn location off? That's right, it would crash.
Not exactly acceptable user experience.
Now, what Google should do is probably: * For apps targetting Android 4.5+, certain features with privacy implications will default to OPTIONAL rather than REQUIRED when implied by a permission request. * AppOps is then able to toggle access to features which are declared optional, which apps must handle the absence of anyway.
Part of why they don't crash is the multi-threaded nature of how the location API works in Android. High level: you basically of instantiate the location object at the start of your thread, and give it a call back function to call once it has a location for you. You don't know when/if you will ever get a callback, so you have to put some checks in.
Can you explain me why people is the product if they use Android?
Personally, given the existing complexity of Android I find it funny that they said it would make things too 'complex' to give users control of their privacy.
Evidence?
The AppOps "release" wasn't a release. It was a private screen that accidentally had a public intent filter (default behavior is public, this is an easy thing to miss). The only reason anyone knows about it is because people made "launchers" that opened the screen, it was never reachable by normal means.
What would show Google working actively would be to modify APIs or provide solid guidelines for developers to ensure that arbitrarily closed permissions didn't cause an app to crash or freeze. Making app privacy a high priority for future Android development would be clearly working towards it.
Having a hidden privacy infrastructure means nothing at all.
[fixed unclear sentences]
I wouldn't be surprised if Android v.next had this feature built-in, but it might require a newer API version.
Let that app ask for my location, but let me define location it returns when I refuse real location. Same for contacts/messages.
This would destroy some apps, e.g. Ingress.
IMHO it's better if developers know about fake data so they can factor them in, using plausibility checks. As is, they seem to assume that the data source is real.
I just wish there was a central place that would let me do this per ap for all permisions.
There was an app called 'App Ops' that gave android users the ability to choose which permissions they wanted to grant applications. No root required.
Get too many notifications from an app, or don't need location functionality? You used to be able to turn these features off one-by-one for each app. You could also see the last time an app used location services. Android developers have a bad habit of requesting every permission under the sun, so I've gotten in the habit of disabling the permissions that don't add value for me.
Unfortunately, Google later removed this feature saying that its release was accidental. I thought it was a clean solution to a major problem.
Source: https://www.eff.org/deeplinks/2013/12/google-removes-vital-p...