Chromium Process-per-Site-Instance vs. Process-per-Tab

This article examines how the Chromium web browser manages its multi-process architecture by comparing its default process-per-site-instance policy against the process-per-tab configuration. It details the underlying enforcement mechanisms managed by the browser kernel, specifically focusing on how Chromium isolates web content, handles cross-site navigations, allocates system memory, and maintains security boundaries between different web origins.

Architectural Foundation

To enforce any process model, Chromium divides its architecture into a single privileged Browser Process and multiple sandboxed Renderer Processes. The Browser Process acts as the kernel; it manages network access, the user interface, and process creation. Renderer Processes execute HTML, CSS, and JavaScript inside restricted operating system sandboxes. The Browser Process dictates which Renderer Process handles which web content using two primary internal abstractions:

  • BrowsingInstance: Represents a group of connected tabs or windows that might need to communicate with each other (for example, a tab and a popup window it opened via JavaScript).
  • SiteInstance: Represents a group of pages within a BrowsingInstance that share the same registered domain name (site) and therefore must share a Renderer Process to allow synchronous scripting access.

How Process-per-Tab Works

In a strict process-per-tab configuration (triggered via the --process-per-tab command-line flag), Chromium attempts to dedicate a single Renderer Process to a single tab, regardless of the user's navigation history within that tab.

Enforcement Mechanism:

  1. Tab Creation: When a user opens a new tab, the Browser Process generates a new BrowsingInstance and spawns a dedicated RenderProcessHost, which launches a single OS-level Renderer Process.
  2. Cross-Site Navigation: If the user navigates from site-a.com to site-b.com within that same tab, the Browser Process instructs the existing Renderer Process to unload the old document and render the new one.
  3. Subframes: Historically, under this model, all <iframe> elements within that tab—even those from different domains—are rendered inside the same process assigned to that tab.

Limitations: Process-per-tab fails to isolate malicious code effectively. If site-a.com and site-b.com share a process during a navigation transition or via an iframe, side-channel attacks (such as Spectre) can allow one site to read memory belonging to the other.

How Process-per-Site-Instance Works

Process-per-site-instance is Chromium’s default policy. It aligns process boundaries with security origins rather than user interface tabs. A "site" is defined by its scheme and registered domain (e.g., https://example.com).

Enforcement Mechanism:

  1. Independent Tabs: When a user opens two separate tabs and navigates both to example.com, Chromium creates two separate BrowsingInstances and two separate SiteInstances. Consequently, it spawns two distinct Renderer Processes, even though the website is the same.
  2. Connected Tabs: If a page on example.com uses window.open() to launch a new tab to sub.example.com, both tabs share the same BrowsingInstance and the same SiteInstance. The Browser Process forces both tabs to run inside the exact same Renderer Process so their scripts can synchronously interact via the DOM.
  3. Cross-Site Navigation: When a user in a single tab clicks a link that navigates from example.com to other-domain.org, the Browser Process intercepts the network request. It recognizes the domain change, creates a new SiteInstance, spawns a new Renderer Process for other-domain.org, swaps the tab's view to the new process, and terminates the old example.com process.

Strict Enforcement via Site Isolation

Modern Chromium strengthens the process-per-site-instance policy through a feature called Site Isolation, which is enabled by default on desktop platforms. Site Isolation ensures that a Renderer Process never hosts documents from more than one site, overriding standard process-per-tab behaviors even if flags are applied.

Out-of-Process iframes (OOPIFs): If a page on example.com embeds an <iframe> pointing to ads.com, the Browser Process creates a separate SiteInstance for the iframe. It spawns a distinct Renderer Process for ads.com and uses the GPU process to composite the visual output of the iframe seamlessly into the parent tab.

IPC Filtering: The Browser Process enforces this isolation at the communication layer using Mojo (Chromium's Inter-Process Communication system). The Browser Process locks each RenderProcessHost to a specific site origin. If a compromised Renderer Process locked to ads.com attempts to send an IPC message requesting cookies or local storage for example.com, the Browser Process rejects the request and terminates the offending Renderer Process.

Process Allocation Under Memory Pressure

Chromium dynamically alters its enforcement of process-per-site-instance when system resources are constrained. The browser sets a hard limit on the maximum number of Renderer Processes based on the device's available RAM and CPU cores.

  • Process-per-Tab Behavior: Continues to spawn processes for new tabs until the OS runs out of memory, resulting in crashed tabs.
  • Process-per-Site-Instance Behavior: Once the process limit is reached, the Browser Process stops creating new processes for new SiteInstances. Instead, it consolidates processes by searching for an existing Renderer Process already dedicated to the target domain (even if it belongs to an unrelated BrowsingInstance) and assigns the new tab to that existing process. This preserves security isolation between different domains while capping memory consumption.