docs/security/permissions-for-powerful-web-platform-features.md
Author: [email protected] Contributors: [email protected], [email protected]
Fugu is a renewed effort to bring powerful new capabilities to the web -- e.g. filesystem read/write access. Allowing users to control which sites are able to access such APIs is crucial for maintaining the security and privacy properties of the web. The impact of restrictions on the developer ergonomics and user utility of the API and the web platform overall must also be considered.
This document explores approaches to guarding powerful APIs, e.g. using installed web app state or some other proxy for high user engagement. The following general principles summarise the overall approach of the Chromium project to evaluating how powerful new features should be controlled on the web:
The remainder of this document explains the reasoning behind these principles, and summarises why alternative proposals were not taken up.
This section outlines the general principles that the Chromium team believes are critical when designing access to powerful new web platform APIs. These principles will be considered when evaluating how new APIs are designed.
Minimally, all new powerful APIs must only be available in secure contexts. Ideally, availability is restricted to top-level frames and requires a user gesture to trigger. When a webpage is running in a secure context in a top-level frame with an active user gesture, we call this situation a baseline context.
Browser extensions are also included as a baseline context, as they can already make use of web platform APIs (subject to the same access checks as web sites).
The permission delegation mechanism may be used to extend privileges to iframes on a page if it makes sense for a powerful capability to be delegated in this way.
In general, any baseline context may access powerful APIs, regardless of its windowing state (in the tabbed browser or in a standalone app window), installation state (installed or not), or user engagement (highly interacted with or not). This avoids the fragmentation of the web into different, sometimes unpredictable states, and encourages careful consideration of new API surfaces such that they are exposed in a way that is safe for the web at large.
In general, access to powerful APIs must be mediated by direct, informed user consent while the requesting site is open in a foreground tab via mechanisms which may include:
These mechanisms must clearly disclose the origin of the request, and follow Chromium's guidelines on displaying URLs. Implementations may be tested using tools such as Trickuri.
As much as possible, APIs should avoid a "double prompt", e.g. a permission prompt requesting access to the file system, followed by a chooser to pick the file/directory to access. There is little security or privacy benefit to such a double prompt, and it detrimentally affects user and developer ergonomics.
There are cases where double prompts are unavoidable, e.g. a web site may request access to contact information, and if the user grants access, the browser may need to request OS-level permission to service the request.
In some cases, Chromium may implicitly grant access to an API if it is not particularly dangerous or does not make sense to guard behind a permission consent. An example of this is the Badging API, which only works for installed web apps, and results in a subtle badging effect on the installed app icon that is not invasive or privacy-sensitive. These cases should be relatively rare considering the powerful APIs that are covered by this document.
The scope of access to APIs follows the web's same-origin model.
The only definite capability granted by installation is persistence. By installing, the user has explicitly indicated that they want the web app to have a persistent presence on their system.
New powerful APIs should exclusively use session-based permissions for web sites that are not installed. In particular, there should be no access while the site is not open in a tab, and access cannot be requested from a non-foreground tab. When the site is closed or navigated away from, it loses any granted access to powerful APIs it had, and must re-ask for access the next time the user visits.
Installed web sites may instead receive a permanent grant, which is removed when the site is uninstalled. In this way, installed web sites may be granted the ability to access capabilities in the background, depending on the particular details of each capability. It also avoids overloading the installation decision with consequences that users may not expect.
Persistency for installed web sites may have other requirements, but non-installed sites may never receive persistent grants to access powerful new APIs.
Some powerful APIs act as a proxy for persistence (e.g. a web site with permission to write files to disk). We distinguish persistence via a currently granted capability from persistent access to the capability itself; it is the latter privilege which is granted by being installed.
It should be obvious to users when sites are using powerful APIs, and they should be given the tools needed to effectively manage and revoke access when necessary.
Removing persistent access from the drive-by web may drive up decision fatigue due to overprompting. However, we anticipate that many of these capabilities will have relatively niche applications that the drive-by web should not commonly access.
Repeated granting of access to powerful APIs can be used as a signal for installation. For instance, after two successful powerful permission grants, Chromium could present the user with the option to install the app on the third permission request.
Powerful new capabilities may be paired with Chromium policies which permit administrators to enforce persisted access to capabilities without prompts. Capabilities may also be restricted or blocked by such policies. This is in line with how many existing permissions have admin policy overrides.
Currently, web sites which are not installed have access to significant persistence mechanisms:
To better align the existing web to the proposal presented here, we suggest a parallel effort to apply new lifetime limits on existing persistence mechanisms. For example, some of the following measures could be explored:
We describe a high level case study based on the principles in this document for granting a web site access to a) read any file in a certain directory; b) write files to a directory.
Apps on any desktop or mobile platform require installation to run, and when installed, apps are automatically granted many privileges. We could extend this concept to the web by restricting powerful APIs like the File System Access API only to installed web apps. That is, the drive-by web could not even ask for permission to access an API -- the site would need to be installed.
A key argument for using installation in this manner is that some APIs are simply so powerful that the drive-by web should not be able to ask for them. However, this document takes the position that installation alone as a restriction is undesirable.
Restricting APIs to installed web apps is not a meaningful security improvement for users for several reasons:
This is a more general concept than installation: that continual, significant usage of a web site should allow that site to access more powerful APIs.
Similar to installation, the Chromium team does not regard engagement as a robust way of controlling access to APIs.