Play Store Update Changes Permissions, And Not For The Better
One of the reasons that mobile OSes such as iOS and Android are more secure than their desktop counterparts is that they include very robust controls over app permissions. Each app requests from the user and operating system permissions that, in theory, are limited to what they need.
As applied, they have not always worked. App developers tend to ask for more permissions than they need; users don’t always pay attention and will approve just about anything. Still, for all the faults of the permissions system, it was there, and users who wanted to be particularly careful about app permissions had a useful tool at their disposal.
Unfortunately, however, it turns out that Google has changed the permissions model of Android in a very fundamental way, significantly reducing its visibility and usability to users. It leaves much more room for malicious app developers to update their apps to add potentially risky permissions to their apps.
How was this done? Developers in various Android discussion forums found that the update to the Play Store – rolled out in mid-May – had also changed how permissions and app updates were handled, and not in a good way.
Previously, if an update to an app meant that it required new permissions, the user would have to explicitly review the permissions and approve it, as if a new app was being installed. That is no longer the case. Now, if the requested permission(s) are in the same group as one the user has granted access to, this explicit approval is no longer necessary. If app auto-updates is turned on, the app can update in the background without the user being aware of the changed permissions.
These permission groups are documented in the Android developer site. The groups are built around functionality; for example all permissions that deal with location services are in one group. The permissions for the wallpaper are in another; the permissions dealing with storage are in yet another. 31 groups in all are defined in the developer documentation, but a total of 13 are explicitly named by Google in an FAQ discussing this topic.
This is all well-meaning – it streamlines the permissions process and makes it simpler for the user. However, it can be highly problematic. It is now easy – trivial, even – to construct an app that starts out with clearly “innocent” permissions at first, then later integrated the permissions necessary for potentially malicious behavior. For example, permissions to use the flash and recording audio/video are under the same group. In effect, a flashlight app can be easily updated to become a recording/stalking app without the user noticing the change. Other permissions that belong to the same group include:
- Reading the contents of the external storage
- Modifying or deleting the contents of the external storage
- Formatting the external storage
- Mounting or unmounting the external storage
Using the list above as an example, an app with the permission to read the contents of the external storage can easily be “upgraded” to having the capability to change or remove content.
In general, because Google has built these groups around specific features and functions, reading and writing permissions tend to be lumped together. In effect, by giving any app the permissions to read something, we are giving that same app the permission to modify something. This sort of flies in the face of what we would consider normal behavior: if I lend something to a friend, I generally expect to get it in the same state it was when I lent it out.
In a very real way, all this breaks permissions and renders it useless. It is now very difficult for a user to control an app based on permissions, since each category is so broad that it becomes very likely that even the most simple app will ask for multiple permissions. Conversely, it becomes very easy for an app developer to insert permissions into an app after the user has installed it in the form of a silent update, which can then be used maliciously.
This means that a greater reliance is placed on other methods to control app behavior, such as Google Bouncer and app verification. All this would be fine, but both are historically proven to be circumventable. For example, Android apps may hide malicious code or dynamically load code from remote servers, making the task of detecting malicious behavior more difficult.
Users do not have much choice in trying to counteract this “update”. One option users may consider is to turn off background auto-updates entirely. The Google Play app will still inform users if updates are available, and users need to manually update and check the new permissions. Unfortunately, this process can be quite burdensome.
In addition, in today’s climate of privacy consciousness, “trust us” – as Google is, in effect, asking us to do – is not an ideal proposition. Users must have the tools to decide for themselves what they do or do not trust. Taking such tools away can only be described as an act of arrogance.