Chrome's Site Isolation and Firefox's Fission place documents from different sites in different operating-system processes. What attack made a process boundary necessary when the same-origin policy was already enforced in browser code, and what does that boundary protect that in-process checks cannot?

## The assumption Spectre broke A browser's security boundaries were historically enforced *in code*: the renderer holds documents from several origins, and checks scattered through the DOM and network stack decide which origin may touch which object. That design is sound against a language-level attacker — you cannot reach a JavaScript object you were never handed. Transient-execution attacks changed the attacker model. A modern CPU speculates past branches: it predicts the outcome of a bounds check, executes the load on the predicted path, and rolls back the architectural state if the prediction was wrong. The rollback restores registers and memory, but not the cache. An attacker who can steer the predictor and then time cache access learns which address the speculative path touched — and thereby the value it depended on. The consequence for a browser is blunt: script in a renderer can read bytes anywhere in that renderer's address space, without violating a single line of JavaScript semantics. Every in-code origin check becomes advisory, because the read never goes through the check. ## The structural response If checks cannot be trusted, the data must not be there. That is Site Isolation in Chrome and Fission in Firefox: - Documents from different **sites** are rendered in different OS processes. Site here means scheme plus registrable domain (the eTLD+1), not full origin — `https://a.example.com` and `https://b.example.com` are the same site. - Cross-site `<iframe>` elements become **out-of-process frames**: the frame's document lives in its own renderer, and the browser process composites the result. The frame tree spans processes, which is why this took years to ship. - The **browser process** validates what each renderer asks for. A compromised renderer claiming to be a different site is refused, because site identity is tracked outside the renderer. - Chrome adds **Opaque Response Blocking** (the successor to Cross-Origin Read Blocking): cross-origin responses that look like HTML, XML or JSON and that the requesting context could not legitimately read are not delivered into that renderer at all. Without it, a `no-cors` fetch of a sensitive JSON endpoint would still pull the bytes into the process even though script cannot read them — which under Spectre is enough. The protection is **by absence**. The renderer running attacker script simply does not contain the victim's data, so no side channel can reach it. ## What the boundary does not cover Two limits matter in interviews. **It is per-site, not per-origin.** Two different origins on the same registrable domain may share a process, so a compromised subdomain can sit in the same address space as a sensitive sibling. The opt-in `Origin-Agent-Cluster: ?1` response header requests origin-keyed agent clustering, which browsers may use as a hint toward origin-level separation, but it is a request, not a guarantee. **Resources are finite.** One process per site costs memory, and on constrained mobile devices coverage has historically been narrower than on desktop. A guarantee you cannot pay for everywhere is not a guarantee an application can rely on. ## Why applications still need COOP and COEP A natural objection: if the browser separates processes, why must a page send headers to get `SharedArrayBuffer` back? Because the browser cannot know what *your* document intends. Site Isolation protects site A from site B as a platform default. It does not establish that everything sharing your document's agent cluster consented to be there — a same-site cross-origin frame, a credentialled third-party subresource, or a cross-origin opener can all still be in the picture. `Cross-Origin-Opener-Policy` and `Cross-Origin-Embedder-Policy` are the application's own attestation that nothing unconsenting shares its process, and `crossOriginIsolated` is the browser confirming it. Only against that stronger, application-level statement will the platform hand back the precise timers and shared memory that make a side channel practical to exploit. The two mechanisms are therefore complementary, not redundant: one is a platform default that limits the blast radius of any page, the other is an opt-in that a page earns in exchange for dangerous capabilities. ## How to talk about it An interviewer asking this is usually checking whether you understand *why* a mitigation is architectural rather than a patch. The strong answer names the mechanism (speculative execution plus a cache timing channel), states the invariant it breaks (in-process checks are bypassable), and derives the response (remove the data from the process) — rather than reciting that "Chrome uses multiple processes for security", which was already true before Spectre for stability and exploit-containment reasons.