On Wed, Feb 4, 2015 at 6:18 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > Still, the way for webapp design to achieve these goals with systems in > place today is to deliberately change the execution context when the app > needs to alter CSP. > Maybe that's the right answer. My understanding is that there are substantial performance benefits associated with avoiding full-page navigations, and that the recent movement towards `pushState()`-driven apps is explicitly encouraged on those grounds. > Is it worth injecting potential vulnerabilities in CSP (allowing the > page to change its own policy) just to enable retaining the single > execution state? If we ensure that the footgun is opt-in (either by making it a separate header, or by having some flag on requests, or whatever), then it might be worth giving developers the option. I suspect at the moment that some sites are either not using CSP, or are using a truly broad (and thereby not particularly effective) policy in order to achieve the performance wins noted above. On Thu, Feb 5, 2015 at 12:07 AM, Deian Stefan <deian@cs.stanford.edu> wrote: > There is the safe use case of only allowing code to further restrict the > CSP policy. This is useful if you want to effectively "drop privileges." Given our existing combination logic, this is possible today just by injecting additional `<meta>` elements containing policy. -- 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 Thursday, 5 February 2015 07:34:56 UTC