This is the third post in my series on privacy and security in mobile computing, which builds on the Commission’s 2013 mobile security workshop. In my last post, I concluded that – despite a history of usability concerns – permissions in mobile operating systems are clearly an improvement over the opacity of traditional operating systems. Nonetheless, improving the usability and efficacy of permission systems remain important challenges to address.
In this post, I will consider several ways that researchers have suggested mobile operating systems could improve the usability and efficacy of permission systems. Specifically, I will examine how – by providing developers with incentives and opportunities to better adhere to the principle of least privilege and facilitating greater context around permissions – mobile operating systems can help users make informed decisions regarding access requests and minimize information flows that defy user expectations.
Trusted user interface components
Trusted user interface (UI) components are an alternative method for mediating developer access to resources. Whereas direct API access provides an application with access to the underlying dataset (e.g., contacts or calendar entries) or device capability (e.g., recording audio, dialing phone numbers, or sending text messages), a trusted UI component is an operating-system-controlled intermediary through which the user can provide the application with finer access to resources (e.g., a single contact or the ability to dial a specific phone number) during the user workflow.
For example, as discussed in our first post, in order to prevent toll fraud, Firefox OS does not provide developers with direct access to its telephony API. However, Firefox OS still provides applications with the ability to dial a phone number through a trusted UI component. As Mozilla’s Michael Coates explained during the FTC’s 2013 mobile security workshop, if the user clicks on a phone number in a third-party application, the operating system populates the number in the device’s built-in phone dialer. The user can then use this trusted UI – the built-in phone dialer – to complete the call. Similarly, Microsoft’s Geir Olsen highlighted Windows Phone’s “Choosers” trusted UI components, which allow the user to pick and share specific information – for example, a single contact from the address book – with an application.
In this manner, compared to APIs protected by install-time or run-time permissions – which provide developers with, for example, direct access to the user’s entire contacts database – trusted UI better implements the principle of least privilege by allowing the user to share only the specific information necessary to the workflow at hand. Moreover, since it is integrated into – and does not interrupt – the workflow, trusted UI can provide the user with contextual cues for the resource access, helping address usability concerns, such as habituation, that are typically associated with install-time and run-time permissions.
Although basic trusted UI components are already common across mobile operating systems, research suggests that developers may not be integrating these components into their applications, opting for direct API access instead. For example, in 2011, a study found that out of thirty-nine Android applications that requested direct API access to send SMS messages, thirty-one could have instead used a trusted UI component – the built-in Android messaging application – without any loss of functionality.
Participants at the 2013 workshop noted that some innovative applications legitimately need direct API access. For example, an application that automatically sends a text message to a loved one upon the user’s arrival at a destination would need direct access to the API for sending SMS messages. This type of application, specifically designed to automate a task for the user, could not depend upon trusted UI, which requires user interaction. However, in another study examining trusted UI, researchers found that out of 100 popular Android applications that requested direct API access to various resources, ninety-one only accessed these resources in response to user input. In many cases, it appears that applications could use trusted UI components rather than direct API access to support their feature sets.
In those instances in which a developer could use either a trusted UI component or direct API access to implement an application feature, mobile operating systems may be able to design APIs in ways that encourage developers to default to trusted UI. For example, when Apple introduced its permission-based access controls in iOS 6, the operating system would prompt the user with a system dialog regardless of whether the application accessed contacts information through the “People Picker” trusted UI component or directly through the contacts API. Given this fact, developers may have had little incentive to choose the trusted UI component over direct access. However, in iOS 8, “the people picker has a new mode that doesn’t prompt the user for access to Contacts [and] the selected contact is returned as a temporary copy.” Since developers likely want to minimize the annoyance of prompts in their applications, this design change may provide developers with an incentive to incorporate the People Picker trusted UI component into their applications rather than directly accessing the user’s address book through the contacts API.
By designing APIs so that developers have an incentive to use trusted UI components, mobile operating systems can encourage developers to adhere to the principle of least privilege, helping minimize information flows that could defy user expectations.
For those application features that require direct API access, mobile operating systems can facilitate greater context for permission requests through support for developer-defined explanations. For example, rather than a general permission request that simply states that an application needs to “access location,” support for developer-defined explanations would allow a weather application to specify that it needs to “access location to provide local weather reports based on your current location.” Both iOS and Firefox OS support developer-defined explanations for permission requests, allowing developers to customize the operating systems’ run-time dialogs with an explanation specifying the reasons that the application needs access to a particular resource.
Microsoft’s Geir Olsen, however, questioned the efficacy of this approach at the 2013 workshop. Conceding that developer-defined explanations could be very beneficial in some instances, he noted that it could also lead to user confusion in those cases where, for example, language barriers prevent effective communication between the developer and the user. Google’s Adrian Ludwig expressed similar concerns, but noted that the iOS and Firefox OS implementations could provide important data on whether allowing developers to include explanations is an effective measure that is “a net positive to transparency or whether it creates complexity and confusion.”
Initial research indicates that developer-defined explanations can be a useful tool in increasing transparency. In a study presented at the ACM Conference on Human Factors in Computing Systems (CHI) 2014, researchers found that users preferred permission dialogs that included developer-defined explanations to those without such explanations, and “were significantly less likely to say they needed additional information to make a decision.” The study found that users were much more likely to grant access to permission requests that included developer-defined explanations.
Anecdotal evidence bolsters these findings. For example, the developer of Cluster, a social networking and photo sharing application, recently detailed how providing greater context around its iOS application’s permission requests has had a “drastic” impact on user’s willingness to grant access to those requests. In addition, the fact that developers often provide explanations for permissions even on operating systems that do not formally support this feature (through, for example, a separate help page on the developer website or in the “description” field of the application listing) seems to indicate that there is consumer demand for such transparency.
Nonetheless, the CHI study also pointed to certain limitations to the efficacy of developer-defined explanations. First, even when permission requests included explanations, users were uncertain “whether [their] personal data would be used for other purposes.” With applications often using data for multiple purposes, it is unsurprising that users may question whether a defined purpose is the only use for that data. For example, an application that collects location data to support a navigation feature may also include a third-party advertising library that collects the same information to provide geo-targeted ads.
With studies finding that “the purpose for which an app requests a certain permission has a major impact on people’s willingness to grant that permission,” consumers must be able to trust developers to disclose all material purposes for an application’s access to a resource. Researchers have suggested that application markets could play a role in this disclosure process. In fact, Mozilla has taken steps in this direction, requiring application reviewers for Firefox Marketplace to validate the accuracy of developer-defined explanations. Other researchers have suggested that mobile operating systems could take technical steps to help users differentiate between, for example, the permissions that an application requests for internal functionality and the permissions requested for third-party advertising libraries. Through such validation processes or technical measures, operating systems can help ensure that developer-defined explanations are consistent with an application’s information flows.
Second, the CHI study found low adoption of developer-defined explanations in iOS, with less than one out of five applications in the study sample incorporating explanations into their permission requests. The study authors propose that providing developers with pre-defined template explanations – based on the most common data use patterns – might help increase developer adoption. Developers could then choose and modify the templates as necessary for their particular applications. This could also help address, for example, language barriers that may make it difficult for some developers to communicate effectively with consumers.
Mozilla has addressed the issue of adoption by requiring developer-defined explanations for all permission requests in Firefox OS. Apple has taken the same approach in iOS 8 for the location permission, though explanations for other permission requests remain optional. At the least, the CHI study authors suggest, operating systems should consider creating developer resources (e.g., guides, tutorials, and trainings) focused on application privacy in order to increase awareness and adoption of these features.
While mobile operating systems may take different approaches to implementing this feature in order to maximize developer adoption and ensure accurate explanations, support for developer-defined explanations can benefit users by providing greater context for access requests and helping users make informed decisions regarding information flows.
Granular permission management options
Granular permission management options provide users with the ability to manage permissions on an individual basis and reverse decisions about granting or denying permissions. These management options can take different forms, such as a centralized “dashboard” or a set of in-app settings. Regardless of the form, since access to a resource depends on continued user trust, granular permission management options can provide developers with a strong incentive to adhere to the principle of least privilege and increase the context around their permission requests.
Both run-time and install-time permission systems can support granular permission management options. For example, iOS and Firefox OS both provide centralized permission management options that allow users to reverse any permission decisions that the user makes in response to a run-time prompt. Meanwhile, Blackberry 10 presents the user with all permission requests at install-time, but allows the user to decide which permissions to accept and which to deny (e.g., if a social networking application asks for access to both the user’s contacts and calendar, the user can accept the contacts request while denying the calendar request). The user can then reverse any of these permission decisions through a centralized permission management screen. Initial research indicates that users are taking advantage of permission management options when made available.
By contrast, Windows Phone does not currently provide users with centralized permission management options. When downloading an application, the user must either accept all permissions requested or decline installation. However, Microsoft requires developers to include an in-app setting that allows users to “enable and disable the app’s access to and use of location from the Location Services API.” While an in-app permission management setting could have the same kinds of benefits as centralized permission management options, research has demonstrated that some Windows Phone applications do not properly implement the mandatory location access settings. Operating systems that depend on individual developers to implement these kinds of options may need to ensure (e.g., through application review) that developers properly implement the required controls. Nonetheless, Windows Phone’s mandatory in-app location setting exemplifies how operating systems can take different approaches to implementing granular permission management options.
Like Windows Phone, Android does not currently feature centralized permission management options. However, Google has suggested that this feature is in development. In fact, some earlier versions of Android included a hidden feature known as “App Ops” that could be used to manage permissions. Not intended to be a user-facing feature at the time, Google made App Ops inaccessible in later releases. Although some criticized this decision, others noted that building permission management options into an existing system can be a complicated task, given the risk that permission removal could cause application crashes. Indeed, in a recent study, researchers found that removing permissions from Android applications caused crashes in 5.9% of the tested applications, with removal of the contacts and location permissions causing the greatest crash rates. However, the researchers also suggested that Google could use certain techniques to lower this crash rate. In any event, taking advantage of Android’s customizability, some Android device manufacturers are already building permission management options into their devices, and it is encouraging to hear that Google is working to bring permission management options to the Android operating system more generally.
Developers have also noted that granular permission management options can provide developers with the opportunity to better adhere to the principle of least privilege. For example, when the developer of Pocket, an Android reading application, introduced an autocomplete feature that required adding the contacts permission, the developer expressed frustration that “there is unfortunately no way to make a permission optional. This is an area in Android that we hope to see improvements in the future and will take advantage of them when they become available.” By providing granular permission management options, operating systems can support developers in creating optional features in their applications, allowing them to request only the minimum number of privileges needed to support a user’s desired feature set. Similarly, in iOS 8, Apple has modified its location API to differentiate between location data that an application collects when the application is in use and location data that the application collects in the background. By differentiating between these two use-cases, iOS 8 allows developers to request background location from only those users that would like to take advantage of features dependent on such data collection.
Of course, too many granular permission options could cause user confusion or place too high of a burden on the user to manage privacy settings. However, researchers have already begun to explore ways to address these usability concerns. For example, one study considered the feasibility of creating a small number of “privacy profiles” that could help users manage permission options by offering defaults consistent with the user’s general privacy preferences.
Given the potential usability concerns, operating systems may take different approaches to implementing granular permission management options. Regardless of the specific form they take, granular permission management options can benefit both users and developers by providing an opportunity to better adhere to the principle of least privilege.
Hybrid approaches to permission systems
Traditionally, operating systems have implemented a single permission type (e.g., install-time or run-time) in their permission systems. However, researchers have suggested that a hybrid approach that incorporates several different permission types would increase the usability of permission systems. In such a hybrid system, the particular type of permission that is presented to the user (install-time, run-time, trusted UI, etc.) is tailored to the particular resource or use-case at hand.
To some degree, mobile operating systems have already begun to take this hybrid approach. As noted previously, Blackberry 10 presents all permission requests at install-time, but still provides users with granular permission management options. Moreover, if the user denies a permission request at install-time that is particularly important to an application’s functionality, the developer can later prompt the user at run-time with an explanation of how the application would like to use the resource. If persuaded by this developer-defined explanation, the user can then change the permission setting through the operating system's permission management screen.
While Mozilla and Apple have incorporated support for developer-defined explanations into their operating systems’ run-time permission systems, Blackberry provides an example of how this feature could be adapted for an install-time system. Indeed, this hybrid approach potentially combines the benefits of an install-time implementation (i.e., fewer prompts that may lead to annoyance or habituation) with the contextual benefits of run-time explanations.
Similarly, since version 4.2, Android – the most commonly cited example of an install-time permission system – has relied on a run-time prompt to warn the user and require consent when an application attempts to text a premium number. This also exemplifies how operating systems can successfully take different approaches in order to achieve the same objectives. While Mozilla has restricted developers from accessing the Firefox OS telephony API in order to prevent the creation of toll fraud applications (as discussed in our first post), Google has used this run-time prompt to mitigate the risk of toll fraud in a different way.
These examples demonstrate that there can be different but equally successful approaches to enhancing user privacy and security. Not all operating systems will come to the same conclusions as to which approaches are best, and there may be instances in which taking a hybrid approach provides the greatest returns. No matter the particular approach, by adapting features that prove effective in giving developers incentives and opportunities to adhere to the principle of least privilege, and by facilitating greater context for access requests, mobile operating systems can improve the usability and efficacy of permission systems by minimizing information flows that defy user expectations.
The author’s views are his or her own, and do not necessarily represent the views of the Commission or any Commissioner.