| CARVIEW |
Permissions
Interacting with Permissions for Powerful Features
W3C Working Draft
- This version:
- https://www.w3.org/TR/2021/WD-permissions-20210831/
- Latest published version:
- https://www.w3.org/TR/permissions/
- Latest editor's draft:
- https://w3c.github.io/permissions/
- Previous version:
- https://www.w3.org/TR/2021/WD-permissions-20210830/
- Editors:
- Marcos Cáceres (W3C)
- Mike Taylor (Google LLC)
- Former editors:
- Mounir Lamouri (Google LLC)
- Jeffrey Yasskin (Google LLC)
- Participate:
- GitHub w3c/permissions
- File an issue
- Commit history
- Pull requests
Copyright © 2021 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
Abstract
The Permissions API specification defines common infrastructure that other specifications can use to interact with browser permissions that allow or deny access to powerful features on the web platform. For developers, the specification defines an API to query the permission state of a powerful feature, or be notified if a permission for a powerful feature changes state.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This is a work in progress.
Some features in this specification are supported by only one user agent, and as such, are marked as at risk.
This document was published by the Web Application Security Working Group as a Working Draft. This document is intended to become a W3C Recommendation.
GitHub Issues are preferred for discussion of this specification.
Publication as a Working Draft does not imply endorsement by the W3C Membership.
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.
This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 15 September 2020 W3C Process Document.
1. Examples of usage
This section is non-normative.
This example uses the Permissions API to decide whether local news should be shown using the Geolocation API or with a button offering to add the feature.
const { state } = await navigator.permissions.query({
name: "geolocation"
});
switch (state) {
case "granted":
showLocalNewsWithGeolocation();
break;
case "prompt":
showButtonToEnableLocalNews();
break;
case "denied":
showNationalNews();
break;
}
This example is checking whether the page has the "geolocation" and the
"notifications" permissions:
const queryPromises = ["geolocation", "notifications"].map(name => {
return navigator.permissions.query({ name });
});
for await (const status of queryPromises) {
console.log(`${status.name}: ${status.state}`);
}This example is checking the permission state of the available cameras.
const devices = await navigator.mediaDevices.enumerateDevices();
// filter on video inputs, and map to query object
const queries = devices
.filter(({ kind }) => kind === "videoinput")
.map(({ deviceId }) => ({ name: "camera", deviceId }));
const promises = queries.map((queryObj) =>
navigator.permissions.query(queryObj)
);
try {
const results = await Promise.all(promises);
// log the state of each camera
results.forEach(({ state }, i) => console.log("Camera", i, state));
} catch (error) {
console.error(error);
}2. Model
This section specifies a model for permissions to use powerful features on the Web platform.
2.1 Permissions
A permission represents a user's decision to allow a web application to access a powerful feature.
Conceptually, a permission can be in one of the following states:
- Prompt:
- The prompt state represents that the user has not made a decision (i.e., it's the same a denied), and the user agent will be asking the user for permission if the caller tries to access the feature. The user might then grant, deny, ignore, or dismiss the request.
- Granted:
- The granted state represents that the caller will be able to successfully access the feature without having the user agent asking the user's permission.
- Denied:
- The denied state represents that the caller will not be able to access the feature.
To ascertain new information about the user's intent, a user agent MAY collect information about a user's intentions. This information can come from explicit user action, aggregate behavior of both the relevant user and other users, or implicit signals this specification hasn't anticipated.
2.2 Powerful features
A powerful feature is a web platform feature (usually an API) for which a user has to grant permission before the feature can be used. Access to the feature is determined by the environment settings object by the user having granted permission via UI, or by satisfying some criteria that is equivalent to a permission grant.
A powerful feature is identified by its name, which is a string literal (e.g., "geolocation").
The user agent is responsible for tracking what powerful features each realm has the user's permission to use. Other specifications can use the operations defined in this section to retrieve the UA's notion of what permissions are granted or denied, and to ask the user to grant or deny more permissions.
2.2.1 Specifying a powerful feature
Specifications wanting to add a new powerful feature are encouraged to coordinate with us on this specification via GitHub.
Each powerful feature has the following permission-related flags, algorithms, and types. When the defaults are not suitable for a particular powerful feature, a specification MAY override below flags, algorithms, and types below.
- An allowed in non-secure contexts flag:
- By default, only secure contexts can use powerful features. If this flag is set for a feature, the UA may grant access to it in non-secure contexts too.
- A permission descriptor type:
-
PermissionDescriptoror one of its subtypes. If unspecified, this defaults toPermissionDescriptor.The feature can define a partial order on descriptor instances. If descriptorA is stronger than descriptorB, then if descriptorA's permission state is "
granted", descriptorB's permission state must also be "granted", and if descriptorB's permission state is "denied", descriptorA's permission state must also be "denied".{name: "("midi-with-sysex") is stronger thanmidi", sysex: true}{name: "("midi-without-sysex"), so if the user denies access to midi-without-sysex, the UA must also deny access to midi-with-sysex, and similarly if the user grants access to midi-with-sysex, the UA must also grant access to midi-without-sysex.midi", sysex: false} - Optional permission state constraints:
- Constraints on the values that the UA can return as a descriptor's permission state. Defaults to no constraints beyond the user's intent.
- An optional extra permission data type:
-
Some powerful features have more information associated with them than just a
PermissionState. For example,getUserMedia()needs to determine which cameras the user has granted the current realm permission to access. Each of these features defines an extra permission data type. If aPermissionNamename names one of these features, then name's extra permission data for an optional environment settings object settings is the result of the following algorithm:- If settings wasn't passed, set it to the current settings object.
- If there was a previous invocation of this algorithm with the same name and settings, returning previousResult, and the UA has not received new information about the user's intent since that invocation, return previousResult.
- Return the instance of name's extra permission data type that matches the UA's impression of the user's intent, taking into account any extra permission data constraints for name.
If specified, the extra permission data algorithm is usable for this feature.
- Optional extra permission data constraints:
-
Constraints on the values that the UA can return as a
PermissionName's extra permission data. Defaults to no constraints beyond the user's intent. - A permission result type:
-
PermissionStatusor one of its subtypes. If unspecified, this defaults toPermissionStatus. - A permission query algorithm:
-
Takes an instance of the permission descriptor type and a new or existing instance of the permission result type, and updates the permission result type instance with the query result. Used by
Permissions'query(permissionDesc)method and thePermissionStatusupdate steps. If unspecified, this defaults to the default permission query algorithm.The default permission query algorithm, given a
PermissionDescriptorpermissionDesc and aPermissionStatusstatus, runs the following steps:- Set
status.stateto permissionDesc's permission state.
- Set
- A permission revocation algorithm:
-
Takes no arguments. Updates any other parts of the implementation that need to be kept in sync with changes in the results of permission states or extra permission data, and then react to the user revoking permission.
If unspecified, this defaults to running react to the user revoking permission.
A default powerful feature is a powerful feature with all of the above types and algorithms defaulted.
2.2.2 Aspects
Each powerful feature has one or more aspects that websites can request permission to access. To
describe these aspects, each feature defines a subtype of PermissionDescriptor to
be its permission descriptor type.
2.3 Reading the current permission state
A descriptor's permission state for an
optional environment settings object settings is the result of the following
algorithm, which returns one of "granted",
"prompt", or "denied":
- If settings wasn't passed, set it to the current settings object.
- If settings is a non-secure context and
descriptor.isn't allowed in non-secure contexts, then return "namedenied". - If there exists a policy-controlled feature identified by
descriptor.and settings has an associatednameDocumentnamed document, run the following step:- If document is not allowed to use the feature identified by
descriptor.return "namedenied".
- If document is not allowed to use the feature identified by
- If there was a previous invocation of this algorithm with the same descriptor and settings, returning previousResult, and the UA has not received new information about the user's intent since that invocation, return previousResult.
- Return whichever of the following options most accurately reflects the user's intent
for the calling algorithm, taking into account any permission state constraints for
descriptor.:name
Safari is the only known UA that returns different results from this algorithm for different settings objects with the same origin. We should test which of the several possible settings objects it uses.
As a shorthand, a PermissionName name's permission state is the
permission state of a PermissionDescriptor with its
name member set to name.
2.4 Requesting permission to use a powerful feature
Spec authors, please note that algorithms in this section can wait for user input; so they shouldn't be used from other algorithms running on the main thread.
To request permission to use a descriptor, the UA must perform the
following steps. This algorithm returns either "granted" or
"denied".
- Let current state be the descriptor's permission state.
- If current state is not "
prompt", return current state and abort these steps. - Ask the user's permission for the calling algorithm to use the powerful feature described by descriptor.
- If the user grants permission, return "
granted"; otherwise return "denied". The user's interaction may provide new information about the user's intent for this realm and other realms with the same origin.NoteThis is intentionally vague about the details of the permission UI and how the UA infers user intent. UAs should be able to explore lots of UI within this framework.
As a shorthand, requesting permission to use a PermissionName name, is the
same as requesting permission to use a PermissionDescriptor with its
name member set to name.
2.5 Prompt the user to choose
To prompt the user to choose one of several options associated with a
descriptor, the UA must perform the following steps. This algorithm returns either
"denied" or one of the options.
- If descriptor's permission state is "
denied", return "denied" and abort these steps. - If descriptor's permission state is "
granted", the UA may return one of options and abort these steps. If the UA returns without prompting, then subsequent prompts for the user to choose from the same set of options with the same descriptor must return the same option, unless the UA receives new information about the user's intent. - Ask the user to choose one of the options or deny permission, and wait for them to choose. If the calling algorithm specified extra information to include in the prompt, include it.
- If the user chose an option, return it; otherwise return
"
denied". If the user's interaction indicates they intend this choice to apply to other realms, then treat this this as new information about the user's intent for other realms with the same origin.NoteThis is intentionally vague about the details of the permission UI and how the UA infers user intent. UAs should be able to explore lots of UI within this framework.
As a shorthand, prompting the user to choose from options associated with a
PermissionName name, is the same as prompting the user to choose from those
options associated with a PermissionDescriptor with its name
member set to name.
2.6 Reacting to users revoking permission
When the UA learns that the user no longer intends to grant permission for a realm to use a feature, react to the user revoking permission by:
- Queue a task on the Realm's settings object's responsible event loop to run that feature's permission revocation algorithm.
3.
Extensions to the Navigator and WorkerNavigator interfaces
WebIDL[Exposed=(Window)]
partial interface Navigator {
[SameObject] readonly attribute Permissions permissions;
};
[Exposed=(Worker)]
partial interface WorkerNavigator {
[SameObject] readonly attribute Permissions permissions;
};
4.
Permissions interface
WebIDL[Exposed=(Window,Worker)]
interface Permissions {
Promise<PermissionStatus> query(object permissionDesc);
};
dictionary PermissionDescriptor {
required PermissionName name;
};
4.1
query() method
When the query() method is invoked, the user agent MUST run the
following query a permission algorithm, passing the parameter
permissionDesc:
- Let rootDesc be the object permissionDesc refers to, converted to an IDL
value of type
PermissionDescriptor. If this throws an exception, return a promise rejected with that exception and abort these steps. - Let typedDescriptor be the object permissionDesc refers to, converted to an
IDL value of
rootDesc.'s permission descriptor type. If this throws an exception, return a promise rejected with that exception and abort these steps.name - Let promise be a newly-created
Promise. - Return promise and continue the following steps asynchronously.
- Run the steps to create a
PermissionStatusfor typedDescriptor, and let status be the result. - Run
status.'s permission query algorithm, passing[[query]].namestatus.and status.[[query]] - Resolve promise with status.
5.
PermissionStatus interface
WebIDL[Exposed=(Window,Worker)]
interface PermissionStatus : EventTarget {
readonly attribute PermissionState state;
readonly attribute PermissionName name;
attribute EventHandler onchange;
};
enum PermissionState {
"granted",
"denied",
"prompt",
};
PermissionStatus instances are created with a [[query]] internal slot,
which is an instance of a feature's permission descriptor type.
When using the API, the "granted", "denied", and "prompt"
enum values represent the concepts of granted, denied, and
prompt respectively.
5.1 Creating instances
To create a PermissionStatus for a given PermissionDescriptor
permissionDesc, return a new instance of the permission result type for the feature named by permissionDesc.name, with the
[[query]] internal slot initialized to permissionDesc, and
name initialized to permissionDesc.name.
5.2
name attribute
The name attribute returns the value it was initialized to.
5.3
state attribute
The state attribute returns the latest value that was set on the current
instance.
5.4
onchange attribute
The onchange attribute is an event handler whose corresponding event
handler event type is change.
Whenever the user agent is aware that the state of a PermissionStatus instance
status has changed, it asynchronously runs the PermissionStatus update
steps:
- Run
status.'s permission query algorithm, passing[[query]].namestatus.and status.[[query]] -
Queue a task on the permissions task source to fire
an event named
changeat status.
5.5 Garbage collection
While an PermissionStatus object has one or more event listeners registered for
"change", there must be a strong reference from the Window or WorkerGlobalScope
object that the PermissionStatus object's constructor was invoked from to the
PermissionStatus object itself.
While there is a task queued by an PermissionStatus object on the permissions task source, there must be a strong reference from the Window or WorkerGlobalScope
object that the PermissionStatus object's constructor was invoked from to that
PermissionStatus object.
6. Powerful features registry
WebIDLenum PermissionName {
"accelerometer",
"ambient-light-sensor",
"background-fetch",
"background-sync",
"bluetooth",
"camera",
"display-capture",
"geolocation",
"gyroscope",
"magnetometer",
"microphone",
"midi",
"nfc",
"notifications",
"persistent-storage",
"push",
"screen-wake-lock",
"speaker-selection",
"xr-spatial-tracking",
};
Each enumeration value in the PermissionName enum identifies a powerful feature.
6.1 Geolocation
The geolocation enum value identifies the Geolocation API powerful feature. It is a default powerful feature.
6.2 Notifications
The notifications enum value identifies the Notifications API Standard powerful feature. It is a default powerful feature and is allowed in non-secure contexts.
6.3 Push
The push enum value identifies the Push API powerful feature.
- permission descriptor type
-
WebIDL
dictionaryPushPermissionDescriptor:PermissionDescriptor{ booleanuserVisibleOnly= false; };{name: "push", userVisibleOnly: false}is stronger than{name: "push", userVisibleOnly: true}.
6.4 Midi
The midi enum value identifies the Web MIDI API powerful feature.
This powerful feature only has a single implementation, and therefore, as per the W3C Process, is at risk.
- permission descriptor type
-
WebIDL
dictionaryMidiPermissionDescriptor:PermissionDescriptor{ booleansysex= false; };{name: "midi", sysex: true}is stronger than{name: "midi", sysex: false}.
6.5 Screen wake lock
The screen-wake-lock enum value identifies the Screen Wake Lock API API
powerful feature. It is a default powerful feature.
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
6.6 Media Devices
The camera, microphone , and speaker-selection
permissions are associated with permission to use media devices as specified in
[GETUSERMEDIA] and [audio-output].
These permissions only have a single implementation, and therefore, as per the W3C Process, are at risk.
- permission descriptor type
-
WebIDL
dictionaryDevicePermissionDescriptor:PermissionDescriptor{ DOMStringdeviceId; }; dictionaryCameraDevicePermissionDescriptor:DevicePermissionDescriptor{ booleanpanTiltZoom= false; };A permission covers access to the device given in the associated descriptor.
If the descriptor does not have a
deviceId, its semantic is that it queries for access to all devices of that class. Thus, if a query for the "camera" permission with nodeviceIdreturns "granted", the client knows that there will never be a permission prompt for a camera, and if "denied" is returned, it knows that no getUserMedia request for a camera will succeed.If a permission state is present for access to some, but not all, cameras, a query without the
deviceIdwill return "prompt".{name: "camera", panTiltZoom: true}is stronger than{name: "camera", panTiltZoom: false}.Note that a "granted" permission is no guarantee that getUserMedia will succeed. It only guarantees that the user will not be prompted for permission. There are many other things (such as constraints or the camera being in use) that can cause getUserMedia to fail.
- extra permission data type
-
A list of
deviceIdvalues for the devices the user has made a non-default decision on access to. - permission query algorithm
-
The permission query algorithm runs the following steps:
- If permissionDesc.deviceId exists in the extra permission data, set
status.stateto permissionDesc's permission state and terminate these steps. - Let global be a copy of permissionDesc with the
deviceIdmember removed. - Set
status.stateto global's permission state.
- If permissionDesc.deviceId exists in the extra permission data, set
- permission revocation algorithm
-
This is the result of calling the device permission revocation algorithm passing
nameanddeviceIdas arguments. If the descriptor does not have adeviceId, thenundefinedis passed in place ofdeviceId.
6.7 Background Fetch
The background-fetch enum value identifies the Background Fetch
powerful feature.
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
6.8 Background Sync
The background-sync enum value identifies the Web Background Synchronization
powerful feature.
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
6.9 Bluetooth
The bluetooth enum value identifies the Web Bluetooth powerful feature.
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
6.10 Persistent Storage
The persistent-storage is enum value identifies the Storage Standard powerful feature.
6.11 Ambient Light Sensor
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
The ambient-light-sensor enum value identifies the Ambient Light Sensor API
powerful feature.
Its permission revocation algorithm is the result of calling
generic sensor permission revocation algorithm passing it
"ambient-light-sensor" as argument.
6.12 Accelerometer
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
The accelerometer enum value identifies the Accelerometer API powerful feature.
Its permission revocation algorithm is the result of calling
generic sensor permission revocation algorithm passing it
"accelerometer" as argument.
6.13 Gyroscope
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
The gyroscope enum value identifies the Gyroscope API powerful feature.
Its permission revocation algorithm is the result of calling
generic sensor permission revocation algorithm passing it
"gyroscope" as argument.
6.14 Magnetometer
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
The magnetometer enum value identifies the Magnetometer API powerful feature.
Its permission revocation algorithm is the result of calling
generic sensor permission revocation algorithm passing it
"magnetometer" as argument.
6.15 Display Capture
The display-capture enum value identifies the Screen Capture powerful feature.
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
- permission state constraints
-
Valid values for this descriptor's permission state are
"
prompt" and "denied". The user agent MUST NOT ever set this descriptor's permission state to "granted".
6.16 NFC
This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.
The nfc enum value identifies the Web NFC API powerful feature.
6.17 XR Spatial tracking
The xr-spatial-tracking enum value identifies the WebXR Device API Device API
powerful feature.
7. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, and MUST NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
A. Relationship to the Permissions Policy specification
This section is non-normative.
Although technically this specification and the Permissions Policy specification ([Permissions-Policy]) deal with "permissions", each specification serves a distinct purpose in the platform. Nevertheless, the two specifications do explicitly overlap.
On the one hand, this specification exclusively concerns itself with powerful features
whose access is managed through a user-agent mediated permissions UI (i.e., permissions
where the user gives express consent before that feature can be used, and where the user
retains the ability to deny that permission at any time for any reason). These powerful
features are explicitly identified by this specification's PermissionName enum.
On the other hand, the Permissions Policy specification allows developers to selectively
enable and disable powerful features through a "permissions policy" (be it
a HTTP header or a the allow attribute). The APIs and features in scope for the
Permissions Policy specification go beyond those identified in this specification's
PermissionName enum (e.g., "sync-xhr" and "gamepad"). In that sense, the Permissions
Policy subsumes this specification in that Permissions Policy governs whether a feature is
available at all, independently of this specification.
A powerful feature that has been disabled by the Permissions Policy specification always
has its permission state reflected as "denied" by this specification. This occurs because
reading the current permission state relies on [HTML]'s "allowed to use" check, which
itself calls into the Permissions Policy specification. Important to note here is the
sharing of permission names across both specifications. Where this specification has the
PermissionName enum, the Permissions Policy specification relies on other
specifications defining the names of the permissions (e.g., the permission "gamepad" is
defined in [Gamepad], and so on).
Finally, it's not possible for a powerful feature to ever become "granted" through any means provided by the Permissions Policy specification. The only way that a powerful feature can be "granted" is through a user-agent provided permission UI, or by some other user agent policy.
B. Automated testing
This section is non-normative.
Automated testing of this specification is performed using the API provided by the Permissions Automation document.
C. Security and privacy considerations
This section is non-normative.
An adversary could use a permission state as an element in creating a "fingerprint"
corresponding to an end-user. Although an adversary can already determine the state of a
permission by actually using the API, that often leads to a permission request UI being
presented to the end-user (if the permission was not already
"granted"). Thus, even though this API doesn't expose new
fingerprinting information to websites, it makes it easier for an adversary to have
discreet access to this information. Thus, implementations are encouraged to have an option
for users to block (globally or selectively) the querying of permission states.
D. IDL Index
WebIDL[Exposed=(Window)]
partial interface Navigator {
[SameObject] readonly attribute Permissions permissions;
};
[Exposed=(Worker)]
partial interface WorkerNavigator {
[SameObject] readonly attribute Permissions permissions;
};
[Exposed=(Window,Worker)]
interface Permissions {
Promise<PermissionStatus> query(object permissionDesc);
};
dictionary PermissionDescriptor {
required PermissionName name;
};
[Exposed=(Window,Worker)]
interface PermissionStatus : EventTarget {
readonly attribute PermissionState state;
readonly attribute PermissionName name;
attribute EventHandler onchange;
};
enum PermissionState {
"granted",
"denied",
"prompt",
};
enum PermissionName {
"accelerometer",
"ambient-light-sensor",
"background-fetch",
"background-sync",
"bluetooth",
"camera",
"display-capture",
"geolocation",
"gyroscope",
"magnetometer",
"microphone",
"midi",
"nfc",
"notifications",
"persistent-storage",
"push",
"screen-wake-lock",
"speaker-selection",
"xr-spatial-tracking",
};
dictionary PushPermissionDescriptor : PermissionDescriptor {
boolean userVisibleOnly = false;
};
dictionary MidiPermissionDescriptor : PermissionDescriptor {
boolean sysex = false;
};
dictionary DevicePermissionDescriptor : PermissionDescriptor {
DOMString deviceId;
};
dictionary CameraDevicePermissionDescriptor : DevicePermissionDescriptor {
boolean panTiltZoom = false;
};E. Acknowledgments
This section is non-normative.
The editors would like to thank Adrienne Porter Felt, Anne van Kesteren, Domenic Denicola, Jake Archibald and Wendy Seltzer for their help with the API design and editorial work.
F. References
F.1 Normative references
- [accelerometer]
- Accelerometer. Anssi Kostiainen; Alexander Shalamov. W3C. 24 July 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/accelerometer/
- [ambient-light]
- Ambient Light Sensor. Anssi Kostiainen; Rijubrata Bhaumik; Tobie Langel. W3C. 16 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/ambient-light/
- [audio-output]
- Audio Output Devices API. Justin Uberti; Guido Urdaneta; youenn fablet. W3C. 6 July 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/audio-output/
- [background-fetch]
- Background Fetch. WICG. cg-draft. URL: https://wicg.github.io/background-fetch/
- [dom]
- DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
- [ECMASCRIPT]
- ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/multipage/
- [generic-sensor]
- Generic Sensor API. Rick Waldron; Mikhail Pozdnyakov; Alexander Shalamov; Tobie Langel. W3C. 29 July 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/generic-sensor/
- [Geolocation]
- Geolocation API. Marcos Caceres. W3C. 12 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/geolocation/
- [GETUSERMEDIA]
- Media Capture and Streams. Cullen Jennings; Bernard Aboba; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet; Daniel Burnett; Adam Bergkvist; Anant Narayanan. W3C. 19 August 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/
- [gyroscope]
- Gyroscope. Anssi Kostiainen; Mikhail Pozdnyakov. W3C. 24 July 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/gyroscope/
- [HTML]
- HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
- [infra]
- Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
- [magnetometer]
- Magnetometer. Anssi Kostiainen; Rijubrata Bhaumik. W3C. 24 July 2021. W3C Working Draft. URL: https://www.w3.org/TR/magnetometer/
- [notifications]
- Notifications API Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://notifications.spec.whatwg.org/
- [Permissions-Policy]
- Permissions Policy. Ian Clelland. W3C. 16 July 2020. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
- [push-api]
- Push API. Peter Beverloo; Martin Thomson. W3C. 16 June 2021. W3C Working Draft. URL: https://www.w3.org/TR/push-api/
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
- [RFC8174]
- Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
- [screen-capture]
- Screen Capture. Martin Thomson; Keith Griffin; Suhas Nandakumar; Henrik Boström; Jan-Ivar Bruaroey; Elad Alon. W3C. 10 June 2021. W3C Working Draft. URL: https://www.w3.org/TR/screen-capture/
- [screen-wake-lock]
- Screen Wake Lock API. Kenneth Christiansen; Marcos Caceres; Raphael Kubo da Costa; Ilya Bogdanovich; Andrey Logvinov. W3C. 26 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/screen-wake-lock/
- [storage]
- Storage Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://storage.spec.whatwg.org/
- [web-background-sync]
- Web Background Synchronization. WICG. cg-draft. URL: https://wicg.github.io/background-sync/spec/
- [web-bluetooth]
- Web Bluetooth. Jeffrey Yasskin. W3C Web Bluetooth Community Group. Draft Community Group Report. URL: https://webbluetoothcg.github.io/web-bluetooth/
- [web-nfc]
- Web NFC API. W3C. W3C Editor's Draft. URL: https://w3c.github.io/web-nfc/
- [WebIDL]
- Web IDL. Boris Zbarsky. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/
- [webmidi]
- Web MIDI API. Chris Wilson; Jussi Kalliokoski. W3C. 17 March 2015. W3C Working Draft. URL: https://www.w3.org/TR/webmidi/
- [webxr]
- WebXR Device API. Brandon Jones; Manish Goregaokar; Rik Cabanier; Nell Waliczek. W3C. 24 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/webxr/
F.2 Informative references
- [appmanifest]
- Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Anssi Kostiainen; Matt Giuca; Aaron Gustafson. W3C. 25 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
- [Gamepad]
- Gamepad. Steve Agoston; James Hollyer; Matthew Reynolds; Brandon Jones; Scott Graham; Theodore Mielczarek. W3C. 5 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/gamepad/
Referenced in:
Referenced in:
Referenced in:
Referenced in:
- § 2. Model
- § 2.1 Permissions
- § 2.2 Powerful features (2)
- § 2.2.1 Specifying a powerful feature (2) (3) (4) (5) (6)
- § 2.2.2 Aspects (2)
- § 2.4 Requesting permission to use a powerful feature
- § 2.6 Reacting to users revoking permission
- § 6. Powerful features registry
- § 6.1 Geolocation
- § 6.2 Notifications
- § 6.3 Push
- § 6.4 Midi (2)
- § 6.5 Screen wake lock (2)
- § 6.7 Background Fetch (2)
- § 6.8 Background Sync (2)
- § 6.9 Bluetooth (2)
- § 6.10 Persistent Storage
- § 6.11 Ambient Light Sensor (2)
- § 6.12 Accelerometer (2)
- § 6.13 Gyroscope (2)
- § 6.14 Magnetometer (2)
- § 6.15 Display Capture (2)
- § 6.16 NFC (2)
- § 6.17 XR Spatial tracking
- § A. Relationship to the Permissions Policy specification (2)
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
- § 2.1 Permissions (2) (3)
- § 2.2.1 Specifying a powerful feature (2) (3) (4) (5) (6) (7)
- § 2.3 Reading the current permission state (2)
- § 2.4 Requesting permission to use a powerful feature
- § 2.5 Prompt the user to choose (2)
- § 6.6 Media Devices (2)
- § 6.15 Display Capture (2)
- § C. Security and privacy considerations (2)
Referenced in:
- § 2.2.1 Specifying a powerful feature (2) (3)
- § 2.2.2 Aspects
- § 2.3 Reading the current permission state
- § 2.4 Requesting permission to use a powerful feature
- § 2.5 Prompt the user to choose
- § 4.1 query() method
- § 5.1 Creating instances
- § 6.3 Push
- § 6.4 Midi
- § 6.6 Media Devices
- § D. IDL Index (2) (3)
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
- § 2.2.1 Specifying a powerful feature (2)
- § 2.3 Reading the current permission state (2)
- § 2.4 Requesting permission to use a powerful feature (2)
- § 2.5 Prompt the user to choose
- § 5. PermissionStatus interface
- § 6.6 Media Devices
- § 6.15 Display Capture
- § C. Security and privacy considerations
- § D. IDL Index
Referenced in:
Referenced in:
Referenced in:
Referenced in:
- § 2.2.1 Specifying a powerful feature (2)
- § 2.3 Reading the current permission state
- § 2.4 Requesting permission to use a powerful feature
- § 2.5 Prompt the user to choose
- § 4. Permissions interface
- § 5. PermissionStatus interface
- § 6. Powerful features registry
- § A. Relationship to the Permissions Policy specification (2) (3)
- § D. IDL Index (2)
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: