Hacker News Reader

Comment by Frazzydee | Hacker News Reader

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

View on HN

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

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.

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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)

Responding to the response inline:

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.

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.

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?

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

Considerably different. Mock location data simply provides the location you want over ADB. It is a supplied value.

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.

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

http://www.fakenamegenerator.com/

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

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

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

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.

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.

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.

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.

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.

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

Why people still uses that false meme?

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

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.

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.

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.

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

Evidence?

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

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]

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.

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

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

In a sense it already does: there were instances of Ingress players "moving" from place to place at 200km/h or so during rush hour in London.

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.

https://play.google.com/store/apps/details?id=com.lexa.fakeg...

I just wish there was a central place that would let me do this per ap for all permisions.

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com