Hacker News new | ask | show | jobs
by ade2 3432 days ago
Isn't this solved with run-time permissions model since android 6? Customers can be informed before requiring individual permissions, in a context where it is understandable, such as requiring WRITE_EXTERNAL_STORAGE when saving a picture. Am I missing something?
2 comments

It's not obvious to users that READ_PHONE_STATE means the ability to obtain your IMEI, and if an app just exits when you deny a permission (or lies to you about why it needs it) what do you expect most users to end up doing?
The user-facing text for READ_PHONE_STATE is "Read and control phone status __and identity__".

How more obvious do you want it to be?

And I expect users to uninstall the app or live with the consequences. Because what other option is there?

If you want a kindergarten OS where a corporation prevents you from running apps according to their daily whim and maximization of profits - get an iPhone. Apple will protect you by making sure you run only kids friendly apps which only work with their dongles and hardwares. And that's ok, but we do not need two operating systems with same limitations that only differ in branding. In corporate controlled Apple world, things like Linux do not exist.

I only know what "identity" means in this case because I've read the SDK docs. There's any number of things that phone identity could mean other than IMEI.

(Before you accuse me of just wanting to restrict what people can do with their devices, I'm on the board of directors of the Free Software Foundation - I am very, very interested in ensuring that ultimately end-users are able to do whatever they want to do with things that they own. But that's not incompatible with the OS being designed to do its best to ensure informed consent for whatever an ap wants to do)

Of course, but is there even a way to phrase this better? Google could (and probably should) write "allows access to IMEI", but I'm not sure that adds a lot of informational content.

Don't get me wrong - I think this is still a severe problem. The fact that Google made a half-arsed solution where apps can just target older API and get away without asking for permission is horrible. The fact that apps can extort users with "give us contacts or I won't run" is also horrible.

But I'm out of ideas on how to fix this without giving control over to a single huge corporate entity which will rather lock you out of your own device than to deal with slight possibility of and kind of liability :/

My understanding is that iOS doesn't give apps access to the IMEI - it gives them a tracking identifier that users can disable. Having the OS empower users feels like a better solution than obfuscating what information you're giving up to apps.
Android has it as well - you either have the "Advertising ID" which behaves the same way as the iOS one (requires no permission on either OS) or ANDROID_ID (also requires no permission).

Both are reset with factory reset, but apps still for some reason demand tracking via IMEI.

> Google could (and probably should) write "allows access to IMEI",

That works perfectly for us technical minded folk.

For the vast majority of the Android user base (the 99% who are not us technical folk), that is just as opaque a description as "access phone state". They will simply have no idea what an IMEI is, nor will they have any idea of the implications of allowing an app to have access to the IMEI.

The one difference is that warnings to those users could be phrased as "do not allow apps access to your IMEI because ...", which they might understand (eventually) without needing to know what an IMEI happens to be.

And I expect users to uninstall the app or live with the consequences. Because what other option is there?

There are other options that Android could have explored, as already mentioned in this submission’s comment thread. For example, this post by qznc:

My solution is to use CyanogenMod (now LineageOS) and deny access when apps request it. To applications it looks like they can access my contacts, but if I deny it, they only get to see an empty list.

As you mentioned, there’s no need for two mobile operating systems that don’t give you control over what apps you can run and how you can run them. If Android gave users the option to block permissions for apps without informing the app that the permission has been denied, it would give Android users more control over their phones and the apps running on them, not less.

But as I wrote again - this is available by default in Android since version 6.0. It even behaves the same way (you get empty contacts etc if the app doesn't use APIs explicitly.)
For your "standard" app user, identity isn't a synonym of IMEI (reading that without being an Android dev, I'd just assume it mean my identity, i.e. accounts, on my phone) and most doesn't even know about IMEI.
You're right. But it's worth considering that most people don't know or care what an IMEI is, and even less so would they understand the consequences of sharing it with an app.

Most users will probably indeed grant the permission when asked, but the choice is there, rather than requiring ALL manifest permissions to install and run the app, so it's a lesser of two evils, imo.

No, apps just ask upfront for all their permissions, only now in several separate windows. And if you will deny app even one thing it asks it won't work. So nothing really changed with fine grained permissions.