diff --git a/index.html b/index.html index 35c768a..3fb3422 100644 --- a/index.html +++ b/index.html @@ -34,6 +34,7 @@ * - .note for informative notes (div, p, span, aside, details) * - .example for informative examples (div, p, pre, span) * - .issue for issues (div, p, span) + * - .assertion for assertions (div, p, span) * - .advisement for loud normative statements (div, p, strong) * - .annoying-warning for spec obsoletion notices (div, aside, details) * @@ -597,7 +598,7 @@ /* Colored Boxes */ /******************************************************************************/ - .issue, .note, .example, .advisement, blockquote { + .issue, .note, .example, .assertion, .advisement, blockquote { padding: .5em; border: .5em; border-left-style: solid; @@ -612,6 +613,7 @@ .note, .example, .advisement, + .assertion, blockquote { margin: 1em auto; } @@ -691,6 +693,15 @@ border-bottom: 1px silver solid; } +/** Assertion Box *************************************************************/ + /* for assertions in algorithms */ + + .assertion { + border-color: orange; + border-style: none solid; + background: #FFEECC; + } + /** Advisement Box ************************************************************/ /* for attention-grabbing normative statements */ @@ -1482,7 +1493,7 @@

The following features are at-risk, and may be dropped during the CR period:

“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.

@@ -1513,8 +1524,9 @@

Table of Contents

  • 3 Algorithms
      -
    1. 3.1 Is settings object a secure context? +
    2. 3.1 Is the environment settings object settings a secure context?
    3. 3.2 Is origin potentially trustworthy? +
    4. 3.3 Is url potentially trustworthy?
  • 4 Threat models and risks @@ -1925,7 +1937,7 @@

    2. Framework

    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.

    + context if the algorithm in §3.1 Is the environment settings object settings 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

    @@ -1989,7 +2001,7 @@

    1. -

      If the result of executing §3.1 Is settings object a secure context? on the current +

      If the result of executing §3.1 Is the environment settings object settings 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 @@ -2006,12 +2018,12 @@

      secure contexts, a simple boolean attribute is added to the global object:

      -
      partial interface WindowOrWorkerGlobalScope {
+
      partial interface WindowOrWorkerGlobalScope {
   readonly attribute boolean isSecureContext;
 };
 
      
     
      
-      WindowOrWorkerGlobalScope does not appear to be defined in W3C’s
+      WindowOrWorkerGlobalScope does not appear to be defined in W3C’s
     HTML. For the purposes of that specification, the IDL above could be
     interpreted as: 
 
      interface GlobalSecureContext {
@@ -2023,11 +2035,11 @@ 
      w3c/html#522.
      
     
      
     
      The isSecureContext attribute’s getter
-  returns true if §3.1 Is settings object a secure context? returns "Secure" when executed upon this global object’s relevant settings object, and false otherwise.
      
+  returns true if §3.1 Is the environment settings object settings a secure context? returns "Secure" when executed upon this global object’s relevant settings object, and false otherwise.

    3. Algorithms

    -

    3.1. Is settings object a secure context?

    +

    3.1. Is the environment settings object settings a secure context?

    Given an environment settings object (settings) this algorithm returns "Secure" if the object represents a context which the user agent obtained via a secure channel, and "Not Secure" otherwise.

    @@ -2042,54 +2054,51 @@

    -

    If §3.1 Is settings object a secure context? returns "Not Secure" when executed upon document’s relevant settings object, return "Not Secure".

    +

    Assert: Workers must be same-origin with the context that created + them, so document’s relevant settings object’s origin and HTTPS + state is the same as global’s relevant settings + object’s origin and HTTPS state.

    +
  • +

    If §3.1 Is the environment settings object settings a secure context? returns "Not Secure" when executed upon document’s relevant settings object, return "Not Secure".

    +
  • +

    Return "Secure".

    +

    Note: Given the assertion above, if we’ve reached this step, the + worker must have been created from a secure context, and + therefore must itself be a secure context.

  • -

    Assert: global is a Window.

    +

    Assert: global is a Window.

    +
  • +

    Let document be settings’s responsible document.

  • -

    If settings object’s responsible document has an creator - browsing context whose creator context security is "Not Secure", return "Not Secure".

    -

    Note: Since we take account of creator browsing contexts' +

    Return "Not Secure" if any of the following are true:

    +
      +
    1. +

      document’s active sandboxing flag set contains the sandboxed secure browsing context flag.

      +

      Note: This check is "at risk". See §2.2.1 Sandboxing for details.

      +
    2. +

      document has an creator browsing context (context), and context’s creator context security is "Not Secure".

      +

      Note: Since we take account of creator browsing contexts' status, a popups' status depends on how it is opened, as discussed in §1.1 Top-level Documents.

      -

      The 'creator context security' concept landed in +

      The 'creator context security' concept landed in WHATWG’s HTML in whatwg/html#1561, but doesn’t yet exist in W3C’s HTML. <https://github.com/w3c/html/issues/524>

      -
    3. -

      If settings object’s responsible document’s active sandboxing - flag set contains the sandboxed secure browsing context flag, - return "Not Secure".

      -

      NOTE: This check is "at risk". See §2.2.1 Sandboxing for - details.

      -
    4. -

      If settings object’s HTTPS state is "modern", return - "Secure".

      -
      - Most of the time, this check will be enough to determine whether - a particular context was securely delivered. Documents delivered over - TLS will have their HTTPS state set, and srcdoc Documents - inherit their ancestor’s HTTPS state (as do other kinds of - requests which inherit their requestor’s origin: see the basic - fetch algorithm for details on some of these [FETCH]). -

      We only continue past this check in order to allow resources - delivered from "trustworthy" but unauthenticated locations like http://127.0.0.1/ to be treated as creating a secure context.

      -
      -
    5. -

      Let origin be settings object’s origin.

      -
    6. -

      If origin is an opaque origin, set origin to the origin of settings object’s creation - URL.

      -

      Note: We use the origin of the URL here because sandboxed content that - is treated as being in a unique origin (e.g. <iframe sandbox src="http://127.0.0.1/">) would otherwise be treated as - non-trustworthy by §3.2 Is origin potentially trustworthy?. Since sandboxing is a - strict reduction in the content’s capabilities, and therefore in the - risk it poses, we look at the origin of its URL to determine whether we - would have considered it trustworthy had it not been sandboxed.

      -
    7. -

      If the result of executing the §3.2 Is origin potentially trustworthy? algorithm - on origin is not "Potentially Trustworthy", then - return "Not Secure".

      +
    8. +

      settings’s HTTPS state is "deprecated".

      +
    9. +

      document’s active sandboxing flag set includes the sandboxed origin browsing context flag, and §3.3 Is url potentially trustworthy? returns "Not Trustworthy" when executed upon settings’s creation URL.

      +

      Note: We check the creation URL here because sandboxed content + that is treated as being in an opaque origin (e.g. <iframe sandbox="allow-secure-context" src="http://127.0.0.1/">) + would otherwise be treated as non-trustworthy by §3.2 Is origin potentially trustworthy?. Since sandboxing is a strict reduction in + the content’s capabilities, and therefore in the risk it poses, we + look at the origin of its URL to determine whether we would have + considered it trustworthy had it not been sandboxed.

      +
    10. +

      document’s active sandboxing flag set does not include the sandboxed origin browsing context flag, and §3.2 Is origin potentially trustworthy? returns "Not Trustworthy" when executed + upon settings’s origin.

      +

  • Return "Secure".

    @@ -2111,22 +2120,17 @@

    On the other hand, the user agent MAY choose to extend this trust to other, vendor-specific URL schemes like app: or chrome-extension: which it can determine a priori to be trusted (see §7.1 Packaged Applications for detail).

    -

    Given an origin (origin), the following algorithm returns - "Potentially Trustworthy" or "Not Trustworthy" as appropriate.

    +

    Given an origin (origin), the following algorithm + returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate.

    1. If origin is an opaque origin, return "Not Trustworthy".

    2. -

      Assert: origin is a tuple origin.

      +

      Assert: origin is a tuple origin.

    3. If origin’s scheme is either "https" or "wss", return "Potentially Trustworthy".

      Note: This is meant to be analog to the a priori authenticated URL concept in [MIX].

      -

      Note: The origin of blob: and filesystem: URLs is the origin of the - context in which they were created. Therefore, blobs created in a - trustworthy origin will themselves be potentially trustworthy. The origin - of data: and javascript: URLs, on the other hand, is an opaque - origin, which will not be considered potentially trustworthy.

    4. If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return "Potentially Trustworthy".

      @@ -2144,7 +2148,26 @@

      Return "Not Trusted".

    -

    Note: Neither origin’s domain nor port has any effect on whether or not it is considered to be a secure context.

    +

    Note: Neither origin’s domain nor port has any effect on whether or not it is considered to be a secure context.

    +

    3.3. Is url potentially trustworthy?

    +

    A potentially trustworthy URL is one which either inherits + context from it’s creator (about:blank, about:srcdoc) or one whose origin is a potentially trustworthy origin. + Given a URL (url), the following algorithm returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate:

    +
      +
    1. +

      If url’s scheme is "data", return "Not Trustworthy".

      +

      Note: This aligns the definition of a secure context with the de facto "data: URL as opaque origin" + behavior that a majority of today’s browsers have agreed upon, rather + than the de jure "data: URL inherits origin" + behavior defined in HTML.

      +
    2. +

      If url is "about:blank" or "about:srcdoc", return "Potentially Trustworthy".

      +
    3. +

      Return the result of executing §3.2 Is origin potentially trustworthy? on url’s origin.

      +

      Note: The origin of blob: and filesystem: URLs is the origin of the + context in which they were created. Therefore, blobs created in a + trustworthy origin will themselves be potentially trustworthy.

      +

    • 4. Threat models and risks

    @@ -2177,7 +2200,7 @@

    4.2. Ancestral Risk

    -

    The §3.1 Is settings object a secure context? algorithm walks through all the ancestors of a +

    The §3.1 Is the environment settings object settings a secure context? algorithm walks through all the ancestors of a particular context in order to determine whether or not the context itself is secure. Why wouldn’t we consider a securely-delivered document in an iframe to be secure, in and of itself?

    The short answer is that this model would enable abuse. Chrome’s @@ -2190,13 +2213,13 @@

    than a speed-bump, slowing down non-secure access to the API, but completely ineffective in preventing such access.

    While the algorithms in this document do not perfectly isolate non-secure - contexts from secure contexts (as discussed in §5.1 Incomplete Isolation), the + contexts from secure contexts (as discussed in §5.1 Incomplete Isolation), the ancestor checks provide a fairly robust protection for the guarantees of authentication, confidentiality, and integrity that such contexts ought to ptovide.

    4.3. Risks associated with non-secure contexts

    Certain web platform features that have a distinct impact on a user’s - security or privacy should be available for use only in secure + security or privacy should be available for use only in secure contexts in order to defend against the threats above. Features available in non-secure contexts risk exposing these capabilities to network attackers:

    @@ -2226,7 +2249,7 @@

    Note: While restricting a feature itself to secure contexts is +

    Note: While restricting a feature itself to secure contexts is critical, we ought not forget that facilities that carry such information (such as new network access mechanisms, or other generic functions with access to network data) are equally sensitive.

    @@ -2234,7 +2257,7 @@

    5. Security Considerations

    5.1. Incomplete Isolation

    -

    The secure context definition in this document does not completely +

    The secure context definition in this document does not completely isolate a "secure" view on an origin from a "non-secure" view on the same origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storage events, BroadcastChannel, and others.

    @@ -2249,7 +2272,7 @@

    6. Privacy Considerations

    -

    The secure context definition in this document does not in itself have +

    The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, @@ -2273,13 +2296,13 @@

    7.3. Restricting New Features

    This section is non-normative.

    When writing a specification for new features, we recommend that authors - and editors guard sensitive APIs with checks against secure contexts. + and editors guard sensitive APIs with checks against secure contexts. For example, something like the following might be a good approach:

    1. - If the current settings object is not a secure + If the current settings object is not a secure context, then:
      1. [insert something appropriate here: perhaps a Promise could be @@ -2288,7 +2311,7 @@

        7.3. <

    -

    Authors could alternatively ensure that sensitive APIs are only exposed to secure contexts by guarding them with the [SecureContext] attribute:

    +

    Authors could alternatively ensure that sensitive APIs are only exposed to secure contexts by guarding them with the [SecureContext] attribute:

    [SecureContext]
@@ -2308,16 +2331,16 @@ 
    7.4
      
    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
+    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.
      
+  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
+  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.
      
       
    3. 
        
      If such a feature is in wide use, we recommend that the existing
@@ -2333,8 +2356,8 @@ 
      
        
      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,
+  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.
      
       
    4. 
        
      The user agent should announce clear intentions to disable the API for
@@ -2406,16 +2429,12 @@ 
      isSecureContext, in §2.2.3
    
    5. non-secure context, in §2
    
    6. potentially trustworthy origin, in §3.2
+   
    7. potentially trustworthy URL, in §3.3
    
    8. sandboxed secure browsing context flag, in §2.2.1
    
    9. secure context, in §2
   
   
      Terms defined by reference
      
   
   
      References
      
   
      Normative References
      
@@ -2514,8 +2541,6 @@ 
      Rich Tibbett. Network Service Discovery. 20 February 2014. WD. URL: http://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
    
      [ENCRYPTED-MEDIA]
    
      David Dorwin; et al. Encrypted Media Extensions. 5 July 2016. CR. URL: https://w3c.github.io/encrypted-media/
-   
      [FETCH]
-   
      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]
@@ -2546,7 +2571,7 @@ 
      Cameron McCormack; Boris Zbarsky. Web IDL (Second Edition). 23 June 2016. ED. URL: https://heycam.github.io/webidl/
   
   
      IDL Index
      
-
      partial interface WindowOrWorkerGlobalScope {
+
      partial interface WindowOrWorkerGlobalScope {
   readonly attribute boolean isSecureContext;
 };
 
@@ -2565,7 +2590,7 @@ 
       ↵
    - WindowOrWorkerGlobalScope does not appear to be defined in W3C’s + WindowOrWorkerGlobalScope does not appear to be defined in W3C’s HTML. For the purposes of that specification, the IDL above could be interpreted as: 
    interface GlobalSecureContext {
@@ -2579,7 +2604,7 @@ 
     The 'creator context security' concept landed in
   WHATWG’s HTML in whatwg/html#1561,
-  but doesn’t yet exist in W3C’s HTML. <https://github.com/w3c/html/issues/524> ↵
    + but doesn’t yet exist in W3C’s HTML. <https://github.com/w3c/html/issues/524> ↵