You already have approval to run the experiment (I am supportive too,
FWIW), but one question below:
On 2/9/26 1:44 p.m., 'Dominik Röttsches' via blink-dev wrote:
Contact emails
[email protected]
Explainer
Make Rust parsing memory safe in Chrome, replace unsafe C library
usage of libxml2 with Rust based XML parsing based on the Rust XML
crate <https://crates.io/crates/xml>. Eliminate class of XML parsing
memory corruption security issues.
Specification
Several web specs affected, wherever we parse XML: DOMParser JS API,
XMLHttpRequest, SVG, XHTML.
Design docs
Internal design doc
<https://docs.google.com/document/d/1ubSlZfl7kLUSfTUKEVRNM-bCsQXjVIiyTgxlyOleTDM/edit?tab=t.0#heading=h.xejx24r20h6z>
Summary
Moving to a Rust based XML parser is part of our strategy to address
security issues and the difficult security track record of libxml2 and
libxslt.
Unfortunately, for XSLT support, libxml2 and libxslt are tightly
entangled. However, we can already ship the Rust based XML parser for
scenarios without XSLT.
In this intent to experiment, I propose to roll out the Rust-based XML
parser for scenarios where no XSLT processing is required.:
1. DOMParser Web API
2. Accessing responseXML of XMLHttpRequest
3. Likely: SVG Standalone Images (i.e. accessing a image.svg document
directly as a top level navigation)
4. Likely: SVG external images (A main document embedding an SVG as
an external image resource).
For details of "Likely", see Risks below.
Blink component
Blink>DOM, Blink>SVG
TAG review
None, no functional change expected.
Risks
Interoperability and Compatibility
*XML Parsing and Serialization*
In implementing the Rust based XML parser we tested against ~400 WPT
and internal web tests and brought down the failures to close to 0.
For DOMParser and XMLHttpRequest test, the new parser is already
permantenly running on bots.
Technically, niche issues remain where in serialization, with the new
Rust parser we may occasionally insert an extra xmlns: element on a
root element due to API restrictions of the XML parser. This does not
affect document semantics.
Can you say more about this? Does this mean the tests are bad (or just
useless in practice, since there are no semantic differences)?
From WPT tests we do not see other compatibility issues, and we
believe we can progress to real-world testing for the non XSLT scenarios.
*Inline XSLT in SVG*
There is a minor theoretical risk regarding standalone SVG images
(scenario 3 above) that utilize inline XSLT to transform raw XML data
into SVG. Example <http://rtsh.es/test/xml/svg_xslt_img.html>
Data: UseCounters (XSLPIInSVGImage and XSLPIInSVGImageStandalone)
currently show 0% usage in Canary and Dev.
It will be interesting to report on this in a future Intent to Ship -
after you get some stable exposure.
Current State: This works in Chrome for standalone docs but not for
externally referenced images (matching Firefox). Safari supports both.
Signal: Mozilla and Apple both have expressed support for deprecating
XSLT in general, not only in this context (WHATWG Issue #11523).
/Gecko/: No signal
/WebKit/: No signal, will file deprecation proposal to disallow XSLT
for SVG generation
/Web developers/: No Signal
/Other signals/: Mozilla and Apple support deprecating XSLT from
discussions in WHATWG. https://github.com/whatwg/html/issues/11523
Security
Changing to Rust based XML parsing eliminates a class (and historic
chain) of memory corruption bugs in XML parsing. Libxml2 had unstable
maintainership, and delays in responding to security issues.
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, expect for the likely non-existent usage of XSLT in SVG.
Goals for experimentation
I propose rolling out to 50% Dev, Canary and Beta. Then progress to 1%
on stable after observing the new use counter for XSLT usage in SVG,
and monitoring the perf histogram Blink.
<http://Blink.>XMLParsing.NonXsltXmlParsingTime.Combined
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.cc;l=7986?q=document.cc>.
The new Rust parser at this point is not on par with the performance
of the libxml2 based parser and shows a 50% regression in the
blink_perf.parser microbenchmark parsing a 3MB heavy XML document and
measuring throughput, tracked in https://crbug.com/470367156
Rolling out at a small percentage to stable helps us gather the
required metrics to decide whether this leads to real-world
performance implications in the metrics we care about: mainly LCP, and
monitoring for major shifts in the UMA histogram for XML parser timing.
Ongoing technical constraints
Performance. The microbenchmark finding shows that the parser is not
at the same performance of the C parser at this point. Finding out
whether this practically matters is one goal of this experiment.
Debuggability
No issues, both libxml2 and the Rust parser parse into internal DOM
structures which are accessible in source view like before.
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.
Flag name on about://flags
Not in about://flags.
Finch feature name
XMLRustForNonXslt
Requires code in //chrome?
False
Tracking bug
https://crbug.com/466303347
Estimated milestones
Experimental roll out to 1% for M147.
Link to entry on the Chrome Platform Status
Rust XML Parser rollout
<https://chromestatus.com/feature/5309598397497344>)
Deprecate XSLT in SVG
<https://chromestatus.com/feature/5143784390262784>
--
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/CAN6muBu762SaOZv_a%2BSDpJDnrRVS6Y2ZRETyJfPjdfuEAEG6qA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBu762SaOZv_a%2BSDpJDnrRVS6Y2ZRETyJfPjdfuEAEG6qA%40mail.gmail.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/671bdc75-5bfa-4dbf-b794-c2e0a5b1ee50%40chromium.org.
