Hi Daniel,
Thanks for looking into this. I should have linked the minimization algorithm directly and been clearer about which value changes. This does not rewrite the HTTP Content-Type header. For example, a same-origin response still has Content-Type: text/example+xml, but its PerformanceResourceTiming entry reports "application/xml". The original header and body are unchanged, as are the existing restrictions on exposing response details. The relevant requirement is in the MIME minimization algorithm <https://mimesniff.spec.whatwg.org/#minimize-a-supported-mime-type>: step 3 preserves image/svg+xml, and step 4 returns application/xml for XML MIME types. Fetch’s timing reporting steps <https://fetch.spec.whatwg.org/#fetch-response-handover> use that algorithm to populate the value returned by PerformanceResourceTiming.contentType <https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-contenttype> . Chromium already does this for text/xml, application/xml, and valid application/*+xml types. The intended change covers valid non-application types ending in +xml. This is a conformance fix, rather than a fix for a particular security vulnerability. The timing value does not determine which parser or external application opens the response. There is a separate Actor effect, which Mike also pointed out. Actor uses the shared XML helper for navigation blocking, so its treatment of SVG and other inputs can change. I’ll follow up with the Actor owners and security reviewer before default enablement. My statement that SVG is unchanged referred to its Resource Timing value; I should have made that distinction explicit. I’ll update the feature description with these links and a clearer explanation of the scope. Thanks, Wonik 2026년 10월 6일 화요일 오후 6시 11분 3초 UTC+9에 [email protected]님이 작성: > Two sections in this response: > 1. either the citations are very broken, or the motivation for this change > is mistaken > 2. why this change seems to contradict IETF standards > > # Quote Not Found in Citation > The justification for this change in behavior cites the WHATWG spec: > > Interoperability and Compatibility > > This change aligns XML MIME type classification with the existing WHATWG > MIME Sniffing Standard. > > It links to the capacious definition of an "XML mime type" in the > specification linked at top: > > On Monday, October 5, 2026 at 11:25:07 PM UTC-4 Chromestatus wrote: > > *Contact emails* > [email protected] > > *Specification* > https://mimesniff.spec.whatwg.org/#xml-mime-type > > > This specification is correctly interpreted to cover text/*+xml as well > as application/xml. That part already appears to be unilaterally > implemented across all browsers. > > What chrome is proposing here is to transform the MIME type into > application/xml. I have been unable to find any justification or precedent > for actively overwriting information in this way—except for a section in > the linked rfc 2046 <https://www.rfc-editor.org/info/rfc2046/>, which is > incorrectly > titled [RFC7303] in the cited spec section > <https://mimesniff.spec.whatwg.org/#xml-mime-type>. > > The WHATWG spec does not specify normalization into application/xml, which > is clearly described as a subtype of the XML MIME types. From the RFC > numbering mistake, I assume there must be a distinct specification that > chrome is referencing to motivate this facially counterintuitive behavioral > change, which in its current form is both forwards and backwards > compatible, by coercing data into a separate valid identifier. I'm not a > WHATWG wiz yet, so I assume chrome has some very strong precedent for > modifying the observed contentType in this way—I would really appreciate a > link so I can learn where this change comes from. Because contentType > coercion is otherwise a complete fabrication outside the spec, according to > the information given herein. > > I assume chrome would not take this step without a strong security > justification—can you please provide a description of what motivated chrome > to propose this change at this time? I understand security concerns are > highly sensitive—a very high-level "yes" or "no" would be helpful here. > > # IETF Precedent > While it remains unclear whether RFC 2046 is the correct reference at all, > it does offer some very specific feedback about interpreting xml types. I > foresee direct application security concerns arising from the proposed > contentType coercion, as well as multiple contradictions with the spirit of > RFC 2046. > > ## Precedent _In Favor_ > I begin with the point in favor of chrome's approach: > > > It may be the case that some user agents, if they can recognize more > than one of the formats, will prefer to offer the user the choice of which > format to view. This makes sense, for example, if a message includes both a > nicely-formatted image version and an easily-edited text version. What is > most critical, however, is that the user not automatically be shown > multiple versions of the same data. Either the user should be shown the > last recognized version or should be given the choice. > > In this proposal's favor, this makes clear that the user agent can and > should apply judgement regarding the form to present. I do not contest that > at all—as above, if this resolves a security concern, I would defer to the > cybersecurity experts' judgement. > > However, the capacity for interpreting formats in this 1997 RFC describes > several assumptions and limitations on that capacity, which I believe > contradict the motivation for this change to chrome behavior. > > First off, it should be evident that the RFC *strongly prefers* and in > fact *assumes* the user agent will provide the *most applicable* form *for > the context of the request* (and, by implication, supports delegating all > the way to the user themself to select the desired format). Secondly, and > much more crucially, in no way does this allow *actively overwriting* the > format as per this proposal—the framework *selects* from the *given* types. > > ## Application is Abstract Interpretation > Particularly puzzling are the examples given of overwriting /text and > /image to application/xml. Elsewhere in RFC 2046, we find: > > 4.5. Application Media Type > > The "application" media type is to be used for discrete data which do > not fit in any of the other categories, and particularly for data to be > processed by some type of application program. This is information which > must be processed by an application before it is viewable or usable by a > user. > > text and images would seem to be the very definition of data the browser > would be expected to interpret. If chrome does not support data in these > formats, I would assume it could request an external handler program (e.g. > the way torrent files pop up a dialog for a handler program from the OS). > Here's where I suspect I'm mistaken—rewriting these more-specific content > types would seem to make it much more difficult to achieve the > context-specific dispatch methodology described above. An application/xml > handler is very unlikely to be able to retroactively parse the MIME the > same way chrome has. If the content is declared as /text or /image, I want > to choose a program for text or images! > > That's why I specifically called out the practice of rewriting to a > separate *valid* and *existing* content-type: this erases information that > must be parsed again from scratch, fully obviating the expectations of MIME > parsing. If instead the content-type was rewritten to *retain* the > *declared* type, while *also* describing chrome's judgement of it as XML, > that would be non-breaking, while still maintaining the purpose of this > proposal. > > However, even that compromise seems hollow, because the content-type > *already* declares itself as xml! From a facial reading of the cited spec, > it's already in conformance! Hence why I suspect there's just a spec link > that didn't propagate correctly to justify this radical breaking change. > > ## Potential Security Hazards > My main concern is with polyglot inputs—*not* the kind that actively > declare multiple formats by type, but inputs which parse correctly in two > evaluation contexts. The erasure of information here seems to be exactly > the type of concern demonstrated by the textbook example of RCE vectors > (postscript/pdf): > > (8) Finally, bugs may exist in some PostScript interpreters which could > possibly be exploited to gain unauthorized access to a recipient's system. > Apart from noting this possibility, there is no specific action to take to > prevent this, apart from the timely correction of such bugs if any are > found. > > As a user, I have absolutely no clue what my browser or OS would invoke > for "application/xml", since XML is a container format, and "application" > (as we saw earlier) is expressly the most abstract and least informative > classifier. I'm concerned that an OS (or perhaps a browser extension?) > might assign a default interpreter for application/xml that, e.g., modifies > the windows registry, or perhaps even invokes a container. This wouldn't > require malicious intent, but merely result from being the only app that > registers application/xml as a *possible* input. This is one of the failure > modes of hastily-written autoconf configure scripts, for example. > > That was speculation. Here's the practical result I'm expecting: > - as a user, an image appears as a blob. If I select an image viewer for > application/xml, it seems to work—but then my actual xml blobs will be > misinterpreted as images, unless I'm very savvy and think to check my > default interpreters. > - as a user, I open a blob with my xml viewer (maybe it's that container > program I mentioned earlier), which works great! But then I get confusing > errors opening images! > - *coercing /text to application/xml directly reinterprets data as > executable code. *This seems facially unsafe, in ways the chrome team has > taught me to recognize over their many years of leadership in web security. > > # Conclusion > This change seems to be an overeager interpretation of the spec, but I > understand such a drastic breaking change is likely to be justified by > precedent. I apologize profusely if I have missed this in my haste to > contribute. > > If this was indeed motivated from external factors beyond spec compliance, > I believe the nature of this proposal induces a singular degree of risk in > its current form, and I would challenge the author to describe a > correspondingly drastic motivation which outweighs the risk I've > inferred–or to explain my misunderstandings. I understand your time is > valuable, so a link is fine. > > I am also unnerved by the complete lack of acknowledgement of this spec > interpretation by any other browser. If RFC 2046 is in play, this > interpretation logic would have been unchanged since 1997 (of the later > updates to RFC 2046, I could find none which had any bearing upon this > proposal). So there's either a wrong citation link, or every browser has > been wrong since 1997. And that seems like a very weak claim to suddenly > identify a new behavior, especially when the new behavior is nowhere in the > spec (that I could find). > > Thanks for your time. Hope your week goes well! > > *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. > > *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. > > *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. > > *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 desktop158 Shipping on Android158 Shipping on WebView158 > > *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/249272bb-c76a-4135-8fd4-7ec576ed7c68n%40chromium.org.
