Re: [REFERRER] 3 of 4 policy states are worst than the default

Exactly what Mike said.  We *are* trying to encourage more HTTPS by making
it possible to upgrade from HTTP while preserving revenue streams that
depend on referrers being sent to third parties still using HTTP, without
having to re-architect your entire application to send all outbound links
through a HTTP redirect shim.

On Wed, Aug 5, 2015 at 12:52 AM Mike West <mkwst@google.com> wrote:

> This behavior is to a large extent the entire point of Referrer Policy. If
> we don't give sites a way around the default behavior or dropping the
> referrer on downgrade, they'll do it themselves via insecure redirects
> (e.g. 't.co').
>
> Perhaps we could offer something like what you want as an addition (though
> I'm not sure I understand the use case (nor do I have a good naming
> suggestion)).
>
> -mike
> On Aug 5, 2015 04:08, "Francois Marier" <francois@mozilla.com> wrote:
>
>> Sorry if this has been discussed before, but I was reading the spec from
>> the point of view of what I'd like to use on my own sites by default and
>> realized that of the 4 non-default policy states:
>>
>> 1. no referrer
>> 2. origin
>> 3. origin when cross-origin
>> 4. unsafe url
>>
>> only #1 is as good as the default (no referrer when downgrade) when
>> looking at HTTPS to HTTP navigations.
>>
>> I wouldn't mind using "origin when cross-origin" but I don't want to
>> leak referrers on HTTP requests so it seems I'm stuck with the default
>> policy.
>>
>> Shouldn't we try to encourage more HTTPS and have all of the policies
>> (except for unsafe URL of course) be at least as good as the default
>> one? In other words, shouldn't "origin" and "origin when cross-origin"
>> also imply "no referrer when downgrade"?
>>
>> Francois
>>
>>