As long as extension APIs empower extensions to do it, it's that API that is bad. And if APIs have feelings, it should feel bad.
-
-
Replying to @jasvir @arturjanc
Are you saying we should forbid extensions from running code in the context of the document?
1 reply 0 retweets 0 likes -
They can run code by injecting scripts, the UA knows which scripts are extension-inserted. But JS event handlers just break.
2 replies 0 retweets 0 likes -
FWIW if the browser could track the source of all scripts/event handlers it wouldn't be a problem. But in practice it doesn't
1 reply 0 retweets 0 likes -
Are you saying some kind of extension code taint tracking could allow warnings/blocks/reports to be silenced?
1 reply 0 retweets 0 likes -
Replying to @johnwilander @nasko
The will of an extension wins over the will of the page per https://www.w3.org/TR/html-design-principles/#priority-of-constituencies … so exts should be exempt from CSP.
2 replies 0 retweets 0 likes -
So ideally, yes, the browser should know what was added by an extension and not subject it to the page's CSP policy.
1 reply 0 retweets 0 likes -
But in practice it doesn't work, so extension-added markup with JS event handlers will break both the extn & the page.
1 reply 0 retweets 0 likes -
Pretty broad reading of the W3 spec. Are extensions authors, implementors, specifiers or theoretically pure?
2 replies 0 retweets 0 likes -
Replying to @jasvir @arturjanc and
Should a page's CSP apply to code generated by code added by an ext or is the stack of turtles ∞ deep?
1 reply 0 retweets 0 likes
It should be ∞ deep, but in practice it's just 1 level deep because browsers don't track script provenance.
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.