24613 2014-02-10 21:04:42 +0000 Why wouldn't referrer for about:blank be based on the origin it inherits? 2015-09-17 08:21:57 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED https://www.w3.org/Bugs/Public/show_bug.cgi?id=26830 http://www.whatwg.org/specs/web-apps/current-work/#processing-model blocked on dependencies P3 normal Unsorted 24080 1 contributor ian adrianba annevk bzbarsky descartavel1 eisinger ian james jonas mike mkwst travil w3c zcorpan contributor oldest_to_newest 100201 0 contributor 2014-02-10 21:04:42 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#processing-model Complete: http://www.whatwg.org/c#processing-model Referrer: Comment: Why wouldn't referrer for about:blank be based on the origin it inherits? Posted from: 98.110.194.132 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 100202 1 bzbarsky 2014-02-10 21:05:57 +0000 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? 100212 2 ian 2014-02-10 21:37:44 +0000 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? 100215 3 bzbarsky 2014-02-10 21:48:08 +0000 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". 101000 4 ian 2014-02-20 20:29:04 +0000 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.) 101053 5 ian 2014-02-20 22:27:46 +0000 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. 101093 6 bzbarsky 2014-02-21 04:56:52 +0000 Yes, I think spec as currently written matches Chrome. 101168 7 ian 2014-02-21 22:54:07 +0000 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) 101387 8 ian 2014-02-25 19:37:08 +0000 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. 101397 9 bzbarsky 2014-02-25 20:06:09 +0000 I'm a pretty firm believer in consistency of origin and referrer if possible, given how referrer is used in practice. 101428 10 zcorpan 2014-02-26 09:16:32 +0000 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. 101435 11 ian 2014-02-26 15:37:21 +0000 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. 101562 12 ian 2014-02-27 23:48:11 +0000 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? 102480 13 annevk 2014-03-17 18:23:58 +0000 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.) 105435 14 annevk 2014-05-08 14:25:23 +0000 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. 105438 15 annevk 2014-05-08 14:48:58 +0000 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. 105440 16 bzbarsky 2014-05-08 14:57:35 +0000 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. 105441 17 annevk 2014-05-08 15:05:59 +0000 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. 109530 18 ian 2014-07-29 21:04:46 +0000 Mike, this impacts your interests. 109563 19 mkwst 2014-07-30 12:02:47 +0000 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. 109568 20 bzbarsky 2014-07-30 13:27:58 +0000 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. 109571 21 mkwst 2014-07-30 13:35:37 +0000 (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. 109572 22 bzbarsky 2014-07-30 13:43:25 +0000 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. 111203 23 ian 2014-09-08 22:00:19 +0000 mike, see comment 22. 111244 24 mkwst 2014-09-09 09:17:20 +0000 (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. 111246 25 annevk 2014-09-09 09:27:31 +0000 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). 120757 26 jonas 2015-06-05 20:56:38 +0000 (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:. 123236 27 annevk 2015-09-17 08:21:57 +0000 This is fixed since HTML now uses Fetch which uses Referrer Policy which defines this behavior afaik. https://github.com/whatwg/html/commit/7c5555a16f2920c02244c10756bb2f1a11e87a22