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. FrancoisReceived on Wednesday, 20 April 2016 00:42:14 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:55 UTC