you could, but the model used by the people designing CSP for how it reduces threats is often wrong.
-
-
please try to understand why 1. There may be important use cases, 2. Security by 1/
-
"every developer should evaluate risks" does not comport with modern security practices 2/2
-
: 2) Developers should evaluate risks, just like they evaluate performance tradeoffs, etc.
@mikesherov@SlexAxton@The_Brown_Shoe -
in general, devs use tools that help make trade-offs for them. In this case, there's 1/
-
nothing ember can do to acquire the eval capability safely cuz no one designed the API 2/
-
and in general the attitude is "shoot capabilities first, ask questions later" 3/3
-
because it's "opt in" granularity is never seen as a high priority, but security teams 1/
-
are eager to opt in (I'm sure you think this is good), but that means in practice I 2/
- 3 more replies
New conversation -
-
-
: I'm not trying to enrage you, sorry if it came across as dismissive. That's not my intent.
@mikesherov@SlexAxton@The_Brown_Shoe -
that's why I didn't actually get angry. But this attitude is extremely frustrating.
-
dynamic eval is important for performance goals. It's possible to eliminate the 1/
-
XSS sinks in other ways (e.g. ember uses templates for all DOM insertion). 2/
-
I'd be very comfortable with a capability approach that shared a nonce with the eval 3/
-
function safely, but CSP attitudes never go down that path for APIs, just HTML. 4/4
-
this! We end up having to do that manually since CSP doesn't support it :(
@mikewest@mikesherov@SlexAxton@The_Brown_Shoe -
honestly the attitude that it's reasonable for apps to turn off eval is frustrating
- 9 more replies
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.