Can we add no-op/report?

[bkardell]

It seems to me that for trusted types to be really successful at what they are aiming to do, they need very large scale adoption and there's a bit here that feels to me less than ideal for achieving that. Mainly, if I set this up today, I think I have a few choices: I can let the bad thing happen and report only, or I can make it throw or return ''. In either of the latter cases I'm still letting something unknown and at least potentially bad happen on my site. Who knows what throwing would interrupt, for example (especially because many of these sinks didn't previously throw, so we don't even reason about that).

It really feels to me that what I, as a page author/website maintainer would prefer is an option to no-op and report.

Since this is all RHS appearing that feels impossible because you don't have context, but... If you think of sinks assigning as setters, this seems possible.

[koto]

Enforcing Trusted Types is done through Content Security Policy, and CSP supports a report-only mode which sounds like exactly something you suggest is needed. Trusted Types rollouts on existing applications (example) were using report-only mode extensively. You can also see report-only TT being used currently on many sites via Chrome's telemetry.

https://web.dev/articles/trusted-types#how_to_use_trusted_types describes the usual rollout process.

Is there anything in the API that you don't feel enables this safe, report-only/no-op rollout?

[lukewarlow]

what Brian means is that the default policy assignment could be a no-op. So the sinks still don't work and report but they don't throw.

Currently this isn't possible.

Would be special like returning null but instead it would be something to say it should no-op rather than throw.

[bkardell]

There isn't a no-op though, right? report-only is only report, right? It's not enforced, it lets the damage happen and only reports it. 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.

[koto]

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" for sink = string assignments , because that can break your application functionally, as the followup code may rely on the sink value being assigned correctly (e.g. p.innerHTML = '<div>'; p.querySelector('div')....). Silently ignoring sink assignments just makes the breakage hard to debug. Trusted Types intentionally fail fast.

[Sora2455]

Wouldn't the no-op version of TrustedTypes be:

const noOpTtPolicy = trustedTypes.createPolicy("noOp", {
    createHTML: (htmlString) => {
        return htmlString;
    },
    createScriptURL: (scriptUrlString) => {
        return scriptUrlString;
    }
});

CSP tells you where this isn't being used, and if you want you can put your own logging inside the policy methods?

[mbrodesser-Igalia]

Wouldn't the no-op version of TrustedTypes be:

const noOpTtPolicy = trustedTypes.createPolicy("noOp", {
    createHTML: (htmlString) => {
        return htmlString;
    },
    createScriptURL: (scriptUrlString) => {
        return scriptUrlString;
    }
});

No. What's asked for in this issue is preventing sink = string assignments from assigning to the sink. That would still happen with that policy.

CSP tells you where this isn't being used, and if you want you can put your own logging inside the policy methods?

[mbrodesser-Igalia]

@shhnjk: given your experience of deploying TT (#398 (comment)), what's your take on the necessity for a no-op mode?