Memory safety for web fonts

Rust integration and FFI in Chromium’s font stack

  • Some worry that introducing Rust into an already polyglot Chromium stack (C++, Swift, Kotlin, Python) adds build, linking, and interop complexity.
  • Others counter that Rust is exposed via C-compatible FFI and tools like cxx.rs, making it similar to consuming any C library; Rust can also be wrapped for Python via tools like maturin/PyO3.
  • Google emphasizes incremental migration: Chromium is too large to rewrite, so components like font parsing are being swapped out piece by piece rather than via a “big rewrite.”
  • The TypeScript-to-Go port is discussed as a contrasting example: Go was chosen for semantic similarity to JS/TS to enable a port (bug-for-bug compatibility) rather than a full Rust-style re-architecture.

Memory safety vs. C/C++ and Go/Java

  • Several commenters see this Rust-based font engine as evidence against the claim that “carefully written and fuzzed C/C++ is just as safe,” especially for complex, attacker-exposed parsers like font engines.
  • Others stress that comparisons should be “new Rust vs. new C” rather than legacy C libraries; rewrites themselves introduce new bugs.
  • There is broad agreement that humans are fallible and that relying on discipline and testing in C/C++ doesn’t scale, particularly when composition of many “small, safe” functions is involved.
  • A long subthread debates whether Go is truly memory safe given data races on maps/slices/interfaces, and contrasts this with Java’s stronger guarantees.

FreeType’s role and limitations

  • FreeType is described as having been designed for trusted, local fonts and low-level performance (fixed-point math, complex TrueType internals), making it hard to harden after the fact.
  • Some call it a “dinosaur” and share frustrations with rejected performance patches; others argue age alone isn’t a problem if it meets its original goals.
  • HarfBuzz is clarified as a shaping engine that typically runs on top of FreeType, not a replacement for it.

Font quality, hinting, and display technology

  • Multiple participants care deeply about precise hinting, subpixel rendering, and consistency across platforms, and worry whether the new Rust stack will fully preserve TrueType hinting behavior.
  • There’s disagreement on the value of subpixel AA in a HiDPI world; macOS’s removal of subpixel AA and differences with Windows/ClearType are debated.
  • Complex subpixel layouts (WOLED, QD‑OLED, Pentile) complicate rendering; EDID/DDDB is cited as a standard that can convey subpixel layout, but panel vendors and software often don’t use it effectively.

Engineering economics and fuzzing cost

  • The blog’s “0.25 FTE to keep up with fuzzing” phrasing triggers a discussion of FTE/SWE‑years as an internal cost unit used to trade off engineering time vs. compute and other resources.
  • Some note this can incentivize pushing work to clients (e.g., codecs) and create “tragedy of the commons” situations, while others argue it’s a useful, if imperfect, decision tool.