W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: referrer spec and backwards compatibility

From: Mike West <mkwst@google.com>
Date: Mon, 9 Feb 2015 09:51:06 +0100
Message-ID: <CAKXHy=dez+AryTfodvOfZnD9DDMEJv1eu5osqCiw8u-nWRtn4A@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Feb 9, 2015 at 8:32 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Hi
>
> (previously on blink-security-dev
>
> https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/-t_-5m6ChDg
> )
>
> Currently, (I believe) in release versions, Firefox supports the
> "origin-when-crossorigin" value for the referrer directive while
> Chrome doesn't.


`origin-when-crossorigin` is in Chrome 41. Give it a few weeks, and this
particular case will be a non-issue.

Unfortunately, the Chrome implementation of the spec
> is "if I don't know the name of the directive value, fall back to the
> secure 'none'".


Nit: It's not just Chrome's implementation of the spec. It's the behavior
the spec mandates. :)

I think the spec should be changed to say "if you don't know the name
> of the directive, ignore it". This will allow web application
> developers to make the best choice according to what they feel is the
> right thing to do. For example, the web application could do:
>
> <meta content="unsafe-url" name="referrer" />
> <meta content="origin-when-crossorigin" name="referrer" />
>
> This will allow the app to provide the most protection possibel
> without breaking features and not being limited by what version of the
> browser the user is relying on.
>
> What do others think?
>

I think you're right.

I also think we need to revisit the override logic; currently, if both
`unsafe-uri` and `origin-when-crossorigin` are supported, the spec mandates
locking down the referrer in the presence of the two <meta> elements you
list above (see the last two steps of
https://w3c.github.io/webappsec/specs/referrer-policy/#set-referrer-policy).
This seemed like a safe way of dealing with conflict between headers, but
would prevent the kind of forward compatibility you're arguing for here.

If we change the one behavior, we should likely change the other as well.

--
Mike West <mkwst@google.com>, @mikewest

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 Monday, 9 February 2015 08:51:54 UTC

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