[whatwg/dom] What is the "security policy" for adding new events and elements to the Web Platform? (#913)

In #831, there is a discussion about whether it is ok to add new html elements and/or attributes to the platform, if those additions could enable scripts to run. The issue/position put forth (e.g. [here](https://github.com/whatwg/dom/issues/831#issuecomment-717423013) and [here](https://github.com/whatwg/dom/issues/831#issuecomment-717890389)) is that **it is possible** for a site to configure an HTML sanitizer such that:
 1. Before the addition of the proposed new element/attribute, that sanitizer does not allow any **known** XSS vulnerabilities through the filter, **but**
 2. After the addition of the proposed new element/attribute, that sanitizer then suffers from a known XSS vulnerability.

If that situation is **possible**, then the conclusion (again, as presented [here](https://github.com/whatwg/dom/issues/831#issuecomment-717423013) and [here](https://github.com/whatwg/dom/issues/831#issuecomment-717890389)) is that we either must:
 1. Not add this feature to the web platform, or
 2. Provide a mitigation which prevents the vulnerability by default (e.g. through an enabling HTTP header)

If this is the "policy", it would seem to preclude several new features being proposed:
 1. [Declarative custom elements](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md)
 2. Really, any new HTML element, assuming it wants to support the existing event listener content attributes. For example, new form elements from [Open UI](https://open-ui.org/).
 3. Any new HTML events, assuming they would be accessible as a content attribute on existing elements.

This logically follows, since it is **possible** to construct a sanitizer that uses a deny-list, and constructs that deny list using only the element/attribute combinations available at a given point in time. Any **new** elements or attributes, even if they are "dangerous", would not be present in the deny list, and would therefore be allowed through this sanitizer.

**Should this be the "policy" for the web platform?**

One alternative viewpoint would be that we should instead work to guard against this situation:
1. Before the addition of the proposed new element/attribute, **well-configured, best-practices sanitizers** do not allow any known XSS vulnerabilities through the filter, but
 2. After the addition of the proposed new element/attribute, these sanitizers then suffer from a known XSS vulnerability.

There are several comments on #831 that appear to be supportive of this alternative way to think about risk mitigation (e.g. [this](https://github.com/whatwg/dom/issues/831#issuecomment-718529680), [this](https://github.com/whatwg/dom/issues/831#issuecomment-718532788), [this](https://github.com/whatwg/dom/issues/831#issuecomment-718722513), and (I think) [this](https://github.com/whatwg/dom/issues/831#issuecomment-718191339)). The difficulty, of course, becomes defining "well configured" sanitizers. This is not an easy job, and likely requires some judgement calls to be made, and data to be gathered. A few categories of sanitizer could potentially be pre-defined as "not well configured", e.g. those using fixed deny-lists. While this "policy" is a bit harder to define, it does seem to re-open the possibility of adding new elements and attributes to the web platform.

-- 
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/913