LGTM3 On Wed, Dec 10, 2025 at 10:53 AM Daniel Bratell <[email protected]> wrote:
> LGTM2 > > /Daniel > On 2025-12-10 10:24, Yoav Weiss (@Shopify) wrote: > > LGTM1 > > This feels like a pile of bug fixes. The fact that we have a flag in place > makes me confident that even if this breaks in the wild, we'd be able to > quickly revert and handle it. > > On Monday, December 8, 2025 at 2:19:51 PM UTC+1 Daniel Vogelheim wrote: > >> 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 >> <https://wpt.fyi/results/trusted-types?sha=80ed8d6999&label=master&max-count=1&product=chrome%5Bstable%5D&product=chrome%5Bexperimental%5D> >> . >> >> 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 >> >> <https://wpt.fyi/results/trusted-types/set-attributes-require-trusted-types-default-policy.html?sha=80ed8d6999&label=master&max-count=1&product=chrome%5Bstable%5D&product=chrome%5Bexperimental%5D> >> 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 >> <https://chromium-review.googlesource.com/c/chromium/src/+/6243963> >> 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 >> >> <https://wpt.fyi/results/trusted-types/TrustedTypePolicyFactory-getAttributeType.html?sha=80ed8d6999&label=master&max-count=1&product=chrome%5Bstable%5D&product=chrome%5Bexperimental%5D> >> would be a good example. >> >> The fact that Safari launched their version of TT >> <https://webkit.org/blog/17333/webkit-features-in-safari-26-0/#web-api> >> 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 >> <http://issues.chromium.org/issues/330516530>. >> >> >> Daniel >> >> On Fri, Dec 5, 2025 at 11:00 PM Daniel Bratell <[email protected]> >> wrote: >> >>> 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 >>> On 2025-12-04 15:49, Chromestatus wrote: >>> >>> *Contact emails* >>> [email protected] >>> >>> *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 >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ETrustedTypes%22> >>> >>> *Web Feature ID* >>> trusted-types <https://webstatus.dev/features/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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> 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 desktop 145 >>> Shipping on desktop 145 >>> Shipping on Android 145 >>> Shipping on Android 145 >>> Shipping on WebView 145 >>> Shipping on WebView 145 >>> >>> *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 >>> <https://chromestatus.com>. >>> -- >>> 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 [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69319f7c.050a0220.107b62.1926.GAE%40google.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69319f7c.050a0220.107b62.1926.GAE%40google.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0f22c576-411e-4def-8832-eff74cd36d7e%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0f22c576-411e-4def-8832-eff74cd36d7e%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8OMv7PzdCH4YQ9B97f8o_BF3xqQBSJNWnbFBi1qC6pXA%40mail.gmail.com.
