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.