teknav-bak/global/article-contents-en-8.js

export const ART_EN8_CONTENT = `
<div class="article-content">
  <p class="lead">The Ladybird browser project made a decision that would be considered radical in most software organizations: all new code, starting now, must be written in Rust. Not "Rust is preferred" or "Rust for new systems components" — all new code. The reasoning traces directly to the data on memory safety vulnerabilities in browsers, and that data is not subtle.</p>

  <figure style="margin: 0 0 28px 0; border-radius: 10px; overflow: hidden; border: 1px solid #E4DDD2;">
    <img src="/images/articles/software-supply-chain.jpg" alt="Ladybird browser Rust memory safety mandate: UAF, buffer overflow, and type confusion prevention" loading="lazy" style="width: 100%; height: auto; display: block;" />
    <figcaption style="font-size: 12px; color: #5F6B6D; padding: 10px 14px; background: #F4EFE6; line-height: 1.7;">Memory safety vulnerabilities — use-after-free, buffer overflows, type confusion — account for approximately 70% of critical browser security bugs. Rust's ownership system makes the entire class of these vulnerabilities impossible to express in safe code, not merely less likely.</figcaption>
  </figure>

  <h2>1. Ladybird: A Browser Engine Built From Scratch</h2>
  <p>Ladybird started as LibWeb, part of Andreas Kling's SerenityOS project — an operating system written from scratch as a learning project that grew into a serious undertaking. In 2022, Kling forked the browser engine out of SerenityOS into its own project, Ladybird, with the explicit goal of building a fully independent browser engine that was not derived from WebKit, Gecko, or Chromium/Blink. The browser engine landscape had effectively consolidated to three implementations plus a long tail of forks, and Ladybird's existence as a clean-room implementation has academic and security significance beyond its current capability level.</p>
  <p>In 2024, the Ladybird Browser Initiative became a US 501(c)(3) nonprofit, received initial funding from GitHub's co-founder Chris Wanstrath, and announced the Rust mandate alongside a commitment to target a developer preview release by 2026. The project currently has a small full-time engineering team and a larger open-source contributor community, with the codebase transitioning from C++ to Rust for all new subsystems.</p>
  <p>The mandate's announcement sparked considerable discussion precisely because Ladybird is building from scratch — they are not constrained by decades of existing C++ code the way Firefox or Chrome are. Choosing Rust from the start is architecturally simpler than retrofitting it into an existing codebase. But the choice still represents a commitment: Ladybird is betting that the memory safety guarantees are worth the productivity cost and ecosystem friction of Rust over C++.</p>

  <h2>2. The Memory Safety Statistics That Drive the Decision</h2>
  <p>The 70% figure — that approximately 70% of critical security vulnerabilities in Chrome are caused by memory safety bugs — comes from Google's own analysis, published in a 2019 Project Zero blog post that examined all 912 security bugs classified as "high" or "critical" severity over the preceding year. The finding has been replicated in subsequent analyses: the 2020 figure was 70%, 2021 was similar, and Microsoft reported identical findings for their own products.</p>
  <p>What makes this statistic striking is not its magnitude but its consistency and the category of bugs it covers: <strong>use-after-free (UAF)</strong>, <strong>buffer overflows</strong>, <strong>type confusion</strong>, and <strong>uninitialized memory reads</strong>. These are not exotic bugs requiring sophisticated attack primitives. They are routine C++ programming mistakes that skilled engineers make under the pressures of large-scale software development. The memory safety problem is not a skills gap — Chrome's engineering team is among the most capable in the industry. It is a language property gap.</p>
  <p>A <em>use-after-free</em> bug occurs when a program continues to use a memory address after the memory at that address has been freed. In C++, this is undefined behavior — the program may crash, produce incorrect results, or execute attacker-supplied code. UAF bugs are the most commonly exploited class of browser vulnerability because they are often controllable: the attacker can sometimes influence what memory gets allocated in the freed location, making the resulting behavior predictable enough to exploit reliably.</p>

  <blockquote style="border-left: 4px solid #D49A2A; margin: 28px 0; padding: 16px 20px; background: #D49A2A0A; border-radius: 0 8px 8px 0; font-size: 16px; color: #263238; font-style: normal;">"If you're writing C or C++ and you're not using a memory-safe language, you're essentially writing code that's going to have memory safety bugs. Not might — will." — Alex Gaynor, former NSA/Heroku security engineer, Rustconf keynote 2019</blockquote>

  <h2>3. How Rust Eliminates Memory Safety Bugs</h2>
  <p>Rust's memory safety guarantee is enforced through the <strong>ownership system</strong> and the <strong>borrow checker</strong> — a compile-time static analysis that tracks how memory is owned and borrowed throughout the program. The rules are:</p>
  <p>Each value has exactly one owner at any time. When the owner goes out of scope, the value is automatically freed — no manual <code>free()</code> or garbage collector needed. You can create references (borrows) to a value, but the borrow checker ensures that either: you have one or more immutable references (readers), or you have exactly one mutable reference (writer) — never both simultaneously. This rule eliminates data races by construction. References cannot outlive the value they reference — this is enforced at compile time, making use-after-free impossible to express in safe Rust.</p>
  <p>The consequence is that the compiler rejects programs that contain UAF bugs, buffer overflows (Rust does bounds checking by default), and data races — not at test time or at runtime, but at compile time. These errors never reach production. The borrow checker is sometimes described as "fighting with the compiler," and it is — but it is fighting that occurs once, during development, rather than in the form of CVEs and security patches post-deployment.</p>
  <p>The <code>unsafe</code> keyword in Rust allows bypassing borrow checker rules for operations that require raw pointer manipulation (FFI with C libraries, direct hardware access). Safe Rust code — code without <code>unsafe</code> blocks — cannot express memory safety violations. Real-world Rust programs contain some <code>unsafe</code> code, but the goal is to minimize and carefully audit it, containing the potential memory safety surface to a small, reviewed fraction of the codebase.</p>

  <h2>4. Firefox's Servo Lessons: What Ladybird Is Learning From</h2>
  <p>Mozilla's <strong>Servo</strong> project, started in 2012, was the first serious attempt to build a browser engine component in Rust. Servo's CSS layout engine, style system, and WebRender compositor have been partially integrated into Firefox, with the Stylo CSS engine (from Servo) now powering Firefox's style resolution since Firefox 57 (Quantum, 2017). The result was measurable: Firefox's style resolution became 2x faster and the attack surface for memory safety vulnerabilities in that subsystem was dramatically reduced.</p>
  <p>Servo also produced lessons that are directly relevant to Ladybird. First: <strong>Rust's learning curve is real but bounded</strong>. Engineers experienced with C++ typically take 2–3 months before they feel productive in Rust; engineers without systems programming background take longer. The learning curve is front-loaded — after the initial learning period, most engineers report that Rust's compiler feedback is actually helpful rather than obstructive.</p>
  <p>Second: <strong>the ecosystem matters</strong>. Browser development requires binding to operating system APIs, graphics libraries, media codecs, and network stacks that are primarily written in C. The quality of Rust's FFI (foreign function interface) and the maturity of Rust bindings to common C libraries has improved significantly since 2012, making new Servo-style projects more feasible than they would have been then.</p>
  <p>Third: <strong>incremental migration is harder than greenfield</strong>. Firefox's partial Servo integration required complex interoperability between Rust and C++ components, which introduces its own safety challenges (unsoundness at FFI boundaries) and maintenance burden. Ladybird, building from scratch, can design the architecture to minimize FFI boundaries rather than inheriting them.</p>

  <div class="insight-box" style="padding: 14px; border-radius: 10px; background: #0F6B7311; border: 1px solid #0F6B7340; margin-bottom: 20px;">
  <strong>Chrome's Memory Safety Strategy:</strong> Google cannot rewrite Chrome in Rust (the codebase is approximately 35 million lines of C++), but they have taken several pragmatic approaches. <em>MiraclePtr</em> is a C++ smart pointer that makes UAF exploitation significantly harder by quarantining freed memory. <em>Memory tagging</em> (ARM MTE, available on Pixel 9+) catches UAF at runtime. New Chrome features are written in C++ with mandatory code review for memory safety, and a subset of new code uses Rust via interop. Google's own estimate is that MiraclePtr will make ~50% of current UAF CVEs unexploitable, without requiring a Rust migration.
  </div>

  <h2>5. What Memory-Safe Languages Cost in Developer Productivity</h2>
  <p>The productivity argument against Rust is real and should not be dismissed. Benchmarks of developer productivity in Rust vs C++ consistently show that experienced engineers write Rust code more slowly — estimates range from 15% to 40% slower depending on the task and experience level. The borrow checker prevents certain code patterns that are natural in C++, and the error messages, while excellent, still require developer time to resolve.</p>
  <p>The honest accounting requires comparing this cost against the alternative cost: the engineering time spent fixing memory safety CVEs, the security engineer time spent performing security audits of C++ code, the user-facing impact of zero-day exploits, and the reputational cost of security incidents. Google has spent enormous resources on Chrome security — Project Zero, fuzz testing infrastructure (OSS-Fuzz), hardening techniques like MiraclePtr — precisely because C++ cannot prevent the vulnerability class in the first place.</p>
  <p>For Ladybird's specific situation — a new project with no existing C++ debt to maintain — the productivity argument for Rust is significantly stronger than for an existing C++ codebase. The incremental cost of writing new code in Rust versus C++ is bounded; the compounding security debt of a C++ browser engine over decades is open-ended.</p>

  <h2>6. The Broader Trend: Memory Safety as Policy</h2>
  <p>Ladybird's Rust mandate is not an isolated decision. The US NSA (National Security Agency) published guidance in 2022 recommending that organizations transition to memory-safe languages. The US CISA (Cybersecurity and Infrastructure Security Agency) followed with similar guidance. The White House ONCD (Office of the National Cyber Director) published a technical report in 2024 explicitly calling for federal software procurement to require memory-safe languages for new development, citing the same 70% memory safety vulnerability statistic.</p>
  <p>Python, Rust, Go, Java, C#, and Swift are all classified as memory-safe by these guidelines. C and C++ are explicitly called out as memory-unsafe. The policy trajectory is clear: government procurement, defense contracting, and critical infrastructure software development is moving toward mandatory memory-safe language requirements, which will create downstream pressure on all software ecosystems.</p>

  <div class="footnote-box" style="padding: 14px; border-radius: 10px; background: #FAF7F0; border: 1px solid #E4DDD2; font-size: 12px; margin-bottom: 20px;">Sources: Chromium project, "Memory Safety" (chromium.org/Home/chromium-security/memory-safety, 2019 analysis). US ONCD, "Back to the Building Blocks: A Path Toward Secure and Measurable Software" (February 2024). NSA, "Software Memory Safety" Cybersecurity Information Sheet (November 2022). Kling, A., Ladybird Browser Initiative announcement (ladybird.org, 2024). Mozilla, "Fearless Security: Memory Safety" (developer.mozilla.org, 2024).</div>

  <h2>Conclusion: A Bet on the Right Side of History</h2>
  <p>Ladybird's Rust mandate is unusual in its absoluteness, but the underlying reasoning is not controversial among security engineers who have spent time with the data. When 70% of critical browser vulnerabilities are prevented entirely by the language choice rather than by better programmer discipline or tooling, the language choice is the highest-leverage security intervention available. Building a new browser engine in 2024 and choosing C++ would require a compelling reason to accumulate the same class of security debt that has generated CVEs in browser engines for 30 years. Ladybird's team didn't find one.</p>
</div>
`;