Ensure to document compatibility with Trusted Types createHTML

[evilpie]

The createHTML function in the TrustedTypePolicy takes a string input and is supposed to return a sanitized version of that HTML. This is a pretty obvious use case fo the Sanitizer API. However since we removed the methods for actually sanitizing to a string from the API, there is actually no direct way of doing this. One of the main reasons for the removal were concerns about reparsing HTML actually being unsafe. I think we might want to think about some way of integrating the Sanitizer and Trusted Types that wouldn't involve any reparsing and intermediate HTML strings.

/cc @lukewarlow @fred-wang

[annevk]

Isn't the idea that setHTML() doesn't go through TT because it guarantees unsafe bits have been removed? If there are other places where you would use the output of createHTML we should probably introduce equivalent methods. (I proposed prependHTML() and such in the past.)

[lukewarlow]

I think previously iframe.srcdoc was the other place that came up as a potentially legitimate place that's not covered.

Prepend I guess you could do via setHTML(newHTML + getHTML()) but that's still got a serialize, reparse cycle that you might not want.

[Sora2455]

Wasn't this issue previously raised in #204?

[mozfreddyb]

+1 to what @annevk says: setHTML() is not going to be controlled by TT because it guarantees XSS-safety.

If people want to plug their own sanitizer into TT, they will currently have to setHTML + get again, which causes a parsing roundtip and that is said. We might want to look at the Sanitizer doing string-based inputs as a v2 thing

[annevk]

Solving this properly would require patching all legacy sinks to take TrustedHTML objects that are backed by a node. And create a way to create such objects. That is a lot of effort for legacy code bases.

[lukewarlow]

Yeah I don't think we need to support this for stuff like DOMParser as that's explicitly outdated for html. For other sinks that don't have a modern equivalent maybe it's interesting. But we should probably just make a new API that's safe and probably better in other ways. Like does iframe.srcdoc support DSD?

[evilpie]

Solving this properly would require patching all legacy sinks to take TrustedHTML objects that are backed by a node. And create a way to create such objects. That is a lot of effort for legacy code bases.

Thanks Anne, this is pretty much what I imagined. I agree that it is probably not worth it.

There might be some places where we should warn about re-parsing issues, like MDN, the Trusted Types and the Sanitizer specifications.

I have also previously said that using Sanitizer for Trusted Types would be useful, which I am not going to do unconditionally now.

[evilpie]

Ha!

I think once upstreamed a note explaining why the safe variants don't use Html string could be useful, even if just as a note to make it clear it's a deliberate choice.

#204 (comment)

[mozfreddyb]

Can we close this and fold it into #291?

[o-t-w]

Would it be worthwhile for Trusted Types to be able to enforce partial sanitisation when working with setHTMLUnsafe()?

Currently I might do the following just to avoid the Trusted Types TypeError.

const passThroughPolicy = trustedTypes.createPolicy("foo", {
    createHTML: (input) => input
});
const trustedHTML = passThroughPolicy.createHTML(html);

And then use the second argument to setHTMLUnsafe to use a sanitiser in a more limited way than what is enforced by setHTML():

document.querySelector('target').setHTMLUnsafe(trustedHTML, {sanitizer: semiSanitizer});

I would rather do the sanitization as part of createHTML but there's no way to do that.

[lukewarlow]

Something that would solve your use case is being discussed in w3c/trusted-types#594 (comment), if that happens you'd just pass the raw string to setHTMLUnsafe but you'd define a trusted options bag for the second param.