[ross-life]

> Can someone shed light on this?

Whoever is in charge of the permission system is absolutely nuts. Or it's designed by the committee from hell. Those are the only reasons I can think of. No one sane would create this.

They actually wanted to "simplify" the permissions system and let the user have more control/understanding. You could argue they've done the first... at the expense of everything else. Half of it seems to have been introduced so "it bugs you less", which is not the point, I want to be bugged (by default) so I know what applications are actually doing. If users wants to "not be bugged" let them manually set it, don't make it default.

I've meant to write a post titled "Android 6 permissions: Still pants" after buying a Nexus 5X and being happy with the phone/camera but utterly disappointed with the "revamped" permission systems:

- Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose...

- Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict?

- You get an Internet, you get an Internet, every application gets an Internet. Because every application needs Internet right? It's not like I'd maybe want to install an application to manipulate a specific file type right now but don't want it connecting all over the net right? Maybe I don't have time to verify it's not nefarious. Maybe I just want control over what applications can actually phone home from my device?

- "Runtime permissions" is hit and miss. Some applications ask and then respect the answer. Others will just pop up the dialog over and over and over again until you accept it... which was not the point.

- READ_PHONE_STATE is still terrible. It's used by app/games to pause tasks when the user gets a phone call but... also gives away the number that's calling you! Of course, nearly every application then requests this. I don't get it, it's yet another obvious use case ("Let the application know the user is busy without leaking any data") that seems to have been glossed over. I thought by this point they'd have a proper IS_USER_BUSY permission that tells applications that you're in a phone call/whatever but doesn't leak any of your personal data *whatsoever".

At this point my next phone will be an iPhone/iOS, even though I don't particularly like them as at least security/sane permissions seems to mean something over there...

[curt15]

>Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose...

Does iOS have separate permissions for the different location resolutions or distinguish reading contacts from writing contacts?

[matwood]

> Does iOS have separate permissions for the different location resolutions

No, and why should it? I'm a technical user and I'm not even sure what the different resolutions are. What is important is to know when an application is asking for location data. iOS permissions for location are a) Never b) Always c) While using. Those make complete sense to even normal users.

[greggman]

Personally I wish iOS did have more fine grained permissions. I agree with you on location but I'd really like

1) Has permission to read your contacts 2) You can access an OS level contact screen to choose a contact but the app can't read the list of all contacts 3) Has permission to write to contacts (remember when facebook changed contact to have a facebook email address? Would prefer no permission)

Photos. Currently it's all or nothing. I'd prefer

1) can write new photos 2) can read old photos

Taking a photos right now is "can access camera" where as I'd prefer no camera access for most non-camera apps (facebook) and just a way to launch a system camera. I don't want apps to have the ability to keep the camera/mic on without my knowledge but "can access camera" = can use constantly without my knowledge while app is running.

Yes I know I can get around some this by doing it manually (don't give app camera permission, swap to built in phone, take picture, do give permission see 100% of my photos, hope they aren't uploading my private photos, choose photo I just took).

It's not enough IMO especially in this age of the revealtion of all the apps that spy

[newjersey]

> 1) Has permission to read your contacts 2) You can access an OS level contact screen to choose a contact but the app can't read the list of all contacts 3) Has permission to write to contacts (remember when facebook changed contact to have a facebook email address? Would prefer no permission)

I think 2 can be integrated into no permission passing some sort of Intent to the iOS address book framework.

Similarly, permission to read photos on a one off basis can be integrated into no permission. The user should get sent to Photos app and the photos app could ask them whether the user would like to share a particular photo or a particular group of photos with the app that sent them there and with the user's permission the iOS system app can pass the data back to the requesting app.

Sort of like what you said with

> Taking a photos right now is "can access camera" where as I'd prefer no camera access for most non-camera apps (facebook) and just a way to launch a system camera. I don't want apps to have the ability to keep the camera/mic on without my knowledge but "can access camera" = can use constantly without my knowledge while app is running.

Yes, I absolutely agree. I'd go as far as to say even Instagram doesn't need camera permission.

[profeta]

i am a technical user and i don't drive. so why even have roads?

[nindalf]

On the internet permission - its a difficult business decision for Google to allow users to restrict the Internet permission. If they did, every ad-supported app would overnight become an ad-free app.

[ross-life]

On one hand: That's a really good point. Thanks.

On the other hand: Everything can now steal my data "just" so adverts can be shown. Really?!

To me that's more outrageous than the original points I listed. My device and my data are left permanently insecure, all to protect their adverts. Even though I purposefully don't use applications with in-built advertising (because they can't be trusted with permissions), I can't easily turn this off.

This really makes my phone suddenly feel like "A rented device who's main purpose is to deliver advertisements to me" instead of "Owned device that helps me managed my life and communicate".

> its a difficult business decision for Google

It's a really easy business decision: User security, user privacy and user control are king. If each application wants to tie "functionality working" along with "internet access" and "advert was displayed" than each application can implement that for themselves. It's not hard.

That this is all baked into the actual OS instead with no (easy/toggle) method of user override is nuts.

[pdkl95]

> "A rented device who's main purpose is to deliver advertisements to me"

You don't own these devices as long as someone else has root. This kind of crap is evidence that we are loosing the War On General Purpose Computation. A lot of people are scared of the power of a general purpose computer in the hands of the general public. Computers (especially internetworked computers) allow people to see throw scams, remove artificial scarcity, and work past propaganda. When middlemen feel their power is under attack, they tend to lash out in stupid ways to counterattack the perceived threat and reestablish their position.

In the end, the general purpose computer must be made back into an appliance, and the internet back into something closer to cable TV. I don't blame the average person for falling for this scam, as they are often ignorant of the underlying technology. However, a lot of people that really should know better have been distracted with shiny baubles and keep buying into these increasingly locked-down walled gardens, when they should be setting an example and working to educate others so they have the information they need when they vote with their wallet.

[LeoNatan25]

That's what happens when conflicting tasks are left to the same management/company. Google's business model is not to make a secure OS or protect your privacy, it is to sell your eyeballs and data to advertisers. Any conflict between these views will usually resolve, maliciously or otherwise, toward advertising. Why do you think AppOps was removed?

I am sure there are people at Google who are tearing their hair, screaming about these issues. But management wants more money, not security or privacy.

As long as people vote with their wallet and buy Google products, they are supporting this. Yes, "I just don't care" is implicit support.

[enraged_camel]

>>- Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict?

I've configured security for a large variety of systems and I've never heard of a write-only permission. Read-only is often seen as a lesser right than read-write.

[victorNicollet]

I'm sure you've heard of the UNIX sticky bit, which is used so that anyone can write a new file to `/tmp`, but without being able to access other files in the same directory. I can certainly imagine the same implementation for contacts (create new contact, see only contacts you have created) and texts (create new text, see only texts you have created).

[azernik]

It's more like append-only in all of these cases - think of the things you want unprivileged processes to be able to do to your logs, for instance.