on handling "unknown" elements

[mozfreddyb]

We've discussed handling unknown elements (e.g. <foo>) in the Sanitizer API.
@otherdaniel Made the point that experience from Trusted Types has shown developers and popular frameworks using them and there needs to be a way to support them.

We can just "detect" custom elements and allow them with the allowCustomElements boolean in the config. We'll continue preventing those unless explicitly enumerated in allowElements and enabled using the boolean above.

Unknown elements can not be detected.
One could infer that an element is truly unknown if it is neither in dropElements or blockElements and explicitly listed by the developer through allowElements.
For now, we've decided that this is OK without an extra boolean switch as unknown elements do not have any semantics unless someone explicitly operates on those elements after creation/insertion. They still need to be listed in allowElements.

The distinction between custom and unknown elements that we've currently made is that a custom element has more "power" and implicit semantics by virtue of inheriting from a potentially function-heavy element that the browser already knows and where the browser is implementing/performing the functionality of the element.

[mozfreddyb]

Just after writing our summary from the meeting, it occurred to me that we could more easily run into mismatch issues. Let's take the <portal> element as an example (regardless of the actual fate of that element. Let's just assume it's going to become enabled by default in a browser.)

For now, allowing this would just be like any other unknown element some browsers. But is this future proof?
Maybe this is completely the web developer's responsibility, given that they need to explicitly list in allowElements? Maybe this will be made future-proof by browser makers maintaining their drop/block defaults speedily?

Would be great to get a gut check on these thoughts from someone else here too. I'm not sure my analysis is completely sound.

[mozfreddyb]

There's also a fun mismatch where "<SCript>" can be created using document.createElementNS(), which really is not a HTML script element. If you have it in a DOM tree and sanitize it, we might just leave it be. Which is also fine, because it does not have the script semantics.

But when parsed, the parser will lowercase all element names and it will become an HTML script element.
There's also the case of things that are now considered "unknown" elements (see comment above) that might become "known" in the future.

So, if we allow "unknown" elements, should we make sure that they do not case-insensitively match disallowed names?
I'm not entirely sure if that's the takeaway. But all this mess makes me think we want to put "unknown" elements behind a boolean allowThingy like we have for allowCustomElements.

Thoughts, @otherdaniel, @annevk?

[annevk]

I guess part of the question here is what the threat model ought to be.

It's not just casing, but namespace as well. E.g., document.createElementNS("blah", "script") would not be blocked (if explicitly allowed), but when serialized and parsed can definitely end up in the HTML namespace and execute script.

So what's a principled answer here?

1. If you try to defend against the serialize and parse attacks: I suspect you'll have to ignore the namespace and case when comparing to the blocklist. You'll have to analyze other potential attack routes as well, such as doing weird tricks with comments, etc. This might be quite hard. See also the discussion at Valid/Invalid characters in document.createElement() whatwg/dom#849 (comment).
2. If you don't try to defend against these attacks:
   1. Having an explicit opt-in boolean makes sense to me at this point to indicate you are entering territory where the browser is no longer sure you are safe.
   2. It's less clear to me that it's principled to have an always blocklist that cannot be overridden, as it's clear you can override it with tricks. This might argue for revisiting that a bit.

cc @domenic

[Sora2455]

It's sounding to me as a developer like the only way to be safe is to use the whitelist config options for both elements and attributes.

[otherdaniel]

There's also a fun mismatch where "<SCript>" can be created using document.createElementNS(), which really is not a HTML script element. If you have it in a DOM tree and sanitize it, we might just leave it be. Which is also fine, because it does not have the script semantics.

But when parsed, the parser will lowercase all element names and it will become an HTML script element. There's also the case of things that are now considered "unknown" elements (see comment above) that might become "known" in the future.

So, if we allow "unknown" elements, should we make sure that they do not case-insensitively match disallowed names? I'm not entirely sure if that's the takeaway. But all this mess makes me think we want to put "unknown" elements behind a boolean allowThingy like we have for allowCustomElements.

It seems that case normalization is a more fundamental part of the web platform that it initially seemed. IMHO, the conclusion would be to leave case normalization in the Sanitizer, unlike what #145 suggests. I'd hate to have case normalization as a special rule for "unknown" elements only. If web authors have to generally deal with case-normalization, then IMHO the Sanitizer should generally deal with it as well.

boolean allowThingy for "unknown" elements is IMHO a reasonable idea. (By being default-disallowed it's already opt-in, though.)

It's not just casing, but namespace as well. E.g., document.createElementNS("blah", "script") would not be blocked (if explicitly allowed), but when serialized and parsed can definitely end up in the HTML namespace and execute script.

There is no syntax to allow a "blah" namespace in the Sanitzer, and I'd prefer to not introduce one either. The way element matching is written in the spec also makes it impossible for the Sanitizer to ever match a non-HTML/SVG/MathML element, so even if a Sanitizer config with a "blah"-namespaced element were constructible it wouldn't match anything. (The spec isn't entirely consistent, though. I should fix that.)

IMHO, a principled answer would be to concentrate on the guarantees the Sanitizer can make about its output: I think the Sanitizer's output should contain only HTML namespaced elements, plus the namespaced content referenced in the HTML spec.

(This matches my reading of the HTML spec, which seems to support arbitrarily namespaced elements only as a legacy concept. IMHO, this justifies restricting the Sanitizer to only support some namespaced content. But maybe I'm reading HTML wrong.)

[otherdaniel]

For now, allowing this would just be like any other unknown element some browsers. But is this future proof?

Sanitizer classifies elements in three groups:

• never. (Like <script>.)
• allowable. (Like <template>, that is not default-allowed, but can be explicitly listed in the config.)
• default-allowed. (Like <span>.)

(We don't use that vocabulary in the spec, but the distinction is there.)

Currently, "unknown" HTML elements are in the allowable group. If a new element is added to HTML, there are 3 options:

• Make it allowable => Everything stays as it is.
• Make it default-allowed => Technically not backwards-compatible, since a site might have relied on blocking this by default. But IMHO this means we (or, in the future, HTML editors) have decided that this element does not have any scriptable semantics, which I think makes this okay. Note that this only makes a difference if a site accepts the Sanitizer default, rather than supplying its own allow-list.
• Make it never => Presumably this means that the element now has "script-y" behaviour. In that case, the downgrade to never is backwards-incompatible, but that is IMHO exactly what an "ever-green" Sanitizer is supposed to do, and what we promised our users in the explainer.

Another interesting question is the reverse, if an element is removed. IMHO, never elements should stay never. Not sure about the other cases.

Currently, "unknown" elements are treated identically to other "allowable" elements. I'd prefer if it would stay that way. (A boolean "allowThingy" would change this. IMHO this is manageable, but makes me a bit hesitant.)

It's worth noting - in the context of this thread particularly - that elements in unknown namespaces (non-HTML, non-SVG, non-MathML) are currently all never. IMHO that's as it should be, provided my reading of HTML - that arbitrarily namespaced content is effectively deprecated - is correct.

[domenic]

Arbitrarily-namespaced content in XML-parsed/serialized HTML documents (i.e. "XHTML") is definitely not deprecated; it's useful for custom vocabularies etc.

In HTML-parsed/serialized documents it's pretty unlikely to be useful or show up at all, but I don't think it's deprecated in any formal way.

[otherdaniel]

Thanks, that makes a lot of sense.

Now I wonder whether XHTML is in scope for the Sanitizer or not. (I believe the case normalization is different for XHTML documents, too.)

[Andrew-Cottrell]

Now I wonder whether XHTML is in scope for the Sanitizer or not.

I have an implementation of a sanitizer within my JavaScript library. I have only ever needed to sanitize HTML-serialized content (which is generally supplied by an untrusted source, such as user generated content via CKEditor). If I did have a need to sanitize XHTML-serialized content that was embedded within an XML document (such as Atom), I would first parse as XML, extract and serialize the content as HTML, and then re-parse the HTML-serialized content using the Sanitizer. In my opinion, it would be OK for the Sanitizer to not have XHTML-serialized markup in scope (although polyglot markup would be supported in either case).

Now I think about it, I remember that I used to use XLink with SVG. There may be existing content using XLink that people might want to sanitize for some reason. But given this use of XLink is deprecated since SVG 2, it's reasonable to exclude it from scope.

[annevk]

@otherdaniel in the world of DOM HTML and XHTML documents are interchangeable. And the Sanitizer operates on the DOM. Hence the need for the Sanitizer to be case-sensitive.

[mozfreddyb]

@otherdaniel I believe #159 closed this, right?

[otherdaniel]

@otherdaniel I believe #159 closed this, right?

Yes, I think so.