WebAppSec Referrer Policy
Home Page: https://w3c.github.io/webappsec-referrer-policy/
License: Other
Would it be possible to make the default referrer policy (i.e., the lack of one) represented by the empty string value? That is how it's represented in Fetch https://fetch.spec.whatwg.org/#referrerpolicy. E.g., when a Request arrives in a service worker. It seems simpler if all policies are part of an enum, as there doesn't seem to be a need to vary on types here unless I'm missing something.
See whatwg/fetch#226 for context.
In point 4.1 is used ABNF, which says that values enclosed in quotation marks are considered as case insensitive and quotes are ignored. Other parts of documents suggests that header value should be enclosed in double quotes (headlines are enclosed in quotes except The empty string).
Currently it is not clear for me if header value should be in quotes or not because of overused quotes inside other parts of documentation. Same with case sensitivity because of Enum.
For greater confusion Mozilla uses double quotes in its reference.
Esp for resources loaded from stylesheets, and stylesheets loaded from stylesheets.
Still reviewing #83
The new text says:
Otherwise, a CSS style sheet with a null location is responsible for the request: set the referrer to its owner node’s node document’s URL, and the referrer policy to the block’s owner node’s node document’s referrer policy.
What is "the block" here?
It seems only the content attribute is defined. We should also define the corresponding IDL attribute (and the elements that implement it). It should be limited to known values and it should have an uppercase "P" to remain consistent with HTML naming conventions.
... maybe
https://html.spec.whatwg.org/multipage/embedded-content.html#relevant-mutations defines a set of mutations that cause the image element to request the image data. There's no text in this specification that indicates how modifications to the referrerPolicy attribute are supposed to affect <img> after a load has previously been started (whether it has previously completed or not).
I got started on HTML integration in whatwg/html#1153 and #42, but there is still much to do. Here are the issues I see:
referrerpolicy content attribute applies should explicitly pass along the referrer policy when making the appropriate fetch (#40), similar to what is done with the crossorigin content attribute today.Travis builds are spontaneously failing, e.g. https://travis-ci.org/w3c/webappsec-referrer-policy/builds/145066155
This is the same Travis config as CSP, so presumably @mikewest has the same problem, and maybe he knows how to fix it too?
Presumably we need to update setuptools but I'm not sure what the right way to do that is.
In the conversation on #14, it seemed like there was agreement (or at least, no objection) to the notion of retaining forward-compatibility with a more robust structure based on JSON. The current syntax doesn't. Was that an intentional decision?
That is, Referrer-Policy: bareword would make a JSON parser sad, whereas Referrer-Policy: "quoted-keyword" would not. I think the quoted version makes more sense, given the direction we seem to be going with header parsing. WDYT, @estark37?
Why does the Referrer-Policy header allow "never", "default", and "always"?
I was under the impression it was because there were shipping implementations that allowed them. However, https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Umj9iVRJM70 indicates that nobody has implemented the header yet, with Blink being the first.
At this point my best guess is that a few user agents have already shipped <meta name="referrer">, which allows the legacy keywords, and that the desire is that the Referrer-Policy header be consistent with the <meta> element?
I don't think that's a very strong argument. Mainly because we're using <meta name="referrer">, not <meta http-equiv="Referrer-Policy">, so there is no reason to say that the meta element should be consistent with the HTTP header.
As such, it seems better to me to say that the HTTP header matches the referrerpolicy="" content attribute in disallowing the legacy values, instead of saying it must match <meta> in allowing them.
It is used as a property of environment settings objects, but it links to some weird UI guidelines spec that talks about HTTP transactions.
@bzbarsky @dakami and I had a hallway discussion at the end of TPAC about the possibility of adding location.ancestorOrigins to Firefox. bz has had longstanding concerns about the information this leaks to iframes. We arrived at a local consensus that any leakage is roughly equivalent to what happens already with referrer, so it would make sense to redact ancestorOrigins according to referrer policy. (and this could resolve that objection to a Mozilla implementation of ancestorOrigins)
I am implementing Referrer policy for CSS for FireFox and I can think of SVG resource documents referenced by CSS properties, e.g. filter:url(...)
It seems like the spec is short here
https://w3c.github.io/webappsec-referrer-policy/#integration-with-css seems work to some cases CSS of SVG element inside an HTML page.
But I think there're cases that we fetch resources in SVG. Should we explain something in the spec, given the complexity of referencing in SVG?
@jeisinger, @estark37 what do you think?
The word parsing here https://www.w3.org/TR/referrer-policy/#parse-referrer-policy-from-header
- Let policy-tokens be the result of parsing
Referrer-Policyin response’s header list.
is undefined. It links to https://fetch.spec.whatwg.org/#concept-header-parse, but unfortunately nothing has an id of concept-header-parse in the document.
Looks like #concept-header-parse links should be updated to https://fetch.spec.whatwg.org/#extract-header-list-values (I think)
The speculative resource loading of Blink conflicts to a dynamically inserted .
Blink scans HTML source to collect URLs for speculative loading as soon as the HTML arrived. In this phase, it skips all <script>.
However, since the <script> may insert to override the referrer policy, and the UA has to respect it, the UA cannot start loading the collected URLs until the script execution completes.
I.e, the UA can't start loading "foo.png" below speculatively until the preceding <script> ran.
<!doctype html>
Can the policy examples be converted to tables, so they confirm every scenario.
Originally suggested at: w3c/webappsec#414
And please check the referrer values in these tables, I'm not sure they are correct (hence why I'd like to have examples).
| Source | Destination | Referrer |
|---|---|---|
| https://example.com/page.html | https://example.com/ | NULL |
| https://example.com/page.html | http://example.com/ | NULL |
| https://example.com/page.html | https://example**.net**/ | NULL |
| https://example.com/page.html | http://example**.net**/ | NULL |
| http://example.com/page.html | https://example.com/ | NULL |
| http://example.com/page.html | http://example.com/ | NULL |
| http://example.com/page.html | https://example**.net**/ | NULL |
| http://example.com/page.html | http://example**.net**/ | NULL |
| Source | Destination | Referrer |
|---|---|---|
| https://example.com/page.html | https://example.com/ | https://example.com/page.html |
| https://example.com/page.html | http://example.com/ | NULL |
| https://example.com/page.html | https://example**.net**/ | https://example.com/page.html ? |
| https://example.com/page.html | http://example**.net**/ | NULL |
| http://example.com/page.html | https://example.com/ | http://example.com/page.html ? |
| http://example.com/page.html | http://example.com/ | http://example.com/page.html ? |
| http://example.com/page.html | https://example**.net**/ | http://example.com/page.html ? |
| http://example.com/page.html | http://example**.net**/ | http://example.com/page.html ? |
| Source | Destination | Referrer |
|---|---|---|
| https://example.com/page.html | https://example.com/ | https://example.com/page.html |
| https://example.com/page.html | http://example.com/ | https://example.com/page.html ? |
| https://example.com/page.html | https://example**.net**/ | NULL |
| https://example.com/page.html | http://example**.net**/ | NULL |
| http://example.com/page.html | https://example.com/ | http://example.com/page.html |
| http://example.com/page.html | http://example.com/ | http://example.com/page.html |
| http://example.com/page.html | https://example**.net**/ | NULL |
| http://example.com/page.html | http://example**.net**/ | NULL |
| Source | Destination | Referrer |
|---|---|---|
| https://example.com/page.html | https://example.com/ | https://example.com/ |
| https://example.com/page.html | http://example.com/ | https://example.com/ |
| https://example.com/page.html | https://example**.net**/ | https://example.com/ |
| https://example.com/page.html | http://example**.net**/ | https://example.com/ |
| http://example.com/page.html | https://example.com/ | http://example.com/ |
| http://example.com/page.html | http://example.com/ | http://example.com/ |
| http://example.com/page.html | https://example**.net**/ | http://example.com/ |
| http://example.com/page.html | http://example**.net**/ | http://example.com/ |
| Source | Destination | Referrer |
|---|---|---|
| https://example.com/page.html | https://example.com/ | https://example.com/page.html |
| https://example.com/page.html | http://example.com/ | https://example.com/ ? |
| https://example.com/page.html | https://example**.net**/ | https://example.com/ |
| https://example.com/page.html | http://example**.net**/ | https://example.com/ |
| http://example.com/page.html | https://example.com/ | http://example.com/ ? |
| http://example.com/page.html | http://example.com/ | http://example.com/page.html |
| http://example.com/page.html | https://example**.net**/ | http://example.com/ |
| http://example.com/page.html | http://example**.net**/ | http://example.com/ |
| Source | Destination | Referrer |
|---|---|---|
| https://example.com/page.html | https://example.com/ | https://example.com/page.html |
| https://example.com/page.html | http://example.com/ | https://example.com/page.html |
| https://example.com/page.html | https://example**.net**/ | https://example.com/page.html |
| https://example.com/page.html | http://example**.net**/ | https://example.com/page.html |
| http://example.com/page.html | https://example.com/ | http://example.com/page.html |
| http://example.com/page.html | http://example.com/ | http://example.com/page.html |
| http://example.com/page.html | https://example**.net**/ | http://example.com/page.html |
| http://example.com/page.html | http://example**.net**/ | http://example.com/page.html |
For example, for img elements, HTML should set the request's associated referrer policy. Similar for requests created for iframe, anchor navigations, etc.
web-platform-tests needs to be updated for:
When nested browsing contexts are created the URL is not known (all browsing contexts are created with an about:blank document in them), and in fact can change over the lifetime of the browsing context.
For example, you can have an <iframe srcdoc> that then has the srcdoc attribute removed and hence loads its src. Or you can have an iframe that loads some http page and then later loads a blob URL. This does NOT create a new nested browsing context.
What you probably need is to do is do the current inheritance unconditionally on nested browsing context creation (so that initial about:blank inherits the referrer policy, but note that there's the open question of whether it should inherit a snapshot or an alias) and then do things for srcdoc and in fetch that inherit referrer policy the way origin is inherited... possibly including the aliasing origin does.
The setup I created to support referrer policies in the fetch() API makes introducing new values rather complicated as three specifications have to be updated.
If Referrer Policy includes https://fetch.spec.whatwg.org/#referrer-policies Fetch could just refer to Referrer Policy for that. Maybe HTML could do a similar thing, with HTML defining the attribute and Referrer Policy the value space.
https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-delivery mentions using noreferrer on <link> elements. https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer does not mention this. Additionally, https://html.spec.whatwg.org/multipage/semantics.html#concept-link-obtain only refers to obtaining the policy from the element's referrerpolicy attribute.
Currently the spec says:
If request was initiated by an element with a referrerpolicy content attribute, let policy be the attribute’s value. Otherwise, let policy be the value of environment’s referrer policy.
That should be something like
If request has a non-empty referrer policy, let policy be that referrer policy. Otherwise, let policy be the value of environment’s referrer policy.
because request's referrer policy can be set via the Request constructor.
and other elements should set the request referrer policy to its content attribute when fetching (for example, navigating).
Afaik W3C URL is not maintained. Doesn't seem helpful to folks reading this document to reference it.
http://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values describes why unknown policy values are ignored and gives an example of how this can be used to deploy new policy values. This should be clarified that it only applies to Document policies delivered via HTTP header or meta tag, not to referrerpolicy attributes (which can only have one token). Authors can use feature detection to deploy new policy values in referrerpolicy attributes.
(see discussion on whatwg/html#1153)
@marumari points out that the spec is a little confusing on how you can use the Referrer-Policy header to specify multiple policies. https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values could do with an example, showing that Referrer-Policy: origin no-referrer is not going to work but that Referrer-Policy: origin, no-referrer will.
The way the spec is written right now, a srcdoc iframe snapshots its owner document's referrer policy at the point when it creates its browsing context. If that parent document's referrer policy then changes due to a <meta referrer>, the srcdoc's referrer policy will NOT change. Is that the desired behavior?
I finally got a chance to read over the things from #83
This bit:
If a CSS declaration block is responsible for the request
is wrong. Consider this stylesheet:
div { background: url(foo); }
That's a declaration block, and it's responsible for the request. But that's not what the spec means by "declaration block". It wants to restrict this case to inline style. What you probably want to do is examine the .parentRule of the declaration block or something.
This is to re-raise this issue in the context of the new Referrer-Policy spec with it's own header.
It would be nice to have a no-window-opener or similar flag for Referrer-Policy. It does change the spec quite a bit to allow multiple tokens as we probably don't want to add another value to the policy enum for every current policy to imply this.
Is it better that this stay as a CSP directive?
Specs said "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" in [1] but I am confusing about priority of that.
There's a case for example:
(a) What if the document ships a referrer Policy and the worker (called from doc) ships with/without a new referrer policy?
If we have multiple sources define referrer policy, anyway do we know which one is latest one?
I don't know if this should be considered an issue or question. Do we have question channel of this specs?
Could you advise? @annevk @jeisinger
Thanks so much.
[1] https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values
https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer step 3 substep 3 subsubstep 1 says:
Let document be the Document object of the active document of the browsing context of environment’s responsible browsing context.
What this means is that if a load happens in a document that's not active, the referrer will be set to whatever document is active in the same browsing context, which has nothing whatsoever to do with where the load is happening. I'm not sure what this bit is trying to do by using "active document", but this doesn't seem right.
Http-redirect fetch no longer has a step 15, and doesn't directly invoke anything from this specification.
In whatwg/html#1150 some folks decided that given
<!-- x.html -->
<script type="module" src="a.js">// a.js
import "./b.js";the referrer when fetching b.js should be a.js, not x.html. This apparently follows CSS, which is nice.
However, we didn't think about referrer policies. It seems like if we were to follow CSS as specified in Referrer Policy, we should be checking for a Referrer-Policy header on a.js, and then falling back to x.html's referrer policy if no such header were present. Does that sound reasonable?
It seems a bit strange that you can get it indirectly using <link rel="preload" referrerpolicy="..." href="..."> plus a later <script src="...">, but can't just do <script src="..." referrerpolicy="..."> directly.
https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-delivery-implicit-nested is inserting steps into browsing context creation that are not at all obvious while reading the HTML spec that defines creation of browsing contexts. This should probably be integrated better with HTML (e.g. via an explicit hook HTML invokes).
@annevk, thoughts?
The first sentence in 8.4 says "must" ("Certain portions of URLs MUST not be included") whereas the second sentence uses "should" ("a URLs fragment, username, and password components should be stripped") to refer to the same thing. Afaiu, the "should" in the second sentence should be replaced by "must".
@jeisinger suggested in https://codereview.chromium.org/2360753002 that ping-from doesn't need to consider the site's referrer policy. That seems strange to me, as it's basically the same data leaking in the same way.
this was removed by accident
After whatwg/html#1069 lands, all referrerPolicy attributes will need to be updated with [CEReactions].
Also, while I'm here: why not define these in a single mixin, and then do HTMLWhateverElement implements ReferrerPolicyUtils 5 times?
Alternately we're happy to upstream the HTML-ey parts of this to HTML, assuming it has cross-vendor interest. I think it's OK either way though.
I think there is a gap in the specification.
The browser's default is no-referrer-when-downgrade.
After moving to https I found that this default policy kills referrer of our partner's sites that were still on http protocol. So I have changed the policy to origin-when-cross-origin. This works ok, because the partner sites on http gets the origin referrer.
But unfortunately this option sends origin referrer even to https pages, too. This has serious consequences for functionality of some pages on different origin (domain), that are relying on the full referrer.
In the specification is missing option, which allows sending the full referrer to https cross origin sites (like the no-referrer-when-downgrade does) and sends origin referrer to http sites (for security reasons).
The name of this policy can be origin-when-downgrade.
It does not say explicitly about fetching resources from child css. Should we fall back to parent's referrer policy or document's policy if there's undefined poilcy of child (no Referer-Policy header)?
Per definition of empty string policy and referrer policy can be defined "Implicitly, via inheritance", we choose parent's, don't we?
I am not sure if that is an issue, but I would like to consult author of the specs before I could go through the implementation of Firefox. @jeisinger do you have any advice? Should we say a bit more in the specs?
Thank you very much
Afaik "DOM4" isn't maintained. Doesn't seem helpful to reference it.
As discussed on the list, in the last teleconf and in the Face-to-face, I will follow up #19 with spec changes for the other two proposed policy states.
https://w3c.github.io/webappsec-mixed-content/ appears to use "a priori authenticated" and "a priori authenticated URL" now, so the links to the definition are broken.
If I'm reading current draft correctly, referrerpolicy is restricted to a, area, img, and iframe? Can we extend it to <link> as well? This would enable developers to control the policy of prefetch/preload/prerender resources (also, stylesheets and other types fetched via link).
<link rel=prefetch as=image href=example.com/thing.jpg referrerpolicy=origin>/cc @mikewest
The fetch spec calls into:
https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer
Which states for workers that:
Otherwise, let referrerSource be environment’s creation URL.
This suggests that the referer header should contains a blob: URL for fetch/xhr requests from a blob: URL worker script.
Is this intended? What should the referer be in the case of a blob: URL worker script?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.