A few things: 1) If I'm reading this correctly, you could never have a more relaxed CSP for a specific resource than the baseline value in an Origin Policy due to the way header combination works for CSP. It seems like some sort of escape hatch is necessary to disable Origin-Policy processing for a given response? (or you have to be absolutely 100% certain about the baseline policy contents and probably still send large delta policies with almost every request) 2) Another smart person at FB points out that the benefit of having the client send which version it is currently enforcing for the domain is that you can avoid having to do an H2 push for every request to avoid blocking. Seems like a big deal, so maybe the "cookie-like" semantics are a big win, after all. 3) Same smart person is concerned about being able to do graceful upgrade without thrashing if servers don't all see the same policy version as current simultaneously. I think this might be best accomplished, again, by the original proposal, so the origin owner could encode a versioning scheme into the policy name and a server that is serving policy v1 doesn't try to override a client that says it's already enforcing v2. (could possibly do this by caching all previous hashes, but that's kind of ugly in the long run) On Wed, Jul 27, 2016 at 10:46 AM Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Jul 27, 2016 at 7:18 PM, Mike West <mkwst@google.com> wrote: > > Granularity beyond the origin seems like a(n attractive) footgun. > > Agreed, let's not do another service worker scope. > > > -- > https://annevankesteren.nl/ >
Received on Wednesday, 27 July 2016 22:44:06 UTC