From e2736be1b4cdf09bf4ccf6b569ea33516b0afc5d Mon Sep 17 00:00:00 2001 From: Mike West Date: Sun, 17 Jul 2016 15:33:57 +0200 Subject: [PATCH] Non-normativizing things. --- index.html | 162 ++++++++++++++++++++-------------------- index.src.html | 197 +++++++++++++++++++++++++------------------------ 2 files changed, 184 insertions(+), 175 deletions(-) diff --git a/index.html b/index.html index 833f678..6762d3e 100644 --- a/index.html +++ b/index.html @@ -1425,7 +1425,7 @@

Secure Contexts

-

Editor’s Draft,

+

Editor’s Draft,

This version: @@ -1632,15 +1632,15 @@

-
- +
+

If a non-secure context opens https://example.com/ in a new window, then things are more complicated. The new window’s status depends on how it was opened. If the non-secure context can obtain a reference to the secure context, or vice-versa, then the new window is not a secure context.

This means that the following will both produce non-secure contexts:

<a href="https://example.com/" target="_blank">Link!</a>
-      
+
 <script>
   var w = window.open("https://example.com/");
 </script>
@@ -1661,7 +1661,7 @@ 
The link can be broken via the noopener link relation, meaning
     that the following will both produce secure contexts:

 
<a href="https://example.com/" rel="noopener" target="_blank">Link!</a>
-      
+
 <script>
   var w = window.open("https://example.com/", "", "noopener");
 </script>
@@ -1920,13 +1920,14 @@ 
2.
     
An environment settings object is considered a secure
   context if the algorithm in §3.1 Is settings object a secure context? returns "Secure", and a non-secure context otherwise.

     
Likewise, a global object is considered a secure context if its relevant settings object is a secure context.

-    
2.1. Intergration with WebIDL

-    
This section is non-normative.

-    
A new [SecureContext] attribute is available for operators, which
-  ensures that they will only be exposed into secure contexts. The
-  following example should help:

-    

-      
+    

+     
2.1. Intergration with WebIDL

+     
This section is non-normative.

+     
A new [SecureContext] attribute is available for operators, which
+    ensures that they will only be exposed into secure contexts. The
+    following example should help:

+     

+       
 
interface ExampleFeature {
   // This call will succeed in all contexts.
   Promise <double> calculateNotSoSecretResult();
@@ -1944,36 +1945,37 @@ 
Promise<any> doAmazingThing();
 };
 

-    

-    
Specification authors are encouraged to use this attribute when defining new
-  features.

-    
2.2. Modifications to HTML

-    
2.2.1. Shared Workers

-    
This section is non-normative.

-    
The SharedWorker() constructor will throw a SecurityError exception if
-  a secure context attempts to attach to an Worker which is not a secure context, and if a non-secure context attempts to attach to a
-  Worker which is a secure context.

-    
The constructor is modified as follows (though the SharedWorker specification
-  remains the normative reference):

-    
    
-     
  1. 
-      
    As the first substep of the SharedWorker() constructor’s current step
+     

+     
Specification authors are encouraged to use this attribute when defining new
+    features.

+     
2.2. Modifications to HTML

+     
2.2.1. Shared Workers

+     
This section is non-normative.

+     
The SharedWorker() constructor will throw a SecurityError exception if
+    a secure context attempts to attach to an Worker which is not a secure context, and if a non-secure context attempts to attach to a
+    Worker which is a secure context.

+     
The constructor is modified as follows (though the SharedWorker specification
+    remains the normative reference):

+     
    
+      
  1. 
+       
    As the first substep of the SharedWorker() constructor’s current step
   6.7 ("If worker global scope is not null, then run these
   steps:"), run the following step:
    
-      
      
-       
    1. 
-        
      If the result of executing §3.1 Is settings object a secure context? on the current
+       
        
+        
      1. 
+         
        If the result of executing §3.1 Is settings object a secure context? on the current
   settings object does not match the result of executing the same
   algorithm on worker global scope’s relevant settings
   object, then throw a SecurityError exception, and abort
   these steps.
        
-      
      
-    
    
-    
    Note: This change landed in WHATWG’s HTML in whatwg/html#1560.
    
-    
     It’s not clear to me how the W3C’s [WEBWORKERS] document is updated.
-  It looks like it’s pulling content from the WHATWG upstream, which means
-  that the PR linked above should flow into it? But that document hasn’t been
-  updated since 2015, so...
    
+       

+     
+     
Note: This change landed in WHATWG’s HTML in whatwg/html#1560.

+     
 It’s not clear to me how the W3C’s [WEBWORKERS] document is updated.
+    It looks like it’s pulling content from the WHATWG upstream, which means
+    that the PR linked above should flow into it? But that document hasn’t been
+    updated since 2015, so...

+    
     
2.2.2. Feature Detection

     
To determine whether a context is capable of making use of features which
   require secure contexts, a simple boolean attribute is added to the
@@ -2269,58 +2271,62 @@ 
7.3. <
 };
-

7.4. Restricting Legacy Features

-

This section is non-normative.

-

The list above clearly includes some existing functionality that is currently - available to the web over non-secure channels. We recommend that such legacy - functionality be modified to begin requiring a secure context as - quickly as is reasonably possible [W3C-PROCESS].

-
    -
  1. -

    If such a feature is not widely implemented, we recommend that the +

    +

    7.4. Restricting Legacy Features

    +

    This section is non-normative.

    +

    The list above clearly includes some existing functionality that is currently + available to the web over non-secure channels. We recommend that such legacy + functionality be modified to begin requiring a secure context as + quickly as is reasonably possible [W3C-PROCESS].

    +
      +
    1. +

      If such a feature is not widely implemented, we recommend that the specification be immediately modified to include a restriction to secure contexts.

      -
    2. -

      If such a feature is widely implemented, but not yet in wide use, we +

    3. +

      If such a feature is widely implemented, but not yet in wide use, we recommend that it be quickly restricted to secure contexts by adding a check as described in §7.3 Restricting New Features to existing implementations, and modifying the specification accordingly.

      -
    4. -

      If such a feature is in wide use, we recommend that the existing +

    5. +

      If such a feature is in wide use, we recommend that the existing functionality be deprecated; the specification should be modified to note that it does not conform to the restrictions outlined in this document, and a plan should be developed to both offer a conformant version of the feature and to migrate existing users into that new version.

      -
    -

    7.4.1. Example: Geolocation

    -

    The [GEOLOCATION-API] is a good concrete example of such a feature; it is - widely implemented and used on a large number of non-secure sites. A reasonable - path forward might look like this:

    -
      -
    1. -

      Modify the specification to include +

    +

    7.4.1. Example: Geolocation

    +

    The [GEOLOCATION-API] is a good concrete example of such a feature; it is + widely implemented and used on a large number of non-secure sites. A reasonable + path forward might look like this:

    +
      +
    1. +

      Modify the specification to include checks against secure context before executing the algorithms for getCurrentPosition() and watchPosition().

      -

      If the current settings object is not a secure context, +

      If the current settings object is not a secure context, then the algorithm should be aborted, and the errorCallback invoked with a code of PERMISSION_DENIED.

      -
    2. -

      The user agent should announce clear intentions to disable the API for +

    3. +

      The user agent should announce clear intentions to disable the API for non-secure contexts on a specific date, and warn developers accordingly (via console messages, for example).

      -
    4. -

      Leading up to the flag day, the user agent should announce a deprecation +

    5. +

      Leading up to the flag day, the user agent should announce a deprecation schedule to ensure both that site authors recognize the need to modify their code before it simply stops working altogether, and to protect users in the meantime. Such a plan might include any or all of:

      -
        -
      1. -

        Disallowing persistent permission grants to non-secure origins

        -
      2. -

        Coarsening the accuracy of the API for non-secure origins (perhaps +

          +
        1. +

          Disallowing persistent permission grants to non-secure origins

          +
        2. +

          Coarsening the accuracy of the API for non-secure origins (perhaps consistently returning city-level data rather than high-accuracy data)

          -
        3. -

          UI modifications to inform users and site authors of the risk

          -
        -
      +
        +
      1. +

        UI modifications to inform users and site authors of the risk

        +
      +
    +
+

8. Acknowledgements

@@ -2446,8 +2452,6 @@

References

Normative References

-
[GEOLOCATION-API] -
Andrei Popescu. Geolocation API Specification. 28 May 2015. PER. URL: http://dev.w3.org/geo/api/spec-source.html
[HTML]
Ian Hickson. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML51] @@ -2458,8 +2462,6 @@

N
V. Fuller; T. Li. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. August 2006. Best Current Practice. URL: https://tools.ietf.org/html/rfc4632
[W3C-PROCESS]
Charles McCathie Nevile. World Wide Web Consortium Process Document. URL: https://www.w3.org/2014/Process-20140801/ -
[WebIDL-1] -
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 8 March 2016. CR. URL: https://heycam.github.io/webidl/
[WEBWORKERS]
Ian Hickson. Web Workers. 24 September 2015. WD. URL: https://html.spec.whatwg.org/multipage/workers.html
[WHATWG-URL] @@ -2479,6 +2481,8 @@

Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[FULLSCREEN]
Anne van Kesteren. Fullscreen API Standard. Living Standard. URL: https://fullscreen.spec.whatwg.org/ +
[GEOLOCATION-API] +
Andrei Popescu. Geolocation API Specification. 28 May 2015. PER. URL: http://dev.w3.org/geo/api/spec-source.html
[IndexedDB]
Nikunj Mehta; et al. Indexed Database API. 8 January 2015. REC. URL: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
[MEDIACAPTURE-STREAMS] @@ -2501,6 +2505,8 @@

Jeffrey Yasskin. Web Bluetooth. Draft Community Group Report. URL: https://webbluetoothcg.github.io/web-bluetooth/
[WEBCRYPTOAPI]
Ryan Sleevi; Mark Watson. Web Cryptography API. 11 December 2014. CR. URL: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html +
[WebIDL-1] +
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 8 March 2016. CR. URL: https://heycam.github.io/webidl/

IDL Index

partial interface WindowOrWorkerGlobalScope {
@@ -2513,9 +2519,9 @@ 
 W3C’s HTML has only an extremely partial port of
     the noopener concept. <https://github.com/w3c/html/issues/523> ↵
It’s not clear to me how the W3C’s [WEBWORKERS] document is updated. - It looks like it’s pulling content from the WHATWG upstream, which means - that the PR linked above should flow into it? But that document hasn’t been - updated since 2015, so... ↵
+ It looks like it’s pulling content from the WHATWG upstream, which means + that the PR linked above should flow into it? But that document hasn’t been + updated since 2015, so... ↵
WindowOrWorkerGlobalScope does not appear to be defined in W3C’s HTML. For the purposes of that specification, the IDL above could be diff --git a/index.src.html b/index.src.html index 843ca1d..a222433 100644 --- a/index.src.html +++ b/index.src.html @@ -270,12 +270,12 @@

Top-level Documents

       <a href="https://example.com/" target="_blank">Link!</a>
-      
+
       <script>
         var w = window.open("https://example.com/");
       </script>
- + @@ -295,12 +295,12 @@

Top-level Documents

       <a href="https://example.com/" rel="noopener" target="_blank">Link!</a>
-      
+
       <script>
         var w = window.open("https://example.com/", "", "noopener");
       </script>
- + @@ -589,70 +589,71 @@

Framework

Likewise, a global object is considered a secure context if its relevant settings object is a secure context. -

Intergration with WebIDL

+
+

Intergration with WebIDL

- This section is non-normative. + This section is non-normative. - A new `[SecureContext]` attribute is available for operators, which - ensures that they will only be exposed into secure contexts. The - following example should help: + A new `[SecureContext]` attribute is available for operators, which + ensures that they will only be exposed into secure contexts. The + following example should help: -
- 
-      interface ExampleFeature {
-        // This call will succeed in all contexts.
-        Promise <double> calculateNotSoSecretResult();
+    

+      
+        interface ExampleFeature {
+          // This call will succeed in all contexts.
+          Promise <double> calculateNotSoSecretResult();
 
-        // This operation will not be exposed to a non-secure context.
-        [SecureContext] Promise<double> calculateSecretResult();
+          // This operation will not be exposed to a non-secure context.
+          [SecureContext] Promise<double> calculateSecretResult();
 
-        // The same applies here: the operation will not be exposed to a non-secure context.
-        [SecureContext] boolean getSecretBoolean();
-      };
+          // The same applies here: the operation will not be exposed to a non-secure context.
+          [SecureContext] boolean getSecretBoolean();
+        };
 
-      [SecureContext]
-      interface SecureFeature {
-        // This interface will not be exposed to non-secure contexts.
-        Promise<any> doAmazingThing();
-      };
-    

-  

+        [SecureContext]
+        interface SecureFeature {
+          // This interface will not be exposed to non-secure contexts.
+          Promise<any> doAmazingThing();
+        };
+
+
- Specification authors are encouraged to use this attribute when defining new - features. + Specification authors are encouraged to use this attribute when defining new + features. -

Modifications to HTML

+

Modifications to HTML

-

Shared Workers

+

Shared Workers

- This section is non-normative. + This section is non-normative. - The {{SharedWorker()}} constructor will throw a `SecurityError` exception if - a secure context attempts to attach to an Worker which is not a - secure context, and if a non-secure context attempts to attach to a - Worker which is a secure context. - - - The constructor is modified as follows (though the SharedWorker specification - remains the normative reference): + The {{SharedWorker()}} constructor will throw a `SecurityError` exception if + a secure context attempts to attach to an Worker which is not a + secure context, and if a non-secure context attempts to attach to a + Worker which is a secure context. - 1. As the first substep of the {{SharedWorker()}} constructor's current step - 6.7 ("If worker global scope is not `null`, then run these - steps:"), run the following step: + The constructor is modified as follows (though the SharedWorker specification + remains the normative reference): - 1. If the result of executing [[#settings-object]] on the current - settings object does not match the result of executing the same - algorithm on worker global scope's relevant settings - object, then throw a `SecurityError` exception, and abort - these steps. + 1. As the first substep of the {{SharedWorker()}} constructor's current step + 6.7 ("If worker global scope is not `null`, then run these + steps:"), run the following step: - Note: This change landed in WHATWG's HTML in - whatwg/html#1560. - - ISSUE: It's not clear to me how the W3C's [[WEBWORKERS]] document is updated. - It looks like it's pulling content from the WHATWG upstream, which means - that the PR linked above should flow into it? But that document hasn't been - updated since 2015, so... + 1. If the result of executing [[#settings-object]] on the current + settings object does not match the result of executing the same + algorithm on worker global scope's relevant settings + object, then throw a `SecurityError` exception, and abort + these steps. + + Note: This change landed in WHATWG's HTML in + whatwg/html#1560. + + ISSUE: It's not clear to me how the W3C's [[WEBWORKERS]] document is updated. + It looks like it's pulling content from the WHATWG upstream, which means + that the PR linked above should flow into it? But that document hasn't been + updated since 2015, so... +

Feature Detection

@@ -1048,63 +1049,65 @@

Restricting New Features

-

Restricting Legacy Features

+
+

Restricting Legacy Features

- This section is non-normative. + This section is non-normative. - The list above clearly includes some existing functionality that is currently - available to the web over non-secure channels. We recommend that such legacy - functionality be modified to begin requiring a secure context as - quickly as is reasonably possible [[!W3C-PROCESS]]. + The list above clearly includes some existing functionality that is currently + available to the web over non-secure channels. We recommend that such legacy + functionality be modified to begin requiring a secure context as + quickly as is reasonably possible [[!W3C-PROCESS]]. - 1. If such a feature is not widely implemented, we recommend that the - specification be immediately - modified to include a restriction - to secure contexts. + 1. If such a feature is not widely implemented, we recommend that the + specification be immediately + modified to include a restriction + to secure contexts. - 2. If such a feature is widely implemented, but not yet in wide use, we - recommend that it be quickly restricted to secure contexts by - adding a check as described in [[#new]] to existing implementations, and - modifying the specification - accordingly. + 2. If such a feature is widely implemented, but not yet in wide use, we + recommend that it be quickly restricted to secure contexts by + adding a check as described in [[#new]] to existing implementations, and + modifying the specification + accordingly. - 3. If such a feature is in wide use, we recommend that the existing - functionality be deprecated; the specification should be - modified to note that it does not - conform to the restrictions outlined in this document, and a plan should - be developed to both offer a conformant version of the feature and to - migrate existing users into that new version. + 3. If such a feature is in wide use, we recommend that the existing + functionality be deprecated; the specification should be + modified to note that it does not + conform to the restrictions outlined in this document, and a plan should + be developed to both offer a conformant version of the feature and to + migrate existing users into that new version. -

Example: Geolocation

+

Example: Geolocation

- The [[GEOLOCATION-API]] is a good concrete example of such a feature; it is - widely implemented and used on a large number of non-secure sites. A reasonable - path forward might look like this: + The [[GEOLOCATION-API]] is a good concrete example of such a feature; it is + widely implemented and used on a large number of non-secure sites. A reasonable + path forward might look like this: - 1. Modify the specification to include - checks against secure context before executing the algorithms for - {{getCurrentPosition()}} and {{watchPosition()}}. + 1. Modify the specification to include + checks against secure context before executing the algorithms for + {{getCurrentPosition()}} and {{watchPosition()}}. - If the current settings object is not a secure context, - then the algorithm should be aborted, and the `errorCallback` - invoked with a `code` of `PERMISSION_DENIED`. + If the current settings object is not a secure context, + then the algorithm should be aborted, and the `errorCallback` + invoked with a `code` of `PERMISSION_DENIED`. - 2. The user agent should announce clear intentions to disable the API for - non-secure contexts on a specific date, and warn developers accordingly - (via console messages, for example). + 2. The user agent should announce clear intentions to disable the API for + non-secure contexts on a specific date, and warn developers accordingly + (via console messages, for example). - 3. Leading up to the flag day, the user agent should announce a deprecation - schedule to ensure both that site authors recognize the need to modify - their code before it simply stops working altogether, and to protect - users in the meantime. Such a plan might include any or all of: + 3. Leading up to the flag day, the user agent should announce a deprecation + schedule to ensure both that site authors recognize the need to modify + their code before it simply stops working altogether, and to protect + users in the meantime. Such a plan might include any or all of: - 1. Disallowing persistent permission grants to non-secure origins + 1. Disallowing persistent permission grants to non-secure origins - 2. Coarsening the accuracy of the API for non-secure origins (perhaps - consistently returning city-level data rather than high-accuracy - data) + 2. Coarsening the accuracy of the API for non-secure origins (perhaps + consistently returning city-level data rather than high-accuracy + data) - 3. UI modifications to inform users and site authors of the risk + 3. UI modifications to inform users and site authors of the risk +