Do pages whitelist handlers on a per-page basis or do you think there will be one policy containing all handlers of an app?
-
-
Replying to @slekies @arturjanc and
Also is the attribute name part of the hash?
1 reply 0 retweets 1 like -
It's likely going to be a per-page policy generated automatically by middleware for static HTML, allowing only scripts from the current doc.
1 reply 0 retweets 1 like -
Replying to @arturjanc @slekies and
One of the proposals was to include event handler names, but this seems more complicated for little benefit so I'd prefer to avoid it.
2 replies 0 retweets 1 like -
Replying to @arturjanc @slekies and
Most importantly, scripts in static pages co-hosted with sensitive content generally don't integrate with the main app and are boring.
1 reply 0 retweets 1 like -
Replying to @arturjanc @slekies and
So if you get script exec that lets you run the contents of any existing event handler, it's fairly limited (no state-changing actions, etc)
1 reply 0 retweets 1 like -
How do you know that this is used only on static pages?
1 reply 0 retweets 0 likes -
You don't know for sure, developers can always get things wrong for any feature, security or otherwise. Guidance in the spec usually helps.
1 reply 0 retweets 0 likes -
How does backwards compatibility work? If the browser does not support the keyword, wouldn't the page break with such a policy.
1 reply 0 retweets 0 likes -
Yes, it's not backwards compatible and you'd have to do UA sniffing to only deliver this to supporting browsers; seehttps://github.com/w3c/webappsec-csp/issues/147 …
1 reply 0 retweets 1 like
Sorry, bad link above (though it's relevant for an earlier part of the discussion so I'm keeping it). This one:https://github.com/w3c/webappsec-csp/pull/247 …
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.