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

> I completely understand the concern about XSS issues. But blocking an entire feature (or otherwise making it much less usable, e.g. by adding HTTP header [footguns](https://github.com/whatwg/dom/issues/831#issuecomment-716078525), or disallowing `innerHTML` usage) based on this concern doesn't seem to make sense to me.

Designing new feature to be secure by default is [pretty important](https://w3ctag.github.io/ethical-web-principles/#privacy) [design principle we have](https://www.w3.org/TR/html-design-principles/#secure-by-design).

> Browsers add new XSS vulnerabilities all the time - they're called "bugs".

Like @koto says, I suspect you're conflating UXSS and XSS. We certainly don't introduce new APIs that cause existing sites to have a brand new XSS vulnerabilities all the time. In fact, we work hard to avoid introducing such features.

> And security is an ongoing process of continuous work. That's why most browsers themselves are released very frequently, to be able to keep up with security issues. This is just another emerging security issue, which does need to be taken into account by sanitizer libraries. Fortunately, this one (as opposed to the bugs) is known ahead of time. I just don't believe we need to block all new features based on the oldest and/or most-misconfigured sanitizers in use across the web.

We certainly don't need to block *all* new features but it surely requires extraordinarily good features to warrant such a trade off. I certainly don't think declarative Shadow DOM is worth such a tradeoff.

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