18. The browser's process model: multi-process architecture and site isolation

A modern browser is not one program — it's several cooperating processes, because a single-process browser means one crashed tab (or one exploited renderer bug) takes down everything, including your banking tab open in another window.

┌─────────────────────────────────────────────────────────────┐
│ Browser Process (1, privileged: disk, network sockets, UI)   │
│  - owns the address bar, bookmarks, extensions installation  │
│  - the ONLY process allowed to touch the filesystem directly │
└───────────────┬───────────────────────────────────────────────┘
                │ IPC (Chrome: Mojo; Firefox: IPDL)
    ┌───────────┼──────────────┬─────────────────┬───────────────┐
    ▼           ▼              ▼                 ▼               ▼
┌────────┐ ┌────────┐    ┌──────────┐      ┌───────────┐  ┌────────────┐
│Renderer│ │Renderer│ ... │GPU process│      │Network    │  │Utility procs│
│(tab A) │ │(tab B) │    │(compositing,      │process    │  │(audio, etc.)│
│sandboxed│ │sandboxed│   │ rasterization)   │(fetches,   │  └────────────┘
│no disk/ │ │no disk/ │   └──────────┘      │ DNS, TLS) │
│network  │ │network  │                     └───────────┘
└────────┘ └────────┘

Each renderer process runs a heavily sandboxed copy of the engine (Blink, Gecko, or WebKit) and is deliberately denied direct filesystem/network access — it must ask the privileged browser process via IPC for everything. This is the concrete mechanism that limits the blast radius of a compromised renderer (e.g., an exploited PDF parser or a malicious ad) from becoming a full system compromise.

Site isolation (shipped in Chrome since 2018, largely in response to Spectre) puts each origin — not just each tab — in its own renderer process by default. This is why opening dev tools and inspecting the "Frames" tree of a page with cross-origin iframes shows genuinely separate processes: a malicious iframe's renderer process physically cannot read memory belonging to the parent page's renderer process, closing off an entire class of speculative-execution side-channel attacks (§51).

Real-world example. Task Manager (Chrome: Shift+Esc) literally shows you this architecture — one row per renderer process (often one per tab, sometimes more for cross-origin iframes), one row for the GPU process, one for the network service. A tab using 400MB isn't "the browser" using 400MB — it's that specific renderer process's V8 heap + DOM + layout data.