The modern web browser is arguably the most complex application installed on any consumer device, effectively functioning as an operating system within an operating system. It executes arbitrary, untrusted code downloaded from the internet while simultaneously managing access to highly sensitive user data, credentials, and hardware interfaces. For years, the security model of the web relied heavily on the Same-Origin Policy (SOP), a logical boundary enforced by the browser engine to prevent one website from accessing the data of another. However, the discovery of hardware-level vulnerabilities in 2018 fundamentally shattered the assumption that logical boundaries within a single process were sufficient. This paradigm shift necessitated a radical re-architecture of browser internals, moving from resource-conserving process models to the strict, OS-enforced boundaries of Site Isolation.
The Pre-Spectre Era and the Limits of Logical Sandboxing
Before the widespread adoption of Site Isolation, browsers like Google Chrome utilized a multi-process architecture primarily for stability and responsiveness rather than strict security isolation. In this "process-per-tab" model, the browser was split into a main "Browser Process" (handling coordination and privileged actions) and multiple "Renderer Processes" (handling HTML parsing and JavaScript execution). While this prevented a crash in one tab from bringing down the entire browser, the mapping of websites to processes was fluid. To conserve memory, the browser often consolidated multiple tabs from different domains into a single Renderer Process.
In this shared-process environment, the security of user data relied entirely on the browser engine's internal logic to enforce the Same-Origin Policy. If evil.com and bank.com were sharing the same Renderer Process, they inhabited the same virtual memory address space. The browser trusted its Just-In-Time (JIT) compiler and internal checks to prevent the JavaScript running on evil.com from reading the memory addresses belonging to bank.com. This model was efficient and fast, but it operated on the assumption that the CPU would faithfully execute instructions without leaking data. That assumption proved fatal with the advent of transient execution attacks.
The Catalyst: Spectre and Speculative Execution
The disclosure of the Spectre and Meltdown vulnerabilities revealed a critical flaw in modern processor design: optimization features like speculative execution could be weaponized to read memory across logical boundaries. CPUs attempt to predict future instructions and execute them ahead of time to improve performance. If the prediction is wrong, the CPU rolls back the changes, but—crucially—traces of that execution remain in the CPU cache.
This allowed a "Side-Channel Attack." A malicious script on a webpage could trick the CPU into speculatively reading memory it shouldn't have access to (like a password from a cross-origin iframe sharing the same process). Even though the browser would eventually block the illegal access, the data had already been loaded into the CPU cache during the speculative window. The attacker could then use high-precision timers to measure how long it took to access specific memory locations; data in the cache loads faster than data in the main RAM. By measuring these timing differences, the attacker could reconstruct the sensitive data bit by bit. This meant that any sites sharing a Renderer Process were no longer secure from each other, regardless of the software-level protections of the Same-Origin Policy.
The Architectural Response: Site Isolation
To mitigate this hardware vulnerability via software, browser vendors, led by the Chromium team, introduced Site Isolation. This architecture fundamentally changes the relationship between web content and OS processes. Under Site Isolation, the browser enforces a strict rule: pages from different websites must be put into different Renderer Processes. This ensures that evil.com and bank.com never share the same virtual address space.
When Site Isolation is active, the browser uses the operating system's process protection mechanisms as the primary security boundary. Even if an attacker uses Spectre to read any memory available to their process, they will find only their own data. They cannot read the data of a cross-origin site because that data physically resides in a completely different process, protected by the OS kernel's memory management unit. This architecture also changes how iframes are handled; a cross-origin iframe is now moved into a separate process from its parent frame, communicating via Inter-Process Communication (IPC) rather than direct memory access. This incurs a significant memory overhead (approximately 10-15% increase) due to the duplication of browser structures for each new process, but it is currently the only robust defense against process-local side-channel attacks.
Defending the Network Layer: CORB and ORB
Isolating the processes is only half the battle. Browsers must also prevent sensitive data from inadvertently entering an attacker's process via valid web requests. For instance, an <img> tag can request data from any origin. If evil.com requests a confidential JSON file from bank.com using an <img> tag, the request might succeed (depending on CORS), and the data would enter the renderer process before the browser realizes it's not a valid image. In a Spectre world, the mere presence of that JSON data in the process memory—even for a microsecond before rejection—is a vulnerability.
To solve this, browsers introduced Cross-Origin Read Blocking (CORB) and later Opaque Response Blocking (ORB). These mechanisms operate within the network service, outside the renderer process. They inspect the content of a response before delivering it to the renderer. If a response requests a resource type that shouldn't be loaded in a cross-origin context (like HTML, XML, or JSON) but effectively claims to be something else (like an image), CORB/ORB intervenes. The network service replaces the sensitive response body with an empty one before it ever reaches the attacker's process memory. This ensures that there is nothing "valuable" in the process memory for a Spectre exploit to steal.
High-Precision Timers and SharedArrayBuffer
Finally, mitigation strategies extend to the tools attackers use to measure side channels. Spectre attacks rely on extremely precise timing to distinguish between a cache hit and a cache miss. To make this difficult, browsers reduced the precision of performance.now() and added "jitter" (random noise) to timestamps.
However, certain legitimate web capabilities, such as SharedArrayBuffer (used for high-performance multithreading and WebAssembly), require high-precision timers and shared memory segments that inherently increase the risk of side-channel attacks. To re-enable these powerful features safely, browsers introduced a new security requirement known as "Cross-Origin Isolation." Developers must explicitly opt-in using specific HTTP headers (Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp). These headers guarantee that the page has no reference to cross-origin popup windows and does not load cross-origin resources without explicit permission. This creates a validated, isolated environment where the browser feels safe providing high-precision timers, knowing the environment is locked down against external leakage.
The Pre-Spectre Era and the Limits of Logical Sandboxing
Before the widespread adoption of Site Isolation, browsers like Google Chrome utilized a multi-process architecture primarily for stability and responsiveness rather than strict security isolation. In this "process-per-tab" model, the browser was split into a main "Browser Process" (handling coordination and privileged actions) and multiple "Renderer Processes" (handling HTML parsing and JavaScript execution). While this prevented a crash in one tab from bringing down the entire browser, the mapping of websites to processes was fluid. To conserve memory, the browser often consolidated multiple tabs from different domains into a single Renderer Process.
In this shared-process environment, the security of user data relied entirely on the browser engine's internal logic to enforce the Same-Origin Policy. If evil.com and bank.com were sharing the same Renderer Process, they inhabited the same virtual memory address space. The browser trusted its Just-In-Time (JIT) compiler and internal checks to prevent the JavaScript running on evil.com from reading the memory addresses belonging to bank.com. This model was efficient and fast, but it operated on the assumption that the CPU would faithfully execute instructions without leaking data. That assumption proved fatal with the advent of transient execution attacks.
The Catalyst: Spectre and Speculative Execution
The disclosure of the Spectre and Meltdown vulnerabilities revealed a critical flaw in modern processor design: optimization features like speculative execution could be weaponized to read memory across logical boundaries. CPUs attempt to predict future instructions and execute them ahead of time to improve performance. If the prediction is wrong, the CPU rolls back the changes, but—crucially—traces of that execution remain in the CPU cache.
This allowed a "Side-Channel Attack." A malicious script on a webpage could trick the CPU into speculatively reading memory it shouldn't have access to (like a password from a cross-origin iframe sharing the same process). Even though the browser would eventually block the illegal access, the data had already been loaded into the CPU cache during the speculative window. The attacker could then use high-precision timers to measure how long it took to access specific memory locations; data in the cache loads faster than data in the main RAM. By measuring these timing differences, the attacker could reconstruct the sensitive data bit by bit. This meant that any sites sharing a Renderer Process were no longer secure from each other, regardless of the software-level protections of the Same-Origin Policy.
The Architectural Response: Site Isolation
To mitigate this hardware vulnerability via software, browser vendors, led by the Chromium team, introduced Site Isolation. This architecture fundamentally changes the relationship between web content and OS processes. Under Site Isolation, the browser enforces a strict rule: pages from different websites must be put into different Renderer Processes. This ensures that evil.com and bank.com never share the same virtual address space.
When Site Isolation is active, the browser uses the operating system's process protection mechanisms as the primary security boundary. Even if an attacker uses Spectre to read any memory available to their process, they will find only their own data. They cannot read the data of a cross-origin site because that data physically resides in a completely different process, protected by the OS kernel's memory management unit. This architecture also changes how iframes are handled; a cross-origin iframe is now moved into a separate process from its parent frame, communicating via Inter-Process Communication (IPC) rather than direct memory access. This incurs a significant memory overhead (approximately 10-15% increase) due to the duplication of browser structures for each new process, but it is currently the only robust defense against process-local side-channel attacks.
Defending the Network Layer: CORB and ORB
Isolating the processes is only half the battle. Browsers must also prevent sensitive data from inadvertently entering an attacker's process via valid web requests. For instance, an <img> tag can request data from any origin. If evil.com requests a confidential JSON file from bank.com using an <img> tag, the request might succeed (depending on CORS), and the data would enter the renderer process before the browser realizes it's not a valid image. In a Spectre world, the mere presence of that JSON data in the process memory—even for a microsecond before rejection—is a vulnerability.
To solve this, browsers introduced Cross-Origin Read Blocking (CORB) and later Opaque Response Blocking (ORB). These mechanisms operate within the network service, outside the renderer process. They inspect the content of a response before delivering it to the renderer. If a response requests a resource type that shouldn't be loaded in a cross-origin context (like HTML, XML, or JSON) but effectively claims to be something else (like an image), CORB/ORB intervenes. The network service replaces the sensitive response body with an empty one before it ever reaches the attacker's process memory. This ensures that there is nothing "valuable" in the process memory for a Spectre exploit to steal.
High-Precision Timers and SharedArrayBuffer
Finally, mitigation strategies extend to the tools attackers use to measure side channels. Spectre attacks rely on extremely precise timing to distinguish between a cache hit and a cache miss. To make this difficult, browsers reduced the precision of performance.now() and added "jitter" (random noise) to timestamps.
However, certain legitimate web capabilities, such as SharedArrayBuffer (used for high-performance multithreading and WebAssembly), require high-precision timers and shared memory segments that inherently increase the risk of side-channel attacks. To re-enable these powerful features safely, browsers introduced a new security requirement known as "Cross-Origin Isolation." Developers must explicitly opt-in using specific HTTP headers (Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp). These headers guarantee that the page has no reference to cross-origin popup windows and does not load cross-origin resources without explicit permission. This creates a validated, isolated environment where the browser feels safe providing high-precision timers, knowing the environment is locked down against external leakage.