From f33451dfe7eac776f51940a5f3916f5602b2412c Mon Sep 17 00:00:00 2001 From: jeisinger Date: Mon, 3 Oct 2016 04:05:25 +0200 Subject: [PATCH] Add a section about CSS and referrers (#5) (#68) * Add a section about CSS and referrers (#5) * updates * add text about link/referrerpolicy * Address Anne's comments * also mention style attributes --- index.html | 2347 ++++++++++++++++++++++++++++++------------------ index.src.html | 25 + 2 files changed, 1510 insertions(+), 862 deletions(-) diff --git a/index.html b/index.html index d72587b..8b2c99b 100644 --- a/index.html +++ b/index.html @@ -1,55 +1,320 @@ + Referrer Policy - - + + + + + -
-

-

Referrer Policy

-

Editor’s Draft,

+

+

Referrer Policy

+

Editor’s Draft,

This version:
https://w3c.github.io/webappsec-referrer-policy/ -
Latest version: +
Latest published version:
http://www.w3.org/TR/referrer-policy/
Version History:
https://github.com/w3c/webappsec-referrer-policy/commits/master/index.src.html
Feedback: -
public-webappsec@w3.org with subject line “[REFERRER] … message topic …” (archives) +
public-webappsec@w3.org with subject line “[REFERRER] … message topic …” (archives)
Issue Tracking:
GitHub
Editors: @@ -1077,7 +1440,7 @@

-

Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

+

Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

Abstract

@@ -1091,36 +1454,36 @@

https://github.com/w3c/webappsec.

-

The (archived) public mailing list public-webappsec@w3.org (see instructions) +

The (archived) public mailing list public-webappsec@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “REFERRER” in the subject, preferably like this: “[REFERRER] …summary of comment…”

-

This document was produced by the Web Application Security Working Group.

+

This document was produced by the Web Application Security Working Group.

This document was produced by a group operating under - the 5 February 2004 W3C Patent Policy. - W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; + the 5 February 2004 W3C Patent Policy. + W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. - An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

-

This document is governed by the 1 September 2015 W3C Process Document.

+ An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

+

This document is governed by the 1 September 2015 W3C Process Document.

-

Table of Contents

-
- -
+ +

1. Introduction

@@ -1226,53 +1590,53 @@

2. Key Concepts and Terminology

-
referrer policy +
referrer policy
- A referrer policy modifies the algorithm used to populate the Referer header when fetching subresources, + A referrer policy modifies the algorithm used to populate the Referer header when fetching subresources, prefetching, or performing navigations. This document defines the various - behaviors for each referrer policy. -

Every environment settings object has an algorithm for obtaining a referrer policy, which is used by default for all requests with that environment settings object as their request + behaviors for each referrer policy. +

Every environment settings object has an algorithm for obtaining a referrer policy, which is used by default for all requests with that environment settings object as their request client.

-
same-origin request +
same-origin request
A Request request is a same-origin request if request’s origin and the origin of request’s url are the same. -
cross-origin request -
A Request is a cross-origin request if it is not same-origin. +
cross-origin request +
A Request is a cross-origin request if it is not same-origin.

3. Referrer Policies

-

A referrer policy is the empty string, "no-referrer", +

A referrer policy is the empty string, "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", or "unsafe-url".

-
enum ReferrerPolicy {
-  "",
-  "no-referrer",
-  "no-referrer-when-downgrade",
-  "same-origin",
-  "origin",
-  "strict-origin",
-  "origin-when-cross-origin",
-  "strict-origin-when-cross-origin",
-  "unsafe-url"
+
enum ReferrerPolicy {
+  "",
+  "no-referrer",
+  "no-referrer-when-downgrade",
+  "same-origin",
+  "origin",
+  "strict-origin",
+  "origin-when-cross-origin",
+  "strict-origin-when-cross-origin",
+  "unsafe-url"
 };
 

-    
Each possible referrer policy is explained below. A detailed
-  algorithm for evaluating their effect is given in the §5 Integration with Fetch and §7 Algorithms sections.

+    
Each possible referrer policy is explained below. A detailed
+  algorithm for evaluating their effect is given in the §5 Integration with Fetch and §8 Algorithms sections.

     
Note: The referrer policy for an environment settings object provides a
   default baseline policy for requests when that environment settings
   object is used as a request client. This policy may be tightened
   for specific requests via mechanisms like the noreferrer link type.

-    
3.1. "no-referrer"

-    
The simplest policy is "no-referrer", which specifies
+    
3.1. "no-referrer"

+    
The simplest policy is "no-referrer", which specifies
   that no referrer information is to be sent along with requests made from a
   particular request client to any origin. The header will be
   omitted entirely.

-    
 If a document at https://example.com/page.html sets a policy of "no-referrer", then navigations to https://example.com/ (or any other URL) would send no Referer header. 

-    
3.2. "no-referrer-when-downgrade"

-    
The "no-referrer-when-downgrade" policy sends a full URL
+    
 If a document at https://example.com/page.html sets a policy of "no-referrer", then navigations to https://example.com/ (or any other URL) would send no Referer header. 

+    
3.2. "no-referrer-when-downgrade"

+    
The "no-referrer-when-downgrade" policy sends a full URL
   along with requests from a TLS-protected environment settings
   object to a a priori authenticated URL, and requests from request clients which are not TLS-protected to any origin.

     
Requests from TLS-protected request clients to non-a
@@ -1280,36 +1644,36 @@ 
Referer HTTP header will not be
   sent.

     

-      If a document at https://example.com/page.html sets a policy of "no-referrer-when-downgrade", then navigations to https://not.example.com/ would send a Referer HTTP header with a value of https://example.com/page.html, as neither resource’s origin is an
+      If a document at https://example.com/page.html sets a policy of "no-referrer-when-downgrade", then navigations to https://not.example.com/ would send a Referer HTTP header with a value of https://example.com/page.html, as neither resource’s origin is an
     non-a priori authenticated URL. 
      
Navigations from that same page to http://not.example.com/ would send no Referer header.

     

     
This is a user agent’s default behavior, if no policy is otherwise specified.

-    
3.3. "same-origin"

-    
The "same-origin" policy specifies that a
+    
3.3. "same-origin"

+    
The "same-origin" policy specifies that a
   full URL, stripped for use as a referrer, is sent as
-  referrer information when making same-origin requests from a particular request client.

-    
Cross-origin requests, on the other hand, will contain no
+  referrer information when making same-origin requests from a particular request client.

+    
Cross-origin requests, on the other hand, will contain no
   referrer information. A Referer HTTP header will not be
   sent.

     

-      If a document at https://example.com/page.html sets a policy of "same-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html. 
+      If a document at https://example.com/page.html sets a policy of "same-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html. 
      
Navigations from that same page to https://not.example.com/ would send no Referer header.

     

-    
3.4. "origin"

-    
The "origin" policy specifies that only the ASCII serialization of the origin of the request client is sent as referrer information
-  when making both same-origin requests and cross-origin requests from a particular request client.

+    
3.4. "origin"

+    
The "origin" policy specifies that only the ASCII serialization of the origin of the request client is sent as referrer information
+  when making both same-origin requests and cross-origin requests from a particular request client.

     
Note: The serialization of an origin looks like https://example.com. To ensure that a valid URL is sent in the
   `Referer` header, user agents will append a U+002F SOLIDUS
   ("/") character to the origin (e.g. https://example.com/).

-    
Note: The "origin" policy causes the origin of HTTPS
+    
Note: The "origin" policy causes the origin of HTTPS
   referrers to be sent over the network as part of unencrypted HTTP requests.
-  The "strict-origin" policy addresses this concern.

-    
 If a document at https://example.com/page.html sets a policy of "origin", then navigations to any origin would send a Referer header with a value
+  The "strict-origin" policy addresses this concern.

+    
 If a document at https://example.com/page.html sets a policy of "origin", then navigations to any origin would send a Referer header with a value
     of https://example.com/, even to URLs that are not a
     priori authenticated URLs. 

-    
3.5. "strict-origin"

-    
The "strict-origin" policy sends the ASCII serialization of the origin of the request client when making requests:

+    
3.5. "strict-origin"

+    
The "strict-origin" policy sends the ASCII serialization of the origin of the request client when making requests:

     

     
Note: The policy’s name doesn’t lie; it is unsafe. This policy will leak
   origins and paths from TLS-protected resources to insecure origins.
   Carefully consider the impact of setting such a policy for potentially
   sensitive documents.

     
3.9. The empty string

-    
The empty string "" corresponds to no referrer policy, causing a
-  fallback to a referrer policy defined elsewhere, or in the case where
-  no such higher-level policy is available, defaulting to "no-referrer-when-downgrade". This defaulting happens in
-  the §7.3 Determine request’s Referrer algorithm.

-    
 Given a HTML a element without any declared referrerpolicy attribute, its referrer policy is the empty string. Thus, navigation
+    
The empty string "" corresponds to no referrer policy, causing a
+  fallback to a referrer policy defined elsewhere, or in the case where
+  no such higher-level policy is available, defaulting to "no-referrer-when-downgrade". This defaulting happens in
+  the §8.3 Determine request’s Referrer algorithm.

+    
 Given a HTML a element without any declared referrerpolicy attribute, its referrer policy is the empty string. Thus, navigation
     requests initiated by clicking on that a element will be sent
-    
     with the referrer
-    policy of the a element’s node document. If that Document has the empty string as its referrer policy, the §7.3 Determine request’s Referrer algorithm will treat the empty
-    string the same as "no-referrer-when-downgrade". 

+    policy of the a element’s node document. If that Document has the empty string as its referrer policy, the §8.3 Determine request’s Referrer algorithm will treat the empty
+    string the same as "no-referrer-when-downgrade".

4. Referrer Policy Delivery

@@ -1387,21 +1750,21 @@

  • Via the Referrer-Policy HTTP header (defined in §4.1 Delivery via Referrer-Policy header). -
  • Via a meta element with a name of referrer. +
  • Via a meta element with a name of referrer.
  • Via a referrerpolicy content attribute on an a, area, img, iframe, or link element.
  • Via the noreferrer link relation on an a, area, or link element.
  • Implicitly, via inheritance.

    4.1. Delivery via Referrer-Policy header

    -

    The Referrer-Policy HTTP +

    The Referrer-Policy HTTP header specifies the referrer policy that the user agent applies when determining what referrer information should be included with requests - made, and with browsing contexts created from the context of the protected resource. + made, and with browsing contexts created from the context of the protected resource. The syntax for the name and value of the header are described by the following ABNF grammar:

    -
    "Referrer-Policy:" 1#policy-token
+
    "Referrer-Policy:" 1#policy-token
 
    
-
    policy-token   = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"
+
    policy-token   = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"
 
    
     
    Note: The header name does not share the HTTP Referer header’s misspelling.
    
     
    §5 Integration with Fetch and §6 Integration with HTML describe
@@ -1418,7 +1781,7 @@ 
    
      
    4.2. Delivery via meta
    
      
    This section is not normative.
    
-     
    The HTML Standard defines the referrer keyword for the meta element, which allows setting the referrer
+     
    The HTML Standard defines the referrer keyword for the meta element, which allows setting the referrer
     policy via markup.

    • @@ -1427,31 +1790,32 @@

    referrer policy attributes which applies to several of its elements, for example:

    -
    <a href="http://example.com" referrerpolicy="origin">
    +
    <a href="http://example.com" referrerpolicy="origin">
+

    4.4. Nested browsing contexts

    This section is not normative.

    The HTML Standard and Fetch Standard define how nested browsing contexts that are not created from responses, such as iframe elements with - their srcdoc attribute set, or created from a blob URL, inherit - their referrer policy from the creator browsing context or blob URL.

    + their srcdoc attribute set, or created from a blob URL, inherit + their referrer policy from the creator browsing context or blob URL.

    5. Integration with Fetch

    This section is not normative.

    -

    The Fetch specification calls out to §7.2 Set request’s referrer policy on redirect before Step +

    The Fetch specification calls out to §8.2 Set request’s referrer policy on redirect before Step 13 of the HTTP-redirect fetch, so that a request’s referrer policy can be updated before following a redirect.

    -

    The Fetch specification calls out to §7.3 Determine request’s Referrer as Step 8 of the +

    The Fetch specification calls out to §8.3 Determine request’s Referrer as Step 8 of the Main fetch algorithm, and uses the result to set the request’s referrer property. Fetch is responsible for serializing the URL provided, and setting the `Referer` header on request.

    6. Integration with HTML

    This section is not normative.

    -

    The HTML Standard determines the referrer policy of any response +

    The HTML Standard determines the referrer policy of any response received during navigation or while running a worker, and uses the result to set the resulting Document or WorkerGlobalScope's referrer policy. This is later used by the corresponding environment @@ -1462,29 +1826,46 @@

    [HTML].

    -

    7. Algorithms

    -

    7.1. Parse a referrer policy from a Referrer-Policy header

    -

    Given a Response response, the following steps return a referrer policy according to response’s `Referrer-Policy` header:

    +

    7. Integration with CSS

    +

    The CSS Standard does not specify how it fetches resources referenced from + stylesheets. However, implementations use the URL a given stylesheet was + loaded from as referrer for the requests for resources from that stylesheet.

    +

    Implementations should keep track of a referrer policy for each stylesheet + that should be used to create requests for resources from the respective + stylesheet.

    +

    For external stylesheets, the referrer policy should be "no-referrer-when-downgrade" unless overwritten by an + `Referrer-Policy` header.

    +

    Note: If the stylesheet was loaded via a HTML link element with a + declared referrerpolicy, this referrer policy will not affect the + requests for resources referenced from the stylesheet.

    +

    For inline stylesheets, and styles applied via an style attribute on an element, the referrer policy is the containing Document's + referrer policy. Both the value of the referrer and the value of the + referrer policy should be captured at the time a given request is created.

    +
    +
    +

    8. Algorithms

    +

    8.1. Parse a referrer policy from a Referrer-Policy header

    +

    Given a Response response, the following steps return a referrer policy according to response’s `Referrer-Policy` header:

    1. Let policy-tokens be the result of parsing `Referrer-Policy` in response’s header list.
    2. Let policy be the empty string.
    3. - For each token in policy-tokens, if token is a referrer + For each token in policy-tokens, if token is a referrer policy and token is not the empty string, then set policy to token.

      Note: This algorithm loops over multiple policy values to allow deployment of new policy values with fallbacks for older user - agents, as described in §10.1 Unknown Policy Values.

      + agents, as described in §11.1 Unknown Policy Values.

    4. Return policy.
    -

    7.2. Set request’s referrer policy on redirect

    +

    8.2. Set request’s referrer policy on redirect

    Given a request request and a response actualResponse, this algorithm updates request’s associated referrer policy according to the Referrer-Policy header (if any) in actualResponse.

      -
    1. Let policy be the result of executing §7.1 Parse a referrer policy from a Referrer-Policy header on actualResponse. +
    2. Let policy be the result of executing §8.1 Parse a referrer policy from a Referrer-Policy header on actualResponse.
    3. If policy is not the empty string, then set request’s associated referrer policy to policy.
    -

    7.3. Determine request’s Referrer

    +

    8.3. Determine request’s Referrer

    Given a Request request, we can determine the correct referrer information to send by examining the referrer policy associated with it, as detailed in the following steps, which return either no referrer or a URL:

    @@ -1519,17 +1900,17 @@

    no-referrer", Fetch will not call into this algorithm.

  • Let referrerURL be the result of stripping referrerSource for use as a referrer.
  • Let referrerOrigin be the result of stripping referrerSource for use as a - referrer, with the origin-only flag set to true. + referrer, with the origin-only flag set to true.
  • Execute the statements corresponding to the value of policy:
    -
    "no-referrer" +
    "no-referrer"
    Return no referrer -
    "origin" +
    "origin"
    Return referrerOrigin -
    "unsafe-url" +
    "unsafe-url"
    Return referrerURL. -
    "strict-origin" +
    "strict-origin"
    1. @@ -1541,10 +1922,10 @@

    2. Return referrerOrigin.

    -
    "strict-origin-when-cross-origin" +
    "strict-origin-when-cross-origin"
      -
    1. If request is a same-origin request, then +
    2. If request is a same-origin request, then return referrerURL.
    3. If environment is not null: @@ -1558,21 +1939,21 @@

    4. Return referrerOrigin.

    -
    "same-origin" +
    "same-origin"
      -
    1. If request is a same-origin request, then +
    2. If request is a same-origin request, then return referrerURL.
    3. Otherwise, return no referrer.
    -
    "origin-when-cross-origin" +
    "origin-when-cross-origin"
      -
    1. If request is a cross-origin request, then +
    2. If request is a cross-origin request, then return referrerOrigin.
    3. Otherwise, return referrerURL.
    -
    "no-referrer-when-downgrade" +
    "no-referrer-when-downgrade"
    1. @@ -1585,14 +1966,14 @@

      Return referrerURL.

    -

    Note: Fetch will ensure request’s referrer policy is not the +

    Note: Fetch will ensure request’s referrer policy is not the empty string before calling this algorithm.

    -

    7.4. Strip url for use as a referrer

    +

    8.4. Strip url for use as a referrer

    Certain portions of URLs MUST not be included when sending a URL as the value of a `Referer` header: a URLs fragment, username, and password components should be stripped from the URL before it’s sent out. This - algorithm accepts a origin-only flag, which defaults + algorithm accepts a origin-only flag, which defaults to false. If set to true, the algorithm will additionally remove the URL’s path and query components, leaving only the scheme, host, and port.

    @@ -1604,7 +1985,7 @@

  • Set url’s password to null.
  • Set url’s fragment to null.
  • - If the origin-only flag is true, + If the origin-only flag is true, then:
    1. Set url’s path to null. @@ -1614,72 +1995,72 @@

    • -

    8. Privacy Considerations

    -

    8.1. User Controls

    +

    9. Privacy Considerations

    +

    9.1. User Controls

    Nothing in this specification should be interpreted as preventing user agents from offering options to users which would change the information sent out via a `Referer` header. For instance, user agents MAY allow users to suppress the referrer header entirely, regardless of the - active referrer policy on a page.

    + active referrer policy on a page.

    -

    9. Security Considerations

    -

    9.1. Information Leakage

    -

    The referrer policies "origin", "origin-when-cross-origin" and "unsafe-url" might leak the origin and the URL of +

    10. Security Considerations

    +

    10.1. Information Leakage

    +

    The referrer policies "origin", "origin-when-cross-origin" and "unsafe-url" might leak the origin and the URL of a secure site respectively via insecure transport.

    Those two policies are included in the spec nevertheless to lower the friction of sites adopting secure transport.

    Authors wanting to ensure that they do not leak any more information than - the default policy should instead use the policy states "same-origin", "strict-origin", "strict-origin-when-cross-origin" or "no-referrer".

    -

    9.2. Downgrade to less strict policies

    -

    The spec does not forbid downgrading to less strict policies, e.g., from "no-referrer" to "unsafe-url".

    + the default policy should instead use the policy states "same-origin", "strict-origin", "strict-origin-when-cross-origin" or "no-referrer".

    +

    10.2. Downgrade to less strict policies

    +

    The spec does not forbid downgrading to less strict policies, e.g., from "no-referrer" to "unsafe-url".

    On the one hand, it is not clear which policy is more strict for all possible - pairs of policies: While "no-referrer-when-downgrade" will - not leak any information over insecure transport, and "origin" will, the latter reveals less information + pairs of policies: While "no-referrer-when-downgrade" will + not leak any information over insecure transport, and "origin" will, the latter reveals less information across cross-origin navigations.

    On the other hand, allowing for setting less strict policies enables authors - to define safe fallbacks as described in §10.1 Unknown Policy Values.

    + to define safe fallbacks as described in §11.1 Unknown Policy Values.

    -

    10. Authoring Considerations

    -

    10.1. Unknown Policy Values

    -

    As described in §7.1 Parse a referrer policy from a Referrer-Policy header and in the meta referrer algorithm, unknown +

    11. Authoring Considerations

    +

    11.1. Unknown Policy Values

    +

    As described in §8.1 Parse a referrer policy from a Referrer-Policy header and in the meta referrer algorithm, unknown policy values will be ignored, and when multiple sources specify a referrer policy, the value of the latest one will be used. This makes it possible to deploy new policy values.

    Suppose older user agents don’t understand - the "unsafe-url" policy. A site can specify - an "origin" policy followed by an "unsafe-url" policy: older user agents will ignore the - unknown "unsafe-url" value and use "origin", while newer user agents will use "unsafe-url" because it is the last to be processed.
    + the "unsafe-url" policy. A site can specify + an "origin" policy followed by an "unsafe-url" policy: older user agents will ignore the + unknown "unsafe-url" value and use "origin", while newer user agents will use "unsafe-url" because it is the last to be processed.

    This behavior does not, however, apply to the referrerpolicy attribute. Authors may dynamically set and get the referrerpolicy attribute to detect whether a particular policy value is supported.

    -

    11. Acknowledgements

    +

    12. Acknowledgements

    This specification is based in large part on Adam Barth and Jochen Eisinger’s Meta referrer document.

    Conformance

    Document conventions

    Conformance requirements are expressed with a combination of - descriptive assertions and RFC 2119 terminology. The key words "MUST", - "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", - "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this + descriptive assertions and RFC 2119 terminology. The key words “MUST”, + “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, + “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

    All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

    -

    Examples in this specification are introduced with the words "for example" +

    Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

    This is an example of an informative example.

    -

    Informative notes begin with the word "Note" and are set apart from the +

    Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

    Note, this is an informative note.

    Conformant Algorithms

    @@ -1692,31 +2073,87 @@

    -

    Index

    -

    Terms defined by this specification

    -