How Mobile App Permissions (Don’t) Protect Privacy
In the 1960s, very few people had computers. They were mostly used at research institutions, for business purposes, or by the military. Computing was expensive, and people were cheap.¹ Thus, scarce computing resources were shared among many users. With a time-sharing system like Multics, a single mainframe computer would often be enough for everyone. Users prepared their computation offline and sent it from their terminals to the mainframe. However, users needed to be protected from each other.² The paradigm of using one computer for multiple users gave rise to the notion of access control. Who should have access to which resources on the computer? To which extent should a user be able to read or write to files on the computer? Access control was later adopted in Unix and continues to live today in our smartphone operating systems. iOS and Android are distant descendants of Unix. In fact, Android creates a separate user for every running app. This is how Android is sandboxing apps to isolate them and prevent interferences.
An important part of access control are permissions. In Unix a permission says what, if anything, a user is allowed to do with a file or directory. For example, depending on the permissions of a file, a user may be able to read and write to it, but may not be allowed execute it, which is important if the file is a program. However, in the smartphone world, instead of user permissions, mobile operating systems adopted app permissions. It is the apps, not the users that need permissions. To achieve this, on Android each app is literally run as a different user. While iOS is running apps as the same user, each has only access to its own part of the file system. Generally, apps are unprivileged by default and must request permissions.³ It is sensible that permissions are shifted from (real) users to apps in smartphones because smartphones are not meant to be shared among multiple users. One user per phone. There is no conflict. It should be the apps requesting permissions, especially, as they often have an incentive to disclose user data to third parties for advertising purposes. However, access control on smartphones has yet to come full circle.
The problem in access control is access. There is a difference between accessing a user’s location and sending it off of the device. The latter can be much more privacy-invasive. Thus, permissions should not (only) reflect what data is accessed on the device, but rather whether that data is leaving it, and possibly whereto. As it currently stands, users have to assume the worst case scenario. If they are giving an app the permission to access the phone’s location, they also have to assume that it will leave the device. Once an app has permission, it is not guaranteed that “what happens on your iPhone, stays on your iPhone.” For mainframes and personal computers, data access is the determinant for setting permissions, and rightly so. But for smartphones there is less privacy risk by just granting data access. A smartphone is intended to be used by a single user to begin with. Under this assumption other people will only gain access to the data if it is sent off of the device. This distinction between data access and collection is also reflected in privacy laws, which often require collection of data and not just access. For example, according to the Federal Trade Commission’s interpretation of the Children’s Online Privacy Protection Act, interacting with personal information that is stored on a device and is never transmitted does not qualify as collection.⁴
App permission systems have improved over the years. Instead of granting all permissions at install time, Android and iOS changed to asking the user to grant individual permissions at the time an app needs those. Also, permissions became much more fine grained. For example, iOS developers can request location permission for their app in form of when-in-use or always authorizations.⁵ Further, upon permission request, a purpose string must be shown to the user in which the developer explains why the app is accessing certain data. However, despite all these improvements, permission systems have not yet fully evolved from their Unix legacy of access control. Privacy protection would increase if they adopt, let us call it, collection control. Just as the other improvements over the last years, the change from access to collection control would ideally be reflected at the operating system level. For example, Android and iOS could require the developer to include a flag for every permission in their app’s manifest or plist files indicating whether the data the permission relates to is only accessed on the device or also collected and sent off. This information could then be displayed to the user. There could be another flag to indicate whether it is the app itself or a third party, e.g., an ad network, that is requesting the access or collection. These changes may give the user a better understanding of what actually happens with the data if a permission is granted. After all, in most cases the privacy problem is not first party access, but third party collection.
- Consider that Voyager 1 and 2, spacecraft that flew beyond our solar system, only have 69.63 kilobytes of memory each, a fraction of a current smartphone. However, for quite some time now, it is the other way around. People are expensive, and computing is cheap.
- Paul A. Karger and Rger R. Schell, Thirty Years Later: Lessons from the Multics Security Evaluation, ACSAC 2002.
- Adrienne Porter Felt, Towards Comprehensible and Effective Permission Systems, Technical Report No. UCB/EECS-2012–185.
- Federal Trade Commission, Complying with COPPA: Frequently Asked Questions, March 20, 2015: FAQ M.1, M.4, and M.5 revised. FAQ M.6 deleted (“Am I ‘collecting’ personal information because the child is interacting with a photo stored on the device? No. You are not collecting personal information simply because your app interacts with personal information that is stored on the device and is never transmitted.”).
- Apple, Requesting Always Authorization.
