Removing XSLT for a more secure browser

Original Article ↗ Hacker News Discussion ↗

Who Is Removing XSLT and Why

  • Chrome is deprecating built‑in XSLT; Firefox and WebKit have publicly signalled support for removal as well.
  • Stated reasons: tiny usage, large/complex code path, and multiple serious vulnerabilities in libxslt and related XML code that’s effectively under‑maintained.
  • Some commenters dispute that other vendors truly “agreed to remove it,” arguing they only agreed to explore removal and also mentioned options like sandboxing or replacement implementations.

Security vs. Maintenance vs. Motive

  • Pro‑removal side: XSLT’s engine parses untrusted input via old C libraries with long‑lived memory‑safety bugs; modern fuzzing keeps finding 20‑year‑old issues. Maintaining this niche feature forever is not worth the ongoing security and engineering cost.
  • Critics argue security is a pretext: Chrome could ship the same WebAssembly/JS polyfill they recommend to site authors, which would sandbox XSLT like any other script.
  • Others note Chrome simultaneously keeps adding much riskier, vendor‑driven APIs (WebUSB, WebBluetooth, etc.), so “shrinking attack surface” appears selective.

Value and Use of XSLT

  • Fans describe XSLT as a powerful, concise, declarative tree‑transformation language, especially for XML‑centric domains (publishing, standards, finance, government, JATS, trade settlements). It enables templating and XML→HTML rendering without JavaScript.
  • Several real production uses are cited: gov/legislative XML, weather data, enterprise integrations, RSS/Atom and sitemap styling, CMSs, directory listings.
  • Critics say XSLT is painful, hard to debug, a Turing tarpit in XML, and effectively replaced by JS + JSON + template libraries; many projects already do transforms server‑side.

Backward Compatibility and “Open Web” Concerns

  • One camp sees this as breaking an old, standardized web feature and violating the “don’t break the web” norm; worries about big vendors unilaterally shrinking the standards surface and marginalizing XML‑based content.
  • Others reply that near‑zero usage plus availability of server‑side transforms or polyfills makes this an acceptable, even necessary deprecation; browsers are not obliged to support every spec feature forever.

Alternatives and Mitigations

  • Suggested paths: server‑side XSLT (often already used for XSLT 2.0/3.0), JS/wasm polyfills (including an official one), possible extensions, or content negotiation for feeds.
  • XPath DOM APIs remain, so Selenium/Playwright XPath locators are unaffected.
  • Some argue vendors should instead have funded a modern Rust XSLT engine or adopted projects like Xee; others see deprecation of rarely used APIs as healthy for an overgrown browser platform.