After an outcry against tying a focused anti-XSS syntax to the existing `X-XSS-Protection`, we're back to `ARTUR`: https://mikewest.github.io/artur-yes/
CSP was safe by default but required arcane spells ('unsafe-eval') to make things work. So few people understood it.
-
-
: I’m pretty sure you told me two weeks ago that the syntactic warts weren’t the problem.
@ericlaw -
I thought you convinced me that they are a problem for folks outside of major companies, so we need something simple :-)
-
: Yup. And I agree with me! But I think adding ‘eval:true’ or something isn’t a big step, seems like a reasonable burden.
@ericlaw -
It's boilerplate that everyone will have to include, with negligible security value. But not the end of the world.
-
A new simple thing to avoid the mistakes of CSP would be more powerful if it focused on the things we know are important.
-
Which in this case are nonces/hashes for blessing scripts and not getting developers to hunt down eval().
End of conversation
New conversation -
-
-
As a result of this complexity, almost everyone uses bad CSP policies. The new approach aims for simplicity instead.
-
: I don’t know anyone who failed to deploy CSP because of the struggle to add ‘unsafe-eval’.
@ericlaw -
Several of our apps spent a lot of time getting rid of 'unsafe-eval' without fixing 'unsafe-inline' first. Complexity bad
-
: Maybe that’s a failure in messaging. ‘very-unsafe-inline’ next time.
@ericlaw
End of conversation
New conversation -
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.