This is the second post in our series on privacy and security in mobile computing, which builds on the Commission’s 2013 mobile security workshop. In my first post, I introduced the principle of least privilege, discussed how it applies to mobile operating systems, and looked at how application programming interface (API) design decisions can affect whether application developers adhere to this principle.
In this post, I will focus on one mechanism that operating systems have used to mediate developer access to resources: permission-based access controls, which ask the user to decide which resources an application can access. Specifically, I will discuss the history of usability concerns regarding permissions, and examine whether – in light of these concerns – permissions provide value as a privacy and security-enhancing mechanism.
Two approaches to implementing permission-based access controls predominate in mobile operating systems: run-time and install-time.
Run-time permissions – as implemented on Apple’s iOS and Mozilla’s Firefox OS – rely on system dialogs that prompt the user when an application attempts to access a particular resource (e.g., the user’s location). The user can then decide, on a case-by-case basis, whether to give an application access to that resource.
Install-time permissions – as implemented on Google’s Android and Microsoft’s Windows Phone – require the developer to identify all of the protected resources that an application can access, and to declare these permissions at the time of installation. Based on the permissions displayed, the user can choose whether or not to install the application. If the user chooses to install the application, the operating system grants the application access to all of the resources specified by the developer (e.g., the user’s contacts, the user’s calendar, and the device’s microphone).
A history of usability concerns
As with any user-facing security feature, the usability of permissions has been widely debated in the security community.
Operating system architects began experimenting with permission-based access controls in the desktop era. For example, with the release of Windows Vista in 2007, Microsoft introduced a security feature known as User Access Control (UAC). In an effort to thwart malware, UAC prompted the user with a run-time system dialog when an application attempted to perform a sensitive task.
Subsequent studies, however, demonstrated that users did not necessarily understand or act appropriately when presented with the UAC run-time dialogs. Moreover, researchers have noted, “a decade of usability research has shown that users may become habituated to [run-time] warnings, making them ineffective.” Developers have observed that run-time dialogs in mobile operating systems can be similarly problematic since an application “usually barrages users with a stack of dialogs on its first launch,” which can lead to the user “carelessly dismissing all of them without reading them.”
This risk of habituation informed Google and Microsoft in their decision to implement install-time permissions in Android and Windows Phone, respectively, with Google explaining that “many user interface studies have shown that over-prompting the user causes the user to start saying ‘OK’ to any dialog that is shown.” Similarly, during the FTC’s 2013 mobile security workshop, Microsoft’s Geir Olsen noted that the company has “quite a bit of experience from our desktop solutions and asking users ‘are you sure?’ . . . and the numbers that we have – we collect regularly show that most users just basically tab through those dialogs. They want what’s on the other side. I compare it to, you know, getting between a mother bear and her cubs . . .”
Recent studies, however, have demonstrated that users also often ignore or do not fully understand install-time permissions. As Mozilla’s Michael Coates remarked during the 2013 workshop, “from our perspective, that’s challenging for users to understand what they’re exactly agreeing to. They see – they want to install an application; they see a large list of permissions; and, unfortunately, I think a lot of users just click okay, let’s get this application running.”
Given this concern, Mozilla – like Apple – implemented run-time permissions in its operating system. Generally, both iOS and Firefox OS only prompt the user with a system dialog the first time that an application accesses a given resource, after which the application can access the API at any time without further prompting. On the one hand, this may help prevent habituation; however, it also risks a user misimpression that an application is only accessing the API on the single occasion that the prompt appears.
Meanwhile, in the most recent version of its mobile operating system, Blackberry reevaluated its approach to permissions, moving away from run-time permissions to an install-time implementation. As Blackberry’s Adrian Stone noted during the 2013 workshop, “we didn’t see a return that would have been expected by having [permissions] at runtime.”
Based on these experiences and the available research, there appear to be important usability concerns with both run-time and install-time permissions. In both cases, users may not fully understand the implications of granting access, or may be so habituated to the prompts that they do not pay attention when making access decisions.
Encouraging the principle of least privilege and dialogue with users
In light of these usability concerns, one may question whether permission-based access controls provide any value as a privacy or security-enhancing mechanism. However, Prof. William Enck observed at the 2013 workshop that permissions present potential benefits apart from their function as a tool to communicate with users.
First, researchers have demonstrated that permissions can have a positive impact in limiting application access to privacy and security-sensitive APIs. For example, one academic study – completed prior to the release of iOS 6 – compared 1,300 cross-platform applications and found that the iOS versions of the applications “consistently access[ed] more [security-sensitive] APIs than their counterparts on Android.” The researchers concluded that the likely explanation for this discrepancy was the fact that on Android “all the privileges required by an application have to be shown to the end user during installation.” However, after Apple introduced more robust permission-based access controls in iOS 6 (as discussed in our first post), the researchers observed a change in iOS developer behavior. For example, the researchers found that Angry Birds, a popular gaming application for iOS, had been regularly accessing users’ address books prior to iOS 6, but removed these privacy-sensitive API calls when Apple’s new permission-based access controls debuted. By calling attention to an application’s resource access, permissions may encourage developers to better adhere to the principle of least privilege.
Second, researchers have noted that permissions may allow advanced users to raise concerns with developers and flag questionable application behavior for other users. Indeed, anecdotal evidence suggests that developers often respond to user concerns regarding permissions. For example, Evernote’s Vice President of Product has engaged with users on the company’s web forums, explaining how the company’s Android application uses several resources. Further, companies like Evernote, Facebook, Uber, and LinkedIn have all released “help” pages that discuss why their Android applications request certain permissions. By encouraging a dialogue between developers and users regarding privacy and security, permissions can increase transparency by prompting developers to specify the purposes for which an application accesses and uses personal data.
Despite a history of usability concerns, permissions appear to be a useful tool in increasing transparency and encouraging developers to adhere to the principle of least privilege. The Commission has long supported the idea of layered disclosures presented in a context that is useful for consumers. From this perspective, permissions in mobile operating systems are clearly an improvement over the opacity of traditional operating systems, which often led to disclosures buried in lengthy legal documents.
Nonetheless, increasing the usability and efficacy of permissions remain important challenges to address. Participants at the 2013 workshop noted that providing users with greater context regarding information flows is an important part of addressing these challenges. Indeed, researchers have applied the concept of "contextual integrity" to permissions, suggesting that in order to minimize habituation and increase user comprehension, mobile operating systems should only ask users to make security decisions when information flows defy user expectations. By providing incentives and opportunities for developers to adhere to the principle of least privilege, mobile operating systems can help minimize the situations in which users must confront such information flows. And by providing greater context for access requests, mobile operating systems can help users make informed decisions about such information flows.
In our next post, we will examine several ways that researchers have suggested permission systems could be enhanced to better support these goals.
The author’s views are his or her own, and do not necessarily represent the views of the Commission or any Commissioner.