From 58921e0254b0f46e1d0ac53a6fa84afe14397d0c Mon Sep 17 00:00:00 2001 From: Mike West Date: Fri, 28 Nov 2014 11:59:51 +0100 Subject: [PATCH] POWER: Cleaning up definitions. In response to Chaals' [1], this patch cleans up the definitions section of the specification. This breaks down into three changes: 1. Flavor text has been dropped from section 2.1; it now simply lists defined terms, and points to their definitions elsewhere in the document. 2. The tags have been removed from section 2.2, ensuring that Bikeshed's glorious autolinks for those terms point outside this document. 3. "Environment settings object" is now "settings object", which is the most that W3C and WHATWG's respective documents seem to be able to agree upon. [1]: http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0360.html --- specs/powerfulfeatures/index.html | 170 ++++++++++---------------- specs/powerfulfeatures/index.src.html | 159 ++++++++++++------------ 2 files changed, 144 insertions(+), 185 deletions(-) diff --git a/specs/powerfulfeatures/index.html b/specs/powerfulfeatures/index.html index 8e6bdcfe..4ec32e90 100644 --- a/specs/powerfulfeatures/index.html +++ b/specs/powerfulfeatures/index.html @@ -53,8 +53,8 @@

Requirements for Powerful Features

Editor’s Draft, - 24 November 2014

-
This version:
https://w3c.github.io/webappsec/specs/powerfulfeatures/
Latest version:
http://www.w3c.org/TR/powerful-features/
Version History:
https://github.com/w3c/webappsec/commits/master/specs/powerfulfeatures/index.src.html
Feedback:
public-webappsec@w3.org with subject line “[POWER] … message topic …” (archives)
Editor:
(Google Inc.)
+ 28 November 2014 +
This version:
https://w3c.github.io/webappsec/specs/powerfulfeatures/
Latest version:
http://www.w3c.org/TR/powerful-features/
Version History:
https://github.com/w3c/webappsec/commits/master/specs/powerfulfeatures/index.src.html
Feedback:
public-webappsec@w3.org with subject line “[POWER] … message topic …” (archives)
Issue Tracking:
Inline In Spec
Editor:
(Google Inc.)

Copyright © 2014 W3C® @@ -126,7 +126,7 @@

  • 4 Algorithms
  • 5 Implementation Considerations
  • 6 Acknowledgements
  • Conformance
  • References
  • Index
  • Issues Index @@ -165,11 +165,9 @@

    2. 2.1. Terms defined by this specification

    -
    powerful feature
    +
    powerful feature
    - The considerations around categorizing a feature as - powerful are explored in more detail in - §3 + Defined in §3 Is [insert feature here] powerful? .
    @@ -178,91 +176,55 @@

    - A Document or environment settings object is considered - sufficiently secure to use powerful features if - and only if the algorithm defined in §4.1 + A Document is considered sufficiently secure if + the algorithm defined in §4.1 Is Document a sufficiently secure context? - - or §4.2 - Is environment settings object a sufficiently secure context? - , respectively, returns + returns Sufficiently Secure when executed upon it. -

    The goal of the normative algorithms noted above is that - powerful features only be enabled in the - context of an origin with one or more of the following - characteristics:

    - -
      -
    1. - The scheme component is either https, wss, - or file. -
      2. -
    2. - The host component is or falls within "localhost." [RFC6761] -
      3. -
    3. - The host component is an IP address within a - loopback special-purpose IP address range (i.e. - 127.0.0.0/8 or ::1/128) [RFC6890]. -
      4. -
    -
    -

    - -

    2.2. Terms defined by reference

    -
    -
    origin
    -
    - An origin defines the scope of authority or privilege under which a - resource operates. It is defined in detail in the Origin specification - [RFC6454]. -
    - -
    - - potentially secure origin - -
    -
    - The term potentially secure origin is defined in the - Mixed Content specification [MIX]. -
    - -
    globally unique identifier
    -
    - This term is defined in - Section 4 of - RFC6454 [RFC6454]. - -

    Note: URLs that do not use - hierarchical - elements as naming authorities (for example: blob:, and - data:) have origins which are globally unique identifiers - [URI].

    -
    - -
    request client TLS state
    -
    response TLS state
    -
    - These terms are defined in - Section 2.2 of the - Fetch living standard [FETCH]. -
    - -
    environment settings object
    -
    - Defined in [HTML5]. +

    Likewise, a settings object is considered sufficiently + secure if the algorithm defined in + §4.2 + Is settings object a sufficiently secure context? + returns Sufficiently + Secure when executed upon it.

    embedding document
    - Given a Document A, the embedding - document of A is the Document + Given a Document A, the embedding + document of A is the Document through which A’s browsing context is nested.
    + +

    2.2. Terms defined by reference

    + +

    An origin defines the scope of authority or privilege + under which a resource operates. It boils down to a tuple of scheme, host, + and port. The concept is defined in detail in [RFC6454].

    + +

    A potentially secure origin is an origin that isn’t + insecure a priori, defined in detail in [MIX].

    + +

    The TLS State of a Response is + defined in [FETCH].

    + +

    The following terms are defined in [HTML5]:

    + +
    @@ -290,8 +252,8 @@

    [GEOLOCATION-API] and [MEDIACAPTURE-STREAMS] are historical examples.

  • - The feature provides access to or information about other devices a user - has access to. [DISCOVERY] and [BLUETOOTH] are good examples. + The feature provides access to or information about other devices a user + has access to. [DISCOVERY] and [BLUETOOTH] are good examples.
  • The feature exposes temporary or persistent identifiers, including @@ -367,26 +329,26 @@

    Document a sufficiently secure context?

    -

    Given a Document document, this algorithm returns - Sufficiently Secure if the Document represents a - sufficiently secure context or Insecure otherwise.

    +

    Given a Document document, this algorithm returns + Sufficiently Secure if the Document represents a + sufficiently secure context or Insecure otherwise.

    1. While document corresponds to an iframe srcdoc Document, let document be that Document’s browsing - context’s browsing context container’s Document. + context’s browsing context container’s Document.
    2. - Let origin be the origin of document. + Let origin be the origin of document.
    3. - If document’s active sandboxing flag set has its - sandboxed origin browsing context flag set: + If document’s active sandboxing flag set has its + sandboxed origin browsing context flag set:
      1. - Set origin to the origin of + Set origin to the origin of document’s address.
      @@ -394,9 +356,9 @@

      Let result be the result of executing the §4.2 - Is environment settings object a sufficiently secure context? + Is settings object a sufficiently secure context? algorithm on document’s - incumbent settings object. + incumbent settings object.

    4. If result is Insecure, return @@ -407,11 +369,11 @@

    5. - If document has an embedding document, return the + If document has an embedding document, return the result of executing §4.1 Is Document a sufficiently secure context? on - document’s embedding document with the + document’s embedding document with the ancestors flag set to true.
    6. @@ -433,16 +395,16 @@

      4.2. - Is environment settings object a sufficiently secure context? + Is settings object a sufficiently secure context?

      -

      Given an environment settings object settings, this - algorithm returns Sufficiently Secure if the object represents - a sufficiently secure context, and Insecure otherwise.

      +

      Given an settings object settings, this algorithm returns + Sufficiently Secure if the object represents a sufficiently + secure context, and Insecure otherwise.

      1. - If settings' TLS state is + If settings' TLS state is authenticated, return Sufficiently Secure.
      2. @@ -450,7 +412,7 @@

      3. - Let origin be settings' origin. + Let origin be settings' origin.
      4. If the result of executing the §4.3 @@ -484,13 +446,13 @@

        A user agent MAY choose to extend this trust to other, vendor-specific URL schemes like app: or chrome-extension:.

        -

        Given an origin origin, the following algorithm returns +

        Given an origin origin, the following algorithm returns Potentially Trustworthy or Not Trustworthy as appropriate.

        1. - If origin is a potentially secure origin, + If origin is a potentially secure origin, return Potentially Trustworthy.

          Note: The origin of blob: and filesystem: URLs @@ -618,7 +580,7 @@

          References

          Normative References

          [FETCH]
          Anne van Kesteren. Fetch. Living Standard. URL: http://fetch.spec.whatwg.org/
          [MIX]
          Mike West. Mixed Content. ED. URL: https://w3c.github.io/webappsec/specs/mixedcontent/
          [RFC4632]
          Vince Fuller; Tony Li. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. RFC. URL: http://www.ietf.org/rfc/rfc4632.txt
          [RFC6454]
          Adam Barth. The Web Origin Concept. RFC. URL: http://www.ietf.org/rfc/rfc6454.txt
          [RFC6761]
          Stuart Cheshire; Marc Krochmal. Special-Use Domain Names. RFC. URL: http://www.ietf.org/rfc/rfc6761.txt
          [RFC6890]
          Michelle Cotton; et al. Special-Purpose IP Address Registries. RFC. URL: http://www.ietf.org/rfc/rfc6890.txt
          [html5]
          Robin Berjon; et al. HTML5. 28 October 2014. REC. URL: http://www.w3.org/TR/html5/
          [rfc2119]
          S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt

          Informative References

          [BLUETOOTH]
          Jeffrey Yasskin; Vincent Scheib. Web Bluetooth. URL: https://webbluetoothcg.github.io/web-bluetooth/
          [COMCAST]
          David Kravets. Comcast Wi-Fi serving self-promotional ads via JavaScript injection. URL: http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
          [CREDENTIAL-MANAGEMENT]
          Mike West. Credential Management. ED. URL: https://w3c.github.io/webappsec/specs/credentialmanagement/
          [DISCOVERY]
          Rich Tibbett. Network Service Discovery. URL: http://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
          [POWERFUL-NEW-FEATURES]
          Chrome Security Team. Prefer Secure Origins For Powerful New Features. URL: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
          [RFC7258]
          Stephen Farrell; Hannes Tschofenig. Pervasive Monitoring Is an Attack. RFC. URL: http://www.ietf.org/rfc/rfc7258.txt
          [URI]
          T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. URL: http://www.ietf.org/rfc/rfc3986.txt
          [VERIZON]
          Mark Bergen; Alex Kantrowitz. Verizon looks to target its mobile subscribers with ads. URL: http://adage.com/article/digital/verizon-target-mobile-subscribers-ads/293356/
          [encrypted-media]
          David Dorwin; et al. Encrypted Media Extensions. 28 August 2014. WD. URL: http://www.w3.org/TR/encrypted-media/
          [geolocation-API]
          Andrei Popescu. Geolocation API Specification. 24 October 2013. REC. URL: http://www.w3.org/TR/geolocation-API/
          [mediacapture-streams]
          Daniel Burnett; et al. Media Capture and Streams. 3 September 2013. WD. URL: http://www.w3.org/TR/mediacapture-streams/
          [service-workers]
          Alex Russell; Jungkee Song. Service Workers. 8 May 2014. WD. URL: http://www.w3.org/TR/service-workers/

          Index

          • conformant server, Unnumbered section
          • conformant user agent, Unnumbered section
          • embedding document, 2.2
          • environment settings object, 2.2
          • globally unique identifier, 2.2
          • loopback special-purpose IP address range, 2.1
          • origin, 2.2
          • potentially secure, 2.2
          • potentially secure origin, 2.2
          • powerful feature, 2.1
          • request client TLS state, 2.2
          • response TLS state, 2.2
          • sufficiently secure context, 2.1
          • tls state, 2.2

          Issues Index

          We need to distinguish between legacy features like cookies, +

          References

          Normative References

          [FETCH]
          Anne van Kesteren. Fetch. Living Standard. URL: http://fetch.spec.whatwg.org/
          [MIX]
          Mike West. Mixed Content. ED. URL: https://w3c.github.io/webappsec/specs/mixedcontent/
          [RFC4632]
          Vince Fuller; Tony Li. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. RFC. URL: http://www.ietf.org/rfc/rfc4632.txt
          [RFC6454]
          Adam Barth. The Web Origin Concept. RFC. URL: http://www.ietf.org/rfc/rfc6454.txt
          [RFC6761]
          Stuart Cheshire; Marc Krochmal. Special-Use Domain Names. RFC. URL: http://www.ietf.org/rfc/rfc6761.txt
          [html5]
          Robin Berjon; et al. HTML5. 28 October 2014. REC. URL: http://www.w3.org/TR/html5/
          [rfc2119]
          S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt

          Informative References

          [BLUETOOTH]
          Jeffrey Yasskin; Vincent Scheib. Web Bluetooth. URL: https://webbluetoothcg.github.io/web-bluetooth/
          [COMCAST]
          David Kravets. Comcast Wi-Fi serving self-promotional ads via JavaScript injection. URL: http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
          [CREDENTIAL-MANAGEMENT]
          Mike West. Credential Management. ED. URL: https://w3c.github.io/webappsec/specs/credentialmanagement/
          [DISCOVERY]
          Rich Tibbett. Network Service Discovery. URL: http://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
          [POWERFUL-NEW-FEATURES]
          Chrome Security Team. Prefer Secure Origins For Powerful New Features. URL: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
          [RFC7258]
          Stephen Farrell; Hannes Tschofenig. Pervasive Monitoring Is an Attack. RFC. URL: http://www.ietf.org/rfc/rfc7258.txt
          [VERIZON]
          Mark Bergen; Alex Kantrowitz. Verizon looks to target its mobile subscribers with ads. URL: http://adage.com/article/digital/verizon-target-mobile-subscribers-ads/293356/
          [encrypted-media]
          David Dorwin; et al. Encrypted Media Extensions. 28 August 2014. WD. URL: http://www.w3.org/TR/encrypted-media/
          [geolocation-API]
          Andrei Popescu. Geolocation API Specification. 24 October 2013. REC. URL: http://www.w3.org/TR/geolocation-API/
          [mediacapture-streams]
          Daniel Burnett; et al. Media Capture and Streams. 3 September 2013. WD. URL: http://www.w3.org/TR/mediacapture-streams/
          [service-workers]
          Alex Russell; Jungkee Song. Service Workers. 8 May 2014. WD. URL: http://www.w3.org/TR/service-workers/

          Index

          Issues Index

          We need to distinguish between legacy features like cookies, localStorage, IndexedDB, etc, which all persist state (and potentially identifiers) across browsing sessions. They’re certainly not features we can reasonably limit to secure contexts in the forseeable future. diff --git a/specs/powerfulfeatures/index.src.html b/specs/powerfulfeatures/index.src.html index 2508644d..0db0b843 100644 --- a/specs/powerfulfeatures/index.src.html +++ b/specs/powerfulfeatures/index.src.html @@ -24,7 +24,7 @@

          Requirements for Powerful Features

          ██ ██ ██ ██ ██████ ██ ██ ███████ ██ ██ ██████ --> 
           [
@@ -56,6 +56,13 @@ 
          Requirements for Powerful Features
          
     "shortname": "html5",
     "level": 0
   },
+  {
+    "linkingText": "origin",
+    "type": "dfn",
+    "url": "https://tools.ietf.org/html/rfc6454#section-3.2",
+    "shortname": "RFC6454",
+    "level": 0
+  },
   {
     "linkingText": "nested through",
     "type": "dfn",
@@ -63,6 +70,13 @@ 
          Requirements for Powerful Features
          
     "shortname": "html5",
     "level": 0
   },
+  {
+    "linkingText": "potentially secure origin",
+    "type": "dfn",
+    "url": "http://www.w3.org/TR/mixed-content/#potentially-secure-origin",
+    "shortname": "MIX",
+    "level": 0
+  },
   {
     "linkingText": "sandboxed origin browsing context flag",
     "type": "dfn",
@@ -77,6 +91,20 @@ 
          Requirements for Powerful Features
          
     "shortname": "html5",
     "level": 0
   },
+  {
+    "linkingText": "settings object",
+    "type": "dfn",
+    "url": "http://www.w3.org/TR/html5/webappapis.html#settings-object",
+    "shortname": "html5",
+    "level": 0
+  },
+  {
+    "linkingText": "tls state",
+    "type": "dfn",
+    "url": "https://fetch.spec.whatwg.org/#concept-response-tls-state",
+    "shortname": "FETCH",
+    "level": 0
+  },
   {
     "linkingText": "top-level browsing context",
     "type": "dfn",
@@ -87,7 +115,7 @@ 
          Requirements for Powerful Features
          
 ]
 
           [
@@ -97,6 +125,13 @@ 
          Requirements for Powerful Features
          
     "url": "http://www.w3.org/TR/html5/dom.html#the-document-object",
     "shortname": "html5",
     "level": 0
+  },
+  {
+    "linkingText": "response",
+    "type": "interface",
+    "url": "https://fetch.spec.whatwg.org/#response-class",
+    "shortname": "FETCH",
+    "level": 0
   }
 ]
          @@ -143,88 +178,23 @@

          Key Concepts and Terminology

          Terms defined by this specification

          -
          powerful feature
          +
          powerful feature
          - The considerations around categorizing a feature as - powerful are explored in more detail in - [[#is-feature-powerful]]. + Defined in [[#is-feature-powerful]].
          sufficiently secure context
          - A {{Document}} or environment settings object is considered - sufficiently secure to use powerful features if - and only if the algorithm defined in [[#document-sufficiently-secure]] - or [[#settings-sufficiently-secure]], respectively, returns + A {{Document}} is considered sufficiently secure if + the algorithm defined in [[#document-sufficiently-secure]] returns Sufficiently Secure when executed upon it. - The goal of the normative algorithms noted above is that - powerful features only be enabled in the - context of an origin with one or more of the following - characteristics: - -
            -
          1. - The scheme component is either https, wss, - or file. -
            2. -
          2. - The host component is or falls within "localhost." [[!RFC6761]] -
            3. -
          3. - The host component is an IP address within a - loopback special-purpose IP address range (i.e. - 127.0.0.0/8 or ::1/128) [[!RFC6890]]. -
            4. -
          -
          -
          - -

          Terms defined by reference

          -
          -
          origin
          -
          - An origin defines the scope of authority or privilege under which a - resource operates. It is defined in detail in the Origin specification - [[!RFC6454]]. -
          - -
          - - potentially secure origin - -
          -
          - The term potentially secure origin is defined in the - Mixed Content specification [[!MIX]]. -
          - -
          globally unique identifier
          -
          - This term is defined in - Section 4 of - RFC6454 [[!RFC6454]]. - - Note: URLs that do not use - hierarchical - elements as naming authorities (for example: blob:, and - data:) have origins which are globally unique identifiers - [[URI]]. -
          - -
          request client TLS state
          -
          response TLS state
          -
          - These terms are defined in - Section 2.2 of the - Fetch living standard [[!FETCH]]. -
          - -
          environment settings object
          -
          - Defined in [[!HTML5]]. + Likewise, a settings object is considered sufficiently + secure if the algorithm defined in + [[#settings-sufficiently-secure]] returns Sufficiently + Secure when executed upon it.
          embedding document
          @@ -235,6 +205,33 @@

          Terms defined by reference

          context is nested.
          + +

          Terms defined by reference

          + + An origin defines the scope of authority or privilege + under which a resource operates. It boils down to a tuple of scheme, host, + and port. The concept is defined in detail in [[!RFC6454]]. + + A potentially secure origin is an origin that isn't + insecure a priori, defined in detail in [[!MIX]]. + + The TLS State of a {{Response}} is + defined in [[!FETCH]]. + + The following terms are defined in [[!HTML5]]: + +
          @@ -262,8 +259,8 @@

          [[GEOLOCATION-API]] and [[MEDIACAPTURE-STREAMS]] are historical examples.

        2. - The feature provides access to or information about other devices a user - has access to. [[DISCOVERY]] and [[BLUETOOTH]] are good examples. + The feature provides access to or information about other devices a user + has access to. [[DISCOVERY]] and [[BLUETOOTH]] are good examples.
        3. The feature exposes temporary or persistent identifiers, including @@ -401,12 +398,12 @@

          - Is environment settings object a sufficiently secure context? + Is settings object a sufficiently secure context?

          - Given an environment settings object settings, this - algorithm returns Sufficiently Secure if the object represents - a sufficiently secure context, and Insecure otherwise. + Given an settings object settings, this algorithm returns + Sufficiently Secure if the object represents a sufficiently + secure context, and Insecure otherwise.