Site Isolation
A one-time architectural or governance choice whose consequences still govern current work.
The 2018 decision to place each cross-site iframe in its own renderer process, refining the multi-process boundary from per-tab to per-site so that an OS-enforced barrier (rather than same-origin policy alone) protects sites from Spectre-class speculative-execution side channels.
“An attacker can subvert the same-origin policy in any browser that runs documents from different web sites in the same renderer process. Site Isolation provides the OS-enforced separation that same-origin policy assumes.” — Charles Reis, Alexander Moshchuk, Nasko Oskov, Site Isolation: Process Separation for Web Sites within the Browser, USENIX Security 2019
Decision Statement
The Chromium project decided in 2017–2018 to place every cross-site document (including cross-site iframes embedded in a host page) in its own renderer process, so that the OS process boundary separates web pages from different sites. Shipped to desktop Stable in Chrome 67 on 17 July 2018 and to most Android Stable users in Chrome 77 in October 2019.
Context
In January 2018, the Spectre and Meltdown disclosures (CVE-2017-5753, CVE-2017-5754) showed that speculative execution in modern CPUs leaks memory across software-enforced boundaries. A malicious JavaScript page could read any data sharing its renderer’s address space, including the bytes of a cross-site iframe loaded in the same process. The Multi-Process Architecture decision of 2008 placed each tab in its own renderer, but cross-site iframes still shared the host tab’s renderer. The same-origin policy, the web’s foundational isolation primitive, was enforced inside the renderer by Blink, and Spectre let JavaScript read past Blink’s checks at the speculation layer below them.
Work on out-of-process iframes had begun at the project as early as 2013 under the name OOPIF, motivated by <webview> isolation for Chrome Apps and by the long-running goal of strengthening cross-origin defenses. Spectre converted a multi-year engineering project into a hard deadline. The team accelerated the rollout, completed the renderer-process-per-site model on desktop in the first half of 2018, and shipped it to Stable in Chrome 67. The Android rollout took longer because of memory constraints on the platform’s broad device population. The per-site boundary reached most Android devices through a phased default-on in Chrome 77 and was conditionally relaxed on low-memory hardware through Process Consolidation Under Memory Pressure.
The decision sits in the lineage of the multi-process architecture but is logically distinct. Multi-Process Architecture answered the question “what is the unit of isolation?” with “the renderer process.” Site Isolation answered the question “what does that boundary protect against?” with “any same-process data exfiltration, including hardware-level side channels.”
Alternatives Considered
| Alternative | Description | Reason rejected |
|---|---|---|
| Trust same-origin policy as enforced by Blink | Keep cross-site iframes in the host page’s renderer; rely on Blink’s same-origin checks to prevent cross-site reads. | Spectre let JavaScript read process memory through speculation. Blink’s checks ran at a layer above the speculation; they were bypassable through gadgets the renderer can’t prevent. Same-origin policy as a software construct couldn’t survive the threat model. |
Disable high-resolution timers and SharedArrayBuffer only | Reduce Spectre’s bandwidth by removing the high-resolution clocks attackers needed to amplify the side channel; keep the rest of the renderer model unchanged. | A partial mitigation. The project shipped these timer restrictions in January–February 2018 as a stop-gap, but the long-term security model couldn’t depend on “attackers can’t get a high-resolution clock back.” Browser-internal clocks were reconstructible; new timing channels would emerge. The OS-level boundary was the only durable mitigation. |
| Hypervisor-isolated renderers | Run each renderer inside a lightweight VM rather than as a process, achieving stronger isolation than the OS sandbox alone. | Memory and startup-latency costs were prohibitive for desktop and infeasible for mobile in 2018. The OS process boundary, hardened by the existing renderer sandbox profile, was strong enough against Spectre once cross-site frames lived on separate processes; the additional hypervisor layer carried cost without commensurate gain at the deployment scale required. |
| Per-renderer-process per cross-site iframe (chosen) | Each cross-site iframe and each top-level cross-site navigation gets its own renderer process; the OS page tables, not Blink, enforce the boundary. | The mitigation Spectre forced and the security model the field had assumed all along. OS-enforced separation holds against side-channel reads because separate processes don’t share an address space; the speculation Spectre exploits can’t reach across process boundaries. The cost (more processes per page, more total memory) was paid because the alternative was conceding cross-origin data exfiltration. |
The acceleration of the existing OOPIF work, rather than a fresh design search, is itself part of the alternative-elimination logic: the project had already evaluated and built the per-site model for other reasons; Spectre supplied the security case that justified shipping it broadly.
Rationale
Three properties of per-site process isolation carried the decision against the partial-mitigation alternatives.
The boundary is below the speculation layer. Spectre and its successors are speculative-execution side channels: the CPU executes instructions past a security check, leaks the result through a microarchitectural channel (cache state, port contention, TLB pressure), and an attacker reconstructs the leaked data through timing measurements. Software-enforced same-origin checks run at the instruction level, where speculation operates below them. Process boundaries are enforced by the page tables, which speculation can’t cross because the cross-site bytes aren’t mapped into a per-site renderer’s address space. The hardware enforces the per-site boundary the same way it enforces separation between any two ordinary processes; there is no speculative path past it.
Cross-site iframes inherit the host’s privilege model, not its address space. Before Site Isolation, a cross-site iframe ran in the host page’s renderer, governed by the host’s same-origin checks but sharing the host’s address space. The host couldn’t read the iframe’s DOM through scripting (same-origin policy), but its bytes lived next to the iframe’s. With Site Isolation, the iframe runs in a separate renderer that the host page reaches only through Mojo IPC; cross-origin reads require an IPC call the browser validates, not a memory access. The Browser-Renderer Privilege Split is what each cross-site frame inherits.
The Spectre threat model treats Blink as adversarial. Before Spectre, Blink was the renderer-side enforcer of same-origin policy; the threat model treated Blink as trusted to deny cross-origin reads. Spectre’s speculation gadgets fit inside JavaScript that Blink accepted, and they ran through the speculation layer below Blink’s checks. Blink couldn’t enforce same-origin policy against an attacker who controlled JavaScript on a same-process page. Per-site processes moved the enforcement out of Blink into the kernel, where the threat model holds. The Untrusted Renderer Axiom is the operational form of this shift: every renderer is hostile, including the one running the host page itself.
Ongoing Consequences
Site Isolation imposes ongoing constraints on every domain the multi-process boundary touches. The consequences differ from those of the founding decision in degree rather than kind, but two new properties of the per-site model are load-bearing for downstream work.
Memory cost is the most visible constraint. The project measured the desktop overhead at the time of the Chrome 67 launch and reported it as approximately 10–13% additional total memory; the figure has remained in that range as Chromium’s underlying memory model has evolved. The cost compounds on pages with many cross-site frames (advertising, embedded video, third-party widgets), where what would have been one renderer process becomes one per origin. The Memory Pressure Response pattern documents the platform-wide companion mechanism that surfaces this cost on constrained hardware. On Android, the cost is high enough that the per-site boundary is conditional: devices below a configured memory threshold receive a coarser-grained isolation (full Site Isolation for password-handling sites only, partial isolation otherwise) via the consolidation pattern.
Cross-process navigation becomes the common case rather than an exception. Every cross-site link follow, form submission, and redirect lands on a renderer that didn’t hold the source page’s content. The whole request lifecycle moves through the browser process between the unload of the source renderer and the commit of the destination. The browser process now owns more of the navigation state machine than it did before 2018, and the Rendering Pipeline reflects this: composition, paint, and even some script execution may need cross-process coordination when a page contains cross-site frames.
For security response, Site Isolation reshapes the structure of exploit chains. Before 2018, a compromise of a renderer that hosted a cross-site iframe was already a cross-origin compromise; the same renderer’s memory held both sites’ data. After 2018, each link of the Sandbox Escape Chain gains a process-boundary check: a memory-corruption primitive in a renderer compromises that site’s renderer, not the host page’s, and the attacker still has to escape the renderer’s OS sandbox to reach the cross-site data. The chain grows another link, and the Spectre-class read path is closed entirely.
For the API governance pipeline, Site Isolation establishes a boundary the Intent to Ship Pipeline actively defends. A proposed web platform feature that would expose cross-origin data through a same-process channel (high-resolution timers, shared array buffers, cross-origin font reads, fingerprinting surfaces) is reviewed against the per-site model. The proposal either demonstrates that the feature works without cross-process data exposure or gates the feature behind cross-origin isolation headers (COOP, COEP) that re-establish the per-site invariant for pages that opt in. The post-Spectre browser-platform features (crossOriginIsolated and the COOP / COEP header pair) are themselves direct consequences of this decision.
For the renderer codebase, the per-site invariant has to be maintained continuously as the project evolves. New rendering features (CSS painting APIs, font loaders, image decoders, web-platform integrations) have to be evaluated for whether they read cross-origin data on a same-process page. The SiteInstance and BrowsingInstance types in content/browser/ are the implementation surface where the decision lives; code that touches process assignment is reviewed against the security model the decision establishes.
Reversal Conditions
The decision is effectively permanent on desktop. Three things would have to be true for it to be revisited.
The hardware side-channel surface would have to be eliminated. A CPU generation that closed the speculative-execution side channels Spectre exploits (through capability-secure memory tagging, process-tag enforcement in the cache, or speculation barriers the OS could trust) would weaken the per-site boundary’s security case. Hardware-mitigation work to date (Intel’s MDS-class fixes, ARM’s pointer authentication, IBR / IBPB barriers) has reduced specific channels but hasn’t closed the general speculative-read surface that Site Isolation defends against. The project treats the hardware side-channel surface as a continuing risk.
The memory cost would have to become prohibitive at the desktop scale, not only on low-memory mobile. The current response on Android is conditional relaxation, not a structural reversal; desktop hasn’t encountered the threshold at which the per-site boundary becomes unaffordable, and the per-site assignment is on by default. A new class of memory-constrained desktop-like devices could force broader conditional relaxation, but the structural commitment to per-site isolation on capable hardware isn’t in question.
A fundamentally different web threat model would have to obtain. The decision is calibrated against a threat model in which cross-site data exposure is a security-relevant compromise, including through hardware side channels. If cross-origin reads through speculation became uninteresting because there was nothing valuable to read across origins, the per-site invariant would become an architectural choice rather than a security requirement. Nothing about the modern web suggests that direction; the threat model has gone the other way since 2018. Spectre’s variants have continued to emerge (L1TF, MDS, RIDL, Fallout, ZombieLoad), each confirming the durability of the design assumption that software-enforced cross-origin boundaries can’t hold against speculation.
None of these conditions is close. The project treats the per-site boundary as a permanent feature of the web platform’s security posture, and reasoning that depends on cross-site data not being readable through the renderer’s address space is the default register for security review.
Notes for Agent Context
An AI coding agent working on Chromium code must hold the per-site process model explicitly, not merely the per-renderer one. Process assignment for a navigation or iframe is governed by SiteInstance in content/browser/site_instance_impl.cc; never propose code that reuses an existing renderer for a navigation to a different site, never reach for cross-frame access that bypasses the IPC-mediated cross-process path, and never assume two frames in the same tab share a renderer. When designing a new web-platform feature, default to “cross-origin data is reachable only through an IPC call the browser validates”; features that would expose cross-origin bytes through a same-process channel (timing, shared buffers, cross-origin font reads) require crossOriginIsolated opt-in via COOP and COEP headers. When writing or reviewing Mojo interfaces that handle content from multiple sites, treat the question “which site’s renderer is this message coming from?” as the load-bearing security check; identity is established by the renderer’s SiteInstance, not by content in the message.
Related Patterns
Sources
The canonical primary source is Reis, Moshchuk, and Oskov’s 2019 USENIX Security paper Site Isolation: Process Separation for Web Sites within the Browser, which records the design, the threat model, the memory-overhead measurement, and the Spectre motivation in their original technical form. The Chrome Security blog post of 11 July 2018, Mitigating Spectre with Site Isolation in Chrome, is the public-facing announcement and the citable reference for the 10–13% desktop memory overhead figure. The Chromium project’s own docs/process_model_and_site_isolation.md is the authoritative living description of the design as it has evolved through subsequent Chrome versions, including the Android consolidation policy and the cross-origin isolation header pair. The January 2018 Spectre disclosure (CVE-2017-5753, CVE-2017-5754) provides the threat-model context the decision responds to; the NVD entries and Project Zero’s 3 January 2018 Reading privileged memory with a side-channel post are the authoritative primary sources for the vulnerability class.
Technical Drill-Down
content/browser/site_instance_impl.cc— theSiteInstanceimplementation; process-assignment logic and theShouldAssignSiteForURLheuristic live here.docs/process_model_and_site_isolation.md— the current design documentation for the process model and Site Isolation, including the Android consolidation thresholds.- Site Isolation: Process Separation for Web Sites within the Browser, Reis, Moshchuk, Oskov, USENIX Security (2019) — the founding paper; memory-overhead measurement is in §6, threat model in §3.
- Mitigating Spectre with Site Isolation in Chrome, Chrome Security blog, 11 July 2018 — the public rationale and the citable source for the 10–13% desktop memory overhead.
- Reading privileged memory with a side-channel, Project Zero blog, 3 January 2018 — the Spectre disclosure that converted the per-site project into a deadline.
docs/security/side-channel-threat-model.md— the project’s documented stance on side-channel threats and the boundary Site Isolation defends.