This report has been produced by the W3C Trust and Permissions Community Group. This is an editor's draft and may be updated, replaced or obsoleted by other documents at any time. Pull requests are welcome and comments may be sent to [email protected].
Editor: Dave Raggett
Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This report surveys existing practices and guidelines for handling trust and permissions for Web applications, including the Open Web Platform, hosted and packaged Web applications, and the use of Web technologies on native platforms. Some opportunities for fresh approaches are outlined.
There are a suite of permission granting mechanisms available to designers:
- Automatic grant
In this case, the operating system or application run-time automatically grants the permission. This may be dependent on the source of the application, e.g. was it pre-installed as part of a standard suite of applications, or was it from a trusted source. This could be assessed on the domain name, the use of transport layer security, and the use of digital certificates attesting to the application.
This may be combined with the use of white and black lists, i.e. if an applications falls within the criteria given in the white list, and is not within the black list, then automatically grant selected permissions. A refinement on this approach is where the user has previously delegated permission granting capability to a trusted third party.
- Trusted user interface
This technique grants permission as a direct side effect of the user making an explicit choice through the application or run-time user interface. An example is where the user selects a file to upload to a website. More details are given in a later section.
- Confirmation dialogue
This is where user is explicitly asked to grant permissions via a confirmation dialogue. An example is for granting permission to access the device's geographic location. Confirmation dialogues are typically generated by the application run-time, e.g. in response to the application either explicitly requesting a permission or implicitly as a result of the application invoking an API for a specific capability.
- Install time warning
In this technique, the user is informed about the capabilities the application will have access to when it is run. The user has an opportunity to cancel the installation.
The most appropriate permission granting mechanism should be selected on the basis of various criteria:
- Can the action be undone with minimal effort?
- If abused is the action just an annoyance?
- Did the user initiate the request?
- Can the action be altered by the user?
- Does it need to work without immediate user approval?
These criteria can be organised into a decision graph as depicted below:
with grateful thanks to Adrienne Felt
In addition:
- How easy is it to explain the capability to the user?
Low level capabilities can be hard to explain to non-technical users. Likewise for very abstract capabilities. In such cases, it may be more appropriate to automaticaly grant permissions where the run-time environment (e.g. a web browser) or a trusted third party has the responsibility for deciding in respect to a particular application.
- How will the capability be used by the applications?
The user's decision may depend upon how the capability will be used by an application, e.g. will the data gathered be saved and shared with other parties.
- Exploring Notice and Choice: Design Guidelines for a User-Centered Permission Model for Personalized Services, Johson et al.
- Towards Comprehensible and Effective Permission Systems, Adrienne Porter Felt, Ph.D dissertation
- User-Driven Access Control: Rethinking Permission Granting in Modern Operating Systems, Roesner et al.
- Information on API Permissions as collected by the Web and Mobile Interest Group