[userbinator]

Why wouldn't Google want users to have such powerful control over their devices? It's always explained like this: Because it's "simpler." Because "things will break if the user does something wrong." Because "the average user won't need it."

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

[Karunamon]

Or, rather, it could be because the feature was unfinished and tended to crash applications when they don't get the stuff that's called for (and the user authorized) on the permission manifest.

http://pocketnow.com/2013/12/17/app-ops

Something something malice stupidity. But no, let's bring out the torches and pitchforks...

[dilap]

I'm a user/dev on the iOS side, and you're definitely right that apps need to be coded to specifically handle cases where they don't get permissions, but...

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

[mortenjorck]

What happens today if an app requires address book access but the user has an empty address book?

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.

[Karunamon]

The app receives an empty address book (as opposed to NO address book), an empty calendar (as opposed to NO calendar), and in your location case, the app gets the "rough" location provided by the cell network.

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.

[mortenjorck]

I don't think you're understanding what I'm suggesting.

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.

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

[Karunamon]

http://www.fakenamegenerator.com/

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

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

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

[wahsd]

I would bet money it has to do with business decisions that relate to carrier demands to support Android. People forget that Android is not in the same position as iOS to impose its will on carriers. Rather, the power dynamics are rather significantly the opposite, Android has to do far more negotiation and accommodating to assuage carriers.

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.

[untog]

That's exactly the reason, and it's more legitimate than you give it credit for. I can foresee numerous situations where users disable location tracking (in the name of saving battery) without realising the effect it will have (rendering a location-based app useless).

A nice middle ground would be to keep App Ops, but hidden away somewhere, much like the Developer Tools are.

[pessimizer]

>users disable location tracking (in the name of saving battery) without realising the effect it will have (rendering a location-based app useless).

If you can assume that location data would be available, you can also assume that users will be sentient.

[Karunamon]

And random developers start getting one-star "Doesn't work!" reviews because our "sentient" user forgot to change their settings.

[jessriedel]

This is easy to fix. Just have the app notify the user that feature X will break without permission Y. The user can then make the decision.

[oshepherd]

So I have an application which can attach location information to posts made from it. It requests access to location data (as is necessary) when installed, then lets you turn that feature on or off from an internal setting.

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.

[fooqux]

Any programmer worth their salt should, whenever doing any sort of IO (regardless of hardware, cloud, or otherwise) should be making sure they get a sane result/object back. Purely anecdotal here, but I run XPrivacy and have the vast majority of my apps blocked from location. You'd think my phone would barely work, but it actually works fine. I don't think I've ever had an application crash from lack of GPS.

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.

[fleitz]

Because Android isn't the product, you are the product.

[Oletros]

Why people still uses that false meme?

Can you explain me why people is the product if they use Android?

[fleitz]

Because given away for free to generate traffic on google properties, therefore Google will not ship features in Android that would be detrimental to the monetization of an android user by allowing them to control their privacy.

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.