Browser
Multi-process sandboxed runtime
The browser is an operating system within an operating system. It receives the OS event, routes it through its own process architecture, and dispatches it into the DOM.
How It Works
A modern browser runs as multiple OS processes, each with different privileges. The browser process (sometimes called the 'main' or 'UI' process) handles the address bar, tabs, bookmarks, and — critically — all network I/O. Renderer processes are sandboxed: they can execute JavaScript and build the DOM, but they cannot directly access the file system, network, or GPU. This architecture means a compromised web page cannot escape its sandbox.
When the OS delivers a keyboard or mouse event to the browser, the browser process receives it first. It determines which tab and renderer should handle it, serializes the event into an IPC message, and sends it to the appropriate renderer process via the Mojo IPC system (Chromium) or equivalent. The renderer process deserializes the event and injects it into its DOM event dispatch pipeline. This IPC hop adds a small amount of latency (~1–2 ms) but provides critical security isolation.
The Signal Flow
Key Concepts
Renderer processes run with minimal OS permissions — no file system access, no network access, no GPU access. All privileged operations go through IPC to the browser process, which enforces security policy.
Each site (scheme + eTLD+1) gets its own renderer process. This prevents Spectre-class attacks where one site could read another's memory. It's why your browser uses so much RAM — it's security, not waste.
The message-passing system between browser processes. Chromium uses Mojo, Firefox uses IPC protocol. All cross-process data flows through serialized messages — no shared memory for sensitive data.
A dedicated process that manages GPU access. Renderers send compositing commands via IPC; the GPU process executes them. This isolates GPU driver bugs from the main browser.
Deep Dive
Why multi-process matters
Before Chrome pioneered multi-process architecture in 2008, browsers were single-process. A crash in one tab killed all tabs. A malicious page could access other pages' data. Multi-process isolation means each site is a separate OS process with its own memory space and permissions. Even if an attacker finds a JavaScript engine vulnerability, they still need a second sandbox-escape vulnerability to do anything useful. This defense-in-depth is why all modern browsers now use multi-process.
The IPC latency tax
Every interaction pays a small tax: the OS event must cross a process boundary to reach the renderer. This IPC hop typically takes 1–2 ms. For most interactions this is imperceptible, but for latency-sensitive use cases (gaming, drawing) browsers have optimized paths. The compositor can handle scrolling and simple animations without involving the renderer process at all — that's why scrolling stays smooth even when JavaScript is busy.