Re: referrer directive expressiveness

+Adam

Hey David!

One the one hand, I agree with you that the current spec combines two
aspects into a single keyword. On the other, I agree with Adam of 2011 that
some of the combinations don't make much sense. I'd like to keep things
simple, and I hope we can do that by addressing your use-case, but sticking
to the single-keyword model.

How about something like this hastily considered list?

none => no referrer header for any request (today's "none")
none-when-insecure => no referrer header for HTTPS->HTTP (today's "default")
origin-always => always send a referrer header containing only the origin
(today's "origin")
origin-when-cross-origin => full referrer header for same-origin requests,
origin referrer header for cross-origin requests
unsafe-url-always => full referrer header for any request (today's "always")

Bikeshedding welcome...

-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 Fri, Jan 31, 2014 at 12:22 AM, David Bruant <bruant.d@gmail.com> wrote:

> Le 31/01/2014 00:18, Anne van Kesteren a écrit :
>
>  On Thu, Jan 30, 2014 at 3:13 PM, David Bruant <bruant.d@gmail.com> wrote:
>>
>>> That's the semantics that Facebook needs, but is not what I read from the
>>> CSP 1.1 draft I've found:
>>>
>> I understand. I wonder what the use case is for only sending origin (+
>> "/") same-origin.
>>
> You mean the use case for the current semantics as spec'ed? Good question.
> Maybe it's just an omission and the intended semantics is the one you
> described.
>
> David
>
>