Intent to Ship: XML Parsing in Rust for non XSLT scenarios

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Specification

https://www.w3.org/TR/xml/

Summary

Roll out the Rust XML parser for scenarios where we are certain that no XSLT processing is required. The Rust XML parser improves security by eliminating memory corruption bugs in XML parsing, it is intended to replace our usage of libxml2 (written in C) with a safe alternative. We are in the process of deprecating XSLT, see https://chromestatus.com/feature/4709671889534976. 

While this process continues, we can already migrate to safe Rust XML parsing in scenarios where no XSLT processing is required: 

1. DOMParser Web API 
2. Accessing responseXML of XMLHttpRequest 
3. SVG Standalone Images (i.e. accessing a image.svg document directly as a top level navigation) 
4. SVG external images (A main document embedding an SVG as an external image resource).

For enabling usage of safe XML parsing in scenarios 3 and 4, previously, inline XSLT for the production of SVG was deprecated in: https://chromestatus.com/feature/5143784390262784

Blink component

Blink>DOM

Web Feature ID

No information provided

Search tags

xml, security, parsing, parser

Risks

Interoperability and Compatibility

No interoperability risks, the new memory-safe implementation is expected and shown to be functionally equivalent to the C++ based implementation. No functional change. For performance considerations, see ergonomics section.

Two or three compatibility issues were identified during the experiment phase and have been fixed.

In the XML parsing Rust crate in upstream, as set of XML conformance tests are run with a good pass rate of test suites, remaining test failures in upstream were investigated and showed that the failures pertain to functionality that we do not use (DTD parsing, for example), or are because of conflicting specifications.

A very low risk of previously unforeseen compatibility issues remains, but I consider it unlikely.

Signals
No browser vendor or developers signals were solicited as there is no functional change or introduction of new API. 

Ergonomics

A 1% @ stable experiment was performed. Analysis of the Blink.XMLParsing.NonXsltXmlParsingTime.Combined histogram confirms an isolated parser performance regression. However, guard rail metrics are unaffected on all relevant platforms. XML parsing becomes slower, more evenly distributed across percentiles on Android between a regression of 36% (50th percentile) and 54% (at the 99th percentile), whereas on Windows, the regression is vastly more pronounced for longer parsing times, 23% at the 25th percentile, to 74% at the 95th percentile, to 209% at the 99th percentile. Still, in practice in absolute numbers we are talking about parse times reaching only tens of milliseconds on Windows and Android.

Activation

No change in behavior means no particular activation risks.

Security

This change's main intention is to improve security. Almost all XML parsing we perform will run through the Rust memory-safe parser. When XSLT deprecation concludes, we can deactivate libxml2 XML parsing and move to Rust XML parsing completely.

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 change in behavior means no particular activation risks.

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

Tracking bug

https://crbug.com/466303347

Measurement

No new behavior that would need adoption measurement. Usage of SVG as external images remains high at about 60% for example, and will run through this code path.

Estimated milestones

Shipping on desktop	151
Shipping on Android	151
Shipping on WebView	151

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5309598397497344

[Chris Harrelson]

LGTM1

--
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/CAN6muBvUpuf3UBfv6vFxfy-b1LW-fgBbaMk02w5heHDPqbS8dg%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

One could also argue that this is a non-web-exposed implementation change, and as long as it's being carefully rolled out, it doesn't need API owner approvals..

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_JjLmCZQ3NGtgivE0gsesNCrQnJcW6MiPkwrMEwKX39w%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

Oh, can you tick all the chromestatus boxes (maybe with N/A?)?

[Mike Taylor]

Enthusiastic LGTM3 from me (but I don't think you need any approvals here). Good luck!

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLDyyo7EJFs2F%3D6LXWPqqmRugqrG_vpTLvt7zjdwRBr3w%40mail.gmail.com.