Permission system changes with Android 6.0: What are the implications for us users?

Question

With Android 6.0, a bunch of permissions and permission groups have been removed:

Groups gone

While on a first glance this doesn't seem important (isn't it rather a way to organize permissions?) – thinking twice reveals a major importance here: Starting with Android 6 (and with the Playstore even before that), if an app update requests a permission from a group where it already held one from in a previous installed version, this "new permission" is not brought to the awareness of the user. With Android 6, it is even granted automatically then. Also keep in mind that the user (with "native Android capabilities") can only revoke access to entire groups, not to single permissions – so fewer groups mean less flexibility, up to a uselessness of the entire feature.

According to the link mentioned above, the following groups have been removed:

ACCOUNTS, AFFECTS_BATTERY, COST_MONEY, DISPLAY, MESSAGES, NETWORK, PERSONAL_INFO, PHONE_CALLS, SCREENLOCK, SOCIAL_INFO, SYSTEM_CLOCK, SYSTEM_TOOLS, USER_DICTIONARY, WALLPAPER

Permissions gone

Less permissions covering more ways to access personal data mean a nightmare for privacy. Concerning accounts, I've raised this question already: Android 6+ and account permissions: where have they gone to? As we found out there, what before was dealt with by the no longer existing USE_CREDENTIALS permission, now got moved to contacts (not sure whether read or write): so if you wish to "login with Google" (or any other account holder), you need to give the app full access to your contact list! The popup on the screenshot there ("Allow Stack Exchange to access your contacts?") popped up immediately on tapping the "Login with Google" button.

So next to most account permissions (except for GET_ACCOUNTS, all of them are gone), which are dealt with in my other question already linked, the following permissions have been removed:

ACCESS_MOCK_LOCATION (now one has to configure a single app handling the MOCK_LOCATION I've seen mentioned?), CLEAR_APP_USER_DATA, GET_TOP_ACTIVITY_INFO, HARDWARE_CONTROLS, HARDWARE_TEST, INJECT_EVENTS, INTERNAL_SYSTEM_WINDOW, READ_HISTORY_BOOKMARKS, READ_PROFILE, READ_SOCIAL_STREAM, READ_USER_DICTIONARY, SET_ACTIVITY_WATCHER, SET_ORIENTATION, SET_POINTER_SPEED, STATUS_BAR, SUBSCRIBED_FEEDS_READ, SUBSCRIBED_FEEDS_WRITE, VOICEMAIL, WRITE_HISTORY_BOOKMARKS, WRITE_PROFILE, WRITE_SMS, WRITE_SOCIAL_STREAM

What does that mean for users and their privacy?

This is my main concern here. Unfortunately (one could almost say "as expected"), there was no official statement made on that – or I had already been aware of those changes a while ago. I hope some of our members who happen to be developers as well have deeper insight, and can help us out with some explanations and advice:

• have those groups/permissions simply be removed (or did some simply got renamed/replaced by others)?
• how is the data previously covered by them protected now?
• what are the implications for users and their privacy, and what can we do about it?
  • concerning the "do about it": sure there's root, XPosed and Xprivacy (how does the latter cope with those changes?) – but I also mean "the average user" without root here.

Answer 1

As I said up above (somewhere) The new permissions system is a drain that shows that a new idea is not often a good idea.

Be warned! This may take a little bit to read, since I'll be talking about the history of android, and more! Go and grab a drink!

You good? Alright, dig In.

The origins of the new permission system

When Google began working on a way to forcibly grant and deny permissions on-the-fly, it was Android 4.3. It was a buggy mess, so they hid it. It can still be used, however, by creating a shortcut to the app ops settings menu. This menu was very similar to the current apps menu, but tapping an option immediately brings up the permissions options. You also had to discover the permissions before you could toggle them, and it was a buggy mess since apps wondered what the balls is going on because you disabled something, and inconveniently crashed. Yay.

The system was removed once modders had found it (so it was removed in 4.4),¹ but made its return in Marshmallow. It looked really good - you could finally choose if things like Facebook could grab your location (though it did ask nicely). Even some Google apps, like Hangouts, aren't safe from your decisions. But then we hit the issue - the system is still broken, just in a new way: the permissions were heavily tweaked.

You want Stack Exchange to login via Google? It needs contacts permissions (though The devs at SE fixed that on their end).² Want To upload images onto Facebook? It needs to see all your files. Why? Compression. Permissions are now granted in groups, where asking for your Google account also allows apps to see every contact on the device. I doubt that was intended, but the removal of most permissions meant that the had to simplify the playing field; most removed permissions were just shoved into super-general groups.

Some of the permissions have been removed because of new SDK's. GET_ACCOUNTS Now triggers a new SDK which allows for Google sign-in, but falls back to doing it via contacts permissions if an app does not support it. That explains that one (including how the SE app was finally fixed), but some of the others don't get that treatment. AFAIK, Apps can just casually read the dictionary regardless through the keyboard. Most other permissions Izzy mentions seem to correlate with modified groups: Most fit into the 'Modify system settings' Godmission (permissions separate from the main ones) and 'usage access'. Some others are handled by apps themselves.

So, Anything not given a new home was killed off. Sometimes, this made sense (we only need GET_ACCOUNTS to trigger the SDK) While other times, it made you want to put a bullet into your phone: oh yeah, I'll just let you access my contacts, you seem fine. Sure, access my calls and waste my money. (Hopefully no one is that dumb. Hopefully.)

At first, I thought yay! Simplification! But it allows seemingly legitimate apps to do illegitimate stuff A LOT easier. Your Minecraft hack tool which wants your Google account is probably also robbing your contacts. And selling them.

This is then compounded by the Lockdown system for permissions, that allowed you to fine-tune app permissions. It's great, but it doesn't work. At all. It also is inaccurate (it e.g. says that Stack Exchange reads my SMS'. No, no it doesn't) and is just plain awful.

But what does that mean for my privacy?

I personally think one of two things:

1. The new permissions system was designed to allow simple, quick changes for the purpose of security. Permissions are now granted in groups, which explains why some are removed: Google thought that leaving them under one big header was a good idea (and for the end-user, I see why: controlling each individual permission could get tedious.) Of course, like communism, it was only good on paper; in reality, it's a shamble that they don't want to admit to. Fair enough.

2. However, they could be doing this to force more apps to use Their SDK to break alleviate suspicious permissions (Don't blame them) and therefore make more money. It's proved they are doing so (and are trying to make Android less open-source) which disgusts me.

So for the end-user, it's like a little bit of iOS - by which I mean something that looks good, but is crap. But can it be fixed? Kinda.

The "Work-arounds."

Method 1- Xprivacy (ROOT NEEDED BOI)

Xprivacy does work on Marshmallow, according to its devs, of course. It requires messing with all sorts of fiddly bits on MM now, and there is verified boot. Which is a pain, since you'll probably get a red or yellow warning, which may prevent boot. (Depending on your luck, and how much messing you have done.) But if you can get Xprivacy working, its easy enough.

Due to the 'Wont boot FULL STOP' attitude N will apparently take, it may even be more of a nightmare to get working on that.

2017 EDIT - Xposed devs are working on getting around all of this (yay!) If i find the post on XDA, I'll link it

METHOD 2 - Go full Lockdown on everything.

This is really fiddly, but allows for maximum control (as far as that's possible). You grant app permissions when absolutely needed, then make a mad dash to turn them back off again. Probably will be easier once Nougat drops on more devices, so multi-window can be used.

METHOD 3 - Don't upgrade (which I'm dubbing the "Izzy solution")

If you did look up when I told you to, you may have noticed what Izzy's method is: You simply refrain from upgrading to Marshmallow or Nougat. Boo-Hoo, I know, but neither are game-changing, really. Give it.... Six months, and most the crap for N will be on the play store, if you really want it. So, the Izzy solution means sticking with the definitely capable 5.1.1 or lower. I can live, and so can you.

METHOD 4 - NUKE IT FROM ORBIT.

(Just to please the masses. FYI, this would be impossible.)

Or, ignore it. Your call.

---

EDIT Izzy found a link to a Stack Overflow question That explains that Credentials, Like Logins for Signing in on various apps, fall under a 'normal permission' (protection-level "normal") – i.e. any app can access them without you knowing. Luckily, some apps and logins will let you remove this through their account managers, Depending on how malicious the Dev is trying to be.

EDIT 2 I forgot to say you can remove apps from accounts :) I'll be using The Google accounts and Facebook app accounts systems as examples, as they are the most used.

Google accounts

1. Head to accounts.google.com or open the Google play settings (varies by device, usually a cog with a g in it)
2. Find apps/Connected apps/connected apps and services (again, Varies)
3. Find what you want to remove, and click 'remove'

DONE!

Facebook

1. Login on the site
2. Head to account settings > apps
3. Find the target app, and click/tap remove.

Done!

Hope that helps! If not, just drop a comment, you know the drill. I'll be working on it anyways. Done, but still let me know if I missed something!

---

¹ _{There were different attempts made by Google to "hide it better", and different versions of AppOps frontends brought it back then for 4.4 and 5.0, but no further}

² _{Apparently, apps can voluntarily use a new SDK that allows Google sign-in without the contacts permission. See here for details.}

Answer 2

^{Summing up my own findings – which might overlap with Dan's answer:}

Origin

Google started on the new permission system with Android Jellybean 4.3. Official intention (revealed later on) was to give users some control on what permissions an app should have access to ("permission on demand") – instead of the "All-or-Nothing" existing at the time (if you didn't like an app having a certain permission: either live with it, or don't install it). The AppOps interface was hidden, but soon revealed, hidden again (Kitkat/4.4), revealed again, and the same a third time with LP/5.0, after which it was protected in a way hard to circumvent.

Current state

Finally, AppOps surfaced with Marshmallow/6.0. But instead of giving users fine-grained permission control, permissions are fine-drained and control is rather raw; if you e.g. want your travel app to be able of adding your bookings to your calendar, but not to read your other calendar entries: no way. Either you forbid calendar access, or you allow it. Similar for other permissions – as AppOps only deals with groups.¹

Furthermore, a lot of permissions have either been removed completely, or assigned to Protection Level "normal" – so they are automatically granted and cannot be revoked by the user. This is e.g. the case for the INTERNET permission, but also for USE_CREDENTIALS (so any app with this permission can use any of your accounts without your explicit approval!) or even BLUETOOTH_ADMIN (pair your Droid with any BT device in reach). For a detailed list, see this Gist.

Also, new protection levels have been added: appop for permissions the user has explicitly to grant via the new "on demand" system, pre23 for permissions automatically granted if an app targets a version below MM (i.e. before "runtime permissions" where introduced), preinstalled for apps that shipped with the ROM (unclear how Android differentiates that from system, which was renamed to privileged), plus 3 more.

Current state summed up

Basically, we're worse off now:

• number of permissions has been drastically reduced, meaning less granular protection
• many permissions have been moved to protection-level normal (and thus out of reach of AppOps)
• AppOps (runtime permission) is rather cosmetical due to its missing granularity and leaving out essential permissions
• apps can request additional permissions with an update. If they already hold a permission in the same group, the user is not notified ("does not require any special additional permission" text sounds familiar?). With the number of permission groups reduced as well, it even got easier to "sneak something in".

So in most cases this means the same as before MM: If you don't like an app having a certain permission, don't install it.

How to deal with it from a user's perspective?

Multiple of the items in the following incomplete list can apply simultaneously. Make your pick:

• Don't update beyond LP if you don't like that (and can live with sticking to LP). That's what I do, until this mess has been cleaned up.
• Don't install apps if you don't want to give them access to what they request.
• When installing an update, don't trust that "no additional permissions" hint. Check in detail before you apply the update. This is not as easy as it used to be, as normally you don't see next-to-each-other which perms an app already has and how they differ from those requested by the update. In the Playstore app, you still get the complete list when scrolling to the end of an app's page and hit the "permission details" link. Do not ignore the "Others" section at the end of the list, as it includes things like INTERNET, BLUETOOTH_ADMIN, and other "surprises".
• to protect your device from rogue apps accessing the internet, consider using a Firewall app. There are good ones not even requiring root and being FOSS, like Netguard.
• if root is an option, and installing the XPosed framework is as well (both available for MM, but installation might get quite tricky with N), use a permission manager like Xprivacy for granular permission control.

---

^1:_{Obviously, the user shouldn't be "overstrained". Still, there could be an "advanced mode" to deal with it.}