Intent to Ship: Trusted Types spec alignment

175 views
Skip to first unread message

Chromestatus

unread,
Dec 4, 2025, 9:50:47 AM (6 days ago) Dec 4
to blin...@chromium.org, voge...@google.com
Contact emails
voge...@google.com

Specification
https://html.spec.whatwg.org/#:~:text=Trusted%20Types

Summary
Trusted Types (https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API) was originally implemented and launched in Chromium in 2019, and has since found use in numerous websites. It has recently gained interest from other browser vendors. The Trusted Type spec was co-written as a "monkey patch" spec along with our original implementation. It now receives fresh attention as others are trying to implement the same spec. It has now been "upstreamed" into HTML + DOM (plus a bit of CSP). As part of that process, various inconsistencies are being identified and fixed. Some of these fixes may be developer observable. This intent is to update our implementation to match the spec, as it's upstreamed into HTML. Meanwhile, WebKit has launched their implementation of the updated Trusted Types spec, which gives us high confidence that this update is highly web compatible.

Blink component
Blink>SecurityFeature>TrustedTypes

Web Feature ID
trusted-types

Motivation
The Trusted Types spec has been upstreamed into HTML, with some minor cleanups and changes. Our implementation should follow the updated spec to ensure cross-browser compatibility. Spec: https://w3c.github.io/trusted-types/dist/spec/ + https://html.spec.whatwg.org/

Initial public proposal
No information provided

TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
The goal is to achieve full cross-browser interoperability. Meanwhile, both WebKit and Firefox have enabled their version -- at least in testing builds -- without any major incompatibility reports. This makes us rather confident that the compability risk is low.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/20) Firefox has enabled their version in Nightly: https://www.firefox.com/en-US/firefox/145.0a1/releasenotes/

WebKit: Support (https://github.com/WebKit/standards-positions/issues/186) WebKit has launched their version: https://developer.apple.com/documentation/safari-release-notes/safari-26-release-notes#New-Features

Web developers: Positive

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided


Debuggability
No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
Yes
https://wpt.fyi/results/trusted-types/

Flag name on about://flags
No information provided

Finch feature name
TrustedTypesHTML

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/u/1/issues/330516530

Estimated milestones
Shipping on desktop145
Shipping on desktop145
Shipping on Android145
Shipping on Android145
Shipping on WebView145
Shipping on WebView145


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

All anticipated spec changes have landed in HTML, DOM, and CSP specs.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5163792014245888?gate=5109165432504320

Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMLJR2%3DBqAugsavCtqSR0Z_CQOgWHjeiyzpU0crTphANQ%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Daniel Bratell

unread,
Dec 5, 2025, 5:02:16 PM (4 days ago) Dec 5
to Chromestatus, blin...@chromium.org, voge...@google.com

Is there a diff-document or changelog or something else that can document what the actual change is? You say that "some [...] may be developer observable", and I guess it is those changes that matter here, but what are they?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69319f7c.050a0220.107b62.1926.GAE%40google.com.

Daniel Vogelheim

unread,
Dec 8, 2025, 8:19:51 AM (2 days ago) Dec 8
to Daniel Bratell, Chromestatus, blin...@chromium.org
Hi Daniel, et al.,

Unfortunately, I don't have a nice document with the changes. The WPT suite is quite thorough, however, and can provide us with a canonical list of observable differences: The TT-related test differences between our current stable version without the flag (i.e., implementation of the old spec) vs the current version with experimental flags enabled.

The changes are a fairly large grab bag of editorial changes and clarifications, where the original spec -- written as a "monkey patch" for HTML -- was incomplete or inconsistent. The intent of the changes was always to keep the existing behaviour, but to fill in under-specified or inconsistent bits. The "large" changes fall into three buckets:
  • Error reports (via CSPViolationException or CSP error reporting) contain the "sink name", usually the element + attribute name. These have changed in quite a few cases.
    • This test would be a good example. The original "sink names" we used were fairly ad-hoc. E.g. when calling `setAttribute("onclick", ...)` we'd report "Element setAttribute" as the sink. The current spec wants this to be "Element onclick", which admittedly makes a lot more sense.
  • The order of checks within a DOM method, i.e., when exactly the TT check is run, has now been properly specified. This is oftentime observable when you have competing error conditions.
    • This CL would be a good example. Note that the implementation change only moved a few lines of code around, but fixed a fairly large number of WPT tests in the process.
  • Trusted Types (when enabled) mostly just blocks invocation of some DOM methods on some elements/attributes, but it also allows you to query on which attributes it would do so. These "metadata" functions have been more thoroughly specified, especially with respect to namespaces.
    • These functions were originally somewhat underspecified. The updated spec is a lot more clear, and our implementation adapts to this. This test would be a good example.
The fact that Safari launched their version of TT without much notice of these differences makes me quite confident that websites aren't inadvertently relying on them.

All implementation changes are tracked in the tracking bug.


Daniel
Reply all
Reply to author
Forward
0 new messages