Re: [referrer] Providing safer policy states

I agree that we shouldn't break existing users.

On Wed, Apr 20, 2016 at 7:06 AM Brad Hill <hillbrad@gmail.com> wrote:

> I would definitely be against changing the meaning of the existing policy
> states to break sending referrers across https->http transitions, since
> that was the biggest motivating use case for the feature, and it is very
> inconvenient to have to do browser sniffing and send different policies
> that sometimes say the same thing but mean different things across
> different UAs and different versions of the same UA.
>
> Who will be the "customers" for these new states that we think it is a
> good idea to break / force change on the existing users?
>
> On Tue, Apr 19, 2016 at 5:44 PM Francois Marier <francois@mozilla.com>
> wrote:
>
>> On 05/04/16 08:43 PM, Emily Stark (Dunn) wrote:
>> > Adding these new policy states sounds reasonable to me. However, I want
>> > to note that there's been discussion about expanding the spec to a
>> > JSON-based syntax that allows much more flexibility. For example, we
>> > might want to express the policy "'unsafe-url' for navigations to and
>> > subresources from myadnetwork.com <http://myadnetwork.com>, and 'none'
>> > for all other origins" -- maybe using some syntax like { "unsafe-url":
>> > ["myadnetwork.com <http://myadnetwork.com>", "'self'"], "none": "*"}.
>> > (I'm not suggesting that as an actual proposal for the syntax, just an
>> > idea of the kind of thing we were thinking about.) In that world, the
>> > policy states would just be shorthand for the most commonly used
>> policies.
>>
>> That would be a good way to express policy the states in the table
>> (taking the liberty to abbreviate your strawman syntax, CSP-style):
>>
>>  no-referrer:                     "none *"
>>  origin:                          "origin *; none 'http:*'"
>>  unsafe-origin:                   "origin *"
>>  same-origin:                     "full 'self'; none *"
>>  origin-when-cross-origin:        "full 'self'; origin *; none 'http:*'"
>>  unsafe-origin-when-cross-origin: "full 'self'; origin *"
>>  no-referrer-when-downgrade:      "full *; none 'http:*'"
>>  unsafe-url:                      "full *"
>>
>> I'm assuming that the wildcard is applied last (i.e. it defaults to that
>> unless there is a more precise match).
>>
>> > If that's the kind of thing that we want to head towards, then I don't
>> > think it makes sense to introduce a new attribute for downgrades.
>> > Presumably in that future world you'd be able to handle downgrades with
>> > something like { "none": "http://*" }.
>>
>> Of course, it would be slightly different from the downgrade idea since
>> it would disable referrer on HTTP regardless of whether or not the page
>> is served over HTTPS, but I think that's just as good because the server
>> can vary the header if it wants to.
>>
>> Francois
>>
>>