diff --git a/specs/mixedcontent/index.html b/specs/mixedcontent/index.html index b1169694..c88c40b4 100644 --- a/specs/mixedcontent/index.html +++ b/specs/mixedcontent/index.html @@ -154,7 +154,7 @@

4.5 User Controls
  • 5 Algorithms -
  • Index -
  • Issues Index +
  • Index @@ -236,8 +235,8 @@

    A resource is said to be mixed content if the resource’s - origin is insecure, and the browsing - context responsible for loading it restricts mixed content. + origin is insecure, and the the context + responsible for loading it restricts mixed content.
    The image http://example.com/image.png is mixed @@ -317,14 +316,6 @@

    A URL whose origin is insecure is itself considered to be insecure.

    -
    - unsecured context -
    -
    - A browsing context is called unsecured if it does - not restrict mixed content. -
    -
    deprecated TLS-protection @@ -430,6 +421,8 @@

    request client

    request context
    request context frame type
    +
    request client authentication state
    +
    response authentication state
    These terms are defined in Section 2.2 of the @@ -443,6 +436,11 @@

    Section 2.3 of the Fetch living standard. [FETCH]

    + +
    environment settings object
    +
    + Defined in [HTML5]. +
    @@ -609,11 +607,13 @@

    -

    If a browsing context restricts mixed content, then user - agents MUST adhere to the following requirements when fetching - resources in response to its requests (including not only requests for a - Document’s subresources, but also requests made from - Workers, SharedWorkers, ServiceWorkers and so on):

    +

    If a browsing context’s incumbent settings object restricts + mixed content, or the relevant settings object for a script + restricts mixed content, then user agents MUST adhere to the + following requirements when fetching resources in response to + requests (including not only requests for a Document’s + subresources, but also requests made from Workers, SharedWorkers, + ServiceWorkers and so on):

    1. @@ -625,9 +625,9 @@

      Responses to requests for blockable resources from - an insecure origin MUST not be delivered to the requesting - browsing context, but instead MUST return a synthetically - generated network error response. + an insecure origin MUST not be delivered to the request + client, but instead MUST return a synthetically generated network + error response.

    2. @@ -657,10 +657,10 @@

      4.2 Script APIs

      -

      If the relevant settings object for a script script has a - responsible browsing context which restricts mixed content, - then user agents MUST adhere to the following requirements when executing - the following APIs in the context of script:

      +

      If the relevant settings object for a script script + restricts mixed content, then user agents MUST adhere to the + following requirements when executing the following APIs in the context + of script:

      1. When processing XMLHttpRequest’s @@ -686,10 +686,10 @@

        4.3 Form Submission

        -

        If a browsing context restricts mixed content, then user - agents MAY choose to warn users of the presence of one or more - form elements with action attributes - whose values are insecure URLs.

        +

        If a Document's incumbent settings object restricts mixed + content, then user agents MAY choose to warn users of the presence of + one or more form elements with action + attributes whose values are insecure URLs.

        Note: Chrome, for example, currently gives the same UI treatment to a page with an insecure form action as it does for a page that displays an insecure @@ -697,8 +697,9 @@

        Further, user agents MAY optionally treat form submissions in the top-level browsing context from a browsing context - which restricts mixed content as a request for blockable - content to protect users from accidental data leakage.

        + whose incumbent settings object restricts mixed content as a + request for blockable content to protect users from accidental data + leakage.

        @@ -746,25 +747,28 @@

        5 Algorithms

        -

        5.1 - Does browsing context restrict mixed content? -

        - -

        Given a browsing context context, the user agent - determines whether context - restricts mixed content - via the following algorithm, which returns true if - context restricts mixed content, and false - otherwise.

        +

        5.1 + Does settings object restrict mixed content? +

        + +

        Both documents and workers have environment settings objects which + may be examined according to the following algorithm in order to determine + whether they restrict + mixed content. This algorithm returns restricts mixed + content or does not restrict mixed content, as + appropriate.

        + +

        Given an environment settings object settings:

        1. - If context is TLS-protected, and that - TLS-protection is neither weak nor deprecated, then return - true. + If settings' authentication state is + authenticated, then return restricts mixed + content.
        2. - If context is a nested browsing context, then: + If settings has a responsible browsing context + context that is a nested browsing context, then:
          1. Let ancestorList be the list of all @@ -774,15 +778,21 @@

            ancestorContext in ancestorList:
              -
            1. If ancestorContext is TLS-protected, and - that TLS-protection is neither weak nor deprecated, - then return true.
              2. +
            2. + Let ancestorSettings be ancestorContext’s + incumbent settings object. +
              3. +
            3. + If ancestorSettings' authentication state is + authenticated, then return restricts mixed + content. +

          3. -
        3. Return false.
          4. +
        4. Return does not restrict mixed content.
        @@ -842,17 +852,13 @@

        frame type be request’s context frame type.

        2. -
      2. - Let browsing context be request’s - client’s responsible browsing context. -
      3. Let origin be the origin of request’s URL.
      4. - If browsing context does not restrict mixed content, - return allowed. + If request’s client does not restrict mixed + content, return allowed.
      5. If request’s context frame type is @@ -902,12 +908,8 @@

      6. - Let browsing context be the client’s - responsible browsing context. -
        7. -
      7. - If browsing context does not restrict mixed content, - return allowed. + If request’s client does not restrict mixed + content, return allowed.
      8. Let context be the request context of @@ -920,30 +922,15 @@

      9. - If the response is not TLS-protected, return - blocked. - -

        Start using the TLS State field whenever Fetch - defines it.

        -
        10. -
      10. - If the response is only weakly TLS-protected, return - blocked. - -

        Note: If a user agent is configured to reject weakly - TLS-protected resources, we’ll never hit this condition, as - step 6 of the Fetch - algorithm would have returned a network error. [FETCH]

        -
        11. -
      11. - If the response’s TLS-protection is deprecated, return - blocked. - -

        Note: This covers cases in which the TLS handshake succeeds, and the - resource exceeds the definition of weakly TLS-protected, but - the user agent chooses to hold it to a higher standard. The definition - of deprecated TLS-protection has some examples of these kinds - of scenarios.

        + If response’s authentication state is not + authenticated, return blocked. + +

        Note: This covers both cases in which unauthenticated resources are + requested, as well as cases in which the TLS handshake succeeds, and + the resource exceeds the definition of weakly TLS-protected, + but the user agent chooses to hold it to a higher standard. The + definition of deprecated TLS-protection has some examples of + these kinds of scenarios.

      3. @@ -1105,8 +1092,8 @@

      secure is false, but entry script’s relevant settings - object’s responsible browsing context restricts mixed - content, then throw a SecurityError exception. + object’s restricts mixed content, then throw a + SecurityError exception.

    • @@ -1241,6 +1228,7 @@

  • a priori insecure URL, 2.1
  • authenticated browsing context, 2.1
  • authenticated origin, 2.1 +
  • authentication state, 2.2
  • blockable, 3.2
  • blockable content, 3.2
  • blockable request contexts, 3.2 @@ -1250,6 +1238,7 @@

  • context, 2.2
  • deprecated, 2.1
  • deprecated TLS-protection, 2.1 +
  • environment settings object, 2.2
  • fetch, 2.2
  • frame type, 2.2
  • globally unique identifier, 2.2 @@ -1269,18 +1258,18 @@

  • potentially secure URL, 2.1
  • request, 2.2
  • request client, 2.2 +
  • request client authentication state, 2.2
  • request context, 2.2
  • request context frame type, 2.2
  • response, 2.2 -
  • restrict mixed content, 5.1 -
  • restricts mixed content, 5.1 +
  • response authentication state, 2.2 +
  • restrict + mixed content, 5.1 +
  • restricts mixed content, 5.1
  • TLS-protected, 2.2 -
  • unsecured context, 2.1
  • weak, 2.2
  • weakly TLS-protected, 2.2 -

    Issues Index

    Start using the TLS State field whenever Fetch - defines it. ↵
    \ No newline at end of file diff --git a/specs/mixedcontent/index.src.html b/specs/mixedcontent/index.src.html index 43f3fb0b..19e7c03e 100644 --- a/specs/mixedcontent/index.src.html +++ b/specs/mixedcontent/index.src.html @@ -9,7 +9,7 @@

    Mixed Content

    Editor: Mike West, Google Inc., mkwst@google.com Group: webappsec Abstract: This specification describes how user agents should handle rendering and execution of content loaded over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document. -Link Defaults: HTML5 (dfn) plugin / browsing context / parent browsing context / nested browsing contexts / top-level browsing context / plugin document / frame / sandboxing flag set / ancestor / navigated / entry settings object / active document / global object / sandboxed origin browsing context flag / an iframe srcdoc document / browsing context container / relevant settings object for a script / responsible browsing context +Link Defaults: HTML5 (dfn) plugin / browsing context / parent browsing context / nested browsing contexts / top-level browsing context / plugin document / frame / sandboxing flag set / ancestor / navigated / entry settings object / active document / global object / sandboxed origin browsing context flag / an iframe srcdoc document / browsing context container / relevant settings object for a script / responsible browsing context / incumbent settings object Link Defaults: HTML5 (interface) document Link Defaults: HTML5 (element) audio / iframe / video / source / track / script Version History: https://github.com/w3c/webappsec/commits/master/specs/mixedcontent/index.src.html @@ -92,8 +92,8 @@

    Terms defined by this specification

    A resource is said to be mixed content if the resource's - origin is insecure, and the browsing - context responsible for loading it restricts mixed content. + origin is insecure, and the the context + responsible for loading it restricts mixed content.
    The image http://example.com/image.png is mixed @@ -173,14 +173,6 @@

    Terms defined by this specification

    A URL whose origin is insecure is itself considered to be insecure.
    -
    - unsecured context -
    -
    - A browsing context is called unsecured if it does - not restrict mixed content. -
    -
    deprecated TLS-protection @@ -281,6 +273,8 @@

    Terms defined by reference

    request client
    request context
    request context frame type
    +
    request client authentication state
    +
    response authentication state
    These terms are defined in Section 2.2 of the @@ -294,6 +288,11 @@

    Terms defined by reference

    Section 2.3 of the Fetch living standard. [[!FETCH]]
    + +
    environment settings object
    +
    + Defined in [[!HTML5]]. +
    @@ -464,11 +463,13 @@

    Resource Fetching

    of the risk (for instance, presenting the user with a confirmation screen she must click through). - If a browsing context restricts mixed content, then user - agents MUST adhere to the following requirements when fetching - resources in response to its requests (including not only requests for a - Document's subresources, but also requests made from - Workers, SharedWorkers, ServiceWorkers and so on): + If a browsing context's incumbent settings object restricts + mixed content, or the relevant settings object for a script + restricts mixed content, then user agents MUST adhere to the + following requirements when fetching resources in response to + requests (including not only requests for a Document's + subresources, but also requests made from Workers, SharedWorkers, + ServiceWorkers and so on):
    1. @@ -480,9 +481,9 @@

      Resource Fetching

    2. Responses to requests for blockable resources from - an insecure origin MUST not be delivered to the requesting - browsing context, but instead MUST return a synthetically - generated network error response. + an insecure origin MUST not be delivered to the request + client, but instead MUST return a synthetically generated network + error response.
    3. @@ -512,10 +513,10 @@

      Resource Fetching

      Script APIs

      - If the relevant settings object for a script script has a - responsible browsing context which restricts mixed content, - then user agents MUST adhere to the following requirements when executing - the following APIs in the context of script: + If the relevant settings object for a script script + restricts mixed content, then user agents MUST adhere to the + following requirements when executing the following APIs in the context + of script:
      1. When processing XMLHttpRequest's @@ -541,10 +542,10 @@

        Script APIs

        Form Submission

        - If a browsing context restricts mixed content, then user - agents MAY choose to warn users of the presence of one or more - form elements with action attributes - whose values are insecure URLs. + If a {{Document}}'s incumbent settings object restricts mixed + content, then user agents MAY choose to warn users of the presence of + one or more form elements with action + attributes whose values are insecure URLs. Note: Chrome, for example, currently gives the same UI treatment to a page with an insecure form action as it does for a page that displays an insecure @@ -552,8 +553,9 @@

        Form Submission

        Further, user agents MAY optionally treat form submissions in the top-level browsing context from a browsing context - which restricts mixed content as a request for blockable - content to protect users from accidental data leakage. + whose incumbent settings object restricts mixed content as a + request for blockable content to protect users from accidental data + leakage.
      @@ -609,25 +611,28 @@

      User Controls

      Algorithms

      -

      - Does browsing context restrict mixed content? +

      + Does settings object restrict mixed content?

      - Given a browsing context context, the user agent - determines whether context - restricts mixed content - via the following algorithm, which returns true if - context restricts mixed content, and false - otherwise. + Both documents and workers have environment settings objects which + may be examined according to the following algorithm in order to determine + whether they restrict + mixed content. This algorithm returns restricts mixed + content or does not restrict mixed content, as + appropriate. + + Given an environment settings object settings:
      1. - If context is TLS-protected, and that - TLS-protection is neither weak nor deprecated, then return - true. + If settings' authentication state is + authenticated, then return restricts mixed + content.
      2. - If context is a nested browsing context, then: + If settings has a responsible browsing context + context that is a nested browsing context, then:
        1. Let ancestorList be the list of all @@ -637,15 +642,21 @@

          For each ancestorContext in ancestorList:
            -
          1. If ancestorContext is TLS-protected, and - that TLS-protection is neither weak nor deprecated, - then return true.
            2. +
          2. + Let ancestorSettings be ancestorContext's + incumbent settings object. +
            3. +
          3. + If ancestorSettings' authentication state is + authenticated, then return restricts mixed + content. +

        3. -
      3. Return false.
        4. +
      4. Return does not restrict mixed content.
      @@ -705,17 +716,13 @@

      Let frame type be request's context frame type.

      4. -
    4. - Let browsing context be request's - client's responsible browsing context. -
    5. Let origin be the origin of request's URL.
    6. - If browsing context does not restrict mixed content, - return allowed. + If request's client does not restrict mixed + content, return allowed.
    7. If request's context frame type is @@ -765,12 +772,8 @@

      1. - Let browsing context be the client's - responsible browsing context. -
        2. -
      2. - If browsing context does not restrict mixed content, - return allowed. + If request's client does not restrict mixed + content, return allowed.
      3. Let context be the request context of @@ -783,30 +786,15 @@

        1. - If the response is not TLS-protected, return - blocked. - - ISSUE: Start using the TLS State field whenever Fetch - defines it. -
          2. -
        2. - If the response is only weakly TLS-protected, return - blocked. - - Note: If a user agent is configured to reject weakly - TLS-protected resources, we'll never hit this condition, as - step 6 of the Fetch - algorithm would have returned a network error. [[!FETCH]] -
          3. -
        3. - If the response's TLS-protection is deprecated, return - blocked. - - Note: This covers cases in which the TLS handshake succeeds, and the - resource exceeds the definition of weakly TLS-protected, but - the user agent chooses to hold it to a higher standard. The definition - of deprecated TLS-protection has some examples of these kinds - of scenarios. + If response's authentication state is not + authenticated, return blocked. + + Note: This covers both cases in which unauthenticated resources are + requested, as well as cases in which the TLS handshake succeeds, and + the resource exceeds the definition of weakly TLS-protected, + but the user agent chooses to hold it to a higher standard. The + definition of deprecated TLS-protection has some examples of + these kinds of scenarios.

        4. @@ -974,8 +962,8 @@

        Modifications to WebSockets

        If secure is false, but entry script's relevant settings - object's responsible browsing context restricts mixed - content, then throw a SecurityError exception. + object's restricts mixed content, then throw a + SecurityError exception.