Re: referrer directive expressiveness

Added this to the draft spec in
https://github.com/w3c/webappsec/commit/601923fddb26d128cc30fe8b0671deb3df3ad85a

If folks hate the names, bikeshedding is welcome. I'm not firmly attached
to them.

-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, Feb 7, 2014 at 4:18 PM, David Bruant <bruant.d@gmail.com> wrote:

> Le 07/02/2014 15:07, Mike West a écrit :
>
>  +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.
>>
> I came to agree with Adam in 2011 and still do. I just wanted to provide a
> background as complete as possible and lay down our options.
>
>
>  How about something like this hastily considered list?
>>
>> none => no referrer header for any request (today's "none")
>>
> I think that some websites break if sent no Referer header, but survive to
> a Referer set to the empty string. But I forgot where I read that. Does it
> ring a bell to someone?
> Maybe that was Accept...
>
>
>  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...
>>
> Looks good to me. I like the "unsafe-" for the last one as it suggests an
> additional danger or at least something to look into.
>
> David
>