Browser Development: The Security Model and Privacy and Anti-Tracking¶

Part 3 of 5 of the Web Browser Development reference (plugin web-browser-development), covering §8–§9. Sibling skills: browser-engine-architecture-and-networking (§0–§3), browser-rendering-pipeline (§4–§7), browser-extensions-platform-and-standards (§10–§14), browser-development-reference (§15–§20). Section numbers are shared across the set; a reference written as §N → skill points into that sibling skill.

Currency: Verified August 2026. See §17 → browser-development-reference for the currency snapshot and what goes stale first.

How to read this. Reference, not tutorial. Sections are independent. Three markers: - [DURABLE] — architecture, algorithms, or a constraint every engine has independently arrived at. Does not expire. - [ENGINE] — specific to Blink/Chromium, Gecko, WebKit, or Servo/Ladybird. Verify against that project's source or docs. - [CONTESTED] — the vendors genuinely disagree, often because their business models differ. Both cases given, including the commercial motive where it's load-bearing.

⚠️ GOTCHA boxes mark the mistakes that produce security holes, jank, or compatibility breakage that can never be undone.

The two framings that organize everything below: 1. A browser is a hostile-input execution environment that must never say no. It runs untrusted code from anyone, on documents that are frequently malformed, and it is not permitted to refuse or crash. Every architectural decision — the multi-process model, the error-tolerant parser, the sandbox — descends from that. 2. The web's compatibility constraint is stronger than any other platform's. You cannot break existing sites. Not the well-written ones, not the abandoned ones. This is why the platform accretes and rarely subtracts, and why "just fix it properly" is almost never available.

§8. The Security Model¶

8.1 Same-origin policy¶

[DURABLE] The foundational rule: an origin is the (scheme, host, port) triple, and code from one origin cannot read data from another. Everything else in web security is an exception to, or a reinforcement of, this.

The historically-permitted cross-origin operations are the source of most web vulnerabilities: you may embed cross-origin (images, scripts, iframes, styles) and you may send cross-origin requests (forms) — you just can't read the results. CSRF exists because sending is allowed with ambient credentials; XSSI and side-channel leaks exist because embedding is allowed.

8.2 The mitigation alphabet¶

Mechanism	Does what
CORS	Server opt-in to cross-origin reads. Simple vs. preflighted requests; `Access-Control-Allow-*`
CSP	Author-declared allow-list of sources and behaviours. Nonce/hash-based CSP with `strict-dynamic` is the modern form; host allow-lists are widely bypassable
Trusted Types	Prevents DOM XSS structurally by requiring typed objects rather than strings at injection sinks. Reached Baseline in February 2026
SameSite cookies	CSRF defence; `Lax` by default in most engines
`__Host-`/`__Secure-` prefixes	Cookie integrity guarantees
HSTS, CT, CAA	Transport and PKI integrity
Subresource Integrity	Hash-pinned third-party scripts
COOP / COEP / CORP / CORB-ORB	Cross-origin isolation and read blocking (§8.6)
Permissions Policy	Delegating or denying powerful features per-frame
Sandbox attribute / `sandbox` CSP	Capability reduction for embedded content
Secure contexts	Powerful APIs restricted to HTTPS

8.3 XSS, still¶

[DURABLE] XSS remains the dominant web vulnerability class, and the browser's role is to make it structurally impossible rather than to filter it. The history is instructive: engines shipped XSS auditors (Chrome's XSS Auditor, IE's XSS Filter), and all of them were removed — they were bypassable, they introduced their own vulnerabilities, and they caused false positives that broke sites. The lesson generalizes: a filter that must guess intent on a Turing-complete input is not a security boundary. Trusted Types and CSP are the structural replacements.

8.4 Never trust the renderer¶

[DURABLE] The single most important implementation rule in browser security. A compromised renderer will lie about its origin, its URL, its permissions, and the contents of any structure it hands you. Every privileged operation must be re-derived and re-validated in the browser process from state the browser process owns.

Chromium is now moving this enforcement into Rust: the security team has been migrating ChildProcessSecurityPolicy to Rust with a live Canary experiment, both for memory safety and to strengthen the security-relevant invariants that Site Isolation depends on — and has an initial Rust Mojo client enabling services to be implemented fully in Rust.

8.5 Memory safety¶

[VERSIONED — the most active area of browser security engineering.] Roughly 70% of serious browser vulnerabilities have historically been memory-safety bugs. The 2026 state of the art, using Chrome as the documented example: - MiraclePtr / BackupRefPtr — reference-counted raw pointers that neutralize use-after-free by keeping the allocation quarantined. Already credited with a major UAF reduction; being expanded to Skia, ANGLE, Dawn, C++ iterators, and std:: containers. - MiracleObject — being deployed on the GPU main thread, targeting up to 90% of UAFs there, explicitly trading local runtime performance for temporal safety. - PartitionAlloc — a hardened allocator; now enabled in Skia. - "Spanification" — a systematic effort to eliminate out-of-bounds bugs by replacing raw pointer+length pairs with bounds-checked spans. - UBSan -fsanitize=return enabled by default in release builds, with plans to expand. - Rust — a centralized Rust SDK, new modular components written in Rust, and the ChildProcessSecurityPolicy migration above. The stated architectural payoff is significant: writing new components in Rust lets complex features run inside high-privilege processes without the performance penalty of sandboxing — i.e. memory safety buys back architectural freedom that process isolation was spending. - Google has also stated it is exploring implementing the browser's top-level UI in HTML/CSS/TypeScript to reduce dependence on C++ frameworks. - AI-assisted vulnerability finding is now real: Google built an agent harness in early 2026 that found a sandbox escape — a compromised renderer tricking the browser into reading local files — that had survived in the codebase for more than 13 years.

Engine comparison [ENGINE]: Gecko relies on Rust for newer components (Stylo, WebRender) but older C++ doesn't benefit from a BackupRefPtr equivalent, and mozjemalloc is less hardened than PartitionAlloc. WebKit leans on OS integration — pointer authentication on ARM64, strict code signing on iOS — and mostly uses system allocators.

8.6 Spectre and the transient-execution problem¶

[DURABLE, and the reason the architecture looks like it does.] Spectre showed that any high-resolution timer plus speculative execution lets attacker JS read arbitrary memory in its own process. There is no software fix for the CPU behaviour. So the browsers' response was architectural: if the secret isn't in the process, it can't be read. That is Site Isolation's origin story.

The supporting mitigations: reduced timer resolution and jitter, disabling SharedArrayBuffer unless cross-origin isolated (COOP+COEP), CORB/ORB to stop sensitive cross-origin responses from ever entering a renderer, and per-site process locks.

§9. Privacy and Anti-Tracking¶

[VERSIONED, and the folklore is badly out of date. This is worth getting exactly right.]

Timeline: - January 2020 — Google announces intent to phase out third-party cookies in Chrome "within two years," alongside the Privacy Sandbox initiative. Deadlines slip from 2022 → 2023 → 2024 → 2025. - 22 July 2024 — Google announces it will not phase out third-party cookies, proposing a user-choice prompt instead. UK CMA competition concerns and ICO disappointment are both part of the record; the CMA had been formally engaged since 2022. - 22 April 2025 — Google confirms it is maintaining the current approach and will not roll out a standalone opt-out prompt. Default behaviour — third-party cookies allowed — unchanged. - 17 October 2025 — Google retires most Privacy Sandbox APIs, citing low adoption: Topics, Protected Audience, Attribution Reporting, Private Aggregation, IP Protection, Related Website Sets and others. Deprecation lands in Chrome 144 (January 2026) with full removal targeted for Chrome 150 (July 2026). Google's stated continuing focus is privacy-preserving measurement plus FedCM and CHIPS.

[DURABLE] The lesson for an engine implementer is not about advertising. It's that a browser vendor whose revenue depends on advertising faces a structural conflict when changing tracking defaults, and that regulators now treat browser defaults as competition policy. Note also the asymmetry that remains: Safari, Firefox, and Brave still block third-party cookies by default, so roughly 17–20% of global traffic is "cookieless" regardless of Chrome — the fragmentation didn't go away, it just stopped being Chrome-led.

9.2 What browsers actually do now¶

Third-party cookie blocking (Safari ITP since 2020, Firefox ETP, Brave) vs. Chrome's user-choice model.
State partitioning / "total cookie protection" — partitioning all storage (cookies, localStorage, IndexedDB, cache, service workers) by top-level site, so a third party gets a separate jar per embedding site. This is the most important anti-tracking mechanism actually deployed, because it defeats cross-site state without breaking same-site embedding. CHIPS (Partitioned cookies) is the opt-in standardized form.
Cache partitioning — closing the shared-cache timing side channel.
Referrer trimming, Referrer-Policy defaults.
Fingerprinting defences — the hard problem (§9.3).
Bounce-tracking mitigation, link decoration stripping, Global Privacy Control.

9.3 Fingerprinting¶

[CONTESTED, and genuinely unresolved.] Canvas, WebGL, fonts, audio, screen metrics, timing, hardware concurrency, and the sheer combination of exposed APIs form an identifier without any storage at all.

Two philosophies: - Randomization (Brave): add per-session, per-site noise so the fingerprint is unstable. - Uniformity (Tor Browser): make every user look identical, at real functionality cost. - Chrome's position historically leaned on "privacy budget"-style ideas that have not broadly shipped.

The honest assessment: nobody has solved this. Every new capability API adds entropy, which is why capability APIs (§11 → browser-extensions-platform-and-standards) are permanently in tension with privacy, and why "just ship the feature" is never the whole answer.

Plugin: web-browser-development · View SKILL.md on GitHub