Re: [whatwg/dom] Declarative Shadow DOM (#831)

IMO, implementors have made it clear that option 4i ("don't implement any mitigation") is off the table… we can't consider it further.

Having said that, if 4i is unacceptable, then I don't think 4iii (`<template onshadowroot>`) would/should be considered acceptable either.

As I understand it, the rule we have to follow is that we must ensure 100% backwards compatibility with any sanitizer that works today or could work today in principle, no matter how oddly constructed. ("It's not acceptable to introduce a new security vulnerability risk just because we can't find a concrete example." "It's not OK for a browser-side change to introduce XSS to sites that didn't have XSS prior to that browser-side change. Introducing XSS merely to the long tail of sites is still not OK.")

Because of this, we do not need (we would have no use for) _any_ data about how actual sanitizers work in practice. The very fact that a sanitizer _could_ be written that would be impacted by this change is sufficient reason to stop the ship. It's simply unacceptable to introduce a new security vulnerability risk (_risk_) just because we can't find even one concrete example, and it is a waste of time to discuss it any further.

If I understand the principle correctly, that principle would stop the ship of `<template onshadowroot>`, too. It's _possible_ to write a sanitizer that uses an enumerated DenyList of `onXXX` attributes. (Maybe they copied the list of event handlers from [https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers](https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers).) A sanitizer like that would sanitize `onload` `onclick` and `onmousemove` because they're on the DenyList, but wouldn't sanitize `onshadowroot`.

I want to be clear, a sanitizer like that would be _foolish_. It would not be the slightest bit futureproof against future global event handlers. If anyone has written a sanitizer like that, they were not considering the security problem properly… but, they are behaving correctly today, and therefore we must guarantee backwards compatibility with them.

Someone might wonder, "do any such sanitizers exist?" But that's not an acceptable question to ask in this forum. A DenyList-based sanitizer _could_ exist. If it did, it would fail to strip `onshadowroot`. That makes `<template onshadowroot>` a security risk, _on principle_, and therefore unacceptable.

I would go further and add that the principle I've been discussing entails that we can never add new HTML features (attributes _or_ elements) that run script, unless an opt-in mechanism is in place. `<template onshadowroot>` doesn't _run script_ exactly, but it does convert `<script>` tags contained within the `<template>` from inert to runnable, which is just as bad.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-718191339