The spec basically requires that referrer not be sent from about:blank or data: documents.  What Gecko does instead is basically aliases the original document URI of the document whose origin we're aliasing... but maybe we should just directly alias the referrer or something?

Who would you be sending the referrer to, exactly? I'm confused. Do you just mean the document.referrer API? Can you give a concrete example of what you mean?

Say I have a document loaded from http://something.com that has:

  <iframe></iframe>
  <script>
    onload = function() {
      var doc = frames[0].document;
      var kid = doc.createElement("iframe");
      kid.src = "http://example.com";
      doc.body.appendChild(kid);
    }
  </script>

Per spec as written right now the "http://example.com" load will not get a referrer sent with it, as far as I can tell.  Arguably it should get "http://something.com".

Ah, yeah. I think you're reading it right.

Any idea what browsers do here? (I'll test it if you don't happen to know.)

The way the base URL defers to the top frame is through step 2 here, FWIW:
   http://www.whatwg.org/specs/web-apps/current-work/#fallback-base-url

Looks like browsers aren't interoperable on the referrer (they are on base URL):
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2831

* Gecko does as you suggest (defer to about:blank's creator browsing context).

* Chrome doesn't send it if it's about:blank, but does for document.written()
  and for the direct frame in the parent.

* Safari doesn't send it if it's about:blank or document.written(), but does
  for the direct frame in the parent.

Spec matches Chrome currently, if I'm reading it right.

Yes, I think spec as currently written matches Chrome.

miketaylr tells me IE11 matches Chrome also.

Arguments for deferring up the chain if the URL is about:blank:
 - if you build your app from script, and part of it is in a new iframe and it has 
   images, your images would be lacking the right referrer.
 - consistency with origin and base URL
 - a browser does this (Firefox)

Arguments for dropping the referrer (spec status quo):
 - it gives you a way to drop the referrer
 - the referring document really is about:blank
 - the script injecting the content is the real culprit, not the parent document
 - two browsers do this (Chrome, IE)
 - three browsers do either this, or are even further away from sending
   referrers (Safari)

Ok, anyone got an opinion as to which they prefer? Did I miss any arguments?

I think I'm leaning towards not changing anything here, but I don't think the arguments in either direction are particularly compelling.

I'm a pretty firm believer in consistency of origin and referrer if possible, given how referrer is used in practice.

I would expect that the referrer of the parent is sent, and if we want to provide a way to opt-out of the referrer it seems clearer to do so explicitly with a <meta> element or so.

Ok, unless someone provides a counter-argument before I get to it (probably later today), I'll change the spec to defer up the chain for referrer, much like it does for the base URL.

Ooh, actually, this impacts fetch. Anne, how do you want to handle this? Should I bring some of http://fetch.spec.whatwg.org/#determine-referrer back into HTML?

Yeah, that bit in Fetch is only there temporarily. My idea is that eventually you make HTML use the main algorithm, which does not do much with Referer. The exact "calling interface" for the main algorithm could be improved though.

(I'm with bz I think on matching referer/origin/base.)

Comment 13 is obsolete. Given CSP having a policy for Referer, it should be in Fetch I think.

I would like to see if the "referrer source" concept can be changed. Fetch requires a global to be changed in (request client), so it would be nice if we could somehow tie it to that. E.g. you either provide an explicit referrer, or just a pointer to a global (window or worker) where it can be retrieved from.

I don't know if this is possible, but I think it would be nice that if Fetch is not passed an explicit Referer, it looks on request's source (which is a global object) and gets it from there. Using that for origin seems good too. This is just a thought, I have not done extensive analysis.

The request source might not be a global object, unless I'm missing something.  E.g. if I have a stylesheet that does @import, the request source and referrer should be the stylesheet.

Sorry, I meant request client: http://fetch.spec.whatwg.org/#concept-request-client It's a relatively new concept needed for service workers.

Agreed that for stylesheets you need an override of sorts. For stylesheets the "referrer source" concept also could not be a Document. My idea would be that we either pass a referrer that's a URL, and fallback to the referrer of the request client if referrer is not passed.

Mike, this impacts your interests.

Thanks for looping me in, Ian. As you're aware, WebAppSec is trying to hammer this out in http://w3c.github.io/webappsec/specs/referrer-policy/

I think we'd be willing to change that spec (and therefore Chrome's behavior) here for 'about:blank'. That would also have impact on framed `blob:` URLs. We'd still probably end up with divergent behavior for `data:` URLs, as I think there's still disagreement(?) between browsers about what origin those URLs ought to be assigned.

That said, regarding comment #16, I'd expect a stylesheet's `@import` or `url()` to be fetched through the Document that's loaded the stylesheet, and for the referrer to be based on that page's policy settings.

Note that there's a distinction between the referrer policy settings and the referrer source.

You could use the document's referrer policy but still use the style sheet's URIas the referrer URI to apply that policy to.  I suggest testing what UAs do in practice for @import.

(In reply to Boris Zbarsky from comment #20)
> Note that there's a distinction between the referrer policy settings and the
> referrer source.

Indeed.

> You could use the document's referrer policy but still use the style sheet's
> URIas the referrer URI to apply that policy to.  I suggest testing what UAs
> do in practice for @import.

On http://stevesouders.com/tests/atimport/link-with-imports.php?t=1406727251, Chrome sends the document's URL as a referrer for `@import`-loaded CSS. Firefox sends the stylesheet's URL. That surprises me a bit.

What do other UAs do?

Are you surprised by one behavior or the other, or by the difference?  

The Firefox behavior is quite purposeful; see <https://bugzilla.mozilla.org/show_bug.cgi?id=249171> (and for that matter <https://bugzilla.mozilla.org/show_bug.cgi?id=249168>, which was about using the sheet as the referrer for url() things).  The referrer really is the sheet in this case, not the document.

mike, see comment 22.

(In reply to Ian 'Hixie' Hickson from comment #23)
> mike, see comment 22.

I continue to be surprised by the Firefox behavior, but not so surprised that I'd oppose changing Chrome's behavior to match. +Jochen, who might have an opinion.

This is not just CSS I think:

* HTML imports
* XSLT (e.g. the document() function)
* Manifest (both appcache and the new one)?

SVG would not be impacted by this, as it can only load external resources when it creates a document environment itself (at least by the policy we plan to align all user agents on).

(In reply to Mike West from comment #19)
> I think we'd be willing to change that spec (and therefore Chrome's
> behavior) here for 'about:blank'. That would also have impact on framed
> `blob:` URLs. We'd still probably end up with divergent behavior for `data:`
> URLs, as I think there's still disagreement(?) between browsers about what
> origin those URLs ought to be assigned.

For what it's worth, I would prefer Gecko's behavior when it comes to sticking data: URLs in an <iframe> or when using data: URLs when creating a Worker.

My preferred behavior is that by default, a <iframe src="data:..."> runs with a "null principal". I.e. it's not same-origin with anything. But that we add something like <iframe allowinherit src="data:..."> which would cause the contained page to be same-origin with parent.


Likewise for workers, where I think new Worker("data:...") should throw as the URL would be considered cross-origin, but where |new worker({ url: "data:...", allowInherit: true }) would cause the worker to be same-origin with the script creating the worker.


Others at mozilla might disagree, so I can't commit to if or when such a change would be acceptable. But I wanted to state my opinion.


Other than this I like mozilla's behavior of sending the URL of the stylesheet as the referrer for url() in stylesheets, and walking up the chain for things like about:blank and data:.

This is fixed since HTML now uses Fetch which uses Referrer Policy which defines this behavior afaik.

https://github.com/whatwg/html/commit/7c5555a16f2920c02244c10756bb2f1a11e87a22