Integrate fragment parser options with trusted types

[noamr]

In the places where TrustedTypes' createHTML is called,
we now also check for createParserOptions and call that if it's available, by calling "get trusted type compliant input" instead of "get trusted type compliant string".

This now allows us to use the sanitizer in legacy markup insertion methods (innerHTML, outerHTML, insertAdjacentHTML, createContextualFragment()), and to also disallow running scripts in createContextualFragment(). This also allows the policy to restrict modern calls like setHTMLUnsafe.

The exceptions to this are srcdoc, document.write(), DOMParser.parseFromString(), and the insertHTML execCommand. We can resolve separately as to whether these should also be sanitized with createParserOptions.

Since all markup insertion methods can now include a sanitizer, most of the steps from "set and filter HTML" are folded into the "fragment parsing algorithm steps", with handling of a null sanitizer when appropriate.

This PR also removes the = {} defaults from SetHTMLUnsafeOptions.sanitizer and ParseHTMLUnsafeOptions.sanitizer so that the default policy can distinguish between an omitted sanitizer member and an explicit configuration.

A default policy is only allowed to provide a sanitizer for HTML documents. In XML documents the createParserOptions shortcut does not apply, so createHTML (or a TrustedHTML) is still required, exactly as today.

Additionally, "configure a sanitizer" now clones its input configuration before canonicalizing, fixing an issue where the built-in safe default configuration singleton was mutated in place on first use.

Note that setting a sanitizer policy by trusted types has a known limitation, as the sanitizer configuration cannot handle JavaScript navigation URLs. See #12686

Together with w3c/trusted-types#606

• At least two implementers are interested (and none opposed):
  • Chromium
  • Gecko (based on HTML streaming & revamped DOM parsing mozilla/standards-positions#1370)
• Tests are written and can be reviewed and commented upon at:
  • Mark createParserOption tests non-tentative web-platform-tests/wpt#61260
  • Sanitizer: Assert that different calls don't modify the baseline configuration or each other web-platform-tests/wpt#62484 (tests that the configurations are immutable when passed to the Sanitizer)
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/491743369
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2043150
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=315741
• MDN issue is filed: Part of blink release process
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

[lukewarlow]

Two things for the top comment, I don't think you do fold set and filter html anymore?

Also this also doesn't touch execCommand with the insertHTML command. (This is probably the right move because that isnt specced correctly to start with. But worth calling out probably).

[noamr]

Two things for the top comment, I don't think you do fold set and filter html anymore?

Also this also doesn't touch execCommand with the insertHTML command. (This is probably the right move because that isnt specced correctly to start with. But worth calling out probably).

Thanks, OP updated.

[lukewarlow]

Did we decide it was okay to not enforce the sanitizing if the document was XML?

[noamr]

Did we decide it was okay to not enforce the sanitizing if the document was XML?

That's what I understood but @mozfreddyb, @evilpie or @otherdaniel would know more. Sanitization is not specified for the XML parser.
Note that this is the status quo that is not changed here - what this does is allows you to sanitize when setting HTML with one of the old methods (and soon with streaming).

[otherdaniel]

Did we decide it was okay to not enforce the sanitizing if the document was XML?

That's what I understood but @mozfreddyb, @evilpie or @otherdaniel would know more. Sanitization is not specified for the XML parser. Note that this is the status quo that is not changed here - what this does is allows you to sanitize when setting HTML with one of the old methods (and soon with streaming).

What I remember is that we specified Sanitizer API only for methods that would inherently only support HTML syntax. setHTML, setHTMLUnsafe, parseHTML, and parseHTMLUnsafe were all new methods, that simply don't support XML syntax. It's right there in the names. We didn't say what to do for XML syntax because we didn't have to.

This is probably best articulated in the hopelessly outdated explainer

Nearly all interesting bits are specified in terms of DOM & DOM operations, so I'd expect this to be easy to adapt to XML. But IMHO, application to XML-parser parse trees requires a second look, since it invalidates one of the assumptions we had when specifying any of this.

---

A silly example, but the only one I can think of: CDataSection in https://wicg.github.io/sanitizer-api/#sanitize-core step 1.1. That shouldn't be difficult to fix; but at least for now Sanitizer would assert-fail on (some) XML parse trees. In our implementation, there's a runtime assert there.

[lukewarlow]

I guess my main concern is people defining a trusted types policy with this new function thinking it protects them and then it doesn't because they're in XHTML or something?

Assuming I'm reading this right you'd end up with a default policy explicitly setup to remove unsafe and then it actually no-ops when it's called by a legacy sync in XML.

[noamr]

I guess my main concern is people defining a trusted types policy with this new function thinking it protects them and then it doesn't because they're in XHTML or something?
Assuming I'm reading this right you'd end up with a default policy explicitly setup to remove unsafe and then it actually no-ops when it's called by a legacy sync in XML.

You mean sink?

Yea it's limited in that way. But createHTML is still there... until we have some solution for this people should probably still use both in their policy or protect XML in other means.

[noamr]

I guess my main concern is people defining a trusted types policy with this new function thinking it protects them and then it doesn't because they're in XHTML or something?
Assuming I'm reading this right you'd end up with a default policy explicitly setup to remove unsafe and then it actually no-ops when it's called by a legacy sync in XML.

You mean sink?

Yea it's limited in that way. But createHTML is still there... until we have some solution for this people should probably still use both in their policy or protect XML in other means.

I think that the specific guidance to developers to be to check the type of document when they create the default policy, use createHTML with the appropriate userland sanitizer if either this is an XML document or TrustedParserOptions is not supported, and createParserOptions otherwise

[lukewarlow]

Non-authoratative LGTM. I'm still slightly unsure about the XML case mentioned above but if the consensus is that it's fine then I buy that.