Even though Google’s recently announced granular permissions model in Android M is a welcome breath of fresh air, bringing it ‘nearly’ on-par with iOS, it still greatly lacking as a thorough privacy solution. There are, of course, a huge swath of improvements in Android M, but for the purposes of this article, I will be focusing only on the user-facing permissions control which was highlighted as one of the major improvements. The relevant I/O presentation can be watched here, which I’d highly recommend – it demonstrates how the 8 broad privacy categories can be toggled on a per-app basis, such as Contacts / SMS / Camera. Before diving a bit further in on a practical level, note that Android M is still in pre-release preview.
How do Android permissions currently work (Pre-M)?
Firstly, a bit of background about permissions. Many app developers are conscious of being too judicious in requesting permissions, as some users are becoming increasingly wary and leaving poor feedback. Others, like Facebook or Twitter, know that the app will likely be installed no matter what, so they go all out and request your first born. The more information they can gather, the more milk they can extract from the cow. Unlike mobile websites, mobile apps can provide a treasure trove of detailed user information – location history, contact lists, call records, calendar events, and more.
Through the years, Google has gradually simplified the permissions dialog that appears when an app is installed. Broad categories were added (like “Phone” or “Device”), where previously there were individual permissions, thus collapsing them. It’s become friendlier and friendlier, even as the number of permissions grew. Fast-forward till today, there are now many dozens of permissions that are hidden by default, unless you install an Xposed module to unmask them (a somewhat lengthy process involving root access which 99% of users will not end up doing). Let me demonstrate an example, if I go to the Play Store now (Android 5.1.1) and have a look at Facebook permissions on install, it looks like this.
The standard Facebook permissions request on Play Store, daunting but nearly everybody immediately presses accept, EULA style.
Looks daunting, but it’s been toned down and simplified already. There’s only three groups – the device history, wi-fi connection and device ID which might seem unusual for a social networking app. Pressing on any of these categories brings up a small description of what that category does. Now, let’s enable the hidden permissions module, reboot and see what Facebook ‘actually’ has access to on your phone.
At this point, you are nearly ready to be producing Facebook milk money at a large rate. Open wide.
I had to turn the tablet in portrait and even then, it took three screenshots to fit all the permissions in. They expand from 12 broad permissions, to around 60 or so permissions, most of which were previously hidden. An average user will never know that they just granted these permissions, ever. Some of which are puzzling – Amazon permissions? Read confidential? Connect/disconnect Wifi? Read battery statistics? Badge permissions? You can see why alot of this has been hidden by default – showing the true list would cause most people some cause for doubt, at the very least. When you lift off the shiny plastic cover, usually it’s not very pretty underneath.
Then there’s permissions scope creep. If an app requires an additional permissions group at a later date through an update, a further user-prompt is required, stopping any auto-updates. However, if the permissions group has already been granted at first install, even if only for a minor permission within that group, then the app can expand it’s use of that group without any further prompts. Many apps will anticipate this, and pre-request categories. From a developer’s point of view, it’s less harmful to request a small permission in an unrelated category up-front, than the re-request it later on, halting auto-updates and causing doubts.
What permission controls does Android M bring?
In terms of privacy, Android is a leaky ship, intentionally by design. Without apps splashing ads regularly, feeding user analytics back for aggregation, or mass-collection of metrics, the advertising ship grinds to a halt. This is Google’s bread and butter, user privacy is a distant priority, despite what the press releases say. What’s good for the advertisers is good for Google, and it’s only in Google’s interest to provide just enough control to users to prevent bad press. Whilst Google has attempted to provide some degree of control to the user, it’s been woefully lacking to date. You can read about the ‘App Ops‘ project introduced in Android 4.3, which was later hidden in 4.4.2. This feature has been built into Cyanogenmod (a third party Android ROM based on AOSP) for years, known as ‘Privacy Guard’ and works quite well.
Business model aside, the technical issue with introducing an iOS-style restriction on broad categories is that many apps don’t gracefully fail when the permission is denied. Some calendar or dialer apps might force close when denied access to the user calendar, for example. Android M (and third-party solutions like XPrivacy) get around this by either feeding the app a blank, but not invalid dataset. Sounds good right? Users can now use the apps they want, whilst blocking off access to their SMS’s or contact lists. This is a substantial step forward, better illustrated with a table.
For a breakdown of what each of those categories entails, see the official Google permissions page here. First up, iOS has granular permissions built-in, for location (which blocks both coarse location, fine location and geo-fencing), for calendar and for contacts. It also has a separate permission for microphone, and by default the included dialer and SMS apps are not-replicable by 3rd-party apps, as per App Store policy. However, it also has it’s own foibles, like iBeacon Bluetooth tracking, which we won’t get into here.
Next up, Android M – in the keynote, Google outlined the eight broad areas of permission restriction, see above, which brings it roughly in line with the iOS model. Then, CyanogenMod’s Privacy Guard (App Ops), allows far more thorough restriction, including clipboard access, wi-fi access, wakelocks and more. Finally, XPrivacy allows control of just about everything an app could request, though not for the faint of heart. If you’ve used Noscript on Firefox with everything switched on, it’s similar. It even goes one step further and allows random spoofing of information to the app as required. Note that both XPosed / CM require root access to the device, something that the vast majority of users won’t be doing, so let’s discount them for the time being.
What doesn’t Android M permissions restrict?
Even though it looks promising, there are some glaring omissions from Android M’s permission model. The list of permissions which are allowed by default for all apps, without ANY permissions prompt at all, and without showing on the permissions screen, is listed below. Some might notice that some permissions have been granted default access (known as protectionlevel = “normal” in the manifest), which were not present in Android L. Giving with one hand, while taking with the other, as the saying goes.
Permissions in Android Lollipop (5.1) that DO NOT require user approval
Permissions in Android Marshmallow (6.x) that DO NOT require user approval
All of the above as seen in 5.1, with the addition of:
Why is this a problem?
As an example, without any prompting, ALL apps can read your Google-registered Gmail address, nearby Wifi networks, currently connected Wifi network, find what other accounts are set up on your device, launch at boot, change your wallpaper / timezone, and more. This is in addition to the permissions they already had in 4.4 and prior – your device serial number, advertising ID, phone number(s), hardware information, IMEI/IMSI, MAC addresses (including Bluetooth devices) and cell tower information. They can also gather a list of all installed apps (via /data/system/packages.list) and detailed device hardware information (via /proc), all by default.
All apps also have unfettered internet access at all times, this cannot be restricted except by putting the phone into airplane mode, which is a crude solution at best. This also doesn’t stop the app from running in the background as a service and waiting till you disable Airplane mode. All apps also have access to the storage area of your phone (which includes your photos / media / downloaded files). Though, note that this does not include app-specific storage in /android/data/ which is restricted to the individual app’s UID. Have a browse around your /sdcard/ folder, you’d be surprised what is accessible.
As for location, since all apps can detect nearby and connected wifi networks, using simple geolocation they can reference with Google, Skyhook, Wigle, Apple or Mozilla’s worldwide wifi geolocation databases to find your location to the nearest 20m or so. It’s even more odious if people leave the ‘always scanning’ wifi option on, which constantly scans nearby wifi networks and builds an even more accurate picture. For more information on location tracking without the location permission, see this article.
In short, you could run across an app on the Play Store which showed the above ‘does not require any special permissions’, which in itself is a rarity nowadays, and press Accept. After installing it, that app could gather a selection of juicy information, including your phone number, hardware info, serial number, IMEI, location to the nearest 20m or so, your GMail address and other accounts and apps installed on the phone and send the whole lot back to a server on the web somewhere. Even with ALL of Android M’s new permissions fully locked down and no notifications to the user. This is a big deal. Notice that it’s for a reason the Play Store mentions ‘special permissions’, not ‘any permissions’.
What’s the takeaway?
Android M permissions are a welcome step forward and bring some much needed privacy controls to users. However, it’s only a bandage on a bleeding artery, there’s still a lot to be done, but it’s a trade-off between convenience/simplicity and privacy controls. For Google, M’s controls are a win-win – provide some basic privacy controls, curb the most nefarious offenders, but at the same time, silently allow developers to gather even more aggregate analytics. The users gain something, the developers gain something, Google gains the most. You could say it’s sacrificing privacy, to increase security.
But, unlike iOS, it can be worked around. If you are one of the very few who is concerned with their privacy, you can still harvest the best that Android has to offer – I’d recommend reading my Android Privacy Guide for some in-depth information on how to secure your device more thoroughly.