From f623c0b0eefcc64a5e62137c7026cd917d761aa3 Mon Sep 17 00:00:00 2001 From: Ian Clelland Date: Fri, 9 Jun 2017 10:35:51 -0400 Subject: [PATCH 1/2] Clarify what it means for a feature to be enabled or disabled by default. --- index.bs | 36 ++++++++++--- index.html | 150 ++++++++++++++++++++++++++++++++++------------------- 2 files changed, 125 insertions(+), 61 deletions(-) diff --git a/index.bs b/index.bs index 0da4172a..a27cd876 100644 --- a/index.bs +++ b/index.bs @@ -159,6 +159,24 @@ spec:fetch; type:dfn; text:value
  • A declared policy.
    • +

    The feature policy for a {{Document}} or {{WorkerGlobalScope}} + determines whether a feature is allowed or disallowed in that + context.

    +

    A feature which is disallowed should be disabled, or be made + unavailable for use in the Document or web worker. Each feature may have a + different mechanism for being disabled when disallowed, which should + be defined in that feature's specification.

    +

    A feature is allowed if it is not disallowed.

    +

    A feature may be allowed by default in a {{Document}} or + {{WorkerGlobalScope}}. If a feature is allowed by default, then it + is allowed unless a declared policy disallows it, or if + in a frame, if its container policy or its parent frame's + feature policy disallows it for that frame.

    +

    A feature may be disallowed by default in a {{Document}} or + {{WorkerGlobalScope}}. If a feature is disallowed by default, then it + is disallowed unless in a frame, in whose parent frame the feature is + allowed, and whose parent frame's feature policy or + container policy allows it.

    Inherited policies

    @@ -257,16 +275,18 @@ spec:fetch; type:dfn; text:value allowlists:

    *
    -
    The feature is allowed at the top level by default, and when allowed, - is allowed by default to documents in child frames.
    +
    The feature is allowed by default in top-level documents. If + allowed in a frame, the feature is allowed by default in that + frame's children.
    'self'
    -
    The feature is allowed at the top level by default, and when allowed, - is allowed by default to same-origin domain documents in child frames, - but is disallowed by default in cross-origin documents in child - frames.
    +
    The feature is allowed by default in top-level documents. If + allowed in a frame, the feature is allowed by default in + same-origin documents in child frames, and is disallowed by default + in cross-origin documents in child frames.
    'none'
    -
    The feature is disallowed at the top level by default, and is also - disallowed by default to documents in child frames.
    +
    The feature is disallowed by default in top-level documents, + and is also disallowed by default in documents in child frames. +
    diff --git a/index.html b/index.html index b8498fc5..69df9524 100644 --- a/index.html +++ b/index.html @@ -1423,7 +1423,7 @@

    Feature Policy

    -

    Draft Community Group Report,

    +

    Draft Community Group Report,

    This version: @@ -1666,6 +1666,18 @@

    4
  • A set of inherited policies.
  • A declared policy. +

    The feature policy for a Document or WorkerGlobalScope determines whether a feature is allowed or disallowed in that + context.

    +

    A feature which is disallowed should be disabled, or be made + unavailable for use in the Document or web worker. Each feature may have a + different mechanism for being disabled when disallowed, which should + be defined in that feature’s specification.

    +

    A feature is allowed if it is not disallowed.

    +

    A feature may be allowed by default in a Document or WorkerGlobalScope. If a feature is allowed by default, then it + is allowed unless a declared policy disallows it, or if + in a frame, if its container policy or its parent frame’s feature policy disallows it for that frame.

    +

    A feature may be disallowed by default in a Document or WorkerGlobalScope. If a feature is disallowed by default, then it + is disallowed unless in a frame, in whose parent frame the feature is allowed, and whose parent frame’s feature policy or container policy allows it.

    4.3. Inherited policies

    @@ -1673,7 +1685,7 @@

    policy-controlled feature. This inherited policy set determines the initial state (enabled or disabled) of each feature, and - whether it can be controlled by a declared policy in the document.

    + whether it can be controlled by a declared policy in the document.

    In a Document in a top-level browsing context, or in a WorkerGlobalScope, the inherited feature set is based on defined defaults for each feature.

    In a Document in a nested browsing context, the inherited feature @@ -1687,28 +1699,28 @@

    4.4. Declared policies

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

    -

    A Document or WorkerGlobalScope is considered feature-policy-aware if it has a declared policy which is +

    A Document or WorkerGlobalScope is considered feature-policy-aware if it has a declared policy which is not empty.

    A Document or WorkerGlobalScope is which is not feature-policy-aware is considered feature-policy-oblivious.

    4.5. Header policies

    -

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

    +

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

    4.6. Container policies

    In addition to the header policy, each frame has a container - policy, which is a policy directive, which may be empty. The container policy can set by attributes on the browsing context + policy, which is a policy directive, which may be empty. The container policy can set by attributes on the browsing context container.

    -

    The container policy for a frame influences the inherited +

    The container policy for a frame influences the inherited policy of any document loaded into that frame. (See §8.8 Define an inherited policy for feature)

    -
    Currently, the container policy cannot be set directly, but is +
    Currently, the container policy cannot be set directly, but is indirectly set by iframe "allowfullscreen", "allowpaymentrequest", and "allow" attributes. Future revisions to this spec may introduce a mechanism to - explicitly declare the full container policy.
    + explicitly declare the full container policy.

    4.7. Policy directives

    @@ -1743,16 +1755,16 @@

    :

    * -
    The feature is allowed at the top level by default, and when allowed, - is allowed by default to documents in child frames. +
    The feature is allowed by default in top-level documents. If + allowed in a frame, the feature is allowed by default in that + frame’s children.
    'self' -
    The feature is allowed at the top level by default, and when allowed, - is allowed by default to same-origin domain documents in child frames, - but is disallowed by default in cross-origin documents in child - frames. +
    The feature is allowed by default in top-level documents. If + allowed in a frame, the feature is allowed by default in + same-origin documents in child frames, and is disallowed by default in cross-origin documents in child frames.
    'none' -
    The feature is disallowed at the top level by default, and is also - disallowed by default to documents in child frames. +
    The feature is disallowed by default in top-level documents, + and is also disallowed by default in documents in child frames.

    @@ -1783,7 +1795,7 @@

    6.

    6.1. Feature-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 client.

    + field can be used in the response (server to client) to communicate the feature policy that should be enforced by the client.

    The header’s value is the §5.1 ASCII serialization of one or more policy directives:.

    FeaturePolicy = serialized-feature-policy *("," serialized-feature-policy)
@@ -1803,7 +1815,7 @@ 
    'src', which
     represents the origin of the URL in the iframe’s src attribute. 
    
      
    When not empty, the "allow" attribute will result in adding
-    an allowlist for each recognized feature to the frame’s container policy, when it is contructed.
    
+    an allowlist for each recognized feature to the frame’s container policy, when it is contructed.
    
     
     
    
      
    6.3. Additional attributes to support legacy
@@ -1820,7 +1832,7 @@ 
    allowfullscreen attribute must have no effect.
    
       
    Otherwise, the presence of an "allowfullscreen" attribute on an iframe
       will result in adding an allowlist of * for the
-      "fullscreen" feature to the frame’s container policy, when it is
+      "fullscreen" feature to the frame’s container policy, when it is
       constructed.
    
       
     This is different from the behaviour of <iframe
         allow="fullscreen">, and is for compatibility with existing
@@ -1837,7 +1849,7 @@ 
    allowpaymentrequest attribute must have no effect.
    
       
    Otherwise, the presence of an "allowpaymentrequest" attribute on an
       iframe will result in adding an allowlist of * for
-      the "payment" feature to the frame’s container policy, when it is
+      the "payment" feature to the frame’s container policy, when it is
       constructed.
    
       
     This is different from the behaviour of <iframe
         allow="payment">, and is for compatibility with existing uses
@@ -1856,7 +1868,7 @@ 
    
      
    7.1. Integration with HTML
    
      
      
-      
    1.  Document and WorkerGlobalScope objects have a Feature Policy, which is populated via the §8.7 Initialize global’s Feature
+      
    2.  Document and WorkerGlobalScope objects have a Feature Policy, which is populated via the §8.7 Initialize global’s Feature
     Policy from response algorithm that is called during the
         "Initialising a new Document object" and "Run a Worker"
         algorithms. 
@@ -1865,8 +1877,8 @@ 
      
         
    3.  Initialize the feature policy for the Document 
        
-      
    4. A feature policy is enforced for
-      a Document or WorkerGlobalScope by setting it as the Document or WorkerGlobalScope's Feature Policy. 
+      
    5. A feature policy is enforced for
+      a Document or WorkerGlobalScope by setting it as the Document or WorkerGlobalScope's Feature Policy. 
       
    6. 
        
      The "allowed to use" algorithm calls into §8.9 Is feature enabled in
     global for origin?, as follows:
      
@@ -1874,7 +1886,7 @@ 
      
          Replace the current steps #3 and #4 with the following step: 
          
        
-          
      • If Document’s feature policy enables the
+          
      • If Document’s feature policy enables the
               feature indicated by allowattribute for the origin
               of Document, then return true. 
          
      
@@ -1888,7 +1900,7 @@ 
      8. Algorithms
      
     
      
      
      8.1. Process response policy
      
-     
      Given a response (response) and global object (global), this algorithm returns a declared feature
+     
      Given a response (response) and global object (global), this algorithm returns a declared feature
     policy.
      
      
        
       
      1. Abort these steps if the response’s header list does
@@ -1908,7 +1920,7 @@ 
        This section is out of date; the header format is no
     longer JSON.
    
      
    Given a string (value) and an origin (origin)
-    this algorithm will return a declared feature policy.
    
+    this algorithm will return a declared feature policy.
    
      
      
       
    1. Let policy be an empty list.
       
    2. 
@@ -1979,7 +1991,7 @@ 
      8.5. Process feature policy
     attributes
      
-     
      Given an element element, this algorithm returns a declared feature policy, which may be empty.
      
+     
      Given an element element, this algorithm returns a declared feature policy, which may be empty.
      
      
        
       
      1. Let policy be a new policy directive. 
       
      2. Let valid-features be the result of running Parse allow attribute on the value of element’s allow attribute. 
@@ -2042,7 +2054,7 @@ 
        8.7. Initialize global’s Feature
     Policy from response
        
      
        Given a response (response) and a global object
-    (global), this algorithm populates global’s Feature Policy
        
+    (global), this algorithm populates global’s Feature Policy
        
      
          
       
        1. Let inherited policies be a new ordered map.
       
        2. Let declared policies be a new ordered map.
@@ -2060,7 +2072,7 @@ 
          If inherited policies[feature] is true, then
 	  set declared policies[feature] to allowlist.
        
        
-      
      3. Let policy be a new feature policy, with inherited
+      
      4. Let policy be a new feature policy, with inherited
       policy set inherited policies and declared policy set declared policies. 
       
      5.  Enforce the policy policy. 
      
      
@@ -2084,7 +2096,7 @@ 
      If the allowlist for feature in container policy matches origin, and parent’s inherited policy for feature is Enabled, return Enabled. 
           
    3. Otherwise return Disabled.
          
    
-        
  • Otherwise, if feature is allowed by parent’s feature policy for origin, return Enabled. 
+        
  • Otherwise, if feature is allowed by parent’s feature policy for origin, return Enabled. 
         
  • Otherwise, return Disabled.
        
       
  • Otherwise, return Enabled.
@@ -2097,13 +2109,13 @@ 
    Disabled" if feature should be considered
     disabled, and "Enabled" otherwise.
    
      
      
-      
    1. Let policy be global’s Feature Policy 
+      
    2. Let policy be global’s Feature Policy 
       
    3. If policy’s inherited policy for feature is Disabled, return "Disabled".
       
    4. 
-       If feature is present in policy’s declared
+       If feature is present in policy’s declared
       policy: 
        
        
-        
      1. If the allowlist for feature in policy’s declared policy matches origin, then return "Enabled". 
+        
      2. If the allowlist for feature in policy’s declared policy matches origin, then return "Enabled". 
         
      3. Otherwise return "Disabled".
        
      
       
    5. If feature’s default allowlist is *, return "Enabled". 
@@ -2285,6 +2297,8 @@ 
      Index
   
      Terms defined by this specification
      
   
    • 
   
    
     
    Inherited policies
    
@@ -400,6 +396,35 @@ partial interface HTMLIFrameElement {
     
    
   
 
+
    
+  
    Combining Policies from different sources
    
+  
    To determine the effective feature policy for a given document, several
+  pieces of information are required:
    
+  
      
+    
    • The default allowlists for all features supported by the user agent
      • 
+    
    • The header policy for the document
      • 
+    
    • The origin of the document
      • 
+  
    
+  
    If the document is in a frame, then this is also required:
    
+  
      
+    
    • The feature policy of the document in the parent frame
      • 
+    
    • The container policy defined for the document's frame by its parent.
+    
      • 
+  
    
+  
    Then, for each supported feature, we go through these steps:
    
+  
      
+    
    1. Use the parent's policy and the container policy to define the
+    inherited policy for the new document.
+    For each feature, if it is allowed by the parent for the new document's origin,
+    and not disallowed by the container policy, then it is enabled in the inherited policy. Otherwise, it is disabled.
      2. 
+    
    2. Use the inherited policy and the document's header policy to determine the
+    effective policy for the new document.
+    For each feature, if it is disabled in the inherited policy, then its allowlist will be empty.
+    If it is enabled, and there is a declaration for that feature in the header policy, then its allowlist will be the declared list from the header.
+    If it is enabled, and there is no declaration for that feature in the header policy, then its allowlist will be the default allowlist for the feature (with 'self' replaced with the origin of the document).
+    
      3. 
+  
    
+
    
 
    
   
    Integrations
    
   
    This document defines a set of algorithms which other specifications will
diff --git a/index.html b/index.html
index 69df9524..131f7100 100644
--- a/index.html
+++ b/index.html
@@ -1494,29 +1494,30 @@ 
    Table of Contents
    
         
  • 6.3.2 allowpaymentrequest
        
      
+    
  • 7 Combining Policies from different sources
     
  • 
-     7 Integrations
+     8 Integrations
      
      
-      
    1. 7.1 Integration with HTML
+      
    2. 8.1 Integration with HTML
      
    
     
  • 
-     8 Algorithms
+     9 Algorithms
      
      
-      
    1. 8.1 Process response policy
-      
    2. 8.2 Parse header from value and origin
-      
    3. 8.3 Parse policy directive from value and origin
-      
    4. 8.4 Merge directive with declared
+      
    5. 9.1 Process response policy
+      
    6. 9.2 Parse header from value and origin
+      
    7. 9.3 Parse policy directive from value and origin
+      
    8. 9.4 Merge directive with declared
     policy
-      
    9. 8.5 Process feature policy
+      
    10. 9.5 Process feature policy
     attributes
-      
    11. 8.6 Parse allow attribute
-      
    12. 8.7 Initialize global’s Feature
+      
    13. 9.6 Parse allow attribute
+      
    14. 9.7 Initialize global’s Feature
     Policy from response
-      
    15. 8.8 Define an inherited policy for feature
-      
    16. 8.9 Is feature enabled in global for origin?
+      
    17. 9.8 Define an inherited policy for feature
+      
    18. 9.9 Is feature enabled in global for origin?
      
    
-    
  • 9 IANA Considerations
-    
  • 10 Privacy and Security
+    
  • 10 IANA Considerations
+    
  • 11 Privacy and Security
     
  •   Conformance
     
  • 
       Index
@@ -1674,10 +1675,9 @@ 
    4
     be defined in that feature’s specification.
    
      
    A feature is allowed if it is not disallowed.
    
      
    A feature may be allowed by default in a Document or WorkerGlobalScope. If a feature is allowed by default, then it
-    is allowed unless a declared policy disallows it, or if
-    in a frame, if its container policy or its parent frame’s feature policy disallows it for that frame.
    
+    is allowed if no other policy disallows it.
    
      
    A feature may be disallowed by default in a Document or WorkerGlobalScope. If a feature is disallowed by default, then it
-    is disallowed unless in a frame, in whose parent frame the feature is allowed, and whose parent frame’s feature policy or container policy allows it.
    
+    is disallowed unless explicitly allowed by policy.
    
     
    • 
     
    
      
    4.3. Inherited policies
    
@@ -1685,7 +1685,7 @@ 
    policy-controlled feature. This inherited policy set
     determines the initial state (enabled or disabled) of each feature, and
-    whether it can be controlled by a declared policy in the document. 
    
+    whether it can be controlled by a declared policy in the document. 
    
      
    In a Document in a top-level browsing context, or in a WorkerGlobalScope, the inherited feature set is based on defined
     defaults for each feature.
    
      
    In a Document in a nested browsing context, the inherited feature
@@ -1699,28 +1699,28 @@ 
    4.4. Declared policies
    
      
    A declared
     policy is an ordered map from features to allowlists. 
    
-     
    A Document or WorkerGlobalScope is considered feature-policy-aware if it has a declared policy which is
+     
    A Document or WorkerGlobalScope is considered feature-policy-aware if it has a declared policy which is
     not empty.
    
      
    A Document or WorkerGlobalScope is which is not feature-policy-aware is considered feature-policy-oblivious.
    
     
    
     
    
      
    4.5. Header policies
    
-     
    A header policy is a list of policy directives delivered via an HTTP header with the document. This forms the document’s feature policy’s declared policy.
    
+     
    A header policy is a list of policy directives delivered via an HTTP header with the document. This forms the document’s feature policy’s declared policy.
    
     
    
     
    
      
    4.6. Container policies
    
      
    In addition to the header policy, each frame has a container
-    policy, which is a policy directive, which may be empty. The container policy can set by attributes on the browsing context
+    policy, which is a policy directive, which may be empty. The container policy can set by attributes on the browsing context
     container.
    
-     
    The container policy for a frame influences the inherited
-    policy of any document loaded into that frame. (See §8.8 Define an inherited policy for
+     
    The container policy for a frame influences the inherited
+    policy of any document loaded into that frame. (See §9.8 Define an inherited policy for
     feature)
    
-     
     Currently, the container policy cannot be set directly, but is
+     
     Currently, the container policy cannot be set directly, but is
       indirectly set by iframe "allowfullscreen",
       "allowpaymentrequest",
       and "allow"
       attributes. Future revisions to this spec may introduce a mechanism to
-      explicitly declare the full container policy. 
    
+      explicitly declare the full container policy. 
    
     
    
     
    
      
    4.7. Policy directives
    
@@ -1795,13 +1795,13 @@ 
    6.
      
    6.1. Feature-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 client.
    
+    field can be used in the response (server to client) to communicate the feature policy that should be enforced by the client.
    
      
    The header’s value is the §5.1 ASCII serialization of one or
     more policy directives:.
    
 
    FeaturePolicy = serialized-feature-policy *("," serialized-feature-policy)
 
    
      
    When the user agent receives a Feature-Policy header field,
-    it MUST process and enforce the serialized policy as described in §7.1 Integration with HTML.
    
+    it MUST process and enforce the serialized policy as described in §8.1 Integration with HTML.
    
     
    
     
    
      
    6.2. The allow attribute of the iframe element
    
@@ -1815,7 +1815,7 @@ 
    'src', which
     represents the origin of the URL in the iframe’s src attribute. 
    
      
    When not empty, the "allow" attribute will result in adding
-    an allowlist for each recognized feature to the frame’s container policy, when it is contructed.
    
+    an allowlist for each recognized feature to the frame’s container policy, when it is contructed.
    
     
    
     
    
      
    6.3. Additional attributes to support legacy
@@ -1832,7 +1832,7 @@ 
    allowfullscreen attribute must have no effect.
    
       
    Otherwise, the presence of an "allowfullscreen" attribute on an iframe
       will result in adding an allowlist of * for the
-      "fullscreen" feature to the frame’s container policy, when it is
+      "fullscreen" feature to the frame’s container policy, when it is
       constructed.
    
       
     This is different from the behaviour of <iframe
         allow="fullscreen">, and is for compatibility with existing
@@ -1849,7 +1849,7 @@ 
    allowpaymentrequest attribute must have no effect.
    
       
    Otherwise, the presence of an "allowpaymentrequest" attribute on an
       iframe will result in adding an allowlist of * for
-      the "payment" feature to the frame’s container policy, when it is
+      the "payment" feature to the frame’s container policy, when it is
       constructed.
    
       
     This is different from the behaviour of <iframe
         allow="payment">, and is for compatibility with existing uses
@@ -1859,16 +1859,42 @@ 
    7. Integrations
    
+    
    7. Combining Policies from different sources
    
+    
    To determine the effective feature policy for a given document, several
+  pieces of information are required:
    
+    
      
+     
    • The default allowlists for all features supported by the user agent
+     
    • The header policy for the document
+     
    • The origin of the document
+    
    
+    
    If the document is in a frame, then this is also required:
    
+    
      
+     
    • The feature policy of the document in the parent frame
+     
    • The container policy defined for the document’s frame by its parent. 
+    
    
+    
    Then, for each supported feature, we go through these steps:
    
+    
      
+     
    1. Use the parent’s policy and the container policy to define the inherited policy for the new document.
+    For each feature, if it is allowed by the parent for the new document’s origin,
+    and not disallowed by the container policy, then it is enabled in the inherited policy. Otherwise, it is disabled.
+     
    2. Use the inherited policy and the document’s header policy to determine the
+    effective policy for the new document.
+    For each feature, if it is disabled in the inherited policy, then its allowlist will be empty.
+    If it is enabled, and there is a declaration for that feature in the header policy, then its allowlist will be the declared list from the header.
+    If it is enabled, and there is no declaration for that feature in the header policy, then its allowlist will be the default allowlist for the feature (with 'self' replaced with the origin of the document). 
+    
    
+   
    
+   
    
+    
    8. Integrations
    
     
    This document defines a set of algorithms which other specifications will
   use in order to implement the restrictions which Feature Policy defines. The
   integrations are outlined here for clarity, but those external documents are
   the normative references which ought to be consulted for detailed
   information.
    
     
    
-     
    7.1. Integration with HTML
    
+     
    8.1. Integration with HTML
    
      
      
-      
    1.  Document and WorkerGlobalScope objects have a Feature Policy, which is populated via the §8.7 Initialize global’s Feature
+      
    2.  Document and WorkerGlobalScope objects have a Feature Policy, which is populated via the §9.7 Initialize global’s Feature
     Policy from response algorithm that is called during the
         "Initialising a new Document object" and "Run a Worker"
         algorithms. 
@@ -1877,16 +1903,16 @@ 
      
         
    3.  Initialize the feature policy for the Document 
        
-      
    4. A feature policy is enforced for
-      a Document or WorkerGlobalScope by setting it as the Document or WorkerGlobalScope's Feature Policy. 
+      
    5. A feature policy is enforced for
+      a Document or WorkerGlobalScope by setting it as the Document or WorkerGlobalScope's Feature Policy. 
       
    6. 
-       
      The "allowed to use" algorithm calls into §8.9 Is feature enabled in
+       
      The "allowed to use" algorithm calls into §9.9 Is feature enabled in
     global for origin?, as follows:
      
        
        
         
      1. 
          Replace the current steps #3 and #4 with the following step: 
          
          
-          
        • If Document’s feature policy enables the
+          
        • If Document’s feature policy enables the
               feature indicated by allowattribute for the origin
               of Document, then return true. 
          
        
@@ -1897,10 +1923,10 @@ 
        
    
    
    
    
-    
    8. Algorithms
    
+    
    9. Algorithms
    
     
    
-     
    8.1. Process response policy
    
-     
    Given a response (response) and global object (global), this algorithm returns a declared feature
+     
    9.1. Process response policy
    
+     
    Given a response (response) and global object (global), this algorithm returns a declared feature
     policy.
    
      
      
       
    1. Abort these steps if the response’s header list does
@@ -1910,17 +1936,17 @@ 
      Add a leading "[" U+005B character, and a trailing "]" U+005D
       character to header.
-      
    2. Let feature policy be the result of executing §8.2 Parse header from value and
+      
    3. Let feature policy be the result of executing §9.2 Parse header from value and
     origin on header and global’s origin. 
       
    4. Return feature policy.
      
    
     
    
     
    
-     
    8.2. Parse header from value and origin
    
+     
    9.2. Parse header from value and origin
    
      
    This section is out of date; the header format is no
     longer JSON.
    
      
    Given a string (value) and an origin (origin)
-    this algorithm will return a declared feature policy.
    
+    this algorithm will return a declared feature policy.
    
      
      
       
    1. Let policy be an empty list.
       
    2. 
@@ -1930,16 +1956,16 @@ 
      §8.3 Parse policy directive from
+        
    3. Let directive be the result of executing §9.3 Parse policy directive from
     value and origin on element and origin 
-        
    4. Run §8.4 Merge directive with declared
+        
    5. Run §9.4 Merge directive with declared
     policy on  directive and policy. 
        
    
       
  • Return policy.
      
     
    • 
     
    
-     
    8.3. Parse policy directive from value and origin
    
+     
    9.3. Parse policy directive from value and origin
    
      
    This section is out of date; the header format is no
     longer JSON.
    
      
    Given a JSON object (value) and an origin (origin) this algorithm will return a policy
@@ -1975,7 +2001,7 @@ 
    
     
    
     
    
-     
    8.4. Merge directive with declared
+     
    9.4. Merge directive with declared
     policy
    
      
    Given a policy direcive (directive) and a declared policy
     (policy), this algorithm will modify policy to
@@ -1989,9 +2015,9 @@ 
    8.5. Process feature policy
+     
    9.5. Process feature policy
     attributes
    
-     
    Given an element element, this algorithm returns a declared feature policy, which may be empty.
    
+     
    Given an element element, this algorithm returns a declared feature policy, which may be empty.
    
      
      
       
    1. Let policy be a new policy directive. 
       
    2. Let valid-features be the result of running Parse allow attribute on the value of element’s allow attribute. 
@@ -2030,7 +2056,7 @@ 
      8.6. Parse allow attribute
      
+     
      9.6. Parse allow attribute
      
      
      Given a list, this algorithm returns a list of feature
     name keywords, which may be empty.
      
      
        
@@ -2051,36 +2077,36 @@ 
        
     
    
     
    
-     
    8.7. Initialize global’s Feature
+     
    9.7. Initialize global’s Feature
     Policy from response
    
      
    Given a response (response) and a global object
-    (global), this algorithm populates global’s Feature Policy
    
+    (global), this algorithm populates global’s Feature Policy
    
      
      
       
    1. Let inherited policies be a new ordered map.
       
    2. Let declared policies be a new ordered map.
       
    3. 
        For each feature supported, 
        
        
-        
      1. Let isInherited be the result of running §8.8 Define an inherited policy for
+        
      2. Let isInherited be the result of running §9.8 Define an inherited policy for
     feature on feature and global. 
         
      3. Set inherited policies[feature] to isInherited.
        
      
-      
    4. Let d be the result of executing §8.1 Process response policy on response and global. 
+      
    5. Let d be the result of executing §9.1 Process response policy on response and global. 
       
    6. 
        For each feature -> allowlist of d: 
        
        
         
      1. If inherited policies[feature] is true, then
 	  set declared policies[feature] to allowlist.
        
      
-      
    7. Let policy be a new feature policy, with inherited
+      
    8. Let policy be a new feature policy, with inherited
       policy set inherited policies and declared policy set declared policies. 
       
    9.  Enforce the policy policy. 
      
    
     
    
     
    
-     
    8.8. Define an inherited policy for feature
    
+     
    9.8. Define an inherited policy for feature
    
      
    Given a string (feature) and a browsing context
-    (context), this algorithm returns the inherited policy for that feature.
    
+    (context), this algorithm returns the inherited policy for that feature.
    
      
      
       
    1. 
        If context is a nested browsing context: 
@@ -2088,34 +2114,34 @@ 
      Let parent be context’s parent browsing
           context’s active document.
         
    2. Let origin be parent’s origin
-        
    3. Let container policy be the result of running §8.5 Process feature policy
+        
    4. Let container policy be the result of running §9.5 Process feature policy
     attributes on context’s browsing context container. 
         
    5. 
          If feature is a key in container policy: 
          
        
-          
      1. If the allowlist for feature in container policy matches origin, and parent’s inherited policy for feature is Enabled, return Enabled. 
+          
      2. If the allowlist for feature in container policy matches origin, and parent’s inherited policy for feature is Enabled, return Enabled. 
           
      3. Otherwise return Disabled.
          
      
-        
    6. Otherwise, if feature is allowed by parent’s feature policy for origin, return Enabled. 
+        
    7. Otherwise, if feature is allowed by parent’s feature policy for origin, return Enabled. 
         
    8. Otherwise, return Disabled.
        
    
       
  • Otherwise, return Enabled.
      
     
    • 
     
    
-     
    8.9. Is feature enabled in global for origin?
    
+     
    9.9. Is feature enabled in global for origin?
    
      
    Given a string (feature) and a global object
     (global), and an origin (origin), this algorithm
     returns "Disabled" if feature should be considered
     disabled, and "Enabled" otherwise.
    
      
      
-      
    1. Let policy be global’s Feature Policy 
-      
    2. If policy’s inherited policy for feature is Disabled, return "Disabled".
+      
    3. Let policy be global’s Feature Policy 
+      
    4. If policy’s inherited policy for feature is Disabled, return "Disabled".
       
    5. 
-       If feature is present in policy’s declared
+       If feature is present in policy’s declared
       policy: 
        
        
-        
      1. If the allowlist for feature in policy’s declared policy matches origin, then return "Enabled". 
+        
      2. If the allowlist for feature in policy’s declared policy matches origin, then return "Enabled". 
         
      3. Otherwise return "Disabled".
        
      
       
    6. If feature’s default allowlist is *, return "Enabled". 
@@ -2126,7 +2152,7 @@ 
      
    
    
    
    
-    
    9. IANA Considerations
    
+    
    10. IANA Considerations
    
     
    The permanent message header field registry should be updated with the
   following registration [RFC3864]:
    
     
    
@@ -2143,7 +2169,7 @@ 
    
    
    
    
    
-    
    10. Privacy and Security
    
+    
    11. Privacy and Security
    
     
    TODO
    
    
    
   
@@ -2310,7 +2336,7 @@ 
    default allowlists, in §4.9
    
  • disallowed, in §4.2
    
  • disallowed by default, in §4.2
-   
  • enforce, in §7.1
+   
  • enforce, in §8.1
    
  • feature name, in §4.1
    
  • feature-name, in §5.1
    
  • feature policy, in §4.2
@@ -2420,7 +2446,7 @@ 
    6.3. Additional attributes to support legacy
     features
-    
  • 8.3. Parse policy directive from
+    
  • 9.3. Parse policy directive from
     value and origin (2)
    
   
@@ -2428,23 +2454,23 @@ 
    #feature-nameReferenced in:
    
   
   
@@ -2457,7 +2483,7 @@ 
    
    #allowedReferenced in:
    
   
   
@@ -2494,17 +2521,17 @@ 
    
    #declared-policyReferenced in:
    
   
   
   
@@ -2558,20 +2584,20 @@ 
    6.3.1. allowfullscreen
     
  • 6.3.2. allowpaymentrequest
-    
  • 8.3. Parse policy directive from
+    
  • 9.3. Parse policy directive from
     value and origin
-    
  • 8.8. Define an inherited policy for
+    
  • 9.8. Define an inherited policy for
     feature
-    
  • 8.9. Is feature enabled in
+    
  • 9.9. Is feature enabled in
     global for origin?
    
   
   
@@ -2580,7 +2606,7 @@ 
    4.1. Policy-controlled Features
     
  • 4.9. Default Allowlists (2)
-    
  • 8.9. Is feature enabled in
+    
  • 9.9. Is feature enabled in
     global for origin? (2)
    
   
@@ -2628,7 +2654,7 @@ 
    6.1. Feature-Policy HTTP Header
     Field
-    
  • 8.7. Initialize global’s Feature
+    
  • 9.7. Initialize global’s Feature
     Policy from response