[Frazzydee]

Google seems to have no interest in protecting android users from this either.

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

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

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

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

[presootto]

There's always going to be some conflict of interest when the company who builds the OS is the same one that runs the advertising platform.

[scep12]

It was never released -- they removed access to a feature that was not intended for the public. That seems well within their right. For you to declare "Google seems to have no interest in protecting android users from this either." seems quite misguided, given that they are clearly working on a solution for this exact problem.

[davidgerard]

>given that they are clearly working on a solution for this exact problem.

Evidence?

[Groxx]

Android's source code has been gaining AppOps runtime permission checks for a while now. It really does look like they're moving towards a runtime permissions model.

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.

[scep12]

The "App Ops" settings that they accidentally released seems evident enough that the feature is forthcoming. Am I missing something?

[huxley]

No it just means that there is permissions infrastructure not that they intend to make it available.

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]

[chinpokomon]

Multiple user account had a similar pre-release. It wasn't initially meant to be seen, but the crafty users a lot of Android developers are, we figured out how to start using it. A future update of Android made it a regular feature. Same with Apps2SD, although the community design wouldn't work for most users, the Android saw value in the project and came up with a solution that was more user friendly.

I wouldn't be surprised if Android v.next had this feature built-in, but it might require a newer API version.

[scep12]

That's fair. I thought it seemed too polished to be an internal debugging tool, but perhaps I'm being overly optimistic. I guess we'll see.

[rasz_pl]

no need to change APIs, just let AppOps insert shim between apps and API calls and return empty datasets instead of null/failing whole calls.

Let that app ask for my location, but let me define location it returns when I refuse real location. Same for contacts/messages.

[jessaustin]

...let me define location it returns when I refuse real location.

This would destroy some apps, e.g. Ingress.

[Pxtl]

What really disappoints me is the terrible placement Google uses for privacy features in the Play store. They're really hidden away instead of being prominent searchable fields. Microsoft of all companies does far better with their Windows Store.

[fooqux]

I would agree with you except for the part where they force you to see them before you're allowed to even install an app. It's hard to get much less hidden than that.

[nitrogen]

It's not particularly useful if the permissions aren't displayed on lists and aren't searchable. The only option now is a brute force search by hand, clicking Install on each app in a category until you find a version of 2048 that doesn't demand SD card, camera, and full net access...