Hacker News Reader

Comment by jessaustin | Hacker News Reader

This is great stuff. I kind of wish they would hire you to run this. Another idea I've had would be for the user to be able to install an app without giving it the perms it "requires" (perhaps by unchecking some boxes in the dialog). Then apps would be responsible for handling a "no you can't see the contact DB" API response. Or they could crash I guess. The point is that users could effectively renegotiate with apps, e.g. "yes I'd like to use NFC to pay, no I don't want you to be able to record everything that's going on around my phone".

View on HN

Actually, you'd want three settings:

Yes, No, and spoof. Otherwise far too many apps would just go "I won't work until you enable the settings I ask for" - and then we're right back at the current situation.

Close. Yes, and spoof.

It is none of the app's business if the "camera" it sees is actually just an animated GIF (in essence).

It is none of the app's business if the "location" information it receives says, Mountain View, California. Wow! Look how many customers live in California. :-P

In short, the app should not even get the yes/no data from the user.

That possibly works.

But at the same time, I have a feeling that there would be frameworks popping up all over the place for recognizing spoofed settings. Yes, you'd end up with the same thing with an explicit "no" option, but the segment of users choosing "spoof" would presumably be smaller, and as such presumably the gain of an app adding functionality to detect spoofing would be smaller.

Although I personally think that the best option is, given that Android has the app store, have it part of the verification process that unrelated functionality of an app must work when functions are disabled.

Yes, and Android's isn't the only app repo that could be doing more verification (reminds one of Windows Update and FTDI, no?). To be frank, however, adding additional required verification is a huge pain for everyone, so it's going to be rare.

To avoid the pain they could roll this out only to apps that declare themselves not to be assholes. I.e., an app could promise not to degrade ungracefully under limited perms, and in return it would never get spoofed data. (All other apps would get spoofed data whenever they access an API that a user had deselected.) If a non-asshole app were ever reported by a user and verified by Android devs to degrade in a user-hostile manner, it could just be placed in the asshole category permanently.

Since the spoofed data is an API, your proposed framework to "recognize spoofed settings" must solve the halting problem -- impossible.

The spoofing API actually has only one requirement -- keep the app from accessing real data.

IIRC Cyanogenmod's privacy guard reenables a lost Android feature that basically does this. Its a main reason why I use cyanogenmod these days.

Agreed. When FB Messenger asks for my location, or my contact list, I just click "don't ask again" and "deny". And I get to ignore all the furor over the new Messenger permissions my friends are freaking out about.

Wnevets,

meanwhile Google Play Services made the Cyanogenmod privacy setting useless.

Any app can mask it’s access to your location, contacts, microphone etc. by using the Google Play Service instead.

It’s all or nothing again.

Try setting the Google Play Services access to “ask each time” and be surprised how many apps that don’t need your location, contacts.. try to spy on you.

Andreas

i completely agree. to avoid crashes the OS could return innocuous zeros, for example, the contacts has no entries, silence on the mic, zero for location, no connection on a network interface. To level the playing field, the vendor should be able to know i declined the request and not provide me the software, that's if their business model is based on advertising or data collection defeated by my choice.

Moreover, why not put a separate tab on the control center overlay that would display current permissions for running app as well as number of requests made that used that permission. If you drill in particular permission it could display history of requests for that particular API.

Having something like this would also allow for better audits. A separate app could show requests against a particular API by all apps as well as allow filtering. Other useful stats would be average number of requests per day per API per app and a graph of API calls by time of day. If nothing else this would allow to quickly identify rogue applications that make too many requests and drain battery.

On the topic of battery drain, I think that "allow to run in background" and "run as a service" would be a useful permissions as well. First one you would want to give to music players and to GPS applications, for additional control include time app allowed to run in the background before it is killed. Second permission would cover apps like IM and Facebook that are known to be tremendous battery hogs.

Totally agree with you here - Android's permissions model would be fine if only I could selectively refuse permissions to applications that ask for them, and have the application continue to operate but without the permissions I refused it. So that would mean my banking application wouldn't be able to take pictures of checks, if I refused it access to my camera, for example.

I can't find the reference right now, but that feature was present in beta versions of Android 4.3 (?) and removed because it broke certain existing apps.

Called "App Ops" and here is an article about it (and its removal): http://pocketnow.com/2013/12/17/app-ops

Reply on news.ycombinator.com