> > It's also a significant win in terms of deployability, as very little code > would actually need to change. Again, anecdotally, a significant subset of > the Google properties that folks spot-checked could use this mechanism > without changing any JavaScript code at all, just by turning on a > nonce-generator in their templating library. > > I guess this is a subjective choice. Personally, my preference for increasing complexity is in the order---web apps and then browsers and then standards. Standards move almost glacially in comparison to web apps: maybe we standardize something and we realize it didn't actually fix the problem. If the concern is doing UA detection is a pain, I think this is another reason to version the CSP header. Lets say that a hypothetical CSP2 header mandates nonce support, hash support, and other improvements. IMO, this would also reduce complexity in the web app; 'unsafe-dynamic', while backwards compatible, seems to be increasing complexity in the app, the browser, and the spec. I do agree with the general concept and threat model (script elements not inserted by parser are safer) behind this. There is also value, as Artur pointed out, in not forcing scripts to pass around nonces. But standardizing something for this one unique use case that could be solved by a polyfill and UA detection seems weird. Maybe I am missing many more use cases? I would love to learn more. Cheers Dev
Received on Sunday, 14 February 2016 05:39:58 UTC