Re: [referrer] Providing safer policy states

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