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

> Also client-side-only XSS-sanitization is an insecure-by-design anti-pattern. The discussion here shows why. You should not make assumptions about what the agent can or cannot do. You don't know.

Nooope :D Let's not generalize and again drift into areas this discussion might not even need to cover. There is lots of situations where client-side sanitation is the _only_ thing that can be done. Think E2EE messaging in the browser, for instance.

There is lots of things that can are are being done by web applications, we can never enumerate them all here and we shouldn't. 
What we should do (in my opinion and I might be wrong) is to think about: How can a DOM-based sanitizer deliver reliable sanitization results for closed shadowroots. It can for _open_ shadowroots without problems and did for the past five years. The only problem right now are the _closed_ ones (a.k.a. the ones the sanitizer sees as text nodes).

> One terrible but a sure way to mitigate the server-side XSS risk is to require an attribute that starts with "on" to enable declarative Shadow DOM on a template element:

Doing some weird prefixing is cargo-cult and will not help. This might help in a world where websites still rely on string-based sanitization. Which is a real anti-pattern. We are long past that with DOM-based sanitizers.

-- 
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-717131730