Browser Security Analysis: New Discoveries and Reaffirmed Findings

2.1 Firefox’s Rust Bet Is Paying Off

Firefox has rewritten major subsystems in Rust. CSS engine (Stylo). Renderer (WebRender). Library sandboxing (RLBox). Parts of the networking stack. Rust eliminates whole bug classes at compile time. Use-after-free. Buffer overflows. Null pointer dereferences. Chromium has mitigations for these and they’re good mitigations. But mitigations manage symptoms. Rust eliminates the root cause.

Roughly 70% of Chromium’s critical-severity bugs are memory safety issues [14]. Firefox’s Rust components have produced zero such CVEs since they shipped [15]. That tracks with what the language guarantees.

The data backs up both approaches. Firefox aims to prevent bugs altogether. The Rust rewrite of CSS, rendering, and library sandboxing has produced zero memory safety CVEs so far. Chromium takes a different path. CFI, PartitionAlloc, V8 sandbox make bugs harder to weaponize even when they exist.

2.2 Content Blocking != Privacy Theater

GrapheneOS called extension-based content blocking “privacy theater.” Equated it with antivirus scanning. That analogy doesn’t hold.

Blocking a request at the network layer before the payload reaches your device is structurally different from scanning a file after it’s on disk. uBlock Origin stops exploits from being delivered before they reach the renderer.

Filter lists can’t block novel zero-days. That’s a real limitation. Zero-day delivery in practice relies on known malicious infrastructure. Compromised ad networks. C2 domains. Exploit kit landing pages. Filter lists block those. The “enumeration is futile” argument assumes attackers spin up fresh infrastructure for every target at zero cost. Not how mass-market exploitation works.

2.3 Monoculture Risk Is Real

Chromium’s mobile market share is overwhelming. When the Chromium engine has a critical vuln, billions of devices are affected at once. That concentration of value creates attacker incentives that don’t exist for Firefox’s minority codebase.

A Chromium zero-day is worth more to an exploit broker than a Firefox zero-day. Purely because of market share. Firefox being ignored by attackers is itself a security property. Not a flattering one but it’s real.

The dual-engine criticism keeps coming up. “Firefox adds a second engine to your device.” Android mandates a system WebView. On GrapheneOS that WebView is Vanadium regardless of your browser choice. Running Firefox on top of that adds marginal attack surface. It also reduces monoculture risk. Different users weigh that differently.

2.4 Pick Your Threat Model

The original paper’s core claim held up. Browser choice is a threat-model alignment. Not a binary “secure vs insecure” judgment.

Targeted state sponsored attacks. Chrome/Chromium makes sense there. Post-compromise containment is the priority and isolatedProcess delivers that. Mass surveillance and drive-by exploits targeting the Chromium monoculture. Firefox makes more sense there. A renderer that’s harder to compromise reduces the probability that any exploit succeeds. Tracking and fingerprinting as primary concern. Firefox’s Total Cookie Protection, ETP, and container isolation are ahead of anything in the Chromium ecosystem.

Depends on what you’re up against.

2.5 Android vs. Desktop Matters

I keep coming back to this because it’s where the debate gets muddled. The sandbox gap is almost entirely Android-specific.

On Windows, Firefox’s sandbox is at parity with Chrome’s. Both use AppContainer for kernel-level process isolation [13]. Both restrict Win32k syscalls from renderer processes [9]. Both use broker process models for privileged operations.

The isolatedProcess thing is an Android limitation. Android apps can’t create namespaces or use seccomp-bpf. The Android Runtime needs too many syscalls. isolatedProcess is the only sandboxing option on Android and Firefox doesn’t use it.

Firefox’s critics treat this as a universal Firefox deficiency. I see it as a platform-specific gap. If Firefox were categorically less secure you’d expect the gap to exist everywhere. On Windows it doesn’t. On Android it does. Weighed against Firefox’s advantages that apply on all platforms.

Picking Chrome on Android because you prioritize mobile security is rational. Claiming “Firefox has no sandbox” or “Firefox is much more vulnerable” without qualifying the platform is overreach.

3.1 I Left Out Half of Chromium’s Mitigations

My first paper spent a lot of time on Firefox’s Rust adoption and barely mentioned Chromium’s mitigations. Made the comparison look one-sided. Here’s what I missed:

Chromium doesn’t prevent memory bugs at the source the way Rust does. It makes them significantly harder to exploit. I should have included that. Ignoring it made my comparison incomplete.

3.2 The isolatedProcess Thing

I categorized GrapheneOS’s “Firefox has no internal sandboxing” claim as “partially outdated.” That was wrong. If you define sandboxing as kernel-level UID isolation, the claim is fully accurate. GeckoView doesn’t use isolatedProcess.

GrapheneOS defines sandboxing as isolatedProcess at the kernel level. I was using a broader definition that includes process-level privilege separation. Both definitions are consistent. I should have been clearer from the beginning.

3.3 Fission Isn’t Really Shipping on Android

My first paper mentioned Fission shipping on Android then rolling back. But the abstract and conclusion referenced Fission like it was a current mitigation. It’s not. Fission is disabled on release and beta channels as of Firefox 152. Nightly and developer builds have it at a reduced level (ISOLATE_HIGH_VALUE rather than full origin isolation). Should have been more careful about this.

3.4 Other Things I Missed

SpiderMonkey has no CFI. V8 has Clang’s Cross-DSO Control Flow Integrity for indirect call validation [16]. SpiderMonkey doesn’t. JS engines are the densest source of critical vulns in both browsers and this is a real gap. Combined with V8’s memory sandbox, Chromium’s JS engine mitigation layer is genuinely stronger. Rust doesn’t help here because JIT-generated code isn’t subject to Rust’s safety guarantees.

I claimed hardware mitigations like MTE, PAC, and BTI are “enforced at the OS and hardware level, not by the browser vendor.” That was wrong. These features need allocator modifications, compiler support, and codebase validation. Chromium has done the work. MTE in PartitionAlloc, PAC/BTI validation. Firefox hasn’t.

The CVE count framing in my first paper was sloppy. Chromium invests way more in fuzzing, AI-guided auditing, and security research. Finding more bugs is a sign of more testing, not less security [18]. Residual risk after mitigation is what matters and that’s not directly measurable from public data.

Extensions break site isolation in both browsers. I implied Firefox’s extension model was more contained. It’s not. Extensions in both browsers run with cross-origin access that bypasses site isolation [19]. The trade-off is between extensions and built-in content filtering (Brave’s approach). Neither is clearly better.

4.1 “Much More Vulnerable” vs “Differently Vulnerable”

GrapheneOS says Firefox is “much more vulnerable to exploitation.” I don’t think the evidence supports that even after accounting for everything I got wrong.

Chrome has stronger post-compromise containment. Firefox has stronger pre-compromise prevention. These are different priorities. Calling one “much more vulnerable” treats containment as the only metric that matters. That’s a value judgment. My position is both are rational depending on what you’re protecting against. Nothing I’ve seen changes that.

4.2 Advisory Latency

GrapheneOS’s advisory on Firefox hasn’t changed significantly since it was written. Firefox’s architecture has evolved. The Fission rollback is an example of this working both ways. Needed to correct my own framing. The advisory also doesn’t acknowledge that Firefox on Windows has reached sandbox parity. Documentation latency is a known problem in security engineering [6]. Not unique to any project.