Note that even Android 6 has a set of "normal" permissions[1] that are automatically granted if requested. While I somewhat understand the rational[2] behind the decision, there are some permissions like "BLUETOOTH_ADMIN", "CHANGE_NETWORK_STATE", and "CHANGE_WIFI_STATE" that make me feel uncomfortable, and I wish that I were able to control fully the permissions granted to applications.
I believe[1] so, based upon my reading of [2]. Personally, I'd be less worried about an app phoning home, and more worried about an app changing my connection to an adversarial network that could sniff on traffic, etc.[3]
[1] Would love if someone with more Android expertise could chime in and confirm/deny
The permission BLUETOOTH_ADMIN allows applications to discover and pair bluetooth devices, but Android system services still handle the necessary user interactions to confirm and complete the process.
CHANGE_NETWORK_STATE allows apps to choose which already-enabled medium to send traffic over, but to overwrite settings the app would require WRITE_SETTINGS which is a runtime permission granted by the user.
CHANGE_WIFI_STATE can send the user directly into the "Add network" Wi-Fi settings screen, but cannot change the connection without user input.
Also, in general, the normal permissions are pretty heavily vetted for attack vectors. I would say that if there is a problem with Android's permissions system its that users don't read important permissions they grant, not that apps can get them without consulting the user (they can't).
So as you may know, in the old pre-6.0 Android model (that is, any app targetting pre 6.0 Android) you are presented with the option to approve a list of all the permissions "up front" when you install the app from the play store. All-or-nothing. If you say no, the app won't install. There is no opportunity for the app really to explain why it needed the permissions, and some like "read phone state" were kind of confusing.
On the new 6.0+ runtime model, permissions are combined into groups-- normal and "dangerous" -- normal includes things like Internet access which all apps have always-- needed to show ads-- and you can't block. "Dangerous" is the category type you'll be asked about. So in this new runtime model, the app is always installed without prompting the user at all about permissions. Then when the app is actually running, before the app can do anything requiring permissions, it must ask the user explicitly to accept the permission it needs via a popup UI. This gives the developer an opportunity to ask "in context". So like, if an app has a button to record some audio, it can ask you only when you press it, and then the user will go "oh, I just told it to record audio, so this makes sense". If the user declines, it's up to the app to decide what to do next-- it can offer a rationale ("The app NEEDS this permission to record sound!!") then ask again, but the 2nd time the user can say "remember my choice", and the app can do anything from disable the feature to shut down completely.
Because the UI is in the hands of the developer, they can ask for them individually "in context", or maybe all up front... and figure out how to handle the case where the user says "no>'.
LineageOS/CM's privacy guard, which predates Google's runtime model, works slightly differently in that (1) the permissions available to be turned on/off are different/more fine-grained than Google's permission groups... (like you can turn off fine vs course location access) but is (2) similar to the Android runtime permission model in that the user is asked "on-the fly". But with Privacy Guard, this is done automatically by the OS when a permission-needing feature is being used, not by the app developer's at their discretion. This means if Privacy Guard is turned on by default, the UI will pop up whether the developer likes it or not, when the permission is needed. In fact, (3) the app often won't know it's even been denied permissions because, (and I think this is still true), (4) if the user says "no" to a permission, the app may just be handed empty data sets (ie, a list of zero contacts or some bogus spoofed location data) rather than an outright permissions exception as with Google's method. Another huge difference is that the privacy settings stuff is available on Android much older than 6.0.
Like google's permission settings, LineageOS' privacy guard settings can be changed from the settings on a per-app basis. Both let you retroactively pull permissions even on pre-6.0 apps, though expect some occassional crashes, especially with the runtime permission model.
Privacy Guard also offers a count of how many times permissions were accessed, when the most recent was, and even shows a notification when an app has been blocked.
The best thing is that both the runtime permissions model and privacy guard can be used at the same time.
"Because the UI is in the hands of the developer, they can ask for them individually "in context", or maybe all up front... and figure out how to handle the case where the user says "no>'.
"
But this system can still be easily abused unless Google tightens its app review process. An adversarial developer could take the teeth out of the system by demanding all permissions at the first run and make the app refuse to work unless all were granted.
An adversial developer can do that on Lineage as well, what is your point? How would you work around that besides adding a foreign corporate babysitter that tells you what you may run?
You could do what LineageOS (apparently) does and lie to the app about what permissions are granted. "Sure, you can have access to my GPS location. I'm in the middle of the Pacific Ocean right now, and will remain there until the end of time. Have fun abusing your new privileges."
At which point it becomes an arms race of the OS providing more and more realistic looking fake data, and the apps developing newer ways of detecting those fakes.
Realistically though, even the most unrealistic fake data is going to be good enough to stop 99% of apps from complaining.
Then they don't start, and are uninstalled and reported as broken as a Google Play store review with 1 star, as has already happened to apps that tried that shit.
The average user doesn't care about permissions and probably are going to fully allow games like that to steal their data. Then they'll give it a good score in the app-store. Install number and rating aren't good indicators. I think there's an implied user-base here that the "mark as broken" response is going to be useful for, but the vast majority of people won't care.
this is a malware with almost 200K installs and poerfect 4.5 rating. It propagates using spam/pirate sites with misleading "your phone is broken and will blow up if you dont install this" scam
It's a losing arms race, you can just feed the apps fake information if they insist. Are they going to disable their app if you don't have GPS reception or if it appears you are on the North Pole?
This may be hard to do for Google but it isn't for people like the Cyanogen developers.
As the developers start annoying more and more normal users this kind of blocking technology becomes more widespread. The web ad businesses and publishers thought they could afford to ignore ad blockers too. And now they are complaining their business is dead.
