Re: Standardize referrer policy

Ok, sure, but I wanted to mention it to avoid ending up with a spec that is incompatible with that future.  

If we want to do something smarter than reverting to Never, would it make sense to rank the states and when resolving conflicts, pick the highest-ranked one?   Just a thought.  Maybe another future-destined idea.

-Sid

On Jun 11, 2014, at 1:24 PM, Hill, Brad <bhill@paypal.com> wrote:
> 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:32:19 UTC