- From: Hill, Brad <bhill@paypal.com>
- Date: Wed, 11 Jun 2014 20:24:46 +0000
- To: Sid Stamm <sstamm@mozilla.com>, Jochen Eisinger <eisinger@google.com>
- CC: John Kemp <john@jkemp.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Adam Barth <abarth@google.com>, Mike West <mkwst@google.com>
Sounds like a 1.2 issue to me. :) -----Original Message----- From: Sid Stamm [mailto:sstamm@mozilla.com] Sent: Wednesday, June 11, 2014 1:09 PM To: Jochen Eisinger Cc: John Kemp; public-webappsec@w3.org; Adam Barth; Mike West Subject: Re: Standardize referrer policy On Jun 11, 2014, at 11:31 AM, Jochen Eisinger <eisinger@google.com> wrote: >> >>> Any comments are more than welcome! >>> >> How does this draft relate to the 'rel=noreferrer' attribute on <a/> tags? I see you refer to the "Javascript Global Environment" and one can imagine that this environment *might* impact how the rel=noreferrer is processed in the same way you describe via inheritance from the "global" environment, but it might be helpful to spell that out (and mention it in the introduction too). > > that's covered in step 6 of the "Set request's Referer header" algorithm, no? Like rel="noreferrer", would it make sense to consider a future where DOM elements or subtrees have their own referrer policy? The conflict resolution in 6.1 "environments" doesn't seem to allow for this except for going from any policy to "Never" in a subtree. I can imagine a situation where a developer may want to declare a site-global policy using a meta tag, but then change the referrer policy for an iframe or for some sub-tree of the DOM (reducing exfiltration in cross-site loads, giving more referrer data to trusted partners, etc). -Sid
Received on Wednesday, 11 June 2014 20:25:14 UTC