Skip to content

Browser Development: Anti-Patterns, Contested Questions, Currency, and Canon

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

Currency: Verified August 2026. See §17 below 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.

§15. Anti-Patterns

Anti-pattern Why Instead
Trusting an origin claimed by a renderer Compromised renderer = full cross-site read Re-derive and validate in the browser process (§8.4 → browser-security-and-privacy)
Giving a renderer direct file/network/device access Removes the sandbox's entire point Broker through validated IPC
Unvalidated sizes/indices/handles over IPC Memory corruption in the privileged process Validate every field; fuzz the surface
Custom HTML error recovery Compatibility divergence from the whole web Implement the spec algorithm exactly (§4.1 → browser-rendering-pipeline)
Left-to-right selector matching Pathological performance Right-to-left + bloom filters (§5.2 → browser-rendering-pipeline)
Recomputing all style on any mutation Jank Invalidation sets (§5.3 → browser-rendering-pipeline)
Mutable layout tree holding inputs and outputs Unpredictable incremental layout Immutable fragment tree (§6.2 → browser-rendering-pipeline)
Doing scroll or transform animation on the main thread Jank whenever JS is busy Property trees + compositor thread (§6.1 → browser-rendering-pipeline)
will-change on everything GPU memory exhaustion Layerize deliberately
Interleaving geometry reads and style writes Forced synchronous layout, N× cost Batch reads, then writes (§7.3 → browser-rendering-pipeline)
Sniffing content into an executable type XSS vector Honour nosniff; restrict sniffing
Shipping an XSS filter as a security boundary Bypassable; introduces its own bugs; all were removed CSP + Trusted Types (§8.3 → browser-security-and-privacy)
Unpartitioned storage or cache Cross-site tracking and timing side channels Partition everything by top-level site (§9.2 → browser-security-and-privacy)
High-resolution timers plus shared-process secrets Spectre Coarsen timers; isolate by site (§8.6 → browser-security-and-privacy)
Adding a capability API without an entropy review Permanent fingerprinting surface Review entropy and permission model together (§9.3 → browser-security-and-privacy, §11 → browser-extensions-platform-and-standards)
Shipping a web feature without an exit plan You can never remove it Origin trial + use counters first (§14 → browser-extensions-platform-and-standards)
Prefixed CSS properties -webkit- became a de facto standard other engines had to implement Flags and origin trials, never prefixes
Reverse-engineering another engine's quirks instead of specifying them Perpetuates the divergence Spec it, add WPT, take it to Interop (§13 → browser-extensions-platform-and-standards)
Treating accessibility as a post-architecture concern It crosses the process boundary; retrofitting is expensive Design the a11y tree with the process model (§12 → browser-extensions-platform-and-standards)
Assuming the network service is trusted It parses hostile input for all sites at once Sandbox and memory-harden it (§3.1 → browser-engine-architecture-and-networking)

§16. Contested Questions

16.1 Manifest V3. §10.2 → browser-extensions-platform-and-standards. Real security argument; real conflict of interest; Firefox demonstrating that supporting both is technically possible.

16.2 Capability APIs — how much should the web be able to do? §11 → browser-extensions-platform-and-standards. Chrome's "the web should match native" versus Apple's and Mozilla's "every API is attack surface and fingerprinting entropy." Both coherent; the disagreement is about risk appetite and, inescapably, about business models.

16.3 The engine monoculture. For consolidation: one excellent open-source engine beats five mediocre ones; interop problems vanish. Against: 81% share means one vendor's priorities become web policy, "works in Chrome" replaces "follows the spec," and there's no check on capability expansion. Note that the counterweight is weakening — Gecko is at ~3% and Mozilla's revenue depends largely on a Google search deal.

16.4 Site Isolation's cost. §2.2 → browser-engine-architecture-and-networking. Chromium's own docs concede the process-count ceiling, especially on Android. The emerging answer is memory-safe languages buying back the isolation that processes were paying for.

16.5 JIT or no JIT. §7.1 → browser-rendering-pipeline. Ladybird's no-JIT position and Apple's JIT entitlement restrictions on iOS come from the same reasoning: JITs are enormous exploit surfaces. The cost is performance, and nobody has shown a no-JIT engine that's competitive on JS-heavy sites.

16.6 Fingerprinting: randomize or uniformize. §9.3 → browser-security-and-privacy.

16.7 Should the browser block ads by default? Brave does; others don't. It's a security control (malvertising), a privacy control, and an existential threat to the ad-funded web simultaneously.

16.8 Living standards vs. versioned specs. Living standards track reality and never go stale; they also mean "conformant" is not a fixed target, which is hard for anyone building an independent implementation — a point Ladybird and Servo feel directly.

§17. Currency Snapshot — verified August 2026

Thing Status as of Aug 2026 Decay risk
Engine share Blink ~81%, WebKit ~14%, Gecko ~3% (desktop+mobile+tablet, ~May 2026). Remaining ~1%: Goanna, Flow, Servo, Ladybird Low
Ladybird Independent C++ engine (LibWeb/LibJS), non-profit-backed, ~7–10 FT engineers, no code from other engines, no search-deal funding. Alpha targeted 2026 (Linux/macOS), beta 2027, stable 2028. Roadmap (not shipped): Rust style/layout, sandboxing, GPU isolation, Wasm GC High
Servo Rust, embeddable, parallel; under Linux Foundation Europe; components (Stylo, WebRender) shipped in Firefox. Positioned as a webview, not a browser Medium
Third-party cookies ⚠️ Not being deprecated in Chrome. 22 Jul 2024 first reversal; 22 Apr 2025 confirmed current approach with no standalone prompt. Safari/Firefox/Brave still block by default (~17–20% of traffic) Medium
Privacy Sandbox ⚠️ Mostly shut down. On 17 Oct 2025 Google retired most APIs (Topics, Protected Audience, Attribution Reporting, Private Aggregation, IP Protection, Related Website Sets) citing low adoption. Deprecated in Chrome 144 (Jan 2026), full removal targeted Chrome 150 (Jul 2026). Continuing focus: privacy-preserving measurement, FedCM, CHIPS Medium
Manifest V2 ⚠️ Essentially dead in Chrome. By June 2026 Chromium removed kExtensionManifestV2Disabled; Chrome 150/151 remove the last overrides. Edge and Opera follow. Full uBlock Origin unavailable on Chrome (uBO Lite only); available on Firefox and Brave. Firefox retains both MV2 and MV3 with blocking webRequest Medium
Interop Interop 2026 is the fifth year (Apple, Google, Igalia, Microsoft, Mozilla). Interop 2025 finished with an overall score of 95 (from 25); Firefox went 46 → 99. 2026 areas: cross-document view transitions, attr(), contrast-color(), custom highlights, scroll-driven animations, scroll snap, shape(), Navigation API precommitHandler, scoped CustomElementRegistry, fetch streaming bodies, mobile testing Medium
Baseline Trusted Types reached Baseline February 2026; also shape(), zstd, Navigation API. Newly available = all major engines; Widely available = +30 months Medium
Chrome memory safety MiraclePtr expanding to Skia, ANGLE, Dawn, C++ iterators, std:: containers; MiracleObject on the GPU main thread targeting ~90% of UAFs there; "spanification" against OOB; UBSan -fsanitize=return default in release; PartitionAlloc in Skia; ChildProcessSecurityPolicy being migrated to Rust (Canary experiment) plus an initial Rust Mojo client; exploring an HTML/CSS/TypeScript top-level UI High
AI in browser security Google's early-2026 Gemini-based agent harness found a sandbox escape that had survived >13 years in Chrome's codebase High
Site Isolation ceiling Chromium docs state plainly that sandboxing and site isolation are reaching their limits — processes are not cheap, especially on Android where extra processes cause background activities to be killed more often Low

Goes stale fastest: Chrome's memory-safety program and AI-assisted vuln finding; Ladybird's alpha timeline; MV2 removal specifics; Privacy Sandbox removal milestones. Essentially never stale: §2.1 → browser-engine-architecture-and-networking–2.4 (process model and IPC discipline), §4.1 → browser-rendering-pipeline (HTML parsing), §5.1 → browser-rendering-pipeline–5.2 (cascade and selector matching), §6.1 → browser-rendering-pipeline–6.2 (pipeline and immutability), §7.3 → browser-rendering-pipeline (event loop), §8.1 → browser-security-and-privacy–8.4 (security model), §15 (anti-patterns).

§18. The Canon

18.1 Primary sources — overwhelmingly the best material

  • The specifications themselves, and they are unusually readable: html.spec.whatwg.org (the parsing algorithm in §4.1 → browser-rendering-pipeline is worth reading in full), dom.spec.whatwg.org, fetch.spec.whatwg.org, url.spec.whatwg.org, the CSS specs at drafts.csswg.org, and HTML Standard §"event loops."
  • Chromium documentation — chromium.org and chromium.googlesource.com/chromium/src/+/main/docs/. Specifically: the Site Isolation design doc, process_model_and_site_isolation.md, the memory safety page (unusually honest about limits), and the Chrome Security quarterly updates, which are the single best running account of browser security engineering anywhere.
  • RenderingNG series on developer.chrome.com/docs/chromium/ — overview, architecture, key data structures, BlinkNG, LayoutNG, VideoNG. Chris Harrelson et al. This is the best public description of a modern rendering engine's architecture, full stop.
  • Mozilla: firefox-source-docs.mozilla.org, Mozilla Hacks (Stylo, WebRender, Quantum, and Fission write-ups), the Mozilla standards-positions repo.
  • WebKit blog (webkit.org/blog) — especially the Interop and ITP posts.
  • web.dev and MDN — MDN is the de facto platform reference; web.dev carries Baseline and the Chrome rendering/performance material.
  • Web Platform Tests (web-platform-tests.org, wpt.fyi) and the Interop dashboard.
  • Ladybird (ladybird.org, and the GitHub repo) and Servo (servo.org) — both are readable codebases in a way the big three are not, which makes them excellent learning material even if you never ship them.

18.2 Books and long-form

Work Why
Tali Garsiel & Paul Irish, "How Browsers Work" The classic single-article overview. Dated in specifics, correct in shape
"Web Browser Engineering" (Panchekha & Harrelson) Free online. Build a browser in Python, chapter by chapter. The best hands-on introduction that exists
Alan Grosskurth & Michael Godfrey, "A Reference Architecture for Web Browsers" The academic framing of the component decomposition
Michal Zalewski, The Tangled Web The best book on web security's actual model and its historical accidents
Ryan Barnett / OWASP materials; Google's Web Fundamentals security docs Practical
Ilya Grigorik, High Performance Browser Networking Free online. The networking reference (§3 → browser-engine-architecture-and-networking)
Lin Clark's cartoon deep-dives (Mozilla) Stylo, WebRender, and Wasm explained better than anywhere else
"Inside look at modern web browser" (Mariko Kosaka, Chrome) A clear four-part architecture series

18.3 People and channels

Chris Harrelson (Blink rendering), Charlie Reis and Adrienne Porter Felt (Chrome security and Site Isolation), Andreas Kling (Ladybird — his development streams are unusually good teaching material), Lin Clark (Mozilla), Ilya Grigorik (networking), Alex Russell (platform, opinionated and worth reading precisely for that), Jen Simmons and Rachel Andrew (CSS layout), Anne van Kesteren (WHATWG specs), Michal Zalewski (web security). Follow the blink-dev and mozilla.dev.platform intent-to-ship threads if you want to see the platform being decided in public.

§19. Quick Reference

19.1 Numbers

  • Frame budget: 16.6 ms @ 60 Hz, 8.3 ms @ 120 Hz — for everything.
  • Engine share: Blink ~81%, WebKit ~14%, Gecko ~3%.
  • Interop 2025 overall score: 25 → 95; Firefox 46 → 99.
  • Baseline Widely available = Newly available + 30 months.
  • Memory-safety bugs ≈ 70% of serious browser vulnerabilities historically.
  • MiracleObject target: neutralize up to 90% of GPU-main-thread UAFs.
  • ~17–20% of global traffic blocks third-party cookies by default regardless of Chrome.

19.2 "Why is this page slow?" — triage order

  1. Network: TTFB, blocking subresources, no preload, no compression, uncached.
  2. Main thread: long tasks, parse/compile cost, forced synchronous layout (§7.3 → browser-rendering-pipeline).
  3. Style: huge selector count, invalidation storms from class toggles on ancestors.
  4. Layout: layout thrashing, deep flex/grid nesting, table layout.
  5. Paint/raster: large paint areas, no layer promotion, or too many layers.
  6. Compositing: main-thread scroll (non-passive listeners), non-composited animations.
  7. GPU/memory: texture memory exhaustion, checkerboarding.

19.3 Browser security review checklist

  • [ ] Does this feature let a renderer assert something the browser process trusts?
  • [ ] Is every IPC field validated in the privileged process?
  • [ ] Does it read cross-origin data into a renderer that shouldn't have it? (CORB/ORB)
  • [ ] Does it add a timing signal usable for Spectre?
  • [ ] Does it add fingerprinting entropy, and has that been quantified?
  • [ ] Is it restricted to secure contexts? Permissions-Policy delegable?
  • [ ] Is storage partitioned by top-level site?
  • [ ] What is the permission UX, and can it be spoofed by page content?
  • [ ] Does it parse untrusted binary input, and in what language, in which process?
  • [ ] Is there an origin trial, a use counter, and a removal path?

§20. Sources and Method

Method. Narrative (not systematic) review. Durable material — §2 → browser-engine-architecture-and-networking (process model and IPC discipline), §4.1 → browser-rendering-pipeline (HTML parsing), §5 → browser-rendering-pipeline (cascade and matching), §6 → browser-rendering-pipeline (pipeline architecture), §7.3 → browser-rendering-pipeline (event loop), §8.1 → browser-security-and-privacy–8.4 (security model), §12 → browser-extensions-platform-and-standards (accessibility), §15 (anti-patterns) — is synthesized from the specifications and from engine documentation listed in §18. Every time-sensitive claim (engine shares, project status, policy changes, security-program specifics) was verified against a primary or near-primary source in August 2026 and is flagged in §17 with a decay-risk rating. Where vendors genuinely disagree, §16 presents both cases — and names the commercial interest where it is material to the disagreement, because in this domain it usually is.

Search log (August 2026): browser engine landscape and Ladybird/Servo status · Privacy Sandbox and third-party cookie policy · Interop 2026 and Baseline · Chrome site isolation, sandboxing, and memory safety · Manifest V3 and the extension platform · RenderingNG, BlinkNG, and LayoutNG architecture.

Primary and near-primary sources consulted (selected): - chromium.org — Site Isolation design doc and overview; process_model_and_site_isolation.md; the memory safety page; Chrome Security quarterly updates - developer.chrome.com — the RenderingNG series (overview, architecture, key data structures, BlinkNG, LayoutNG), Chris Harrelson et al. - blog.google / Google Security — "Stronger with every update: How we're making Chrome and the web safer in the AI Era" (2026); SecurityWeek coverage of the 13-year-old flaw found by Google's agent harness - privacysandbox.google.com — "Next steps for Privacy Sandbox and tracking protections in Chrome"; contemporaneous reporting on the Oct 2025 API retirements - web.dev — Interop 2026 announcement, Baseline monthly digests; webkit.org — "Announcing Interop 2026"; hacks.mozilla.org — "Launching Interop 2026"; web-platform-tests/interop 2026 README - ladybird.org and the Ladybird W3C/TPAC session description; servo.org and Servo's W3C presentation materials - ublockorigin.com and the uBlock wiki on MV2 deprecation; Mozilla Blog on its MV3 approach; Neowin, The Register, PCWorld on the MV2 flag removals - WHATWG and W3C specifications as cited throughout

Confidence statement. High confidence in §2–§8 → browser-engine-architecture-and-networking, browser-security-and-privacy and §11–§15 → browser-extensions-platform-and-standards, §18–§19 — these rest on specifications and first-party engine documentation, much of it unusually candid. High confidence in §17's verified items as of the stated date. Moderate confidence in the engine market-share figures in §1.1 → browser-engine-architecture-and-networking and §19.1: browser share is measured by analytics vendors with known sampling biases, varies by region and device class, and the ~81/14/3 split should be read as approximate and directional. Moderate confidence in §9.1 → browser-security-and-privacy's timeline granularity — the third-party-cookie story reversed twice and secondary sources disagree about which date was "the" reversal, so the dates here follow Google's own posts and are given as a sequence rather than a single event. The Ladybird timeline in §1.1 → browser-engine-architecture-and-networking and §17 is a project target, not a shipped fact, and such targets have slipped before across this entire field.

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