On Fri, Jan 23, 2015 at 7:29 PM, Brad Hill <hillbrad@gmail.com> wrote: > > >The pinning model in the proposal uses the existing > > combination logic for multiple headers: resources simply > > need to pass all the policies applied to a protected resource. > > I think overriding the pinned policy completely would undermine > > its impact to some extent; I'd prefer to avoid doing that unless > > there's a good reason to. > > > I don't know about that. I like the idea of "here's a backup policy in > case things go wrong and we forget to send one". For example, if an > application ends up returning an error page before the logic that applies > the policy was reached. I hadn't thought about the problem this way; it's a compelling alternative, mostly because it reduces the deployment risk to (practically) nil. The overall concept, then, would be "Every page on my host(s) MUST have a Content Security Policy.", which is similar conceptually to HSTS's promise that every page on a host will be delivered over HTTPS. I think it's worth exploring (sorry, Jim; I shouldn't have dismissed the idea so quickly). I don't want to entirely give up the stricter "Every page on my host(s) MUST have a CSP that's at least this strict." variant. I think Yan had some use cases that would benefit from that sort of promise. Perhaps we can do both with something horrible like a `no-override` directive? Also, if we allow overrides at all, I'd suggest that `<meta>`-delivered policies shouldn't override pinned policies. That seems like a bad idea. -- Mike West <mkwst@google.com>, @mikewest 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 Friday, 23 January 2015 19:20:52 UTC