diff --git a/index.bs b/index.bs index a99c2ce5..630d698b 100644 --- a/index.bs +++ b/index.bs @@ -1,6 +1,6 @@ 
-Title: Feature Policy
-Shortname: feature-policy
+Title: Permissions Policy
+Shortname: permissions-policy
 Level: 1
 Indent: 2
 Status: ED
@@ -70,17 +70,17 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
     requirements set by other embedders - e.g. various social networks, search
     engines, and so on.
   
-  
This specification defines a feature policy mechanism that addresses the
-  above use cases.

+  
This specification defines a policy mechanism that addresses the above use
+  cases.

 
 

   
Examples

   

     
SecureCorp Inc. wants to disable use of Fullscreen and Geolocation APIs
     within their application. It can do so by delivering the following HTTP
-    response header to define a feature policy:

+    response header to define a permissions policy:

     
-      Feature-Policy: fullscreen 'none'; geolocation 'none'

+      Permissions-Policy: fullscreen 'none'; geolocation 'none'

By specifying the "'none'"keyword for the origin list, the specified features will be disabled for all browsing contexts, regardless of their origin.

@@ -100,9 +100,9 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/ origin is "https://example.com", even in the presence of an attacker who can embed their own iframes on SecureCorp's pages. It can do this by delivering the following HTTP response header to define a restricted - feature policy for Geolocation:

+ permissions policy for Geolocation:

-      Feature-Policy: geolocation 'self' https://example.com
+ Permissions-Policy: geolocation 'self' https://example.com

The allowlist is a list of one or more origins, which can include the application's origin, optionally with the keyword "'self'", and any third-party origin.

@@ -136,7 +136,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/ features, and requires the developer to opt back in to each of them, so it is impossible to extend the set of sandbox features without significant compatibility risk.

-

Feature Policy is intended to be used in combination with the sandbox +

Permissions Policy is intended to be used in combination with the sandbox mechanism (i.e. it does not duplicate feature controls already covered by sandbox), and provides an extensible mechanism that addresses the above limitations.

@@ -148,7 +148,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/

A policy-controlled feature is an API or behaviour which can be enabled or disabled in a document by referring - to it in a feature policy. + to it in a permissions policy.

For brevity, policy-controlled features will often be referred to in this document simply as "Features". Unless otherwise indicated, the term "feature" refers to policy-controlled features. @@ -156,7 +156,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/ avoid any ambiguity.
This spec currently only deals with features defined in Documents. We should figure out how to word this to include the possibility - of features and feature policies in Workers and Worklets as well.
+ of features and permissions policies in Workers and Worklets as well.

Policy-controlled features are identified by tokens, which are character strings used in policy directives.

Each policy-controlled feature has a default allowlist, @@ -177,17 +177,17 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/

Policies

-

A feature policy is a struct with the following items:

+

A permissions policy is a struct with the following items:

-

An empty feature policy is a feature policy that - has an inherited policy which contains "Enabled" for - every supported feature, and a declared policy which is an - empty map.

+

An empty permissions policy is a permissions + policy that has an inherited policy which contains + "Enabled" for every supported feature, and a declared + policy which is an empty map.

Inherited policies

@@ -197,7 +197,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/ "Enabled" or "Disabled".

The inherited policy for a feature feature is the value in the inherited policy whose key is feature. - After a feature policy has been initialized, its inherited + After a permissions policy has been initialized, its inherited policy will contain a value for each supported feature.

Each document in a frame tree inherits a set of policies from its parent @@ -210,13 +210,13 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/

In a {{Document}} in a [=top-level browsing context=], the inherited policy is based on defined defaults for each feature.

In a {{Document}} in a [=child browsing context=], the inherited policy - is based on the parent document's feature policy, as well as the [=child + is based on the parent document's permissions policy, as well as the [=child browsing context=]'s container policy.

Declared policies

-

A declared +

A declared policy is an ordered map from features to allowlists.

@@ -225,7 +225,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/

Header policies

A header policy is a list of policy directives delivered via an HTTP header with a document. This forms the document's - feature policy's declared policy.

+ permissions policy's declared policy.

Container policies

@@ -257,8 +257,9 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/

Allowlists

-

A feature policy allowlist - is conceptually a set of [=origins=]. An allowlist may be either: +

A permissions policy allowlist is conceptually a set of + [=origins=]. An allowlist may be either:

-

Feature Policy Serialization

+

Permissions Policy Serialization

ASCII serialization

Policy Directives are represented in HTTP headers and in HTML attributes as ASCII text.

-      serialized-feature-policy = serialized-policy-directive *(";" serialized-policy-directive)
+      serialized-permissions-policy = serialized-policy-directive *(";" serialized-policy-directive)
       serialized-policy-directive = feature-identifier RWS allow-list
       feature-identifier = 1*( ALPHA / DIGIT / "-")
       allow-list = allow-list-value *(RWS allow-list-value)
@@ -330,24 +331,24 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
     

       The string "'self'" may be used as an origin in an allowlist.
       When it is used in this way, it will refer to the origin of the document
-      which contains the feature policy.
+      which contains the permissions policy.

Delivery

-

Feature-Policy HTTP Header +

Permissions-Policy HTTP Header Field

The `Feature-Policy` HTTP - header field can be used in the [=response=] (server to client) to - communicate the feature policy that should be enforced by the + id="permissions-policy-header">Permissions-Policy` + HTTP header field can be used in the [=response=] (server to client) to + communicate the permissions policy that should be enforced by the client.

The header's value is the of one or more policy directives:.

-      FeaturePolicy = serialized-feature-policy *("," serialized-feature-policy)
+      PermissionsPolicy = serialized-permissions-policy *("," serialized-permissions-policy)
@@ -370,9 +371,9 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/

Additional attributes to support legacy features

Some features controlled by - Feature Policy have existing iframe attributes defined. This specification - redefines these attributes to act as declared policies for the iframe - element.

+ Permissions Policy have existing iframe attributes defined. This + specification redefines these attributes to act as declared policies for the + iframe element.

allowfullscreen

The "allowfullscreen" iframe attribute controls access to @@ -427,11 +428,11 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/ whether a feature is enabled or not. (Some features may not have any observable failure mode, or may have unwanted side effects to feature detection.)

-

Documents and iframes both provide a {{FeaturePolicy}} object which can be - used to inspect the feature policies which apply to them.

+

Documents and iframes both provide a {{PermissionsPolicy}} object which can + be used to inspect the permissions policies which apply to them.

Document policies

To retreive the currently effective policy, use - document.featurePolicy. This returns a {{FeaturePolicy}} + document.permissionsPolicy. This returns a {{PermissionsPolicy}} object, which can be used to: * query the state (allowed or denied) in the current document for a given feature, @@ -445,7 +446,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/ 

   <!doctype html>
   <script>
-   const policy = document.featurePolicy;
+   const policy = document.permissionsPolicy;
 
    // This will be true if this document can use WebUSB.
    const can_use_usb = policy.allowsFeature('usb');
@@ -489,7 +490,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
   <iframe id="frame" allow="fullscreen; xr-spatial-tracking"></iframe>
   <script>
    const iframe_element = document.getElementById("frame");
-   const iframe_policy = iframe_element.featurePolicy;
+   const iframe_policy = iframe_element.permissionsPolicy;
 
    // True if the framed document will be allowed to use WebXR
    if (iframe_policy.allowsFeature('xr-spatial-tracking')) {
@@ -511,7 +512,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
   <iframe id="frame" allow="fullscreen https://example.com" src="https://example.net/" ></iframe>
   <script>
    const iframe_element = document.getElementById("frame");
-   const iframe_policy = iframe_element.featurePolicy;
+   const iframe_policy = iframe_element.permissionsPolicy;
    // This will be false, as the URL listed in the src attribute is not allowed
    // by policy to use fullscreen.
    const is_fullscreen_allowed_in_frame = iframe_policy.allowsFeature('fullscreen');
@@ -520,17 +521,17 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
    new_frame.allow = 'sync-xhr';
    // This will be true, as the iframe is allowed to use sync-xhr at whatever URL is
    // mentioned in its src attribute, even though that attribute is not yet set.
-   const is_sync_xhr_allowed = new_frame.featurePolicy.allowsFeature('sync-xhr');
+   const is_sync_xhr_allowed = new_frame.permissionsPolicy.allowsFeature('sync-xhr');
   </script>
-

The featurePolicy object

+

The permissionsPolicy object

 [Exposed=Window]
-interface FeaturePolicy {
+interface PermissionsPolicy {
   boolean allowsFeature(DOMString feature, optional DOMString origin);
   sequence<DOMString> features();
   sequence<DOMString> allowedFeatures();
@@ -538,44 +539,44 @@ interface FeaturePolicy {
 };
 
 partial interface Document {
-    [SameObject] readonly attribute FeaturePolicy featurePolicy;
+    [SameObject] readonly attribute PermissionsPolicy permissionsPolicy;
 };
 
 partial interface HTMLIFrameElement {
-    [SameObject] readonly attribute FeaturePolicy featurePolicy;
+    [SameObject] readonly attribute PermissionsPolicy permissionsPolicy;
 };
-

A {{FeaturePolicy}} object has an associated node, which is a - {{Node}}. The associated node is set when the {{FeaturePolicy}} - object is created.

-

A {{FeaturePolicy}} object has a default origin, which is an - origin, whose value depends on the state of the {{FeaturePolicy}} - object's associated node: - * If the {{FeaturePolicy}} object's associated node is a +

A {{PermissionsPolicy}} object has an associated node, which + is a {{Node}}. The associated node is set when the + {{PermissionsPolicy}} object is created.

+

A {{PermissionsPolicy}} object has a default origin, which is + an origin, whose value depends on the state of the + {{PermissionsPolicy}} object's associated node: + * If the {{PermissionsPolicy}} object's associated node is a {{Document}}, then its default origin is the {{Document}}'s origin. - * If the {{FeaturePolicy}} object's associated node is an + * If the {{PermissionsPolicy}} object's associated node is an {{Element}}, then its default origin is the {{Element}}'s declared origin.

Each {{Document}} has a policy object, which is - a {{FeaturePolicy}} instance whose associated node is that + a {{PermissionsPolicy}} instance whose associated node is that {{Document}}.

-

A {{Document}}'s {{Document/featurePolicy}} IDL attribute, on getting, - must return the {{Document}}'s [=Document/policy object=].

+

A {{Document}}'s {{Document/permissionsPolicy}} IDL attribute, on + getting, must return the {{Document}}'s [=Document/policy object=].

Each <{iframe}> element has a policy object, - which is a {{FeaturePolicy}} instance whose associated node is that - element.

-

An <{iframe}>'s {{HTMLIFrameElement/featurePolicy}} IDL attribute, on + which is a {{PermissionsPolicy}} instance whose associated node is + that element.

+

An <{iframe}>'s {{HTMLIFrameElement/permissionsPolicy}} IDL attribute, on getting, must return the <{iframe}>'s [=iframe/policy object=].

The {{allowsFeature(feature, origin)}} method must run the following steps: - 1. If |origin| is omitted, set |origin| to this {{FeaturePolicy}} object's - default origin. - 2. Let |policy| be the observable policy for this {{FeaturePolicy}} - object's associated node. + 1. If |origin| is omitted, set |origin| to this {{PermissionsPolicy}} + object's default origin. + 2. Let |policy| be the observable policy for this + {{PermissionsPolicy}} object's associated node. 3. If |feature| is allowed by |policy| for |origin|, return true. 4. Otherwise, return false. @@ -587,9 +588,10 @@ partial interface HTMLIFrameElement {

The {{allowedFeatures()}} method must run the following steps: 1. Set |result| to an empty ordered set. - 2. Let |origin| be this {{FeaturePolicy}} object's default origin. - 3. Let |policy| be the observable policy for this {{FeaturePolicy}} - object's associated node. + 2. Let |origin| be this {{PermissionsPolicy}} object's default + origin. + 3. Let |policy| be the observable policy for this + {{PermissionsPolicy}} object's associated node. 4. For each supported feature |feature|: 1. If |feature| is allowed by |policy| for |origin|, append |feature| to |result|. @@ -598,9 +600,10 @@ partial interface HTMLIFrameElement {

The {{getAllowlistForFeature(feature)}} method must run the following steps: 1. Set |result| to an empty list - 2. Let |origin| be this {{FeaturePolicy}} object's default origin. - 3. Let |policy| be the observable policy for this {{FeaturePolicy}} - object's associated node. + 2. Let |origin| be this {{PermissionsPolicy}} object's default + origin. + 3. Let |policy| be the observable policy for this + {{PermissionsPolicy}} object's associated node. 4. If |feature| is not allowed in |policy| for |origin|, return |result| 5. Let |allowlist| be |policy|'s declared policy[|feature|] 6. If |allowlist| is the special value `*`, append "`*`" to |result| @@ -609,13 +612,13 @@ partial interface HTMLIFrameElement { |origin| to |result| 8. Return |result|. -

The observable policy for any Node is a feature policy, - which contains the information about the policy in the browsing context - represented by that Node which is visible from the current browsing context. -

+

The observable policy for any Node is a permissions + policy, which contains the information about the policy in the browsing + context represented by that Node which is visible from the current browsing + context.

To get the observable policy for a Document |document|, return - |document|'s feature policy.

+ |document|'s permissions policy.

To get the observable policy for an Element |node|, run the following steps:

1. Let |inherited policy| be a new ordered map. @@ -625,7 +628,7 @@ partial interface HTMLIFrameElement { policy for feature in container at origin on |feature|, |node| and |node|'s declared origin. 2. Set |inherited policy|[|feature|] to |isInherited|. - 4. Return a new feature policy with inherited policy + 4. Return a new permissions policy with inherited policy |inherited policy| and declared policy |declared policy|.

To get the declared origin for an Element |node|, run the @@ -654,21 +657,21 @@ partial interface HTMLIFrameElement {

Reporting

-

Feature policy violation reports indicate that some behavior of - the Document has violated a feature policy. It is up to each - individual feature policy to define/determine when a - violation of that policy has - occurred.

+

Permissions policy violation reports indicate that some behavior + of the Document has violated a permissions policy. It is up to + the specification of each individual policy-controlled feature to define what + it means to violate that + policy, and how to determine when such a violation has occurred.

-

Feature policy violation reports have the report type - "feature-policy-violation".

+

Permissions policy violation reports have the report type + "permissions-policy-violation".

-

Feature policy violation reports are visible to +

Permissions policy violation reports are visible to ReportingObservers. 

     [Exposed=Window]
-    interface FeaturePolicyViolationReportBody : ReportBody {
+    interface PermissionsPolicyViolationReportBody : ReportBody {
       readonly attribute DOMString featureId;
       readonly attribute DOMString? sourceFile;
       readonly attribute long? lineNumber;
@@ -677,36 +680,39 @@ partial interface HTMLIFrameElement {
     };
- A feature policy violation report's [=report/body=], represented in - JavaScript by {{FeaturePolicyViolationReportBody}}, contains the following + A permissions policy violation report's [=report/body=], represented in + JavaScript by {{PermissionsPolicyViolationReportBody}}, contains the following fields: - - featureId: The string - identifying the policy-controlled feature whose policy has been - violated. This string can be used for grouping and counting related - reports. + - featureId: The + string identifying the policy-controlled feature whose policy has + been violated. This string can be used for grouping and counting + related reports. - - sourceFile: If known, - the file where the violation occured, or null otherwise. + - sourceFile: If + known, the file where the violation occured, or null otherwise. - - lineNumber: If known, - the line number in [=FeaturePolicyViolationReportBody/sourceFile=] where - the violation occured, or null otherwise. + - lineNumber: If + known, the line number in + [=PermissionsPolicyViolationReportBody/sourceFile=] where the + violation occured, or null otherwise. - - columnNumber: If known, - the column number in [=FeaturePolicyViolationReportBody/sourceFile=] where - the violation occured, or null otherwise. + - columnNumber: If + known, the column number in + [=PermissionsPolicyViolationReportBody/sourceFile=] where the + violation occured, or null otherwise. - - disposition: A string - indicating whether the violated feature policy was enforced in this - case. [=FeaturePolicyViolationReportBody/disposition=] will be set to + - disposition: A + string indicating whether the violated permissions policy was + enforced in this case. + [=PermissionsPolicyViolationReportBody/disposition=] will be set to "enforce" if the policy was enforced, or "report" if the violation resulted only in this report being generated (with no further action taken by the user agent in response to the violation). Note: There is currently no mechanism in place for enabling report-only - mode, so [=FeaturePolicyViolationReportBody/disposition=] will always be - set to "enforce". + mode, so [=PermissionsPolicyViolationReportBody/disposition=] will always + be set to "enforce".
@@ -715,30 +721,30 @@ partial interface HTMLIFrameElement {

Process response policy

Given a [=response=] (response) and an [=origin=] - (origin), this algorithm returns a declared feature + (origin), this algorithm returns a declared permissions policy.

  1. Abort these steps if the response’s header list does not contain a [=header=] whose - [=name=] is "Feature-Policy". + [=name=] is "Permissions-Policy".
  2. Let header be the concatenation of the [=value=]s of all [=header=] fields in response’s header list whose name is - "Feature-Policy", separated by U+002C (,) (according to + "Permissions-Policy", separated by U+002C (,) (according to [RFC7230, 3.2.2]).
    3. -
  3. Let feature policy be the result of executing Parse +
  4. Let policy be the result of executing Parse header from value and origin on header and origin.
    5. -
  5. Return feature policy.
    6. +
  6. Return policy.

Parse header from value and origin

Given a string (value) and an [=origin=] (origin) - this algorithm will return a declared feature policy.

+ this algorithm will return a declared permissions policy.

  1. Let policy be an empty ordered map.
  2. For each element returned by
-

Process feature policy - attributes

+

Process permissions + policy attributes

Given an element (element), this algorithm returns a container policy, which may be empty.

    @@ -880,10 +886,12 @@ partial interface HTMLIFrameElement {
-

Create a - Feature Policy for a browsing context

-

Given a browsing context (browsingContext), and an origin - (origin) this algorithm returns a new Feature Policy.

+

Create a Permissions Policy for a browsing + context

+

Given a browsing context (browsingContext), and an + origin (origin) this algorithm returns a new + Permissions Policy.

  1. Let inherited policy be a new ordered map.
  2. Let declared policy be a new ordered map.
    3. @@ -897,22 +905,22 @@ partial interface HTMLIFrameElement { isInherited.
-
  • Let policy be a new feature policy, with inherited - policy inherited policy and declared policy declared - policy. +
  • Let policy be a new permissions policy, with + inherited policy inherited policy and declared policy + declared policy.
  • Return policy.

    • Create a Feature - Policy for a browsing context from response

    + id="create-from-response">Create a Permissions Policy for a browsing + context from response

    Given a browsing context (browsingContext), origin (origin), and a [=response=] (response), this algorithm returns a new - Feature Policy

    + Permissions Policy

      -
    1. Let policy be the result of running Create a Feature Policy for a browsing +
    2. Let policy be the result of running Create a Permissions Policy for a browsing context given browsingContext, and origin.
    3. Let d be the result of running Process response policy on @@ -952,7 +960,7 @@ partial interface HTMLIFrameElement { policy for that feature.

      1. Let policy be container's node document's - Feature Policy + Permissions Policy
      2. If policy's inherited policy for feature is "Disabled", return "Disabled".
        3. @@ -962,7 +970,7 @@ partial interface HTMLIFrameElement { origin, then return "Disabled".
      3. Let container policy be the result of running - Process feature policy attributes on + Process permissions policy attributes on container.
      4. If feature is a key in container policy: @@ -993,8 +1001,8 @@ partial interface HTMLIFrameElement { returns "Disabled" if feature should be considered disabled, and "Enabled" otherwise.

          -
        1. Let policy be document's Feature Policy -
          2. +
        2. Let policy be document's Permissions + Policy
        3. If policy's inherited policy for feature is Disabled, return "Disabled".
        4. If feature is present in policy's declared @@ -1018,40 +1026,40 @@ partial interface HTMLIFrameElement {
    -

    Generate report for violation of - |feature| policy on |settings|

    +

    Generate report for violation of + permissions policy on |settings|

    Given a feature (|feature|), an environment settings object (|settings|), and an optional string (|group|), this algorithm generates a report about the violation of the policy for |feature|.

    - 1. Let |body| be a new {{FeaturePolicyViolationReportBody}}, initialized + 1. Let |body| be a new {{PermissionsPolicyViolationReportBody}}, initialized as follows: - : [=FeaturePolicyViolationReportBody/featureId=] + : [=PermissionsPolicyViolationReportBody/featureId=] :: |feature|'s string representation. - : [=FeaturePolicyViolationReportBody/sourceFile=] + : [=PermissionsPolicyViolationReportBody/sourceFile=] :: null - : [=FeaturePolicyViolationReportBody/lineNumber=] + : [=PermissionsPolicyViolationReportBody/lineNumber=] :: null - : [=FeaturePolicyViolationReportBody/columnNumber=] + : [=PermissionsPolicyViolationReportBody/columnNumber=] :: null - : [=FeaturePolicyViolationReportBody/disposition=] + : [=PermissionsPolicyViolationReportBody/disposition=] :: "enforce" 2. If the user agent is currently executing script, and can extract the source file's URL, line number, and column number from |settings|, then - set |body|'s [=FeaturePolicyViolationReportBody/sourceFile=], - [=FeaturePolicyViolationReportBody/lineNumber=], and - [=FeaturePolicyViolationReportBody/columnNumber=] accordingly. + set |body|'s [=PermissionsPolicyViolationReportBody/sourceFile=], + [=PermissionsPolicyViolationReportBody/lineNumber=], and + [=PermissionsPolicyViolationReportBody/columnNumber=] accordingly. 3. If |group| is omitted, set |group| to "default". 4. Execute [[reporting#queue-report]] with |body|, - "feature-policy-violation", |group|, and |settings|. + "permissions-policy-violation", |group|, and |settings|. - Note: This algorithm should be called when a feature policy has + Note: This algorithm should be called when a permissions policy has been violated.
    @@ -1061,7 +1069,7 @@ partial interface HTMLIFrameElement {
    1. Set |window| to |request|’s window.
    2. If |window| is not a {{Window}}, return false. -
      Feature Policy within non-Window contexts ({{WorkerGlobalScope}} or {{WorkletGlobalScope}}) is being figured out in issue #207. After that’s resolved, update this algorithm to allow fetches initiated within these contexts to use policy-controlled features. *Until* that’s resolved, disallow all policy-controlled features (e.g., sending Client Hints to third parties) in these contexts.
      +
      Permissions Policy within non-Window contexts ({{WorkerGlobalScope}} or {{WorkletGlobalScope}}) is being figured out in issue #207. After that’s resolved, update this algorithm to allow fetches initiated within these contexts to use policy-controlled features. *Until* that’s resolved, disallow all policy-controlled features (e.g., sending Client Hints to third parties) in these contexts.
    3. Set |document| to |window|’s associated `Document`.
    4. Let |origin| be |request|’s origin.
      5. @@ -1081,7 +1089,7 @@ partial interface HTMLIFrameElement { following registration [[!RFC3864]]:

      Header field name
      -
      Feature-Policy
      +
      Permissions-Policy
      Applicable protocol
      http
      Status
      @@ -1090,7 +1098,7 @@ partial interface HTMLIFrameElement {
      W3C
      Specification document
      - Feature Policy API + Permissions Policy API
    @@ -1139,11 +1147,11 @@ partial interface HTMLIFrameElement {

    Unanticipated behavior changes

    -

    Feature policy grants a document the ability to control which features will - and will not be availble in a subframe at the time it is loaded. When a - feature represents an existing, long-standing behavior of the web platform, - this may mean that existing published content on the web was not written with - the expectation that a particular API could fail.

    +

    The Permissions Policy mechanism grants a document the ability to control + which features will and will not be availble in a subframe at the time it is + loaded. When a feature represents an existing, long-standing behavior of the + web platform, this may mean that existing published content on the web was not + written with the expectation that a particular API could fail.

    As a practical (though contrived) example, consider a document which uses @@ -1185,11 +1193,12 @@ partial interface HTMLIFrameElement {

  • In the case where feature detection is not possible, new web content can - be written to use the `policy` object to inspect the feature policy which is - currently enforced, and adjust behaviour or user interface accordingly.
    • + be written to use the `policy` object to inspect the permissions policy + which is currently enforced, and adjust behaviour or user interface + accordingly. -

    Authors integrating their features with Feature Policy can decide when and - how the feature will fail when a document attempts to use it while it is +

    Authors integrating their features with Permissions Policy can decide when + and how the feature will fail when a document attempts to use it while it is disabled. Authors should attempt to make use of existing failure modes, when they exist, to increase the chance that existing content will already be correctly handling such failures.