Early morning thoughts on referrers.

After skimming through the (prolific! exciting!) discussions on the
`referrer` directive and referrer policy in general, I see the following
areas of discussion:

1. Referrer policy allows sites to send _more_ referrer information than
they currently do. And this is bad, because it breaks the mental model of
CSP that site authors might be working with (and, in doing so, makes the
CSP processing model more complex than it ought to be).

2. Related to #1; `unsafe-url` is dangerous to specify.

3. There's a lack of granularity in the available policies, as they
describe specific points on a matrix consisting of the referrer's
granularity (origin? path? query string?) and the relationship between the
referrer and referree (same-origin? same-public-suffix?
cross-public-suffix? downgrade from HTTPS to HTTP?).

I have a few suggestions. In reverse order:

3. Let's extend the policy definition language to treat the current set of
policies as shorthand for a more detailed language. I have some ideas here,
but nothing that feels right for all the use cases. As a strawman, let's
break requests into two buckets: same-public-suffix and
cross-public-suffix, and add a `downgrade` flag. We then need to set three
flags to have a reasonably granular policy: one controlling behavior for
bucket 1, one for bucket 2, and one override for the downgrade case. A
policy like `origin` might expand into `origin-when-same-suffix
origin-when-cross-suffix allow-downgrade` (note the origin->suffix change;
I think the latter makes more sense, but maybe we need both?).
`origin-when-cross-origin` might expand into `url-when-same-suffix
origin-when-cross-suffix allow-downgrade`. `no-referrer-when-downgrade`
might expand into `url-when-same-suffix url-when-cross-suffix
deny-downgrade`. This needs more spelling out, but it might make things
easier to reason about.

While on the topic (tangentially), I think it's a perfectly reasonable idea
to allow a site to specify a same-origin "base referrer url", and to use
that as the basis upon which to perform the origin/whatever stripping
operations. I don't think that's at all an essential component, however,
and I'd like to work everything else out first. :)

2. I believe the risk of specifying something that some folks don't like
and want to experiment with killing is is already sufficiently mitigated
via language that allows user agents to treat it as a maximal limit on
referrer information, rather than a mandate. I also think it's important to
allow sites to opt-into behavior they've come to expect from the web when
migrating from HTTP to HTTPS; regardless of that behavior's awesomeness,
I'd like to remove as many barriers to that transition as possible.

1. Making the policy language more granular might allow us to more clearly
define what sorts of things are acceptable in <meta>. It does not, of
course, address the core of Brian and other's comments about the
complexity; it makes things more complex, honestly. But that complexity
might bring with it a bit more clarity, as we won't be hiding behaviors
behind opaque policy names.

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