Re: Standardize referrer policy

On Wed, Jun 11, 2014 at 10:31 PM, Sid Stamm <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>
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 06:58:19 UTC