W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Standardize referrer policy

From: Sid Stamm <sid@mozilla.com>
Date: Thu, 12 Jun 2014 08:16:34 -0700
Message-ID: <5399C452.5050500@mozilla.com>
To: Mike West <mkwst@google.com>, Sid Stamm <sstamm@mozilla.com>
CC: "Hill, Brad" <bhill@paypal.com>, Jochen Eisinger <eisinger@google.com>, John Kemp <john@jkemp.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Adam Barth <abarth@google.com>
Right Mike, agreed on all fronts.  I'll quiet down.  Draft looks good to me.

-Sid

On 06/11/2014 11:57 PM, Mike West wrote:
> On Wed, Jun 11, 2014 at 10:31 PM, Sid Stamm <sstamm@mozilla.com
> <mailto:sstamm@mozilla.com>> wrote:
> 
>     Ok, sure, but I wanted to mention it to avoid ending up with a spec
>     that is incompatible with that future.
> 
> 
> The spec currently defines the `rel='noreferrer'` attribute as
> overriding the page's referrer policy for a specific navigation. I don't
> think there's any reason that we couldn't define similar attributes
> which would override the page's referrer policy for other types of
> resource requests (even going in the other direction:
> `rel='alwaysreferrer'`?).
> 
> I'd agree with Brad, though, that it's probably best to just get this
> out the door after ensuring that it accurately describes user agent's
> current behavior. There's plenty of time to invent new behavior once we
> have these basics pinned down in a way we generally agree upon.
>  
> 
>     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.
> 
> 
> The current spec is pretty draconian in its conflict-handling, granted.
> It's not entirely clear what a reasonable ordering of states would be,
> however. For instance, is "Origin" higher or lower than "None When
> Downgrade"?
> 
> An alternative would be to just let the last-set policy win. That might
> have some advantages for single-page apps, as the current behavior locks
> an app into one referrer policy forever. It's certainly imaginable that
> an app built upon pushState, etc might want different referrer policy
> for different pieces of the app. *shrug*
> 
> I'd like to support those kinds of use cases. I'm not sure I want to do
> that in the first version of the document. :)
> 
> --
> Mike West <mkwst@google.com <mailto:mkwst@google.com>>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
> 
> 
Received on Thursday, 12 June 2014 15:20:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC