What's that? You wanted _more_ CSP directives? Sure! Here you go!
(This is @arturjanc's fault.)https://twitter.com/intenttoship/status/1037699686583427072 …
-
Show this thread
-
Replying to @mikewest @arturjanc
CSP is turning into a kitchen sink spec fire, what say you
@Scott_Helme ?2 replies 0 retweets 0 likes -
The fact that CSP shipped without a more granular "off" switch (you have to set script-src 'unsafe-inline' if any part of your app has an inline event handler) has led to a situation where 90% of applications with CSP have useless policies. This change solves that problem.
1 reply 0 retweets 1 like -
Replying to @arturjanc @hardyjohnson and
So while I'm always down for dissing the CSP spec (and others) for complexity, this ugliness is a necessary concession which allows CSP to deliver on at least a part of its original promise.
1 reply 0 retweets 1 like -
Consessions and complexity lead to a security win? The cryptography community has learned a hard lesson here and pivoted to designing hard to misuse libraries and strong protocols. Why can’t the we get that in web specs? CSP will suffer the same fate as P3P at this rate.
1 reply 0 retweets 0 likes -
CSP is *by design* a kitchen sink of restrictions that you can pick and choose from to lock down your app. It just so happens that this feature (hashes for JS event handlers) lets CSP be deployed in a useful way in a large number of places where it had been misconfigured before.
1 reply 0 retweets 0 likes
Luckily (kind of), the complexity cost here is borne mostely by the browser vendors, rather than by web applications. So if you deploy CSP with the new directives it's not more difficult than with script-src in the past.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.