Permissions

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.

Note: Limitations

Current Web APIs have different ways to deal with permissions. For example, the [notifications] API allows developers to request a permission and check the permission status explicitly. Others expose the status to web pages when they try to use the API, like the [Geolocation] which fails if the permission was not granted without allowing the developer to check beforehand.

The solution described in this document is meant to be extensible, but isn't expected to be applicable to all the current and future permissions available in the web platform. Working Groups that are creating specifications whose permission model doesn't fit in the model described in this document should contact the editors by filing an issue.

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.

A user agent SHOULD provide a means for the user to review, update, and reset the permission state of powerful features associated with a realm or origin.

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.

Note: Implicit signals

2.2 Powerful features

A powerful feature is a web platform feature (usually an API) for which a user gives express 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.

Express permission refers to an act by the user, e.g. via user interface or host device platform features, through which the user grants permission the use of the feature by the web application.

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

Note

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 algorithms and types. When the defaults are not suitable for a particular powerful feature, a specification MAY override below algorithms and types below.

A permission descriptor type:

PermissionDescriptor or one of its subtypes. If unspecified, this defaults to PermissionDescriptor.

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", sysex: true} ("midi-with-sysex") is stronger than {name: "midi", sysex: false} ("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.

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 a PermissionName name 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:

PermissionStatus or one of its subtypes. If unspecified, this defaults to PermissionStatus.

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 the PermissionStatus update steps. If unspecified, this defaults to the default permission query algorithm.

The default permission query algorithm, given a PermissionDescriptor permissionDesc and a PermissionStatus status, runs the following steps:

Set status.state to permissionDesc's permission state.

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 permission lifetime:

Every permission has a lifetime, which is the duration for which a particular permission remains granted before it reverts back to its default permission state. A lifetime could be until a particular Realm is destroyed, until a particular top-level browsing context is destroyed, an amount of time, or infinite. The lifetime is negotiated between the end-user and the user agent when the user gives express permission to use a feature - usually via some permission UI or policy.

Specifications that define one or more powerful features SHOULD suggest a permission lifetime that is best suited for the particular feature. Some guidance on determining the lifetime of a permission is noted below, with a strong emphasis on user privacy. If no lifetime is specified, the user agent provides one.

When the permission lifetime expires for an origin:

Set the permission back to its default permission state (e.g. setting it back to "prompt").
For each browsing context associated with the origin (if any), queue a global task on the permissions task source with the browsing context's global object to run the permission revocation algorithm.

Note: Determining the lifetime of a permission

For particularly privacy-sensitive features, such as Media Capture and Streams, which can provide a web application access to a user's camera and microphone, some user agents expire a permission grant as soon as a browser tab is closed or navigated. For other features, like the Geolocation API, user agents are known to offer a choice of only granting the permission for the session, or for one day. Others, like the Notifications API Standard and Push API APIs, remember a user's decision indefinitely or until the user manually revokes the permission. Note that permission lifetimes can vary significantly between user agents.

Finding the right balance for the lifetime of a permission requires a lot of thought and experimentation, and often evolves over a period of years. Implementers are encouraged to work with their UX security teams to find the right balance between ease of access to a powerful feature (i.e., reducing the number of permission prompts), respecting a user's privacy, and making users aware when a web application is making use of a particular powerful feature (e.g., via some visual or auditory UI indicator).

If you are unsure about what lifetime to suggest for a powerful feature, please contact the Privacy Interest Group for guidance.

A default powerful feature is a powerful feature with all of the above types and algorithms defaulted.

2.2.2 Aspects

Each powerful feature can define zero or more additional aspects that websites can request permission to access.

To describe an aspect, a specification MUST define a WebIDL dictionary that inherits from PermissionDescriptor, and have that interface be its permission descriptor type.

Example 4: Defining your own permission descriptor type

A hypothetical powerful feature "food detector API" has two aspects that allow sensing taste and smell. So, a specification would define a new WebIDL interface that inherits PermissionDescriptor:

dictionary SensesPermissionDescriptor : PermissionDescriptor {
  boolean canSmell = false;
  boolean canTaste = false;
}

Which would then be queried via the API in the following way:

// Check if the "sense" powerful feature is allowed to smell things
const status = await navigator.permissions.query({
  name: "senses",
  canSmell: true,
});
// Do something interesting with the status.

A user can restrict the "sense" powerful feature to only "taste", in which case the PermissionStatus's state above would be "denied" .

2.3 Reading the current permission state

To get the current permission state, given a name name and an optional environment settings object settings:

Let descriptor be a newly-created PermissionDescriptor whose name is initialized with name.
Return the permission state of descriptor and settings.

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, return "denied".
If there exists a policy-controlled feature identified by descriptor's name and settings has an associated Document named document, run the following step:
1. If document is not allowed to use the feature identified by descriptor's name return "denied".
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's name:

succeed without prompting the user

"granted"

show the user a prompt to decide whether to succeed

"prompt"

fail without prompting the user

"denied"

Issue 278: Safari returns different results for current permission state

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

Note

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 for express 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.
Note
This 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.
Note
This 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 name's permission descriptor type. If this throws an exception, return a promise rejected with that exception and abort these steps.
Let promise be a newly-created Promise.
Return promise and continue the following steps asynchronously.
Run the steps to create a PermissionStatus for typedDescriptor, and let status be the result.
Let query be status's [[query]] internal slot.
Run query's name's permission query algorithm, passing query and status.
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's name, with the [[query]] internal slot initialized to permissionDesc, and name initialized to permissionDesc's 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:

Let query be status's [[query]] internal slot.
Run query's name's permission query algorithm, passing query and status.
Queue a task on the permissions task source to fire an event named change at 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.

The accelerometer enum value identifies the Accelerometer API powerful feature.

The ambient-light-sensor enum value identifies the Ambient Light Sensor powerful feature.

The background-fetch enum value identifies the Background Fetch powerful feature.

The background-sync enum value identifies the Web Background Synchronization powerful feature.

The bluetooth enum value identifies the Web Bluetooth powerful feature.

The camera and microphone enum values identify the Media Capture and Streams powerful features.

The display-capture enum value identifies the Screen Capture powerful feature.

The geolocation enum value identifies the Geolocation API powerful feature.

The gyroscope enum value identifies the Gyroscope API powerful feature.

The magnetometer enum value identifies the Magnetometer API powerful feature.

The midi enum value identifies the Web MIDI API powerful feature.

The notifications enum value identifies the Notifications API Standard powerful feature.

The persistent-storage enum value identifies the Storage Standard powerful feature.

The push enum value identifies the Push API powerful feature.

The speaker-selection enum value identifies the Audio Output Devices API powerful feature.

The xr-spatial-tracking enum value identifies the WebXR Device API Device API powerful feature.

6.1 Screen wake lock

The screen-wake-lock enum value identifies the Screen Wake Lock API powerful feature. It is a default powerful feature.

Issue

This powerful feature only has a single implementation, and therefore, as per the W3C Process, it is at risk.

6.2 NFC

Issue

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.

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 SHOULD 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.

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",
};

F.1 Normative references

[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/
[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/
[mediacapture-streams]: Media Capture and Streams. Cullen Jennings; Bernard Aboba; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet. W3C. 3 December 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/
[Permissions-Policy]: Permissions Policy. Ian Clelland. W3C. 16 July 2020. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
[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-wake-lock]: Screen Wake Lock API. Kenneth Christiansen; Marcos Caceres; Raphael Kubo da Costa. W3C. 7 December 2021. W3C Working Draft. URL: https://www.w3.org/TR/screen-wake-lock/
[web-nfc]: Web NFC API. W3C. W3C Editor's Draft. URL: https://w3c.github.io/web-nfc/
[WEBIDL]: Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

F.2 Informative references

[accelerometer]: Accelerometer. Anssi Kostiainen. W3C. 4 December 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/accelerometer/
[ambient-light]: Ambient Light Sensor. Anssi Kostiainen; Rijubrata Bhaumik. W3C. 3 December 2021. W3C Working Draft. URL: https://www.w3.org/TR/ambient-light/
[appmanifest]: Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Matt Giuca; Aaron Gustafson; Daniel Murphy; Anssi Kostiainen. W3C. 10 November 2021. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
[audio-output]: Audio Output Devices API. Justin Uberti; Guido Urdaneta; youenn fablet. W3C. 15 November 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/
[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/
[Geolocation]: Geolocation API. Marcos Caceres. W3C. 24 November 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. W3C. 3 December 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/
[gyroscope]: Gyroscope. Anssi Kostiainen. W3C. 4 December 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/gyroscope/
[magnetometer]: Magnetometer. Anssi Kostiainen; Rijubrata Bhaumik. W3C. 4 December 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/
[push-api]: Push API. Peter Beverloo; Martin Thomson. W3C. 3 November 2021. W3C Working Draft. URL: https://www.w3.org/TR/push-api/
[screen-capture]: Screen Capture. Martin Thomson; Keith Griffin; Suhas Nandakumar; Henrik Boström; Jan-Ivar Bruaroey; Elad Alon. W3C. 2 December 2021. W3C Working Draft. URL: https://www.w3.org/TR/screen-capture/
[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/
[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. 26 October 2021. W3C Working Draft. URL: https://www.w3.org/TR/webxr/

Chrome	43+
Chrome Android	43+
Edge	No
Edge Mobile	?
Firefox	46+
Firefox Android	46+
Internet Explorer	No
Opera	Yes
Opera Android	Yes
Safari	No
Safari iOS	No
Samsung Internet	4.0+
WebView Android	No

Chrome	43+
Chrome Android	43+
Edge	No
Edge Mobile	?
Firefox	No
Firefox Android	No
Internet Explorer	No
Opera	30+
Opera Android	30+
Safari	No
Safari iOS	No
Samsung Internet	4.0+
WebView Android	No

Chrome	43+
Chrome Android	43+
Edge	No
Edge Mobile	?
Firefox	46+
Firefox Android	46+
Internet Explorer	No
Opera	Yes
Opera Android	Yes
Safari	No
Safari iOS	No
Samsung Internet	4.0+
WebView Android	No

Chrome	43+
Chrome Android	43+
Edge	No
Edge Mobile	?
Firefox	46+
Firefox Android	46+
Internet Explorer	No
Opera	Yes
Opera Android	Yes
Safari	No
Safari iOS	No
Samsung Internet	4.0+
WebView Android	No

Chrome	43+
Chrome Android	43+
Edge	No
Edge Mobile	?
Firefox	46+
Firefox Android	46+
Internet Explorer	No
Opera	Yes
Opera Android	Yes
Safari	No
Safari iOS	No
Samsung Internet	4.0+
WebView Android	No

Permissions

Interacting with Permissions for Powerful Features

Abstract

Status of This Document

1. Examples of usage

2. Model

2.1 Permissions

2.2 Powerful features

2.2.1 Specifying a powerful feature

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

2.6 Reacting to users revoking permission

3. Extensions to the `Navigator` and `WorkerNavigator` interfaces

4. `Permissions` interface

4.1 `query()` method

5. `PermissionStatus` interface

5.1 Creating instances

5.2 `name` attribute

5.3 `state` attribute

5.4 `onchange` attribute

5.5 Garbage collection

6. Powerful features registry

6.1 Screen wake lock

6.2 NFC

7. Conformance

A. Relationship to the Permissions Policy specification

B. Automated testing

C. Security and privacy considerations

D. IDL Index

E. Acknowledgments

F. References

F.1 Normative references

F.2 Informative references

Permissions

Interacting with Permissions for Powerful Features

Abstract

Status of This Document

1. Examples of usage

2. Model

2.1 Permissions

2.2 Powerful features

2.2.1 Specifying a powerful feature

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

2.6 Reacting to users revoking permission

3. Extensions to the Navigator and WorkerNavigator interfaces

4. Permissions interface

4.1 query() method

5. PermissionStatus interface

5.1 Creating instances

5.2 name attribute

5.3 state attribute

5.4 onchange attribute

5.5 Garbage collection

6. Powerful features registry

6.1 Screen wake lock

6.2 NFC

7. Conformance

A. Relationship to the Permissions Policy specification

B. Automated testing

C. Security and privacy considerations

D. IDL Index

E. Acknowledgments

F. References

F.1 Normative references

F.2 Informative references

3. Extensions to the `Navigator` and `WorkerNavigator` interfaces

4. `Permissions` interface

4.1 `query()` method

5. `PermissionStatus` interface

5.2 `name` attribute

5.3 `state` attribute

5.4 `onchange` attribute