If convenience damages security and developer explicitly chose security, libraries need to conform. Simple.
-
-
I was thinking more about the default behavior. But if security is inconvenient, no one will adopt it.
2 replies 0 retweets 0 likes -
FWs will want to *work* when developers "turn on" security features. So they will work around them. Simple.
1 reply 0 retweets 0 likes -
And if they do they will be wrong, and detrimental to user security. Luckily it's a fixable problem.
1 reply 0 retweets 1 like -
is ng-csp detrimental to user security?
1 reply 0 retweets 0 likes -
Yes, the Angular security model based on bypassing platform security features (via {{ }} and AST*) is wrong
2 replies 0 retweets 1 like -
Replying to @arturjanc @sirdarckcat and
... and is the source of countless vulnerabilities we otherwise wouldn't have. We can't let it happen again.
1 reply 0 retweets 2 likes -
Replying to @arturjanc @sirdarckcat and
Also, saying that hardening APIs is bad because "frameworks can work around it" is incredibly short-sighted.
1 reply 0 retweets 4 likes -
I am not saying that at all. Just saying we need to take this into account to not get it wrong.
1 reply 0 retweets 0 likes -
Replying to @slekies @arturjanc and
I can show you dozens of examples where the current behavior of innerHTML led to hacks in libraries.
3 replies 0 retweets 0 likes
I don't doubt this :) But that's not an argument against libraries playing nice with a hardened innerHTML...
-
-
Replying to @arturjanc @slekies and
Especially if the hardened, safe behavior is an explicit developer opt-in as currently proposed.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.