This was discussed at some length in today's API OWNERS call, working through the logic and risk profile. Given that there is a feature flag, we are happy to go forward given that it can be rolled back via Finch if there's an error.
LGTM2. On Friday, October 9, 2026 at 7:03:31 AM UTC-7 [email protected] wrote: > Hi Daniel, Mike and Philip, > > Thanks for the questions. I’ve reviewed the affected code paths, checked > the Actor interaction, and completed the browser comparisons. I’ll address > the points together below. > > *1. Specification basis and motivation* > > I should have linked the MIME minimization algorithm directly, rather than > only the XML MIME type definition. > > The XML definition includes text/xml, application/xml, and MIME types > whose subtype ends in +xml. > > The minimization algorithm preserves image/svg+xml in step 3 and returns > application/xml for other XML MIME types in step 4: > > > - https://mimesniff.spec.whatwg.org/#xml-mime-type > - https://mimesniff.spec.whatwg.org/#minimize-a-supported-mime-type > > Fetch uses this algorithm when recording response information for Resource > Timing, and PerformanceResourceTiming.contentType exposes that recorded > value: > > > - https://fetch.spec.whatwg.org/#fetch-response-handover > - > > https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-contenttype > > This is a conformance change, not a fix motivated by a particular security > vulnerability. It changes the MIME value recorded for Resource Timing. It > does not rewrite the server’s HTTP Content-Type header or response body, > and the timing value does not select a parser or external application. > > There is a separate effect on Actor because it uses the same > classification helper; I address that below. > > *2. Implementation scope and classifier unification* > > The implementation is here: > > https://chromium-review.googlesource.com/c/chromium/src/+/8301932 > > This CL changes blink::IsXMLMimeType, which is used by Resource Timing > minimization and Actor’s MIME checks. > > MIMETypeRegistry::IsXMLMIMEType is a separate implementation. It already > recognizes non-application +xml types in cases such as those tested here, > and this CL does not change it. XHR uses that implementation, as do > renderer document-type and decoder-selection paths. > > Object embedding and navigation also involve MIME-support and download > decisions. Recognizing something as XML does not, by itself, establish that > the browser will display it as an XML document when navigated to. > > The proposed unification of the two classifiers is outside this CL. That > work would need a separate assessment of the callers and behavior > differences before proceeding. > > *3. Browser comparisons and feature OFF/ON results* > > I tested the following installed release browsers on macOS 26.5.1 (25F80), > without changing experimental flags: > > - Safari 26.5 (21624.2.5.11.4) > - Firefox 157.0.1 > - Google Chrome 154.0.8037.58 > > I used a local HTTP server to serve a small XML document with different > Content-Type headers. Requests were same-origin. The results below focus on > text/example+xml, image/example+xml and font/example+xml. > > The tests were run on October 9, 2026. The normal response body was a > small XML document with a probe element containing XML_TEST_OK. XHR, > decoding and Resource Timing results were collected automatically. For > objects, I recorded document information as well as the displayed result; > direct navigation was checked manually. > > Object embedding: > > I checked each response with the object’s type attribute omitted and > explicitly set. > > > - For text/example+xml, all three browsers displayed source text > without the attribute. With it specified, Chrome and Firefox displayed > source text, while Safari displayed fallback content. > - For image/example+xml and font/example+xml, Firefox and Safari > displayed fallback in both cases. Chrome showed a blank view without type > and fallback with it. The blank cases still had pending events when > sampled, so I can’t say whether they had reached a final state. > > Direct navigation: > > > - All three browsers displayed text/example+xml as source text and > downloaded image/example+xml and font/example+xml. > > XHR document responses: > > > - All three parsed these responses as XML in both the default response > mode and responseType="document". > > XHR text decoding: > > I served an XML declaration specifying windows-1252, with body bytes > representing “café” in that encoding. > > > - The returned text matched across browsers. Default XHR without an > HTTP charset used the XML declaration and returned “café”. Explicit > responseType="text" returned “caf�”. Adding an HTTP charset=utf-8 also > produced “caf�” in both modes. > - There was a separate responseXML difference in that deliberately > invalid UTF-8 case: Firefox returned null, while Chrome and Safari > returned > a document containing the replacement character. > > Effect of this CL: > > I repeated these checks with the same local Chromium 157.0.8092.0 build, > with SpecCompliantXmlMimeTypes disabled and enabled in separate profiles. > > > - I observed no differences in these four areas between OFF and ON. > - The recorded differences were the Resource Timing contentType values > for the three MIME types above, which became application/xml with the > feature enabled. > > So the engines agree on XML parsing for these normal XHR fixtures, but > that does not extend to every use of the XML MIME definition. In > particular, object handling differs, and direct navigation does not display > these responses as XML documents. > > These are observations from local tests on one OS, not an official WPT > run. > > The implementation also includes C++ tests for both feature states. The > WPT additions for Resource Timing minimization are here: > > https://github.com/web-platform-tests/wpt/pull/62420 > > *4. Compatibility and RUM providers* > > Code that branches on the old contentType values, or uses them to group > resources in reports, could behave differently when it receives > application/xml. > > I don’t have usage measurements or RUM-provider feedback showing how often > sites rely on those values. The tests above tell us what changes, but not > how much breakage to expect. > > I don’t have a RUM-provider request or issue to point to; this change is > driven by spec conformance. This intent thread is where I’ve raised the > behavior change for review. > > I also don’t have evidence that enterprise applications are more likely to > be affected. I shouldn’t have singled them out in the original description. > The same concern applies to any application relying on the previous values. > > For the application/atom+xml example, Chrome already reports > application/xml in both the installed version and the local build. That > value is not newly changed by this feature. > > *5. Actor* > > This change is driven by spec conformance; I don’t have a RUM-provider > request or issue to point to. I’ve raised the behavior change in this > intent thread, but haven’t contacted RUM providers directly. > > Code that branches on the previous contentType values, or uses them to > group resources in reports, could behave differently when those values > become application/xml. The local tests show which values change, but I > don’t have usage measurements or provider feedback to estimate how often > this would cause problems. > > There’s no evidence that enterprise applications are more likely to be > affected, so I shouldn’t have singled them out in the original description. > The same concern applies to any application relying on the previous values. > > For the application/atom+xml example, Chrome already reports > application/xml in both the installed version and the local build. That > value is not newly changed by this feature. > > *6. Mozilla and WebKit positions* > > I followed up on the existing position issues to ask whether they cover > this change. > > Mozilla: > https://github.com/mozilla/standards-positions/issues/705#issuecomment-6030333458 > > WebKit: > https://github.com/WebKit/standards-positions/issues/88#issuecomment-6030345052 > > WebKit confirmed that its existing position covers this, since > minimization was a condition of its support. The Mozilla link is my > follow-up question, rather than a confirmation from Mozilla. > > Thanks, Wonik > 2026년 10월 8일 목요일 오후 9시 19분 25초 UTC+9에 Philip Jägenstedt님이 작성: > >> Hi Wonik, >> > >> I'd like to understand the compat and interop risks a little better here. >> The change is to Chromium's implementation of >> https://mimesniff.spec.whatwg.org/#xml-mime-type, and in specs that >> affects a lot more than resource timing. >> >> *Compat risk* >> >> Starting from >> https://dontcallmedom.github.io/webdex/x.html#XML%20MIME%20type%40%40mimesniff%25%25dfn, >> >> I found these places: >> >> - https://html.spec.whatwg.org/#the-object-element, where it seems we >> might treat more responses as XML and render them instead of treating as >> unsupported >> - https://html.spec.whatwg.org/#loading-a-document, which presumably >> affects navigation directly to such resources >> - https://xhr.spec.whatwg.org/#document-response, which I think will >> cause more responses to be parsed as XML >> - https://xhr.spec.whatwg.org/#text-response, seems to only affect >> how encoding is detected (less likely to break things badly) >> >> >> Will all of these also change in Chromium, or are they all part of >> the MIMETypeRegistry::IsXMLMIMEType unification? >> >> *Interop risk* >> >> Can you test what Gecko and WebKit do for the above cases connected to >> the same definition? You mentioned Gecko's XHR implementation and WebKit's >> XML MIME classification code, but which of the cases in the spec does this >> map to? >> >> To ensure all engines align on a change that won't break existing >> content, having test cases and their results across all the engines in >> their stable configuration would be very helpful. As it is, I can't judge >> if Firefox+Safari already completely match the spec and Chrome is the >> outlier, or if it's more complicated. >> >> Best regards, >> Philip >> > >> On Wed, Oct 7, 2026 at 4:30 PM Mike Taylor <[email protected]> wrote: >> >>> \On 10/7/26 12:38 a.m., Wonik Choi wrote: >>> >>> Hi Mike, >>> >>> I’ve documented the Actor interaction in this bug comment #12 >>> <https://issues.chromium.org/u/1/issues/362282752#comment12>. Could you >>> point me to the appropriate Actor owner to review this? I’d also like to >>> confirm whether the existing security review covered these behavior changes. >>> >>> >>> https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/actor/OWNERS >>> has >>> a list of folks who can review. >>> >>> Thanks >>> >>> >>> 2026년 10월 6일 화요일 오후 7시 1분 28초 UTC+9에 [email protected]님이 작성: >>> >>>> On 10/5/26 11:24 p.m., Chromestatus wrote: >>>> >>>> *Contact emails* >>>> [email protected] >>>> >>>> *Specification* >>>> https://mimesniff.spec.whatwg.org/#xml-mime-type >>>> >>>> *Summary* >>>> Chrome is updating how it Detects XML MIME types to fully align with >>>> Web standards. Chrome will now recognize valid MIME types whose subtype >>>> ends in `+xml` as XML across Chrome and Android WebView, including >>>> non-application types such as `text/example+xml` and `image/example+xml`. >>>> For these responses, `PerformanceResourceTiming.contentType` returns >>>> application/xml. The value for image/svg+xml remains unchanged. Enterprise >>>> web applications that rely on previous `contentType` values may observe >>>> behavior changes. Chrome Actor also uses this shared XML classification >>>> for >>>> dangerous MIME type navigation checks, so it may block navigations to >>>> additional non-application +xml responses. IT admins should check whether >>>> their applications depend on these MIME types or the previous >>>> `contentType` >>>> values. >>>> >>>> *Blink component* >>>> Blink>Network >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22> >>>> >>>> *Web Feature ID* >>>> *No information provided* >>>> >>>> *Motivation* >>>> Chromium currently applies generic +xml suffix matching only to >>>> application/* MIME types, although the WHATWG MIME Sniffing Standard >>>> defines any valid MIME type whose subtype ends in +xml as an XML MIME >>>> type. >>>> As a result, non-application types such as text/example+xml are not >>>> minimized to application/xml in PerformanceResourceTiming.contentType. >>>> This >>>> change aligns Chromium's classification with the existing standard and >>>> improves interoperability. Implementation (merged behind an experimental >>>> feature): >>>> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 >>>> >>>> *Initial public proposal* >>>> *No information provided* >>>> >>>> *TAG review* >>>> Requesting a TAG review exception for this small conformance change to >>>> the existing WHATWG MIME Sniffing Standard. The change broadens XML MIME >>>> type suffix matching to include non-application types. No new API surface >>>> or API design is introduced. >>>> >>>> *TAG review status* >>>> Not applicable >>>> >>>> *Goals for experimentation* >>>> None >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> This change aligns XML MIME type classification with the existing >>>> WHATWG MIME Sniffing Standard. The web-visible change is that >>>> PerformanceResourceTiming.contentType returns "application/xml" for >>>> additional non-application MIME types whose subtype ends in "+xml". Code >>>> that depends on the previous contentType value may observe a different >>>> result. The special handling of "image/svg+xml" is preserved. The change >>>> is >>>> controlled by SpecCompliantXmlMimeTypes, allowing the previous behavior to >>>> be restored by disabling the feature. >>>> >>>> From what I can tell this change is just scoped to resource timing, so >>>> only a handful of RUM providers would be affected (in the hypothetical >>>> that some script is expecting "application/atom+xml" via >>>> PerformanceResourceTiming.contentType but now seeing "application/xml" and >>>> exploding). Is there some issue where RUM providers are asking for this / >>>> might find out about the change? >>>> >>>> Even so, I'd love to better understand the compat risk of this proposed >>>> change. Above it mentions "Enterprise web applications that rely on >>>> previous `contentType` values may observe behavior changes" - do we think >>>> enterprises are more likely to be affected by this change? Are we able to >>>> estimate or reason about breakage for non-enterprise use cases? e.g., some >>>> site is expecting "application/atom+xml" via >>>> PerformanceResourceTiming.contentType but now seeing "application/xml" >>>> going to break something (that sounds far-fetched, I dunno)? >>>> >>>> As an aside, >>>> https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/actor/execution_engine.cc;l=288-299 >>>> >>>> should probably be looked at by the security reviewer/other owners for >>>> this >>>> change. "image/svg+xml" will start to return true here with this change, >>>> when it return false before, if I'm reading the code correctly. >>>> >>>> I see in your CL >>>> <https://chromium-review.git.corp.google.com/c/chromium/src/+/8301932/comments/dabacf37_52e1d902> >>>> >>>> you wrote "MIMETypeRegistry::IsXMLMIMEType unification is intentionally >>>> left as follow-up" - can you explain your plan there? That seems like a >>>> riskier change to me, since it will affect navigation & loading. >>>> >>>> >>>> *Gecko*: No signal Firefox recognizes non-application "+xml" MIME >>>> types in its XHR implementation, but the Resource Timing minimization >>>> behavior differs. In the WPT PR #62420 run dated 2026-09-04, Firefox >>>> Nightly 157.0a1 failed all five added XML cases. For example, contentType >>>> returned "text/example+xml" instead of "application/xml". Results: >>>> https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664 >>>> >>>> No formal standards position has been requested. An exception is requested >>>> for this small conformance change, subject to API owner review. >>>> >>>> We should probably request a formal position at >>>> https://github.com/mozilla/standards-positions, because the ideal >>>> outcome is all browsers are doing the same thing rather than diverging in >>>> subtle ways. >>>> >>>> >>>> *WebKit*: No signal WebKit recognizes non-application "+xml" MIME >>>> types in its XML MIME classification code. This does not establish support >>>> for PerformanceResourceTiming.contentType. In the WPT PR #62420 run dated >>>> 2026-09-04, Safari Technology Preview 251 failed all five added XML cases >>>> because contentType was undefined. Results: >>>> https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=5125540410556416 >>>> >>>> No formal standards position has been requested. An exception is requested >>>> for this small conformance change, subject to API owner review. >>>> >>>> Ditto here - https://github.com/WebKit/standards-positions please. >>>> >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> *Ergonomics* >>>> No new API or calling convention is introduced. Developers continue to >>>> read PerformanceResourceTiming.contentType through the existing Resource >>>> Timing API. >>>> >>>> *Activation* >>>> No developer opt-in is required. Applications that rely on the previous >>>> contentType value for non-application "+xml" responses may need to adjust >>>> their expectations. >>>> >>>> *Security* >>>> The change broadens the MIME types classified as XML by >>>> blink::IsXMLMimeType. It does not change the existing response-access >>>> checks that govern exposure of PerformanceResourceTiming.contentType. The >>>> shared helper is also used by Chrome Actor's dangerous-MIME-type >>>> navigation >>>> checks. When those checks and SpecCompliantXmlMimeTypes are enabled, >>>> additional non-application "+xml" types may be blocked. >>>> >>>> *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? >>>> Applications that inspect PerformanceResourceTiming.contentType may >>>> observe "application/xml" for additional non-application "+xml" MIME >>>> types. >>>> Applications that depend on the previous value may behave differently. The >>>> change is guarded by SpecCompliantXmlMimeTypes, which provides a way to >>>> restore the previous behavior. >>>> >>>> >>>> *Debuggability* >>>> 1. Basic support Manually checked on macOS using Content Shell with >>>> --enable-features=SpecCompliantXmlMimeTypes and DevTools attached to the >>>> test page. Console evaluation and autocomplete worked during the check. >>>> Chrome DevTools for agents was not separately tested. 2. Inspectability A >>>> local server returned Content-Type: text/example+xml. The response was >>>> fetched and its PerformanceResourceTiming entry was obtained through >>>> PerformanceObserver. Reading entry.contentType in the DevTools Console >>>> returned "application/xml" as expected. Autocomplete for contentType was >>>> also verified. The server's original Content-Type header and the minimized >>>> Resource Timing value are distinct. 3. Extended support No dedicated >>>> DevTools workflow is proposed. The changed value can be inspected through >>>> existing Console functionality. 4. Automated testing Yes. The existing WPT >>>> resource-timing/content-type-minimization.html exercises the added >>>> non-application "+xml" cases. Implementation: >>>> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 WPT >>>> export: https://github.com/web-platform-tests/wpt/pull/62420 >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> Yes >>>> The change uses shared Chromium MIME classification code with no >>>> platform-specific restrictions. Support is intended for Windows, macOS, >>>> Linux, ChromeOS, Android, and Android WebView. >>>> >>>> *Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> Yes >>>> The implementation adds test cases to: >>>> mimesniff/mime-types/resources/mime-types-minimized.json These cases are >>>> exercised by: resource-timing/content-type-minimization.html Coverage >>>> includes text/example+xml, image/example+xml, font/example+xml, uppercase >>>> MIME types, and MIME parameters. Parameterized C++ unit tests cover both >>>> enabled and disabled feature states, existing XML MIME types, additional >>>> "+xml" types, and invalid MIME inputs. Implementation and tests: >>>> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 WPT >>>> export: https://github.com/web-platform-tests/wpt/pull/62420 The WPT >>>> additions were merged upstream on September 30, 2026: >>>> https://github.com/web-platform-tests/wpt/pull/62420 PR-level browser >>>> results are available, including the five added XML cases: >>>> https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664&run_id=5125540410556416 >>>> >>>> *Flag name on about://flags* >>>> enable-experimental-web-platform-features >>>> >>>> *Finch feature name* >>>> SpecCompliantXmlMimeTypes >>>> >>>> *Rollout plan* >>>> Will ship enabled for all users >>>> >>>> *Requires code in //chrome?* >>>> False >>>> >>>> *Tracking bug* >>>> https://issues.chromium.org/issues/362282752 >>>> >>>> *Measurement* >>>> No dedicated UseCounter is added by this change. The occurrence of >>>> affected non-application "+xml" MIME types is not separately measured by >>>> this implementation. >>>> >>>> *Availability expectation* >>>> Expected to be available by default on Blink platforms after launch >>>> approval and default enablement of SpecCompliantXmlMimeTypes. >>>> >>>> *Adoption expectation* >>>> Existing users of PerformanceResourceTiming.contentType will receive >>>> spec-compliant values for additional XML MIME types without changing their >>>> API usage. No quantitative adoption estimate is available. >>>> >>>> *Adoption plan* >>>> Communicate the behavior change through the Blink intent process and >>>> track any necessary documentation and browser compatibility updates. >>>> >>>> *Non-OSS dependencies* >>>> >>>> Does the feature depend on any code or APIs outside the Chromium open >>>> source repository and its open-source dependencies to function? >>>> None. The implementation uses Chromium code and its existing >>>> open-source dependencies. >>>> >>>> *Estimated milestones* >>>> Shipping on desktop 158 >>>> Shipping on Android 158 >>>> Shipping on WebView 158 >>>> >>>> *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). >>>> None anticipated. This change implements the existing XML MIME type >>>> definition and MIME type minimization rules in the WHATWG MIME Sniffing >>>> Standard. >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/5092584283308032?gate=6712519581368320 >>>> >>>> *Links to previous Intent discussions* >>>> Intent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a922400.e8a51b51.6abb3.033c.GAE%40google.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/6ac46a00.082f26cb.22c2b.02d5.GAE%40google.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac46a00.082f26cb.22c2b.02d5.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/2c8015ee-38c6-4ccf-ad3b-8213cef63aba%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c8015ee-38c6-4ccf-ad3b-8213cef63aba%40chromium.org?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/8752ed0e-df7d-43d9-b060-c49029bf8437n%40chromium.org.
