- From: Mike West <mkwst@google.com>
- Date: Mon, 10 Nov 2014 06:10:12 +0100
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Cc: Jochen Eisinger <eisinger@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Brian Smith <brian@briansmith.org>
- Message-ID: <CAKXHy=dO-rs2_8i7Fo-bw77+8e1wHNn6x1uaN6bKkpv9NmXYng@mail.gmail.com>
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.)
Received on Monday, 10 November 2014 05:11:00 UTC