Chrome Is Open Source and Still Hard to Reverse Engineer. Here's Where the Real Work Is!

You can read Chromium's source today, and people still spend years reverse engineering Chrome. The code isn't the hard part. The hard parts are the process model the code implies, the Google layer on top of it, and the behavior no design doc covers.

This is a map of where that work pays off, and which repos and docs got there first.

The Part You Don't Have to Reverse

Start with what's documented, because most "Chrome internals" posts reverse-engineer things that are written down. The Chromium design docs tell you to begin with multi-process architecture. Most of the other design documents assume you've read it.

The model is simple to state. The browser and renderers talk over Mojo or the legacy IPC system, and each renderer process has exactly one RenderProcess object. Mojo is also how the browser's own services talk to each other. The network service is designed as a Mojo service that doesn't need to know which thread or process it runs on. It can run in a utility process or inside the browser process.

Site Isolation is where this pays off. Each renderer process can be locked to documents and workers from a single site, even when those documents sit in iframes. It isn't uniform across platforms. Desktop gets full site-per-process. Android gets a partial mode on devices with 2+ GB of RAM. Chrome for iOS runs on WebKit, which has no out-of-process iframe support. So "Chrome's security model" is really three models, and the one you reason about depends on the platform.

The best primary source here is the paper from Charles Reis and the Chrome team on deploying Site Isolation. It covers the performance and compatibility problems of retrofitting a production browser with the new architecture. Read it for the tradeoffs the design docs leave out.

If you want to test the boundary yourself, the security docs describe how. Passing --enable-features=MojoJS lets you call Mojo methods from JavaScript, which simulates a compromised renderer. That makes the renderer-to-browser Mojo interfaces your real attack surface. In the doc's own framing, calling a Mojo API can mean code execution in the browser process, which is a far worse outcome than code execution in the sandboxed renderer.

V8 Is a Negotiation, Not a Pipeline

Most developers know V8 "has a JIT." The useful model is that it's a tiering policy driven by runtime feedback. Maglev exists because the gap between Sparkplug and TurboFan was too wide. Until 2021 V8 had only Ignition and TurboFan, then added Sparkplug, and Maglev arrived in Chrome M117. The docs put the cost tradeoff at Maglev compiling about 10x slower than Sparkplug and about 10x faster than TurboFan. Per one writeup, TurboFan's internals were rebuilt onto Turboshaft by March 2025 without adding a fifth tier.

The practical reverse-engineering move is reading the thresholds. v8pedia quotes the flag definitions for invocation counts at each tier, such as 400 for Maglev and 3000 for TurboFan. Treat those as a snapshot, since flag defaults change between V8 versions. Verify them against the source for the version you're analyzing.

For the exploitation side, this curated resource list is the best single index I've found. It points to bug-hunting-101, Jack Halon's browser exploitation series and doar-e's TurboFan introduction. The list flags some entries as outdated, so check before relying on them.

The Repos That Did the Real Reversing

Three projects stand out. Each reverses a different layer.

ungoogled-chromium reverses the Google dependency graph. Its premise is that Chromium still has some dependency on Google web services and binaries even without signing in. The interesting part is the method. It uses domain substitution, replacing Google domains in the source with non-existent ones ending in qjz9zk, plus binary pruning. A fail-safe blocks internal requests to those domains, in case Google introduces new components its patches don't disable. The patch set is effectively a map of every place Chromium phones home.

chrome-devtools-mcp is Google reverse-exposing its own browser to agents. It's a TypeScript server wrapping Chrome DevTools and Puppeteer so that coding agents like Gemini, Claude, Cursor or Copilot can control and inspect a live Chrome. One detail matters before you point it at anything sensitive. It collects usage statistics and checks for updates by default, with flags to turn both off. The README also warns that it exposes browser content to the MCP client.

js-reverse-mcp and the api-mapper skill turn Chrome into a reverse-engineering instrument for the sites inside it. The first traces function calls through logpoints and injects scripts before page load. The second captures XHR/Fetch traffic over CDP, inspects JS bundles when requests contain computed values, and probes endpoints with curl. Both reflect the same shift: the browser is now the reverse-engineering tool as well as the target.

Where Google's Layer Shows Up: On-Device AI

The most current example of Chrome diverging from Chromium is Gemini Nano. The APIs and the model are both built into Chrome, with the model downloaded on first use. It isn't on mobile, and from Chrome 140 it supports English, Spanish and Japanese. One analysis notes that when conditions are met, Chrome downloads the model in the background with no installation prompt.

You can inspect all of it. Gemini Nano in Chrome documents the flags, the chrome://on-device-internals page, and a useful gotcha: Chrome's internal pages are built from web components with content in shadow DOM, so automation has to walk shadow roots. It reports a model footprint of roughly 4 GB on its test machine. That's one machine's number, and the docs say the size varies with updates.

Why This Matters Beyond Chrome

Three takeaways hold up across everything above.

First, the real boundary is Mojo, not the tab. If you want to understand Chrome's security, read the interface definitions between renderer and browser.

Second, Chrome is a platform with a diverging proprietary layer. Gemini Nano, DevTools-for-agents and the Google service dependencies that ungoogled-chromium strips out all sit above or beside the open core.

Third, the browser has become an agent runtime. When Google ships an MCP server for its own browser, the reverse-engineering target moves from "what does Chrome do" to "what can an agent do through Chrome."

Where to Start

Read the multi-process architecture doc first. Then use Chromium Code Search to follow one navigation from RenderProcessHost outward. Use the ungoogled-chromium patch set as your map of Google dependencies, and run chrome-devtools-mcp against a throwaway profile.

Chrome's code was never the secret. What you learn is how a billion-user browser makes its tradeoffs, and Google has written most of that down.

Follow for more coverage on MCP, agentic AI, and AI infrastructure.