Krzysztof Kotowicz

Enforcing Trusted Types is done through Content Security Policy, and CSP supports a [report-only mode](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#testing_your_policy) which sounds like exactly something you suggest is needed. Trusted Types rollouts on existing applications...

> I would like to make it possible to be enforced, but the enforcement is just "return" in the setter, so it cannot impact the page. There is no "no-op"...

> This allows shipping v1 without guarding all injection sinks. Covering the remaining sinks (https://github.com/w3c/trusted-types/issues/385) could be done in v2. I'm not sure I follow. Do you propose to only...

All injection sinks are covered, some are covered not on the IDL+`[[StringContext]]` layer, e.g. https://w3c.github.io/trusted-types/dist/spec/#enforcement-in-event-handler-content-attributes, https://w3c.github.io/trusted-types/dist/spec/#require-trusted-types-for-pre-navigation-check, or the eval-related sinks.

I don't think there's a single authoritative, exhaustive and up-to-date list of those, but the implementation following the spec should cover all of them, to the best of our knowledge....

+1. Let's not add `getTypeMapping`, nor `beforecreatepolicy`

I don't think there are, at least in Web APIs? For TT (or, more generally, CSP) it's a known limitation. Controls are per-document or realm, whereas XSS affects the whole...

+1 to removing them, after confirming they see no significant enough usage.

+1 to what mikesamuel@ said. For runtime-enforced security, it's necessary to be able to constrain later running code, and the features as described here would make that impossible.

I need to find out on which machine I have the build environment for this project, it's pretty much abandoned. Can someone just clone the repo and create a separate...