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

Re: Standardize referrer policy

From: Mike West <mkwst@google.com>
Date: Thu, 12 Jun 2014 17:17:52 +0200
Message-ID: <CAKXHy=e_B5ynwQ8ngNCTysYMKPWwKG4LtcFao1=wKCVmnOfEyA@mail.gmail.com>
To: Sid Stamm <sid@mozilla.com>
Cc: Sid Stamm <sstamm@mozilla.com>, "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>
I didn't at all mean "quiet down". I mean "file bugs that we can poke at in
the future" and "make sure we're not crazy when we're defining things".

Feedback === good. :)

-mike

--
Mike West <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.)


On Thu, Jun 12, 2014 at 5:16 PM, Sid Stamm <sid@mozilla.com> wrote:

> 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:18:41 UTC

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