Skip to content

Section 37: Browser and Sandbox Architecture

Purpose and Scope

The web browser is arguably the most complex software system running on consumer hardware. A modern browser is an operating system within an operating system: it manages multiple sandboxed processes, implements a JIT compiler, a GPU-accelerated rendering pipeline, a network stack with protocol implementations, a storage subsystem, and an inter-process communication system — all while executing untrusted code from arbitrary websites without compromising the host system. This section covers Chromium's multi-process architecture, V8's JavaScript engine internals (compilation tiers, GC), the rendering pipeline from HTML to pixels, browser security (same-origin policy, CSP, CORS, sandboxing), WebAssembly, WebGPU, service workers, Mojo IPC, and browser fuzzing techniques.

Prerequisites

  • Operating system process isolation concepts (Section 07)
  • Virtual memory and memory management (Section 11)
  • Compiler fundamentals and JIT compilation (Section 30)
  • Security fundamentals — sandboxing, privilege escalation (Section 26)
  • Networking basics — HTTP, TLS, DNS (Section 15)

Learning Objectives

By the end of this section, you will be able to:

  1. Describe Chromium's multi-process model and explain why each process exists
  2. Trace a JavaScript function through V8's compilation tiers from parsing to TurboFan
  3. Describe the browser rendering pipeline from DOM construction to GPU composite
  4. Explain same-origin policy and describe how CORS and CSP enforce it
  5. Explain how the Chromium sandbox works on Linux (seccomp-bpf + namespaces) and Windows (restricted token + job objects)
  6. Describe WebAssembly's compilation model and its security isolation properties
  7. Explain how service workers enable offline functionality and background sync
  8. Describe Mojo IPC and explain how it differs from traditional UNIX IPC

Architecture Overview

Chromium Multi-Process Model

  Browser Process (privileged, one per browser window)
  +-------------------------------------------------------------+
  |  UI thread: window chrome, navigation bar, menus           |
  |  Network thread: HTTP/HTTPS, WebSockets, fetch API         |
  |  Storage thread: cookies, localStorage, IndexedDB          |
  |  Process launcher: spawns/kills renderer/GPU/utility procs |
  +-------------------------------------------------------------+
         |                   |                   |
         | Mojo IPC           | Mojo IPC           | Mojo IPC
         v                   v                   v
  Renderer Process    Renderer Process    GPU Process
  (one per site       (another site,      (one per browser)
   origin, sandboxed)  sandboxed)
  +---------------+   +---------------+  +---------------+
  | Blink engine  |   | Blink engine  |  | GPU driver    |
  | V8 JS engine  |   | V8 JS engine  |  | compositing   |
  | HTML/CSS/DOM  |   | HTML/CSS/DOM  |  | WebGL/WebGPU  |
  | Rendering     |   | Rendering     |  +---------------+
  | SANDBOXED     |   | SANDBOXED     |
  +---------------+   +---------------+

  Additional processes:
  Network Process:  DNS, HTTP(S), WebSockets (separated from browser ~2019)
  Utility Process:  audio, print, media codec (sandboxed helper)
  Plugin Process:   PDF viewer (remaining PPAPI plugin)

  Site Isolation: each cross-origin iframe gets its own renderer process
  (post-Spectre security requirement, enabled ~2018)

V8 JavaScript Engine Compilation Tiers

  JavaScript source code
         |
         v (Parser + Ignition)
  AST -> Bytecode (Ignition interpreter)
  Fast startup, no compilation overhead
         |
         | (Hot function detected by runtime feedback)
         v
  Maglev (mid-tier JIT, ~2022)
  Typed speculation, SSA-based, fast compilation
         |
         | (Very hot function, stable type feedback)
         v
  TurboFan (optimizing JIT compiler)
  Full type specialization, inlining, LICM,
  range analysis, escape analysis -> native code
         |
         | (Type assumption violated = deoptimization)
         v
  Fallback to Ignition bytecode (deopt, recompile)

  Object shape optimization:
  Hidden classes (Maps) track object property layout.
  Objects with same shape share hidden class -> monomorphic IC.
  Property access: 1-2 instructions instead of dictionary lookup.

  Garbage Collection (Orinoco):
  Young gen (Scavenger): semi-space copying, parallel
  Old gen (Mark-Sweep-Compact): incremental marking,
  concurrent sweeping, parallel compaction

Browser Rendering Pipeline

  HTML bytes received
         |
         v
  +------+------+
  |    Parse    |   HTML -> DOM tree
  |    HTML     |   Tokenizer + Tree builder
  +------+------+
         |
  +------+------+
  | Parse CSS   |   CSS -> CSSOM tree
  |             |   @media, specificity, cascade
  +------+------+
         |
  +------+------+
  | Style Calc  |   Attach computed styles to each DOM node
  |             |   (expensive for large documents)
  +------+------+
         |
  +------+------+
  |   Layout    |   Compute geometry (positions, sizes)
  |             |   Block formatting context, flexbox, grid
  +------+------+
         |
  +------+------+
  |   Pre-paint |   Property tree update, compositing decisions
  |             |   Which elements get their own compositor layer?
  +------+------+
         |
  +------+------+
  |    Paint    |   Record display lists (SkCanvas commands)
  |             |   No rasterization yet — display list only
  +------+------+
         |
  +------+------+
  |  Composite  |   GPU process rasterizes tiles (Skia/GPU)
  |  (GPU proc) |   Composites layers -> frame buffer -> screen
  +------+------+

  Critical path for 60fps:
  Frame budget: ~16.7ms total
  JS + Style + Layout + Paint + Composite must fit
  Compositor thread runs independently for scroll/transform

Chromium Sandbox Architecture (Linux)

  Browser Process (no sandbox)
  Full OS access, manages renderer lifetime
         |
         | fork() + execve()
         v
  Renderer Process
  Pre-sandbox setup:
    - Open necessary file descriptors
    - Initialize Mojo channel
  Apply sandbox:
    1. Seccomp-BPF filter (whitelist of allowed syscalls)
       Only: read, write, mmap (anonymous), futex, exit...
       Deny: open, connect, fork, execve, ...
    2. setuid to unprivileged user
    3. Unshare namespaces (network, PID, mount)
    4. chroot to empty directory (optional)

  Any attempt to open a file, make a network connection,
  or fork: blocked by seccomp -> SIGSYS -> browser process
  decides to kill renderer

  Windows: Restricted Token + Job Object + ACL restrictions
  macOS: Seatbelt (sandbox profiles, sandbox_init())

Key Concepts

  • Site Isolation: Chromium's architectural response to Spectre. Places each unique origin in a separate renderer process with its own address space. Prevents a compromised or speculative-execution-abusing page from reading another origin's memory.
  • Mojo IPC: Chromium's internal IPC system replacing older Chrome IPC. Typed interfaces defined in .mojom files, code-generated bindings for C++, Java, and JavaScript. Supports message pipes, data pipes, and shared memory handles.
  • Blink: Chromium's rendering engine (forked from WebKit in 2013). Implements the DOM, CSSOM, HTML parser, layout engine, and the Web Platform APIs. V8 is embedded in Blink for JavaScript execution.
  • V8 Hidden Classes (Maps): V8's optimization for object property access. Each unique object shape gets a hidden class; objects sharing a shape can use the same IC (Inline Cache) compiled code for property access.
  • Same-Origin Policy (SOP): The foundational web security rule: a page at origin A cannot read data from origin B. Origin = scheme + host + port. CORS allows controlled exceptions for cross-origin resource access.
  • Content Security Policy (CSP): HTTP response header declaring which resource origins are trusted for scripts, styles, images, etc. Mitigates XSS by blocking inline scripts and restricting external script sources.
  • WebAssembly (Wasm): Binary instruction format compiled to a stack machine with a formal type system. Sandboxed execution (linear memory with bounds checking, no direct system calls). Targets near-native performance. WASI extends Wasm with OS-like capabilities.
  • WebGPU: W3C API for direct GPU access from browsers. Exposes compute shaders and render pipelines. Built on Vulkan (Linux), Metal (macOS/iOS), D3D12 (Windows) backends. Replaces the complexity of WebGL with a modern API.
  • Service Workers: Background scripts that intercept network requests, enabling offline caching, push notifications, and background sync. Run in their own thread, no DOM access, communicate via postMessage.

Major Historical Milestones

Year Milestone
1993 Mosaic — first graphical web browser
1995 Netscape Navigator — JavaScript (Mocha/LiveScript) introduced
2001 Internet Explorer 6 — peak IE dominance; ActiveX exploits proliferate
2003 Safari — Apple forks KHTML into WebKit
2004 Firefox 1.0 — open-source browser renaissance
2008 Chrome 1.0 — multi-process architecture, V8 JIT, process-per-tab
2008 V8 JavaScript engine — JIT compilation brings near-native JS speed
2010 Chrome 4 — HTML5 Canvas, Web Workers
2012 Chrome 17 — GPU accelerated rendering (Blink GPU compositing)
2013 Blink — Chromium forks from WebKit
2014 asm.js — precursor to WebAssembly, LLVM -> JS ahead-of-time compilation
2015 Service Workers — offline-capable Progressive Web Apps
2017 WebAssembly MVP — W3C recommendation, all major browsers ship
2018 Spectre/Meltdown — Site Isolation enforced in Chrome 67
2018 Mojo IPC replaces legacy Chrome IPC
2019 Network Process separated from browser process
2021 WebGPU origin trial begins in Chrome
2023 WebGPU ships in Chrome 113 — compute shaders in browsers
2024 V8 Maglev mid-tier JIT ships in Chrome stable

Modern Relevance

Browsers run code from any website on the planet, making them the most hostile execution environment imaginable. The security architecture of Chromium has directly influenced OS-level container and sandbox design. V8's JIT infrastructure is studied as a model for high-performance managed language runtimes. WebAssembly has escaped the browser: WASM is now the isolation mechanism for Cloudflare Workers, Fastly Compute@Edge, and Wasmtime-based serverless runtimes. WebGPU is enabling GPU compute on the web. Understanding browser internals is essential for web security research, browser exploit development, performance engineering, and the growing field of browser-hosted edge compute.

File Map

37-browser-and-sandbox-architecture/
├── 00-overview.md              <- This file
├── 01-multi-process-model.md
├── 02-chromium-internals.md
├── 03-v8-javascript-engine.md
├── 04-rendering-pipeline.md
├── 05-dom-and-cssom.md
├── 06-layout-and-paint.md
├── 07-compositor-and-gpu.md
├── 08-same-origin-policy.md
├── 09-csp-and-cors.md
├── 10-browser-sandboxing.md
├── 11-browser-storage.md
├── 12-webassembly.md
├── 13-webgpu.md
├── 14-service-workers.md
├── 15-mojo-ipc.md
└── 16-browser-fuzzing.md

Cross-References

  • Section 07 (Process Management): Multi-process model; process isolation via OS primitives
  • Section 26 (Security): Sandbox escape vulnerabilities; CSP bypass techniques
  • Section 27 (Kernel Exploits): Renderer-to-browser escalation; seccomp-bpf bypass
  • Section 30 (Compilers): V8 TurboFan JIT; WebAssembly compilation pipeline
  • Section 36 (Mobile OS): Chrome on Android (uses Binder); Safari on iOS (WebKit, App Store restriction)