W3C Logo

Next steps on trust and permissions for Web applications

3–4 September 2014, Paris, France


W3C gratefully acknowledges Gemalto, for hosting this meeting.


HTMl5Apps Thanks also to support from the European Union through the Seventh Framework Programme (FP7/2013-2015) under grant agreement n° 611327 - HTML5 Apps.


Google doc we used for minute taking: Short URL: http://bit.ly/1nxM1em

Meeting page


  • Dave Raggett, W3C
  • Dominique Hazaël-Massieux, W3C (remote)
  • Robin Berjon, W3C (webapps etc.)
  • Wendy Seltzer, W3C (security, privacy) 2nd day only
  • Stefan Håkansson, Ericsson (Co-chair Media Capture TF, WebRTC)
  • Philipp Hoschka, W3C
  • Giridhar Mandyam, Qualcomm
  • Claes Nilsson, Sony Mobile
  • Wonsuk Lee, Samsung
  • Vadim Draluk, GM (automotive)
  • Adrienne Porter Felt, Google
  • Jonghong (Jonathan) Jeon, ETRI
  • Steven Woolcock, Apple
  • John Hazen, Microsoft
  • Stephanie Ouillon, Mozilla
  • Kenneth Rohde Christiansen, Intel
  • Olivier Potonniee, Gemalto
  • Anssi Kostiainen (remote)
  • Virginie Galindo (remote)

group photo
Credits to Johnathon Jeon, see also comic turn

Wednesday, 3rd September

Session 1: Introductions by participants

We went around the room (and the phone) introducing ourselves.

Dave set out the meeting objectives:

  • Areas where we have a rough consensus and need to work on the details?
  • Areas where we are still some way apart and what steps can be taken to close the gap?
  • What can be ruled as out of scope for W3C work on trust and permissions in the open web platform?
  • Whether we want to set up a Community Group, a Cross Working Group Task Force or some other approach?
  • What design rules can we give to allow work to proceed in parallel on APIs and trust & permissions?

At the end of the meeting we would like to have a clear idea for next steps

Session 2: Logistics and agenda tweaking

We decided to stick with the agenda on the meeting page

Session 3: Review of existing practices for the Open Web Platform (OWP)

Wonsuk goes through history from SysApps till today:

SysApps attempted to handle many APIs (around 15) with focus on packaged apps with input from Tizen, Firefox OS and Chrome OS.

Issues: Packaged apps were very tied to the specific stores which broke the basic idea of the web: the hyperlink. Second issue: Versioned apps, web apps are usually updated on the go without the users having to install an update. Less than 5% of apps on the FirefoxOS market place use APIs requiring the app to be a packaged app instead of a hosted one.

Note: It was decided that content protection (DRM) would be considered out-of-scope for this meeting.

From GMandyam[a]: I believe the reason the SysApps WG failed in developing a runtime and security specification for installable web apps was that many platforms had already solved this problem[b] independent of the W3C. Any standard developed by the W3C in this area may be ignored by the industry. The focus for this work should be on hosted web apps.

Geolocation-specific issues (GMandyam):

The PING group conveyed the concern (during the May meeting focused on the re-chartered Geolocation Working Group) that service providers do not provide information to the end user as to how geolocation information is used by the website. The current browser permissions model does not cover this. However, mechanisms that rely on the browser chrome for expressing intended use of geolocation information are subject to abuse.

Geolocation WG looks at adding geofencing which is security sensitive (indoor location, SSIA sharing, etc). Ad services: Sites adds the location as part of the request. There were privacy concerns about setting up geofences with respect to indoor centroids, as many times the most effective way to define the centroid is with respect to an indoor WiFi AP. Does the end user want a website to know the SSID of an AP in his/her home? Does the browser need to obscure such information from the website?

Native platforms have solved geolocation permissions mainly through declared permissions[c] (e.g. in a manifest) and/or application signing. The signing is supposed to be an indication of trust - the app has been vetted by an app store. However, app stores still have to rely on end user feedback in order to revoke permissions for rogue apps.

Media Capture/WebRTC (StefanH):

Pioneered by Ian Hickson, first proposal was device element, based on feedback the navigator.getUserMedia was introduced. The original idea was that the app should not know anything before granted access (the user should be presented with the possibility to opt in to any devices (=microphones, cameras) available, but the app would not know about available devices before access granted), but has developed into that the app _is_ able to find out what devices are available before asking access, and can ask for what devices it wants access to. In short, the current model allows for more fingerprinting than the original model.

Persistent access has also been introduced, meaning that an app could get access (if the user agrees) to devices without being presented with a prompt. This requires that the app is served over https.

Once the app has access to devices it can record to file (and then send the recording anywhere), capture images, send to arbitrary peer. But isolated media streams have been introduced, they prohibit recording/image capture and can only be sent to a peer with a defined identity.

Screen sharing is currently being discussed, proposal at http://rawgit.com/fluffy/w3c-screen-share/master/screenshare.html

Dom about the DAP models:

4 of DAP APIs are permission-less: Battery Status API, Ambient Light Event, Proximity Events, Vibration API. HTML Media Capture uses an implicit approval model: by taking the picture and selecting it, the user implicitly approves sharing it with the browser app. Network Service Discovery has a prompt then implicit-selector to determine from which devices to e.g. select media. The upcoming Wake Lock API expects to use the “ask for forgiveness rather than permission” approach, whereby the ability to keep the screen up is granted by default, but the user gets informed and can revoke that permission at the same time. Web Intents waking up again

Session 4: Review of approaches used by other platforms (web and native)

We had summaries for iOS, Android, Windows Phone, Chrome Apps, Firefox OS, and GM

Steven Woolcock gave us a quick overview of Apple's approach for iOS. There are a small number of permissions and when apps invoke the APIs for the corresponding capabilities, the user is prompted to obtain the permission. The context in which the prompts occur make it easier for users to understand what the prompts are for as compared to asking for permissions at install time. Apple has recently provided a means for developers to pass an explanatory string for use in the operating system generated permission dialogues.

Steven noted that in certain cases it would be desirable to ask for permissions prior to use. One example is where parents want to control what permissions are appropriate for apps used by their children.

Adrienne Felt summarised how permissions are used in Android. There are something like 150 permissions available. The ones that developers think they will need have to be declared in the application manifest and users have to give their consent as a precondition for installing an app. A few permissions are only available to applications certified by Google. Dom cited the API for bricking a stolen phone as an example.

She also described a study she had been involved in which exampled app program code to see which APIs the app used and compared this with the manifest to see whether developers are requesting privileges they aren't using. For the most part developers just request the permissions they need, and most of the exceptions seem to be explained by misunderstandings of what a given permission is required for.

Adrienne commented that when asked users thought about pernissions in terms of what they thought developers would do, and by and large, didn't appreciate the space of possibilities that permissions enable.

Dave wondered if permissions could be tied to use policies that are contractually binding on developers. If apps are found to breach these policies, then the apps and developers could be black listed.

Others noted that the Android permission model trained users to click through the consent dialogue in order to try out the newly installed app.

In many ways users would prefer to know whether the app is trustworthy or not and not have to see the legalese of the permissions dialogue.

John Hazen: Notes on Microsoft Permissions Model

The Microsoft model for permissions in Windows 8 was driven by earlier experiences with User Account Control (UAC) prompts, and by a desire to minimize the total number of permissions available to developers and end users. In both of these cases our prior experience indicated to us that users and developers will do the wrong thing, either by simply clicking through dialogs or by overdeclaring permissions just to make the app work. Our desire to keep the list short was driven by a desire to ensure that the developers and users could reason clearly about the capability. We ended up with about a dozen capabilities, but they are not very nuanced. For example, the picture library capability does not distinguish between read-only access or read-write access. The desire to minimize prompts led us to favor implicit consent through user actions, for example using the file picker to access particular files, or even choosing to install a particular app from the Windows Store. The only place where we decided to keep explicit prompts was for capabilities which expose something about the user in real time (geoloc, camera, microphone, etc.). In most cases, the end-user is delegating trust to the Store for many of the capabilities. This of course means that the Store needs to have an adequate review process to weed out most malware, but also needs to have revocation capabilities for cases where mis-behaving apps have been released to the wild. Finally, I also noted that it is not always the end-user who really should be making the trust decision--for example, in the Windows ecosystem access to Enterprise Credentials (Domain creds) is a powerful capability, but the resources that are being protected do not belong to the user - they belong to the network administrator, so the platform allows the network admins to allow/deny such apps from running on their networks.

Stéphanie Ouillon: Firefox OS Permission Model

We worked on a paper about the app permission model in Firefox OS. The following is copied from that document except for the table on permssions vs levels.

Permission Model Overview

Firefox OS’s proprietary APIs require permissions if they expose sensitive data or functionality to the web. Apps declare the permissions they want in an associated JSON manifest. Permissions are then denied/allowed or granted by the user according to the permission level of the app. Additionally permissions which have privacy implications also require user consent, by way of a runtime at first use of the API.

Permission Levels

“Web” apps permissions

“Web” apps follow the web security model and in general can not gain higher privileges than regular web pages. They may be hosted or packaged, and installed via the Firefox Marketplace, or from any website.

“Privileged” permissions

More sensitive APIs are restricted to “privileged” apps. For actually receiving these permissions, the app must be signed by the Mozilla Marketplace. “Privileged” apps are ZIP files that are digitally signed and distributed from the Mozilla Marketplace. All privileged apps undergo a security review by a (human) reviewer. The application review process is described at the following link: https://developer.mozilla.org/en-US/Marketplace/Publishing/Marketplace_review_criteria

“Certified” permissions

“Certified” permissions give access to system APIs which are needed to build a web-based mobile operating system. For security and/or privacy reasons, these APIs cannot be exposed to either privileged or hosted apps. Certified permissions can only be granted at build time (Gaia apps) and are not available to apps installed by the user (except to side-loaded apps for developers).

Challenge: exposing these APIs to the Web

Mozilla wants to evolve our proprietary APIs so they can be exposed to the web. The biggest challenge for this task is resolving intersection between the traditional use cases of native apps and the security risks of the APIs needed to support these use cases. In general there are three approaches to this problem:

  • limit the functionality of the APIs so they are safe enough for the web
  • adding system level mitigating controls to address security threats (e.g. notification UI to make the user aware that an app is using a certain device)
  • mandating security requirements for apps to increase the level of in web application code

Firefox OS currently employs a mixture of these approaches. Making the APIs safer

  • Adding more granularity to the permission model in order to expose safer API subsets

e.g the Mobile Network API exposes a read-only subset of the Mobile Connection API to allow privileged apps identify the carrier without needed to talk directly to the SIM card or mobile network. See details here:


  • Exposing an API through system-mediated UI

e.g. the Mobile ID API allows an app to verify the user’s mobile number without needing access to directly be able to send a silent SMS (which is a common use case).

See details here: https://wiki.mozilla.org/WebAPI/MobileIdentity

  • Requiring user-interaction to prevent inadvertent access to APIs

e.g. Sensor access (accelerometer etc) is limited to content which is in the foreground to prevent surreptitious monitoring.

e.g. getUserMedia, as on desktop browsers, requires prompt prior to granting access to the camera/microphone streams.

System Security Controls

  • Notification UI

e.g. The notification bar shows when an app is using the camera through getUserMedia, to make the user aware that the camera/microphone is enabled.

  • Global configuration

e.g. Enable/disable GPS button to allow users control over when geolocation is available.

Improving trust

Enforcing an integrity mechanism to that apps can not be modified

e.g. Privileged apps require apps to be static code within a ZIP file, and a Content Security Policy is enforced to ensure that only script from within that package can be run within the privileged application origin.

Challenge: the Web is dynamic, and forcing static content limits how web apps can be developed and deployed.

  • Signing application content

Privileged apps are required to be signed by the Mozilla marketplace to ensure they have gone through security review.

Challenge: current implementation requires code to be static ZIP files, similar issues as to above.

Challenge: Firefox Marketplace is the only source of trust for signing privileged applications. How do we delegate this trust to in the decentralised model of the web?

See discussion about the future of packaged apps and app developer signing: https://groups.google.com/forum/#!topic/mozilla.dev.webapi/68I80XiipBI

Reviewing application code

e.g. Privileged apps go through manual review prior to being granted privileged permissions.

Challenge: how to scale this control to the web?

API Case Studies

Advancing the permission model will require reviewing specific APIs and use cases. Below are some key APIs which represent some of the main types of APIs indicative:

API: MozMobileMessageManager
Description: API used by the system apps to send & receive SMS and MMS messages.


  • Extremely high threat API - abuse directly costs the user’s money and compromises privacy
  • WebAPI Security Discussion: Web SMS API

API: DeviceStorage
Description: Add, read, or modify media files stored on the device.


  • If content is exposed to the web, it is compromised if the app developer server is hacked.
  • A system-mediated UI file picker doesn’t solve the case when a gallery app wants to access *all • photos.

API: SystemXHR
Description: Allows anonymous (no cookies) cross-origin XHR without the target site having CORS enabled.


  • Risk is leading attacks on websites behind firewalls, when the phone is on an internal network.
  • Whitelisting domains in the review process (too complicated for the user to approve).
  • Ideally, WebSocket, WebRTC and CORS should replace TCP/UDPSocket and SystemXHR.

The following APIs are either privileged or certified but work is underway to try to expose (parts of them) to the web based on partner and app developer requests for functionality.

Work in progress

Mozilla is currently working to expose the following APIs to Privileged Apps:

  • Devices
  • NFC
  • Bluetooth
  • Wi-Fi (requested, but not priority)
  • WebSerial (requested, but not priority)
  • App embedding
  • Lockscreen (to allow for replaceable lockscreens)
  • Homescreen-webapps-manage (to allow for replaceable homescreens)
  • Firefox-accounts (allow for device wide sign-in)

Other controls are currently in progress or in discussion:

  • Allowing user auditing of API access:
    • One feature which is currently in progress is allowing users to monitor data usage on a per-application basis. This control could be employed for any API where resource consumption is a security concern (disk space, battery etc).
  • Improving the UX by giving the user more power and information by:
    • Tying permissions to actual actions which would be meaningful for the user to better inform about the impact of granting the permission requested by an app.

    • Requiring SSL as a mandatory control.

Claes Nilsson: Trusted hosted apps for FFOS - Sony research project

The dynamic nature of hosted web apps compared to installed web apps is advantageous in many aspects. Sony is evaluating how sensitive APIs could be opened up not only for installed privileged and pre-installed certified FFOS apps but also for hosted web apps. The model is based on using the existing web security mechanisms secure transport and Content Security Policies (CSP).

The model is described below:

  1. Content and manifest are downloaded to the device with ssl/tls, i.e. server authentication, encryption and integrity protection.

  2. Certificate pinning is used, which means that only certain specific certificates are trusted, for example only certificates signed by Sony and Mozilla are trusted.

  3. Signature of trusted app's manifest must be verified by a trusted authority

  4. There is a CSP field in the manifest file. It is defined so that by default only "self" is allowed, i.e. only content from the origin domain of the app is allowed to download. It is also possible to whitelist other domains with CSP that may be accessed through ssl/tls with certificate pinning. The resources that are accessed through ssl/tls with pinning are script and style src resources. (as declared in 'style-src' and 'script-src' directives in CSP element of the manifest.)

    In addition default security policies apply:

    • Eval and related functions are disabled
    • Inline JavaScript will not be executed
  5. Trusted hosted apps are allowed to access a set of more sensitive APIs than normal hosted apps.

    Manifest example:

       "name": ”Test app",
       "description": ”Test of trusted hosted apps",
       "version": "1.0",
       "type": "trusted",
       "launch_path": "/index.html",
       "icons": { "16": "/favicon.ico" },
       "developer”: { "name": ”Developer Team", "url": "http://devloper.com" },
       "csp" : "script-src ’self’ https://.123.testfront.net;
                style-src 'self’ https://123.testfront.net",
       "permissions": {
              "device-storage:videos":{ "access": "readonly" },
              "device-storage:pictures":{ "access": "readwrite" }
       "appcache_path": "/manifest.appcache"

    Mozilla permissable table example (“trusted” is the additional application type “trusted hosted web applications)::

    "device-storage:pictures": {
       app: DENY_ACTION,
       trusted: PROMPT_ACTION,
       privileged: PROMPT_ACTION,
       certified: ALLOW_ACTION,
       access: ["read", "write", "create"]
    "device-storage:videos": {
       app: DENY_ACTION,
       trusted: PROMPT_ACTION,
       privileged: PROMPT_ACTION,
       certified: ALLOW_ACTION,
       access: ["read", "write", "create"]

Further information about the project

Stefan Håkansson: “Trusted Service Worker/Provider“ - Ericsson research concept

Gives regular web apps access to extended functionality. Extended functionality requires access to privileged APIs (not exposable to web application for security reasons).

A Provider runs trusted code (JavaScript) from a third party, it has access to selected privileged APIs and can formulate consent questions that make sense to users. It executes in a separate context and exposes its own API towards web applications using web messaging (postMessage).

Enables new APIs to be built on top of privileged APIs, in a way that allows them to be securely exposed to web apps.

A Provider runs in a new type of Worker - ProviderWorker and exposes its own API towards web applications via web messaging. Differs from Web Workers in that it:

  • Can only execute code from trusted sources
  • Gets its origin from the Provider publisher
  • Access to selected privileged APIs

A manifest is used (Title, description, permissions, …)

The Provider (having access to privileged APIs) must be distributed by an app store (code reviewed etc.)

More details are in Stefan's presentation on Web Providers.

Vadim Draluk: GM focus on web and automotive:

While General Motors had announced its own HTML-based development platform a while back, strategically it is looking forward to emergence of a more standardized environment for Web applications that would facilitate build-up of an ecosystem suitable for automotive environment, among other verticals. As a result, GM has joined the W3C Automotive Business Group, and has been active in its proceedings. One of the issues that came up within that group was permissions and security model. The group decided that it would be highly beneficial to have such a model defined within W3C horizontally, such as the same one could apply to all verticals, automotive included.

There are some aspects that differentiate automotive industry requirements. First, the most typical deployment models are installed and installed-projected (that is, installed on a phone that is projecting its screen onto the IVI display), less so hosted. The reason is that, mostly due to security concerns, browsers are not installed in the IVI systems. However, attracting Web developers remains an important objective, hence the bias towards installed JavaScript/HTML apps. We do realize that the focus of the SysApps WG is currently on hosted use cases. However we believe it is possible to introduce a model which will be applicable to both modes, so that some of the [less entrenched] JS runtimes could choose to adopt it.

Another industry-specific consideration, related to permissions but not exactly equivalent to them, is business sensitivity of some automotive signals, and hence APIs that are used to access them. Thus the notion of “licensed” APIs, ones that are available based on some external arrangements to some apps but not others, is a concept widely accepted by automotive OEMs. This is already reflected in Availability APIs that are part of the automotive spec, currently under a public review. Our belief is that it should be possible to cover this notion under a comprehensive permissions system, though we are equally comfortable with leaving it within the automotive vertical

Here’s a link to a doc page that describes QNX’s current approach vis-à-vis permissions:

I believe all their apps are installed, not hosted

Dom: I guess the hope had been that these independently developed solutions to the permissions problem could converge in a standard approach. But that seems unlikely to succeed now.

Session 5: What lessons come out of academic studies

Adrienne's hexagon diagram was warmly received (Figure 8.1 in her dissertation)

decision graph for permission mechansis

This provides a decision graph for determining the most appropriate permission granting mechanism for a given capability: {automatic grant, trusted UI, confirmation dialog, install time warning}. The criteria include:

  • 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?

Two things to be added to the diagram:

  1. The degree to which the capability is explainable to the user
  2. How the capability will be used by the application

If understandable, is there any point in the app explaining what it wants it for (and how to trust that info).

Users want to know how a capability will be used instead of how it _can_ be used. But evil apps would lie about the intended use anyway. UAs should have a system for reporting apps that are abusing APIs/Capabilities. Basis for trust is is related to how much an app is reviewed by e.g. an app store. Is the browser the right tool for monitor the app behavior? Can be, but not specced by the W3C. Malware agents outside the scope of W3C.

We discussed the role of trusted UI as a natural means for users to grant permissions through user interaction, e.g. clicking on an icon of camera in other to take a photo. The browser disables the UI and greys it out if anything occludes its pixels. Likewise, the browser can apply a simple animation when the UI control is initially displayed as a means to signify that the control needs to be visible for a minimum period before it becomes active (analogous to speed bumps in roads that force drivers to slow down). The browser also needs to ensure user interaction with trusted UI controls can't be spoofed by applications.

Trusted UI may give developers some control over the rendering, e.g. the color palette or theme.

Session 6: Discussion of what considerations are important for the OWP

Tailoring user experience. Put a lot of justification in the app before asking for access to capabilities. Likewise, discovering when capability access has been revoked to show a suitable UI. Standards may be needed here. Naming of capabilities.

Result of this discussion may eventually be input to the WebApps WG work on manifest.

Granularity: different questions what is available to developer vs. what is presented to the user. Broad categories help for e.g. future proofing. What about vendor specific extensions?

Capabilities needed will vary depending on area (automotive, health, ….), and so may the permission model. But who should take care of future proofing? W3C CSS has worked out in this respect.

Should we develop specs or design patterns? Should it be in IG, CG or WG? Robin: does not really matter unless IPRs are in scope. Dom: Perhaps the Web and Mobile IG could host the work. But more important: who will have the time and interest to put in work?

Claes: can we produce anything normative? A lot is UI, difficult to be normative about that. Can anything normative be put (referenced to) from the UDP/TCP socket recommendation for example? There is a question if permission models should be specced, for other specs to reference.

MS: I’d definitely like to cover patterns and practices, let’s see if we go beyond that (depends on if we have well defined use cases. We might spec how the developer declares how to spec the capabilities wanted (e.g. in a manifest). But people need to bring that question back to their organisations.

App store seem to be a central part, do we need app stores for the web? Broad question, outside the scope of this meeting perhaps.

Implications of different approaches have for API design:

  • Some APIs only useful in certain contexts. Mislabeling controls to fool people.
  • There should always be a failure callback (permissions may have been revoked).
  • Need to check if the app has permissions or not.
  • May not be a need to involve the user at all.
  • Should be uniform across APIs.

Comes down to allow the developer to provide the best user exp.

Do we need patterns for persistence (once, rest of session, forever, ….)? Up to each UA, or something we should work on? Perhaps to default to per session.

Thursday, 4th September

We continue with the discussion of considerations we consider important for permission handling in the OWP.

GMandyam: I think in order to focus the discussion on trust, we should leave the discussion of app stores and the business processes they implement aside. Appsigning as an indication of trust has worked well, and the client does not have to have precise knowledge of the testing and validation that the application may have undergone in obtaining its signature in order for determining the level of trust in the application. Previous attempts at standardization of the app store and developer ecosystem (e.g. WAC, OMA) have not succeeded. The W3C should stay away from app store standardization if it wants to make progress in the area of application trust. Adrienne: if the browser uses heuristics to determine whether or not to grant permissions automatically or to ask the user or just to block some capabilities, this could be too surprising for users, and a potential pain for developers to figure out what they need to do to avoid the user permission prompts.

What kind of framework would be needed to support this?

Dom: pre-declaring required permissions might help, but we would need to look into the details, first.

John: we can’t avoid this problem if we are to give guidance to other groups. There are likely to be different implementations from different vendors, but we want to avoid the need for websites to have to apply different guidelines for different browsers.

Kenneth: web intents (Wonsuk: Ask to Kenneth whether does this should be replaced by Web components or not?) will complicate matters. (Claes: I think that Kenneth referred to web apps composed by several web components where the different components will require their permissions separately)

Adrienne: one case concerns trust across sites, the other is whether the browser trusts a site.

Steven: the browser wouldn’t trust apps when they make requests outside of their site

John: or more generally, controlled via CSP

Steven: issue when a developer makes a bad call when it comes to trusting 3rd party sites

John talks about a range of heuristics that browsers could employ. Fundamentally, we need some kind of delegated trust.

Adrienne: I agree. Otherwise iframes will need to ask for permissions separately, confusing the user.

GMandyam: If the user is actively managing website permissions using the browser chrome, then permission delagation needs to be managed accordingly. For instance, if the end user has denied permission for x.com to get access to the camera and then browses to y.com which tries to delagate permission back to x.com, then the browser needs to manage permissions approriately (e.g. blocking the delagated permission to x.com or prompting the user).

Stefan: sometimes you don’t trust the parent apps, but do trust the child app, currently no way to deal with this effectively, e.g. users can’t see the URL for the iframe.

Adrienne: users don’t understand apps which span websites.

John: in native world you can embed all kinds of stuff, e.g. maps, and you don’t care where it comes from. If we want web apps to offer similar user experience, we need to support some kind of trust delegation. In some cases it is okay for transitive trust to apply.

John asks how this could apply to the web?

Wendy: difference in scale, between installed apps (relatively few) and browsed-to websites. some questions around accountability and legal attribution

Wonsuk: likely need for contractual relationships between apps and nested apps around delegation of trust, and between app store vendor and app developers

Some discussion around level of curation involved

(FYI: http://www.w3.org/wiki/File:Manifest-usecases.png)

Wendy: you can imagine a liability regime which provides an incentive for the parent app developer to form contractual relationships or otherwise manage the trustworthiness of the sites it depends on for its services. I’m not sure we’re there today.

Kenneth: today we see concerns around security and payments that lead to users being transferred from one site to another.

John talks about what it means to “install” (other trust gestures include “pinning”, “bookmarking”) hosted apps when you could review the trust and enable a more native like user experience as compared to sites you just visit (drive by sites)

Steven: upfront declarations have some bearing on this. It helps developers to think about what they are doing, and as well as helping with code review

Anssi: "pinning", "bookmarking", "installing" are trust gestures for keeping. Another type of indirect trust indicator is e.g. the frecency algorithm. The following is a brief extract from the document:

Frecency is a score given to each unique URI in Places, encompassing bookmarks, history and tags. This score is determined by the amount of revisitation, the type of those visits, how recent they were, and whether the URI was bookmarked or tagged. The word "frecency" itself is a combination of the words "frequency" and "recency."

Steven: is there any value in W3C looking at using manifest for upfront declarations as part of the delegation model?

John: the browsers could be doing a lot behind the scenes, there could be some UI involved or none. My sense of the room is that some form of delegation is valuable.

Wendy: before we leave trust and delegation, consider attribution trails/provenance: keeping (and perhaps exposing in some way) the chain of trust delegations.

Dave: when visiting arbitrary websites, the website itself could reference endorsements by third parties that are generally deemed trustworthy, but it is also interesting to consider active roles for 3rd party agents that monitor at what you are visiting and can flag good/bad sites, independently of the browser. This is already the case for the native world e.g. Lookout on android.

Dom: on native, the main app stores are operated by the same companies that are distributing the operating systems; trusting the OS is necessary, and extending that trust to the store, and implicitly to the apps these stores distribute makes some kind of sense; on the Web, the basic trust level is in the User Agent; and the User-Agent plays a role in protecting user data, but also already goes a bit further than that by e.g. alerting the user on phishy web sites, or sites that are known to have malware via centrally maintained Web sites. Maybe there is more to be learned from that comparison, although we clearly don’t want to the Web to become a closed/filtered ecosystem.

Adrienne: if there are many different ways for trust to accrue this could create complexity for developers as they seek to control the user experience

Kenneth: could it make sense to the user to “pin” a site to grant it additional permissions?

John: “pin” as a proxy for some gesture for indicating trust

Robin: “install” metaphor is easier for users to understand than pinning. That could be implied by installing as a gesture

Wendy: it makes sense to have an explicit user-gesture to grant increased permissions; should be something that users can easily understand

Adrienne: we’re going to see websites yelling at users to pin them just as now they encourage users to install the site’s native app

Robin: this is likely to be a short lived problem as the ecosystem matures (and 3rd party endorsements take off). Also consider buckets of permissions.

We move on to the broad category of questions around permission management

Dom: regarding indicators, we already know some specs (e.g. getUserMedia) set requirements on how indicators are expected to behave (if there are indicators); to me, this means we probably need to give guidance on whether that’s a good a idea to set these requirements, and if it is, what requirements might look like.

There are some existing W3C specs that call out for indicators but don’t specify the user experience for that.

Dave: Is there a need to inform apps when the user revokes a permission, e.g. to enable the app to dynamically adapt the user experience to match? i.e. by handling events rather than having to poll.

John: similarly, changes in system capabilities, e.g. caused by the user disconnecting something.

Kenneth: does native apps have a means to listen for such changes?

Steven: probably

John: it’s not clear how important this is, but I don’t want to rule it out just yet

Re privacy implications, we could drop a permission-denied signal and just return a failure.

(Related specs and Links - security/privacy considerations and best practices)

  • http://www.w3.org/TR/geolocation-API/#security
  • http://dev.w3.org/geo/api/spec-source.html#security
  • http://www.w3.org/TR/web-intents/#privacy-considerations
  • http://www.w3.org/TR/service-workers/#security-considerations
  • http://www.w3.org/TR/html-media-capture/#security
  • http://www.w3.org/TR/telephony/#security-and-privacy-considerations
  • http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/
  • http://www.w3.org/TR/app-privacy-bp/

Kenneth: there is a difference between background (app running with window/tab in the background) or when the app windows is closed and the app is running as a system service (think Facebook Messages).

Giri: I agree, there is a difference between background as in service worker and visibility

Dom: most native platforms provide a number of APIs whose access is very limited (usually only to the OS maker or some device manufacturers); this provides isolation of the most dangerous or hard to explain permissions; is that something we want to extend to the Web, using e.g. Web Intents or an approach based on registerProtocolHandler? Should W3C deal with APIs to access these most limited APIs (as SysApps is currently chartered to do, e.g. the telephony API)?

Wendy: 3d party reviewers can assess the use of more granular permissions, give incentive to constrain access to what’s necessary

Lunch break and group photo, we resume at 13:30 French time

Session 7: Permissions-related API proposals

Adrienne introduced Mounir Lamouri's proposal for an API for developers to test whether a given permission had been granted, denied or would result in a prompt by the browser when the app tried to use the corresponding capability.

API Permissions articles/papers etc.:

  • https://www.w3.org/wiki/Mobile/articles#API_Permissions Retired work items from the Device APIs WG:
  • http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
  • http://www.w3.org/TR/api-perms/ Permissions API proposal posted to the public-webapps mailing list:
  • https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
  • (a similar proposal, but with mixins: https://github.com/w3c/push-api/issues/3#issuecomment-43056068)

Steven: The four states I was referring to are:

  1. Permission being sought and denied
  2. Permission being sought and granted
  3. Permission previously denied
  4. Permission restricted

Giri: Are there still privacy considerations in exposing user preferences? {This seemed to be an issue the last time that DAP considered a permissions API} Could we reduce this concern by exposing “unavailable” rather than distinguishing permission not granted from unavailable? Also suggested that Mounir present this idea to PING to see if he can get some concrete feedback on any privacy concerns.

Vadim: Automotive, “availabiity” API, we have different reasons for non-availability, business, security, etc.

Adrienne: two different privacy considerations, fingerprinting

Wendy: Need to provide for the Tor browser use case: a browser that makes settings uniformly to provide an anonymity set

Robin: fingerprinting is probably a lost cause, but in the browser engine, you can detect sites doing too much investigation

Dave: look at ways the browser could protect you until the site is trusted; ways for third parties to assess apps at either install or run-time.

See also Nick Doty’s work with the Privacy Interest Group

Wendy: Can we bring in revocability? Useful in the API, e.g. to offer user “try this feature out for 30 min then automatically disable, unless you choose to keep it” without going out to the browser chrome.

Kenneth: can we use the names of the APIs as the names for permissions? Robin: yes, that was what we agreed yesterday

(Jonathan Jeon: we can reference from android case)

  • http://developer.android.com/reference/android/Manifest.permission.html
  • http://developer.android.com/reference/android/Manifest.permission_group.html

Steven: does the proposal include support for categories / groups of permissions? Adrienne: no, not at the moment.

Steven: still concerned about pre-flight request for permission. If dev has permission, should only be because they’re using it. So why would you need the “has permission”?

John: in some cases it may be indeterminate whether a prompt will be needed, for instance, various factors may allow the browser to grant the permission without needing to ask the user.

Slightly favour exposing information that “this feature is not available *or • permission not granted” (it is not exposed to the web app whether this is due to a permission setting or unavailability of the device) rather than returning information“the feature is available *and* access to it has been granted”. Don’t promote harassing the user with “come on, please please grant this permission”

Steven: in principle, the user could disable a capability whilst the prompt for the permission is present. This means that you can’t completely rely on the returned value.

John: I am interested in the proposed API, but would like to see “prompt” replaced by a value that denotes that it is indeterminate whether a prompt would be invoked when attempting to use the associated capability.

We agree that we need names (strings) for permissions, e.g. for use in manifest and when dealing with requests for multiple permissions, but these names can be taken from the corresponding APIs, e.g. navigator.geolocation

Session 8: Plans for future work

(dom’s link) web permissions requirements matrix

Adrienne's diagram of a decision graph for permission mechanisms:

decision graph for permission mechanisms

We agreed that the permission mechanisms need to be chosen according to the capabilities involved. Adrienne's diagram is very helpful for explaining some of the criteria involved. It would be valuable to provide guidelines on the principles to W3C working groups that are defining standards for APIs. This could be addressed by a W3C Community Group.

Trusted UI, that is embedded within web apps, is an promising area for further study as it allows user actions to implicitly grant permissions in a natural way without the need for the browser to prompt the user directly. The design of the corresponding UI requires a good understanding of the use cases. This too is something that could be addressed as part of a Community Group.

We agreed that trust delegation is essential to reducing the burden on users for understanding permissions. This would also permit finer grained permissions that make it easier for developers to only request the minimum capabilities they actually need. We can expect innovation by browser vendors for heuristic mechanisms for assessing apps and deciding when to ask the user and when to automatically grant or deny particular permissions. There needs to be some standards around how trusted third parties can endorse apps, especially for hosted apps.

W3C needs to define standards for permission handling for hosted apps on the Open Web Platform. Companies see a continuing need for packaged apps and we shouldn't rule these out, despite the lack of interoperability for packaged apps due to variations in APIs and packaging across vendors. We agree that declaring permissions in an app manifest can be useful for people reviewing apps, and as such facilitate trust in apps. A similar argument can be made for app developers to provide richer descriptions of what the app is using capabilities for. This information is aimed at reviewers and doesn't need to be presented to end users. There is a risk of developers trying to mislead reviewers, but this can be countered through having multiple independent reviews and through innovations in reviewing practices and heuristic tools for accessing apps.

We also liked the idea of enabling app developers to adapt the user experience according to what permissions have been granted and are available as capabilities. This could make it a little easier to finger print devices, but there are already many ways in which to do so, and rather than worrying about adding extra bits of finger printing information, it is more appropriate to consider ways for browsers to apply heuristics to flag up apps that appear to be using finger printing. Reviewers could then decide whether the app is behaving reasonably given its stated purpose, or whether it is a rogue app.

There is further work to be done on the details of the permission models, for example, whether developers have access to {granted, denied, prompt} for permissions, or whether the permissions APIs should not distinguish between a permission being denied, and the corresponding capability not being available. The persistence model for permissions is expected to be an area where browser innovation around trust is likely to make it hard to standardize in a prescriptive way.

Areas of Rough Consensus on Work Items (and which groups)

  • Handling of trust delegation to iframes, web components (Adrienne) (WebAppSec? (CSP) HTML? (doing sandbox already))
  • Extension of manifest to declare permissions needed/features used (WebApps WG)
    • http://w3c.github.io/manifest/
  • Permissions API proposal (WebApps WG (proposed there)? SysApps? DAP (could already be in charter (Dom)? WebAppSec ? PING should review)
    • DAP Charter (http://www.w3.org/2011/07/DeviceAPICharter) has the following work item in scope “An API for requesting and managing user permissions to use device features”
  • Review of APIs wrt how they handle permissions (Best Practices) (Mobile Web IG? TAG? DAP? WebApp? (important: find somebody to do the work (Adrienne interested) [Dom interested to help if not alone]))
    • Dom’s review of existing APIs permissions in Mobile Web IG (but really Dom only - Adrienne/Chrome have content to contribute)
    • Document existing practices for permission handling http://www.w3.org/TR/app-privacy-bp/
      • http://lists.w3.org/Archives/Public/public-web-mobile/2014Jan/0001.html
  • Best practices for browser vendors (Microsoft, Google, Qualcomm interested - CG?)
    • not a normative document
    • Dom’s review of existing APIs permissions also relevant here
    • enterprise rules & policy
    • Adrienne’s work (flowchart)
    • helpful for partcipants to agree on best practices
    • not necessarily read
    • Trusted UIs, gadgets rather than prompts (Dave)
      • researchy
  • (Packaged apps not ruled out)

Areas where we are still some way apart but agree to work on closing the gap

  • (how about permission model ?)
  • An interoperable way for indicating trust, e.g. endorsements for hosted web apps (premature to determine group? put into CG above)
    • Use cases to document what we want to achieve wrt trust delegation
    • Permissions on sensitive APIs (gemalto)
      • standard way to represent endorsement as “trustworthy” by some party (signature)
      • like certificate authorities
      • (some debate on whether this should be done)
      • or signed webapp “packages”. not a CA
  • (what considerations from mission critical case - web and automotive ?)

Next Steps

The W3C staff are planning on a blog post to draw attention to the meeting at its conclusions. A session will be held at TPAC to further encourage discussions on next steps including the launch of the Community Group.


Jonathan Jeon made the following suggestions after the meeting:

I didn't propose the issues during this meeting, but I think we need to consider as below issues for future work.

  • Wide scope permission issue on web app store ecosystem:

    As we know well, Web app store will be a key component on web app ecosystem. So if we want to make an open web app ecosystem, we need to make the way for Open Web App Store Federation. Web app store federation is also related with app permission issue. The Web Application Store Community Group has prepared some Requirements and Use Cases for Open Web Application Store.

  • Permission & APIs for system setting:

    If we will make the permission APIs, it would be good to consider the API for high level system setting. High level setting API can be provide a simple interface to manage the global system-level device preferences and setting. Here is a proposal for a System Settings API.

Our thanks to Gemalto for hosting this meeting and to all those who participated.