Re: [referrer] Providing safer policy states

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
>
>