Permissions Registry

W3C Draft Registry

More details about this document
This version:
Latest published version:
Latest editor's draft:
Commit history
Marcos Cáceres (W3C)
Mike Taylor (Google LLC)
GitHub w3c/permissions-registry (pull requests, new issue, open issues)


This document serves as the W3C registry of permissions of the web platform, which includes both policy-controlled features and powerful features.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

The list of features in this registry is not exhaustive. It is expected that new features will be added to this document as they are implemented across multiple user agents.

Please subscribe to the Permissions Registry Repository on GitHub to be notified of changes.

This document was published by the Web Application Security Working Group as a Draft Registry using the Registry track.

Publication as a Draft Registry does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 03 November 2023 W3C Process Document.

1. Purpose

This W3C Registry provides a centralized place to find the policy-controlled features and/or powerful features of the web platform. Through the change process it also helps assure permissions in the platform are consistently specified across various specifications.

By splitting the registry into standardized permissions and provisional permissions, the registry also provides a way to track the status of these features.

2. Change Process

The change process for adding and/or updating this registry is as follows:

  1. If necessary, add a "Permissions Policy" section to your specification which includes the following:
    1. The string that identifies the policy controlled feature (e.g., "super-awesome"). Make sure the string is linkable by wrapping it a dfn element.
    2. The default allowlist value (e.g. 'self').
  2. Determine if your feature meets the definition of a powerful feature (i.e., requires express permission to be used). If it does:
    1. Specify a powerful feature in your specification in conformance with the Permissions specification.
  3. Modify either the table of standardized permissions or the table of provisional permissions filling out each column with the required information.
  4. Submit a pull request to the Powerful Features Registry Repository on GitHub with your changes. The maintainers of the repository will review your pull request and check that everything integrates properly.

3. Registry table of standardized permissions

For a permission to appear in the table of standardized permissions, and thus be considered a standardized permission, it needs to meet the following criteria:

Each permission is identified by a unique literal string. In the case of Permissions Policy, the string identifies a policy-controlled features. Similarly, in the Permissions specification the string identifies a powerful feature.

Note: Permissions and Permissions Policy
Table of standardized permissions of the web platform
Identifying string Is policy-controlled feature? Is powerful feature? Specification Implementations
Chromium Gecko WebKit
"geolocation" YES YES Geolocation API YES YES YES
"notifications" NO YES Notifications API Standard YES YES YES
"web-share" YES NO Web Share API NO YES YES

4. Registry table of provisional permissions

Provisional permissions are permissions that are not yet standardized (i.e., they are either experimental, still in the incubation phase, or are only implemented in a single browser engine).

Table of provisional permissions
Identifying string Is policy-controlled feature? Is powerful feature? Specification Implementations
Chromium Gecko WebKit
"accelerometer" YES YES Accelerometer YES NO NO
"window-management" YES YES Window Management YES NO NO
"local-fonts" YES YES Local Font Access YES NO NO

A. References

A.1 Informative references

Accelerometer. Anssi Kostiainen. W3C. 2 November 2023. W3C Candidate Recommendation. URL:
Geolocation API. Marcos Caceres; Reilly Grant. W3C. 1 September 2022. W3C Recommendation. URL:
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL:
Local Font Access. WICG. cg-draft. URL:
Notifications API Standard. Anne van Kesteren. WHATWG. Living Standard. URL:
Permissions. Marcos Caceres; Mike Taylor. W3C. 13 June 2023. W3C Working Draft. URL:
Permissions Policy. Ian Clelland. W3C. 17 October 2023. W3C Working Draft. URL:
Push API. Peter Beverloo; Martin Thomson; Marcos Caceres. W3C. 10 October 2023. W3C Working Draft. URL:
W3C Process. Elika J. Etemad (fantasai); Florian Rivoal. URL:
Web Share API. Matt Giuca; Eric Willigers; Marcos Caceres. W3C. 30 May 2023. W3C Recommendation. URL:
Window Management. Joshua Bell; Mike Wasserman. W3C. 6 September 2023. W3C Working Draft. URL: