Most large internet companies use the same general methods for informing users about how their data will be used. These include agreements any frequent internet user would be familiar with such as privacy policies or terms of service. This study looks at one type of agreement: the permissions required by apps on Android devices.
In the Android operating system, this point of contact is a three-way relationship between the user, Google (the designer and provider of the Android operating system) and third-party app developers. Google moderates the relationship between the user and the third-party app developer using a set of “permissions” for each app a user downloads. Permissions are Google’s way of requiring developers to disclose how the app will be interacting with the user’s device and what information the app will have access to.
In the Android ecosystem, the burden is on the developer to choose the correct permissions that describe to the user what the app is doing. This is not to say Google is entirely hands off, but the first step begins with the app developer.
After an app developer has built an app, chosen the correct permissions, and has created the list to which users will eventually agree, Google scans the app for malware and malicious code.
Permissions range from allowing the app to interact with specific hardware on the device (such as the camera flash) to allowing the app to access a user’s contact list. The user must agree to the entire list before downloading the app.
Again, it is important to note that the above information describes how the Android operating system functioned through June 2015, when Google announced a new feature in the next version of the Android operating system (Android 6.0, referred to as “Marshmallow,” was released in the fall of 2015). This new feature would allow users to turn off certain permissions on an app-by-app basis and to see all of the apps permissions in a single place (sometimes referred to as a “permissions dashboard”). See the “How to Find Permissions” section above for a detailed explanation of the updates in Android 6.0.
Google App Permissions Basics
Documenting the various permissions that different apps require of users is a key focus of this study. This section of the report examines the range of app permissions in the Google Play Store, with a focus on permissions that have the potential to allow apps to collect or share users’ personal information.
In total, the 1,041,336 apps in this dataset contain 235 unique permissions. The most permission-hungry apps can require a large number of permissions from users: the single highest number of permissions required by any app was 127, although it is generally quite rare for apps to require this many. Most apps request only a handful of permissions. The average (mean) app requests five permissions. Indeed, this analysis found that nearly 100,000 apps request no permissions at all.
Ultimately, in the apps that were part of this data collection, a relatively small number of permissions appear in a wide range of apps: out of the 235 total permissions, just 10 are used by more than 20% of the apps in the Google Play Store. Conversely, a large number of permissions are used by only a small handful of apps: 147 of the 235 permissions identified are used in fewer than 1,000 individual apps (that works out to 0.09% of the total number of apps.)
Of course, the total number of permissions an app requests does not necessarily reflect how much user information it is able to access. An app with a single permission could potentially access a wealth of user information, while an app with multiple permissions might be able to interact with only the phone’s hardware components but remain walled off from any actual end user data.
The analysis that follows takes a deeper look at the types of permissions in the Google Play Store. In particular, it examines the relative prevalence of two different types of permissions: permissions that could in any way allow an app to access user information and permissions that only allow an app to interact with the device itself (and not the data residing on the device).
It is important to note here that these distinctions define “user information” in the broadest possible sense. Permissions were given the distinction of accessing “user information” if they hypothetically gave access to any user information. Whereas permissions that access the device hardware allow an app to only access functions of the device itself.
This distinction was created by Pew Research Center to help differentiate between permissions that access any user information and those that do not. Google also makes a similar distinction by categorizing permissions into several levels of security. The two most common are “Normal” and “Dangerous.” This distinction is slightly different than the one used in this report and can be read in detail here.
The main difference is that the distinction in this report uses a much more broad definition of “access to user information” to include permissions that access even the most trivial of user information. Permissions that could access user information fall on a continuum with some granting access to sensitive user information and some granting access to very little, if any, sensitive information. The goal of the distinction used in this report was to not make judgements about what is “sensitive” user information and what is not, as that can often be a highly subjective question. Instead permissions were simply categorized as accessing any user information or none. Permissions that do not access user information can still be harmful to the device, but that is a different question than what is studied here.
Permissions that control device hardware
Of the 235 unique permissions collected in this scraping, 165 allow the app to interact with just the hardware components of a device and do not allow access to any user information.
The two most common permissions, for example, help apps connect to the internet. The “Full Network Access” permission (used by 83% of apps) allows an app to access whatever network the device is connected to at the time, while the “View Network Connections” permission (used by 69% of apps) allows the app to see what networks the device has access to. Any app requiring access to the internet in order to function properly would need to have one or both of these permissions. While these two permissions are near-ubiquitous, they do not, by themselves, allow their associated apps to access any user information directly.
Some other examples of this type of permission include:
- Control Flashlight – This permission allows an app to interact with the built-in flash in most smartphones and tablets. Usually this flash is for the camera, but apps can use this to create a “flashlight” by permanently turning the flash on and off.
- Set Wallpaper – This allows an app to set the image in the background of the home screen on a device (commonly called the “wallpaper” on Android devices).
- Control Vibration – This allows the app to control the vibration function found in most smartphones.
These permissions are not necessarily entirely benign. If used incorrectly (or maliciously), an app with one of these permissions could potentially damage a user’s device. But ultimately these permissions by themselves do not allow an app to access user information. The next section will cover permissions that do, in theory, give an app access to some kind of user information.
Permissions that access user information
The second category of permissions includes those that allow apps to access user information of one kind or another. This category of permissions is generally less common than permissions that control device hardware — out of the 235 unique permissions identified in this scraping, 70 could potentially access user information.
Examples of this type of permission might include permissions that allow an app to modify or delete photos from a user’s photo library or to read the contents of a user’s contact list. As these examples illustrate, these permissions exist on a continuum in terms of the volume and type of information they might allow an app to access.
In addition, it is extremely challenging to judge the potential damage to a smartphone user that could be caused by access to any particular piece of personal- or phone-collected information. It is certainly the case that a permission such as “View Wi-Fi connections” would expose very little user information to the app, since it simply grants the app access to see what Wi-Fi networks are available and collect basic information about them. But without knowing how apps are using the information they collect used it is hard to decide what user information is “sensitive”; therefore any user information is treated as potentially sensitive for the purpose of this analysis. At the same time, this judgement is highly contextual, and users should not necessarily view these permissions as inherently dangerous or detrimental to their privacy.
The most-common permission that could access user information is “modify or delete the contents of your USB storage,” and it is required by 54% of apps. This permission allows an app to look at information stored on a devices’ external storage and delete or change that information.
This permission is a good illustration of the continuum on which these permissions exist. The level of “exposure” users might experience would depend both on the type of information the user has stored on their external storage and also on the setup of the device itself. Some devices store information on external storage, while others do not even have external storage in the first place. Ultimately, this permission could certainly give an app access to user information — but this potential is highly dependent on each user’s individual situation and device.
The “record audio” permission is another example that has the potential to collect sensitive information, but is highly contingent on how it is used. This permission allows an app to turn on the microphone of the device and record audio — a relatively simple task, but one broad enough to potentially cause harm.
In 2013, Facebook created some controversy when it added a new feature to its app that utilized the “record audio” permission. The new feature let users opt-in to a service that would automatically detect what they were watching or listening to when posting to Facebook and include that information along with their posts.
This feature created an uproar among some users and pundits, who worried that Facebook could potentially use it to record and store everyday conversations. Facebook later clarified that the feature was entirely opt-in, would not record anything other than music, TV shows and movies, and would not store any of those recordings for any amount of time.
In each of these instances, it is difficult to determine just how much personal information (if any) a given permission might be able to access. At the same time, certain permissions clearly provide access to sensitive information — regardless of the users’ behavior or the individual circumstances of the device. For example, two permissions allow an app to ascertain the user’s physical location at any given moment. One does this using the device’s GPS and network connection (“precise location,” used by 24% of apps), while the other does so using just the network connection (“approximate location,” used by 21% of apps).
In this case, users do have the option of “overriding” the permission by turning off the location feature on their device entirely. In fact, 59% of Americans who own a smartphone and have downloaded apps had turned off the location tracking feature on their device or turned off the location feature in an app.
But users are not able to override all permissions in this manner. For example, the “read your contacts” permission allows an app to read all of the contact information stored on the device. This permission is used by 64,377 apps (6% of all apps studied here) and cannot be turned off — if a user agrees to allow an app to use this permission, he or she cannot selectively disable this feature (this will change somewhat with Android 6.0).
This distinction adds another layer of complexity to the permissions process and the ability of users to make informed decisions about the apps they download. Even with the system now in place in the newest version of Android, users will not have the ability to control all permissions, only a select set. See the previous section for more detail on the newest updates to permissions in Android 6.0.
Interactive