[snek]

We have APIs to put content in DOM elements without it being interpreted as html, and we have APIs to build DOM elements without using strings. Given that trusted types don't actually prevent xss from occuring and only make your data flow more explicit, why not just recommend to developers that they use the other APIs, instead of adding this new one?

[koto1sa]

I don't think you can build applications without using the dangerous sinks at all yet. Some common scenarios we know are common:

window.open href Setting text on a script element Setting src of a script element form.action innerHTML

Applications do use these sinks quite often, and some of them cannot be just get ridden of (e.g. href or script.src). Even removing eval takes ages. Complex applications parse HTML from the users, load scripts dynamically, and such.

That said - TT allow you to have such enforcement too - just set a "Content-Security-Policy: trusted-types;" header and all dangerous sinks can never be called. We call it Perfect Types, but it's not yet practical to build client side applications in that setting.

[snek]

Your response makes it sound like this is intended more for cases where a site uses innerHTML and its too much of a burden to rewrite, so you allow only that innerHTML, but that allowed innerHTML is still susceptible to XSS, so what is the point?

As a side note, having a header to disallow innerHTML and etc is definitely a good step, but the rest of this seems superfluous or even leading to a false sense of security.