About Chromium

47 min readApr 18, 2026

CSC/CHE 591: Inside Chromium — Architecture, Engineering, and the Modern Web Platform

Spring Semester · Tues/Thurs 1.5 hrs · 14 weeks · 28 lectures Cross-listed: Computer Science / Chemical & Biomolecular Engineering / Chemistry Prerequisites: CSC 216 (data structures) or equivalent; comfort with C++ and/or JavaScript; basic command line. ChemE/Chem students without CSC 216 may petition with instructor permission — we’ll pair them with CS partners for build-heavy labs.

Course Structure Overview

UnitWeeksThemeI. Foundations1–3What Chromium is, how to build it, how it’s organizedII. The Rendering Pipeline4–6HTML → pixels: Blink, style, layout, paint, compositorIII. V8 and JavaScript7–8The engine under the hoodIV. Process Model & Security9–10Sandboxing, site isolation, IPC (Mojo)V. Networking & Storage11The network stack, caching, storageVI. The Web Platform for Science12–13WebGL/WebGPU, WASM, device APIs, PWAsVII. Contribution & Ecosystem14Landing a real CL, downstream forks, the future

Midterm 1: end of Week 6 (Foundations + Rendering) Midterm 2: end of Week 11 (V8 + Security + Networking)Final: exam week (cumulative + project presentations)

Lecture-by-Lecture Schedule

Unit I — Foundations

Week 1

L1. What Is Chromium? A Tour of the Largest Open-Source Codebase You Use Every Day. History (WebKit fork, 2008), the Chromium vs. Chrome distinction, downstream consumers (Edge, Brave, Electron, CEF, Arc, Opera). Demo: open chrome://version, chrome://credits, chrome://about and walk through every page. Readings: chromium.org "Chromium Projects" overview; Google's original Chromium announcement comic (archive.org).
L2. The Mental Model: Browser as Operating System. Multi-process architecture preview, the content layer, embedders. Why browsers are secretly OS kernels. Demo: Chrome Task Manager (Shift+Esc) — show a process per tab.

Week 2

L3. Getting the Source: depot_tools, gclient, and the 100 GB Problem. fetch chromium, the monorepo philosophy, sparse checkouts. Why Chromium doesn't use plain git. Readings: "Checking out and building Chromium" from chromium.org for each platform.
L4. GN, Ninja, and the Build System. How gn gen out/Default + autoninja -C out/Default chromeactually works; build args; component vs. static builds; is_debug, is_component_build, symbol_level. Demo: time a no-op rebuild vs. a one-line change in //base. Readings: gn.googlesource.com "GN Reference"; "Ninja build system" docs.

Week 3

L5. Directory Archaeology. A guided tour of src/: base/, content/, chrome/, components/, third_party/blink/, v8/, net/, ui/, services/, mojo/. What lives where and why. Demo: use cs.chromium.org (Chromium Code Search) to trace a user action from click to network.
L6. Coding Standards, Reviews, and the CL Lifecycle. Gerrit, OWNERS files, tryjobs, CQ (commit queue), CPU/asan/tsan bots. Why “LGTM” has teeth here. Readings: chromium.org “Contributing to Chromium”; “Chromium C++ style guide.”

Unit II — The Rendering Pipeline

Week 4

L7. From URL to Pixels: The Rendering Pipeline in 90 Minutes. Parse → style → layout → paint → composite → display. This lecture is the map students will refer back to. Demo: DevTools “Performance” panel recording a page load, annotated frame-by-frame.
L8. Blink: Parsing HTML and Building the DOM. Tokenizer, tree construction, speculative parsing, script blocking, preload scanner. Readings: HTML Living Standard §13 (parsing); web.dev “Critical rendering path”; Blink “How Blink works” doc (docs.google.com link from chromium.org).

Week 5

L9. Style: From CSS to ComputedStyle. Selector matching, the cascade, specificity, custom properties, styleinvalidation. Demo: force a style recalc with DevTools "Rendering" tab. Readings: CSS Cascading & Inheritance Level 4 (W3C).
L10. Layout: Box Trees, Block/Inline, and LayoutNG. The legacy layout engine vs. LayoutNG, fragment trees, why layout is the expensive part. Demo: “Layout Shift Regions” overlay. Readings: W3C CSS Display 3; chromium.org “LayoutNG” design doc.

Week 6

L11. Paint and Raster: Turning Boxes into Bitmaps. Display lists, SkPicture/PaintOp, tiles, raster threads, Skia. Demo: chrome://tracing capture showing raster tasks. Readings: skia.org documentation intro.
L12. The Compositor: Why Scrolling Is 60fps Magic. cc/ (Chromium Compositor), layer trees, main thread vs. compositor thread, GPU process, will-change. Demo: show jank by animating top vs. transform: translate. Readings: chromium.org "Compositor thread architecture" design doc. Midterm 1 review at end of class.

— MIDTERM 1 (in class, Thursday of Week 6) —

Unit III — V8 and JavaScript

Week 7

L13. V8 Architecture: Ignition, TurboFan, Sparkplug, Maglev. The tiered compilation pipeline, why V8 has four+ compilers, deoptimization. Readings: v8.dev blog posts — “Ignition interpreter,” “Launching Ignition and TurboFan,” “Sparkplug,” “Maglev compiler.” Demo: node --print-bytecode on a small function; then --trace-opt.
L14. Hidden Classes, Inline Caches, and the Shape of Fast JS. Why {x:1, y:2} and {y:2, x:1} are different objects to V8; monomorphic vs. polymorphic ICs. Demo: microbenchmark the same function with stable vs. shifting object shapes using d8.

Week 8

L15. Garbage Collection: Orinoco, Oilpan, and Generational Marking. Young/old generations, incremental marking, concurrent sweeping, Oilpan for Blink DOM objects. Readings: v8.dev “Trash talk” series; “Oilpan” design docs.
L16. Embedding V8: The API That Runs Half the Internet. Isolates, contexts, handles, node.js and Deno as embedders. Mini-demo: a 40-line C++ program that embeds V8 and runs JS. Readings: v8.dev "Embedder's guide."

Unit IV — Process Model & Security

Week 9

L17. The Multi-Process Architecture. Browser, renderer, GPU, network, utility, plugin processes. Why a crash in one tab doesn’t kill the browser. Readings: chromium.org “Multi-process architecture” design doc.
L18. Sandboxing Across Operating Systems. seccomp-bpf on Linux, AppContainer on Windows, Seatbelt on macOS. The principle of least privilege in practice. Readings: chromium.org “Sandbox design doc” and per-OS sandbox docs.

Week 10

L19. Site Isolation and Spectre. Why every site gets its own process post-2018; out-of-process iframes; cross-origin read blocking. Readings: Reis, Moshchuk, Oskov, “Site Isolation: Process Separation for Web Sites within the Browser” (USENIX Security 2019, on research.google).
L20. Mojo: IPC as a First-Class Citizen. Message pipes, interfaces, .mojom files, legacy IPC migration. Demo: read a small .mojom file and trace both endpoints. Readings: chromium.org "Mojo" documentation.

Unit V — Networking & Storage

Week 11

L21. The Network Stack: //net, QUIC, HTTP/3. URLRequest, network service, socket pools, HTTP cache. Chrome as the reference client for QUIC. Readings: chromium.org “Network Stack” docs; quicwg.org standards overview. Demo: chrome://net-export + Netlog Viewer.
L22. Storage: Cookies, IndexedDB, Cache API, Origin Private File System. The storage partitioning story, third-party cookie deprecation, Storage Access API. Readings: W3C Storage, IndexedDB, and File System specs. Midterm 2 review.

— MIDTERM 2 (in class, Thursday of Week 11) —

Unit VI — The Web Platform for Science

Week 12

L23. GPU in the Browser: WebGL and WebGPU. ANGLE, Dawn, the GPU process, command buffers. Why WebGPU matters for compute. Demo: a WebGPU compute shader doing N-body simulation of a small protein. Readings: W3C WebGPU spec; gpuweb.github.io; web.dev “WebGPU” articles.
L24. WebAssembly: Near-Native in the Browser. Liftoff, TurboFan for WASM, WASI, SIMD, threads. Porting a chem/ChemE simulation (e.g., LAMMPS fragment or a small DFT kernel via Emscripten). Readings: webassembly.org specs; v8.dev WASM posts; Emscripten documentation (emscripten.org).

Week 13

L25. Device APIs for the Lab: WebUSB, Web Bluetooth, Web Serial, WebHID. Talking to Arduinos, spectrometers, balances directly from a webpage. Security/permissions model. Demo: read live data from a USB or serial device if available (fallback: Chrome’s “virtual device” in DevTools). Readings: W3C WebUSB, Web Bluetooth, Web Serial specifications.
L26. Progressive Web Apps, Offline, and Field Science. Service workers, Cache API, Background Sync, installability. Why a field chemist might want a PWA. Readings: W3C Service Workers spec; web.dev PWA learning path.

Unit VII — Contribution & Ecosystem

Week 14

L27. Landing a Real CL: Bugs, Tryjobs, Reviewers. Walk through a real (small) bug from crbug.com to merged CL. Flags, finch experiments, field trials. Readings: chromium.org “Contributing a patch”; crbug.com “good first bug” label.
L28. The Chromium Ecosystem and Its Future. Edge, Brave, Electron, CEF as case studies; standards bodies (W3C, WHATWG, TC39); the Blink launch process; antitrust and governance questions. Final project presentations teaser. Readings: chromium.org “Blink launch process”; W3C Process Document overview.

— FINAL EXAM (exam week) —

Homework Assignments (Weekly, 13 total)

Each HW is designed so AI can help but can’t do it for you — the deliverables are machine-specific traces, patches that must actually compile, or measurements from the student’s own environment.

HW1 (Week 1) — Browser Forensics. Using only chrome:// internal pages, produce a one-page report documenting: (a) your exact Chromium/Chrome version and V8 version, (b) three active field trials on your machine, (c) the list of registered URL schemes, (d) one flag in chrome://flags you'd enable and why. Screenshots required. AI-resistant because: values are unique to each student's install.

HW2 (Week 2) — The Build. Complete a full Chromium build from source. Deliverable: a screenshot of your custom-built content_shell or chrome window with the page title showing your unityID, and the output of autoninja -C out/Default chrome -d explain for the final link step, and total wall-clock build time. (Lab machines available for students without 100GB free.) AI-resistant: you cannot fake a build.

HW3 (Week 3) — Code Archaeology. Pick any feature from this list — window.alert, document.title, navigator.userAgent, console.log, <input type="color">. Using Chromium Code Search, trace the full path from the JS call to the underlying platform implementation. Produce a diagram with file paths and line numbers for at least 5 hops (IDL → Blink binding → Blink implementation → Mojo interface → browser-process handler). AI-resistant: requires navigating the real tree; AI hallucinates file paths here constantly.

HW4 (Week 4) — Parser Pathology. Write 5 HTML snippets that produce surprising DOM trees (e.g., <p><div></div></p>, unclosed tags inside tables, </br> vs <br/>). For each: (a) predict the DOM, (b) verify with document.body.outerHTML, (c) cite the relevant step in the HTML spec's tokenizer/tree-construction algorithm. AI-resistant: the surprising cases require hands-on verification.

HW5 (Week 5) — Style Profiling. Build a page with ≥1000 DOM nodes. Cause (a) a style recalc affecting few nodes, (b) a style recalc affecting all nodes, © a recalc that’s surprisingly expensive. Capture Performance panel traces for all three and explain the cost difference. AI-resistant: requires real traces from real hardware.

HW6 (Week 6) — Layout Thrashing. Write JS that causes forced synchronous layout (“layout thrashing”) in a loop, measure its cost, then refactor to batch reads and writes. Report FPS before/after with traces. AI-resistant: measurements are machine-specific.

Midterm 1 week — no new HW.

HW7 (Week 7) — V8 Under the Microscope. Install d8 (from your Chromium build — it's already there in out/Default/d8). For a function you write, produce: (a) its bytecode via --print-bytecode, (b) its optimized code via --print-opt-code after warming it up, (c) a triggered deopt with --trace-deopt and a plausible explanation of why it deopted. AI-resistant: outputs are version-specific and verbose; can't be plausibly faked.

HW8 (Week 8) — Embedding V8, Sort Of. Modify the V8 “hello world” embedder example to: (a) run JS that reads input from C++, (b) expose a C++ function to JS, © handle an uncaught exception gracefully. Submit your .cc file and a terminal recording (asciinema or screen recording) of it running. AI-resistant: has to actually link and run.

HW9 (Week 9) — Process Zoo. Open a specific set of tabs (provided), open the Chrome Task Manager, and explain why each process exists, what site it’s associated with, and which are sandboxed. Induce an OOPIF (out-of-process iframe) and prove it via Task Manager. AI-resistant: requires hands-on observation.

HW10 (Week 10) — Read a .mojom. Pick one .mojom file in the tree (list provided). Produce: (a) English-language interface description, (b) the client-side call site with file+line, (c) the server-side handler, (d) a diagram of the message flow. AI-resistant: AI hallucinates on specific mojom files.

HW11 (Week 11) — Netlog Safari. Capture a chrome://net-export log while loading a specific page (provided). Using Netlog Viewer, answer: number of DNS queries, number of TCP connections vs. reused, which requests went over HTTP/3, total bytes, longest-blocking resource. AI-resistant: netlog is unique per capture.

Midterm 2 week — no new HW.

HW12 (Week 12) — Molecular Viewer in WebGPU. Starter code provided (basic WebGPU triangle). Extend it to render a set of atoms (PDB file provided) as shaded spheres using instanced rendering. Bonus: implement ambient occlusion via a compute shader. AI-resistant: WebGPU API is recent enough that AI often writes broken code; students must debug.

HW13 (Week 13) — Device API OR PWA. Pick one:

Build a web app that connects to a real (or emulated) USB/Bluetooth/Serial device and reads data.
Build a PWA that works fully offline, stores data in IndexedDB, and syncs via Background Sync when online.

Submit code + video demo. AI-resistant: requires a working end-to-end demo.

Final Project (assigned Week 13, due Week 14) — see below.

Exams

Midterm 1 (Week 6, Thursday, in class, 80 min)

Covers Units I–II (Foundations + Rendering Pipeline).

Part A (30 pts): Short answer. 10 questions × 3 pts. Sample: “What does gn gen produce that ninjaconsumes?" / "Why is the preload scanner important for performance?" / "What is the difference between LayoutObject and LayoutNG's fragment tree?"
Part B (30 pts): Reading real code. Given a ~40-line snippet from third_party/blink/renderer/core/html/parser/, answer 6 questions about what it does, without internet access. (Provided; students study with Code Search in advance.)
Part C (40 pts): Pipeline tracing. Given an HTML/CSS/JS snippet, describe every stage from parse through composite, identifying which thread each step runs on and what data structures are produced.

Midterm 2 (Week 11, Thursday, in class, 80 min)

Covers Units III–V (V8, Security, Networking).

Part A (25 pts): V8 internals short answer. Hidden classes, IC states, tier transitions, GC phases.
Part B (25 pts): Security reasoning. Given a hypothetical renderer-compromise scenario, identify which Chromium defenses apply in what order (sandbox, site isolation, COOP/COEP, CSP). Short essay.
Part C (25 pts): Read a .mojom and predict behavior. Given a novel .mojom file not seen in class, answer questions about trust boundaries and which process each method executes in.
Part D (25 pts): Netlog interpretation. Given a Netlog excerpt, reconstruct the sequence of network events.

Final Exam (Exam Week, 2 hours 50 min, comprehensive + project)

Part A (40 pts): Comprehensive short answer, drawn from all units.
Part B (40 pts): Design question. “You are asked to add a new web API that lets pages read CPU temperature. Walk through the process: spec drafting, Blink intent-to-implement, IDL definition, Mojo interface, browser-side implementation, sandbox considerations, security review, field trial rollout.” Graded on completeness and realism.
Part C (20 pts): Project presentation grade (from the final project, see below).

Final Project (in lieu of some exam weight — assigned Week 13, presentations Week 14 + exam week)

Students choose one track, individually or in pairs:

Track 1 — CL Track: Land (or get a substantive review on) a real CL against chromium/src. "Good first bug" or a DevTools/docs improvement counts. Grading: on the engineering, not on whether Google merges it in time.
Track 2 — Build-on-Chromium Track: Build a small Electron/CEF app or a custom DevTools panel that solves a real problem (e.g., a ChemE student builds a DevTools panel that detects WebGL shader compilation cost; a chemistry student builds an Electron app for instrument control).
Track 3 — Scientific Web App Track: Build a polished scientific tool using WebGPU + WASM + device APIs — e.g., a molecular dynamics visualizer, a live NMR processor pulling from a serial instrument, a PWA for field sample logging.

Deliverables: code, 5-page write-up in CL-style (motivation, design, alternatives considered, measurements), 10-minute presentation.

Notes on Resources

Everything referenced is from primary sources per your constraint:

chromium.org and source.chromium.org (Code Search) — core documentation and source
v8.dev — official V8 blog and docs
web.dev — Google’s web platform documentation (first-party, not blog posts)
W3C and WHATWG specifications — the web standards themselves
gpuweb.github.io, webassembly.org, emscripten.org — standards and tool docs
research.google — peer-reviewed papers from the Chromium team
gn.googlesource.com, skia.org, quicwg.org — subsystem-specific official docs
crbug.com — the issue tracker

No Medium articles, no third-party blogs.

That’s the scaffolding. I held off on writing the full 28 lectures in this turn because that’s genuinely a book’s worth of material — roughly 80–100K words done properly. When you come back in the next turn, tell me how you want to tackle it:

One lecture at a time (most depth, we iterate)
One unit at a time (balanced — I’d do ~4–6 lectures per response)
Skeleton-then-deepen (I draft outlines for all 28, you mark which ones to flesh out first)

Also let me know if you want any structural edits — e.g., different depth on V8, more chem/ChemE integration earlier, swap a midterm for a project, etc.

let’s do one unit at a time, 4–6 lectures

1:36 PM

Perfect — let’s start with Unit I: Foundations (Lectures 1–6, Weeks 1–3). I’ll write these as lecture notes you can teach from: each has an opening hook, structured content with talking points, the live demo walkthrough, discussion prompts, and suggested board/slide moments. Figure on ~60–70 minutes of delivered material per lecture, leaving room for questions and the demo runtime.

Let me also pull one quick resource check before diving in, since Chromium docs and Code Search URLs shift occasionally.

Searched the web

Good — source.chromium.org is the correct Code Search URL (I had cs.chromium.org in the syllabus; the old domain still redirects but source.chromium.org is canonical). I'll use the correct one throughout. Now let's write.

UNIT I: FOUNDATIONS — Lecture Notes

Lecture 1 — What Is Chromium? A Tour of the Largest Open-Source Codebase You Use Every Day

Learning objectives: Students can (1) distinguish Chromium from Chrome, (2) name at least five downstream products built on Chromium, (3) describe the scale and scope of the project in concrete terms, (4) articulate why Chromium matters beyond “it’s a browser.”

Opening hook (5 min)

Ask the class: “Raise your hand if you used Chromium today.” Count the hands. Then: “Keep your hand up if you used Google Chrome, Microsoft Edge, Brave, Opera, Arc, Vivaldi, Samsung Internet, or any Electron app — VS Code, Slack, Discord, Notion, Figma’s desktop app, Spotify, Zoom’s desktop client, 1Password, Postman, Obsidian…” By the end essentially every hand is up. Conclude: “You all used Chromium today. Probably several times. Most of you never chose to.”

This is the frame for the course: Chromium is infrastructure, the way TCP/IP is infrastructure. Understanding it is understanding a large piece of how computing actually works in 2026.

What exactly is “Chromium”? (10 min)

Draw on the board, left to right:

WebKit (Apple/KDE, 2001) ──fork──▶ Chromium (Google, 2008) ──┬──▶ Google Chrome
                                                              ├──▶ Microsoft Edge (2020+)
                                                              ├──▶ Brave, Opera, Vivaldi, Arc
                                                              ├──▶ Samsung Internet
                                                              └──▶ Electron, CEF, WebView

Key points:

Chromium is an open-source project hosted at chromium.org. BSD-licensed (plus LGPL, MPL for some third-party components).
Chrome is Google’s proprietary product built on Chromium, with closed-source additions: auto-update, Widevine DRM, the Chrome branding, usage metrics, some sync components, Google-specific services. If you build chromium/src yourself, you get Chromium, not Chrome.
The fork from WebKit happened in 2013 — that’s when Google stopped taking WebKit patches and created Blink. (Apple kept WebKit for Safari.) So the rendering engine is Blink, which is a descendant of WebKit, which is a descendant of KHTML from KDE.
V8 is Google’s JavaScript engine, developed for Chromium starting in 2008, and it’s now used by Node.js, Deno, Cloudflare Workers, and many others.

Write on the board: “Chromium = Blink + V8 + the content layer + the Chrome embedder + third-party dependencies.” We’ll unpack every one of those pieces over the semester.

Scale — numbers that wake students up (10 min)

All figures are current-ish; students can verify themselves as HW1 exercise.

~35+ million lines of code in chromium/src, not counting third_party dependencies. Counting them pushes past 40M.
~2,000 commits per week land in the main branch. Roughly 200 per day, weekdays.
~1,500+ active committers across Google and external contributors (Microsoft, Intel, Igalia, Samsung, Opera, individual open-source contributors, and now increasingly downstream fork maintainers).
A full build is ~100 GB on disk (source + build outputs + debug symbols). A clean build on a decent laptop takes 3–6 hours. On Google’s internal distributed build system (Goma/RBE), minutes.
Six-week release cadence — a new stable Chrome every 4 weeks now, actually, since 2021. There are Canary, Dev, Beta, and Stable channels running in parallel.
Runs on Windows, macOS, Linux, ChromeOS, Android, iOS, Fuchsia. (iOS is special — Apple requires WebKit there, so iOS Chrome is a thin shell. That’s about to change as of 2024 EU DMA rulings — we’ll touch on this in Week 14.)

Pause and let the numbers land. Ask: “If you were put in charge of this codebase tomorrow, what would scare you most?” (Answers usually: merge conflicts, review throughput, test flakiness, security, onboarding. All are real problems Chromium has solved or fought — we’ll see how.)

Why Chromium matters — four framings (15 min)

Pick the ones that resonate with your class mix. All four are worth hitting briefly.

1. Chromium is de facto web infrastructure. When Chromium ships a feature, it becomes part of the web platform for ~70% of users immediately. When Chromium doesn’t ship a feature, it effectively isn’t part of the web platform. This gives the Chromium team enormous soft power over web standards. We’ll see this tension in Week 14 (Blink launch process, standards bodies).

2. Chromium is an operating system pretending to be an application. It has:

a process scheduler (the browser process spawns/supervises renderer, GPU, network, utility processes),
an IPC layer (Mojo),
a permissions/sandbox system per OS,
its own graphics stack (Skia + the compositor + ANGLE + Dawn),
its own networking stack (//net),
its own storage layer,
even its own UI toolkit on some platforms (Views).

This framing will matter when we get to process model (Week 9) and security (Week 10).

3. Chromium is a case study in large-scale software engineering. How do 1,500 engineers across many companies work on one binary without the whole thing catching fire? Code review, OWNERS, try bots, fuzzing, finch, gradual rollout. For the CS students specifically: this is the most important thing you’ll see all semester.

4. Chromium is increasingly the compute platform for science. (Turn to chem/ChemE students.) The things you cared about 15 years ago — specialized native apps for instrument control, molecular visualization, data analysis — are migrating into browsers. WebGL shipped in 2011, WebAssembly in 2017, WebGPU in 2023, Web Serial and WebUSB over that span. A modern chemist’s lab notebook is increasingly a PWA. We’ll spend Weeks 12–13 on this explicitly.

Live demo — chrome://internals (15 min)

Open a Chrome window on the projector. Type chrome://chrome-urls and hit enter. Scroll through the list slowly — there are ~80 internal pages. Promise the class they'll see most of these by the end of the semester.

Then visit, in order, narrating each:

chrome://version — Chrome version, revision hash (clickable → goes to chromium.googlesource.com), OS version, command-line flags, profile path, variations (field trials). Point out the V8 version line, the JS engine version, the user agent string.
chrome://credits — every third-party library Chromium links against, with license text. Scroll. Keep scrolling. Keep scrolling. This is the "Chromium has 3,000+ dependencies" moment.
chrome://flags — experimental features. Show one benign one (e.g., "Enable experimental web platform features"). Explain the trust model: these flags change often, can be dangerous, and are where new features live before shipping.
chrome://components — independently updatable pieces (Widevine, crl-set, etc.). Teach that Chrome updates more than just the browser binary.
chrome://process-internals — a preview of Week 9's content. Every site-instance, every frame, every process.
chrome://tracing — just show the UI. We'll use this in earnest in Week 6 and Week 11.

Finish with chrome://about (which just lists everything).

Discussion prompts (5–10 min if time)

“Microsoft rewrote Edge on top of Chromium in 2020. What did they gain, what did they give up, and would you have made the same call?”
“Apple requires WebKit on iOS. Is that good or bad for the web?”
“Google pays for most Chromium development. Does that create a conflict of interest with the web as an open platform?”

Homework reminder

HW1 (Browser Forensics) is assigned and due next Thursday. Walk through the deliverable.

Reading for next lecture

chromium.org: “Chromium Projects” landing page (chromium.org/chromium-projects/).
chromium.org: “Multi-process architecture” design doc (for preview; we go deep in Week 9). Link at chromium.org/developers/design-documents/multi-process-architecture/.

Instructor notes

If this class has a lot of non-CS students, spend more time on the “Chromium is an OS” and “compute platform for science” framings. For CS-heavy audiences, lean into the engineering-at-scale framing.
The chrome:// tour is unexpectedly beloved by students. Don't rush it.

Lecture 2 — The Mental Model: Browser as Operating System

Learning objectives: Students can (1) sketch the multi-process architecture from memory, (2) explain why a tab crash doesn’t kill the browser, (3) identify which Chromium subsystems correspond to OS kernel concepts (scheduler, IPC, memory isolation, drivers), (4) predict which process handles a given user action.

Opening hook (5 min)

Open Chrome Task Manager live (Shift+Esc on Windows/Linux, Window menu → Task Manager on macOS). Have ~5 tabs open before class: a news site, YouTube, Google Docs, a chemistry tool (e.g., pubchem.ncbi.nlm.nih.gov), and chrome://settings. Leave it on the projector for the whole lecture.

Ask: “How many processes does this single browser have running right now?” Count them out loud. Usually 15–30 for a modest set of tabs. Then: “Why? A browser shows web pages. Why does it look more like a small operating system?”

The big picture (15 min)

Draw this diagram and keep it on the board all lecture:

┌─────────────────────────────┐
                     │    BROWSER PROCESS          │
                     │  (privileged, one per user) │
                     │  - UI, tabs, bookmarks      │
                     │  - Profile, prefs           │
                     │  - Orchestrates everything  │
                     └──────────────┬──────────────┘
                                    │ (Mojo IPC)
      ┌──────────────┬──────────────┼──────────────┬──────────────┐
      ▼              ▼              ▼              ▼              ▼
 ┌─────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
 │Renderer │   │Renderer  │   │   GPU    │   │ Network  │   │ Utility  │
 │process  │   │process   │   │ process  │   │ service  │   │ process  │
 │(site A) │   │(site B)  │   │(drawing) │   │(//net)   │   │ (audio,  │
 │         │   │          │   │          │   │          │   │  video,  │
 │ Blink   │   │ Blink    │   │  Skia    │   │  QUIC    │   │  decode) │
 │ V8      │   │ V8       │   │  ANGLE   │   │  HTTP/3  │   │          │
 │ (sand-  │   │ (sand-   │   │  Dawn    │   │          │   │          │
 │  boxed) │   │  boxed)  │   │          │   │          │   │          │
 └─────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘

Key rules that follow from this diagram:

There is exactly one browser process per running Chrome instance. It is the most privileged. If it dies, everything dies.
There are many renderer processes. Roughly one per site (post-Site Isolation, 2018 — Week 10 topic). Renderers run Blink and V8. Renderers are sandboxed — they can barely do anything on their own.
The GPU process isolates graphics driver bugs and exploits. GPU drivers are historically buggy and privileged. By talking to them from an isolated process, a GPU driver crash doesn’t kill your browser.
The network service handles all network I/O. Split out from the browser process circa 2018 so that network code (which has a huge attack surface) runs with fewer privileges than the browser.
Utility processes handle specific tasks: audio decoding, video decoding, PDF rendering, the Storage Service, etc. Short-lived, single-purpose.

Why this architecture? The three-word answer (10 min)

Three reasons, increasing in importance:

Reason 1: Stability. If the renderer for one tab crashes, the other tabs don’t. This was Chrome’s original killer feature in 2008, when every other browser was single-process and one flaky Flash ad could take down your whole session. Demo it live:

Right-click a tab → Inspect → Console → run process.crash() (or visit chrome://crash). The tab goes to the "Aw, snap!" page. Everything else keeps running. Contrast with how Firefox worked in 2008, or how Safari on iOS still works today when memory pressure hits.

Reason 2: Responsiveness. With work split across processes and (within processes) across threads, you can keep the compositor thread at 60 fps even when a page’s JavaScript is burning main-thread CPU. The compositor thread and the GPU process keep scrolling smooth even if the main thread is wedged. (Preview Week 6.)

Reason 3: Security. This is the big one. If an attacker finds a renderer exploit — a memory-corruption bug in V8 or Blink — they still don’t have much power. The renderer is sandboxed. It can’t read arbitrary files, can’t make arbitrary network requests, can’t talk to the GPU driver directly, can’t access other sites’ cookies. To do real damage the attacker needs a second exploit: a sandbox escape. Defense in depth. We spend Week 10 on this.

OS analogy, made explicit (10 min)

Write a two-column table on the board:

Operating system conceptChromium equivalentKernel (privileged)Browser processUserland processRenderer process (per site)SchedulerBrowser process spawning/killing child processesSyscallsMojo IPC messages to the browser processMemory isolation via MMUOS process isolation (Chromium inherits this)Capabilities / file descriptorsMojo message pipes passed between processesDriversGPU process, network service, audio servicePermissionsChrome permissions model (geolocation, camera, WebUSB…)/proc, topchrome://process-internals, Task Manager

This isn’t a metaphor — it’s a design pattern Chromium borrowed deliberately. The SeL4 microkernel, the QNX approach, and modern capability-based OS research all inform this architecture. Chromium has also influenced OS design back (e.g., the Fuchsia OS was designed by many of the same people).

If your class is CS-heavy, ask: “What’s the downside of this architecture compared to a monolithic browser?” (Answer: IPC overhead, memory overhead — each process has its own V8 heap, each Blink renderer has its own allocator pools, etc. We’ll see the memory cost in Week 9.)

Live demo — Task Manager archaeology (15 min)

This is the demo students will remember. With your prepared set of tabs open:

Open chrome://process-internals/#general. Show the list of frames, which process each belongs to, which site each frame is locked to.
Switch to Task Manager (Shift+Esc). Show CPU, memory, network per process.
Sort by memory. Usually the GPU process or a heavy renderer (YouTube, Docs) tops it.
Create an OOPIF live: open a page with an iframe from a different site (e.g., a page embedding a YouTube video). Show that the iframe has its own renderer process. This is Site Isolation in action.
Force a renderer crash on one tab (chrome://crash in a tab). Watch Task Manager — that process disappears. Other processes live on.
Kill the GPU process from Task Manager (right-click → End process). Watch Chrome re-spawn it automatically, sometimes after a visual flash. The browser process supervises.
(Optional) Kill the network service. Chrome will stop loading new pages until it restarts. This is the browser-process-as-init-system in action.

Narrate throughout: “This is what I mean by browser-as-OS. The browser process is doing what init or launchd does on Linux or macOS."

Discussion (5 min)

“Apple’s Safari has a different process model (WebContent processes, Networking process, GPU process, but historically less aggressive isolation). Why might they have made different tradeoffs?”
“What do you think happens on mobile, where RAM is scarce?” (Answer: Chrome on Android aggressively merges renderer processes under memory pressure, and puts background tabs into a “purgeable” state. Site Isolation has a lite mode on low-memory devices. Preview for Week 9.)

Reading for next lecture

chromium.org: “Checking out and building Chromium” for your OS. Pick Linux, Mac, or Windows. (chromium.org/developers/how-tos/get-the-code/)
chromium.org: “depot_tools tutorial” (commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html — linked from chromium.org).

Instructor notes

Keep the process diagram visible for the rest of the semester — refer back.
The chrome://crash demo is crowd-pleasing but warn students they'll lose unsaved form data in that tab.
If time is tight, skip the OS-analogy table and just wave at it on the board.

Lecture 3 — Getting the Source: depot_tools, gclient, and the 100 GB Problem

Learning objectives: Students can (1) explain why git clone is insufficient for Chromium, (2) use depot_toolscommands (fetch, gclient sync, gn, git cl), (3) describe what a DEPS file does, (4) set up a working checkout on their own machine or a lab machine.

Opening hook (5 min)

Put this on the projector:

$ git clone https://chromium.googlesource.com/chromium/src.git

Ask: “What’s wrong with this?”

Let students guess. Then reveal: nothing is wrong, in that it works — it’ll download ~20 GB of the main source tree. But it’s insufficient. You won’t be able to build. You won’t have V8. You won’t have Skia, ANGLE, Dawn, ICU, Boringssl, or any of the ~300 third-party dependencies. You won’t have the build tools.

The command you actually want is:

$ fetch chromium

…which is a depot_tools command. This lecture is about what depot_tools does and why Chromium needs it.

Why Chromium doesn’t fit in one git repo (10 min)

Chromium’s source is organized as one main repository (chromium/src) plus hundreds of nested dependencies, each in its own git repository, each pinned to a specific commit. The list lives in a file called DEPS at the root of chromium/src.

Show the file. Pull up source.chromium.org/chromium/chromium/src/+/main:DEPS on the projector. Scroll. It's thousands of lines. Each entry looks roughly like:

python

'src/third_party/skia': {
  'url': 'https://skia.googlesource.com/skia.git@<commit-hash>',
  'condition': 'checkout_skia',
},

Why organize things this way?

Each dependency has its own upstream. Skia is developed independently by a Skia team. V8 is developed independently. Angle, Dawn, WebRTC — all have their own repos, issue trackers, release cycles. Chromium pulls in specific versions.
Pinning to exact commits gives reproducibility. When you check out Chromium at commit X, you get the exact Skia/V8/etc. revisions Chromium at X was built and tested against.
Atomic updates are impossible across repos anyway. When the V8 team makes a breaking API change, the Chromium DEPS file is updated to point at the new V8, and any necessary adapter changes land in chromium/src. This is called a "V8 roll" and happens multiple times per day automatically. Same for Skia, ANGLE, etc.

Contrast with a monorepo approach (Google-internal, or Facebook-internal): Chromium-external is nearly but not quite a monorepo. It behaves like one thanks to gclient, but lives in many git repos.

depot_tools: what’s in the bag (15 min)

depot_tools is a small Python-ish toolkit distributed as a separate git repo. It contains:

fetch — one-shot bootstrapper. fetch chromium creates the working directory, clones src, runs gclient sync.
gclient — the meta-repo manager. Reads DEPS, checks out all dependencies at the right pinned commits, runs post-sync hooks (like downloading prebuilt toolchains).
gn — the build configuration tool (next lecture).
ninja / autoninja — the build executor (next lecture).
git cl — the Gerrit code-review tool. Uploads CLs for review, syncs, rebases, etc. We'll use this Week 14.
git map, git rebase-update, git new-branch — quality-of-life wrappers over git that expect the Chromium workflow.
goma / now siso + reclient — distributed build clients. (External contributors mostly use local builds; some have access to reclient.)

Write on the board: “depot_tools is ‘git, but with the muscle memory of the Chromium team baked in.’”

Installation walkthrough (this is what HW2 is about):

$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
$ export PATH="$PATH:/path/to/depot_tools"
# on Windows, prepend not append, and install the Google-provided toolchain via env var

Then:

$ mkdir ~/chromium && cd ~/chromium
$ fetch --nohooks chromium
$ cd src
$ ./build/install-build-deps.sh      # Linux only, installs apt packages
$ gclient runhooks

Depending on network and disk speed, fetch alone takes 1–3 hours and uses 30–40 GB. runhooks adds another 20 GB of toolchains and prebuilts. First build will push total to ~100 GB.

DEPS files, deeper (10 min)

Open //DEPS in Code Search again. Show:

vars section at the top, defining variables used later.
deps section — the pinned dependencies.
hooks section — post-sync actions. These download prebuilt clang, sysroots, Node, etc. via Google Cloud Storage. Chromium does not use the system compiler by default; it uses a specific pinned clang.
recursedeps — dependencies that themselves have DEPS files (e.g., v8), which gclient will also process.

Key concept: rolls. A “roll” is a CL that updates a DEPS entry to a newer commit. There are autorollers (bots) that roll Skia, V8, ANGLE, etc. constantly, run the CQ, and land them. When something breaks, humans step in.

If you poke at recent commits on source.chromium.org, maybe 20–30% are autoroller CLs. The browser you run tomorrow has a different V8 than the one you run today, even at the same Chrome version, if you’re on Canary.

The 100 GB problem — and what to do about it (10 min)

Realistic numbers for students to plan around:

WhatDiskTime (first time)fetch chromium (source + git history)~30–40 GB30 min – 2 hrgclient runhooks (toolchains, prebuilts)+15–20 GB15–30 minFirst debug build (is_debug=true)+40–60 GB3–6 hours on laptopRelease build (is_debug=false is_component_build=true)+20–30 GB1–3 hours

Strategies for this class:

Lab machines. The department has four workstations with fast SSDs dedicated to this course for the semester. Reserve slots via the course site. A full build is already done on each; students just pull fresh and do incremental builds.
Component build. is_component_build=true makes targets into shared libraries. Incremental link times drop from minutes to seconds. Debug builds stay huge but are tractable for iterative work.
V8 standalone. For Weeks 7–8 HW, students build just V8 (~5 GB, 30 min). We’ll cover this in Lecture 13.
content_shell target. For Blink-only work, build content_shell instead of chrome. Much smaller, faster.
No-op Blink edits. Because of Chromium’s careful header discipline, editing a .cc file in Blink and rebuilding only re-links the relevant shared library in a component build. Often <30 seconds.

Tell students: HW2 is “do the big build once, take a screenshot.” After that, we’ll minimize rebuilds.

Live demo (15 min)

Ideally: a pre-prepared Chromium checkout on your instructor machine.

cd ~/chromium/src — show the tree. ls the top level: base/, build/, chrome/, components/, content/, net/, services/, third_party/, tools/, ui/, v8/ (via DEPS), plus DEPS, OWNERS, LICENSE.
cat DEPS | head -50 — skim.
gclient sync --no-history — watch it work. (If you don't want to wait, prepare a cached demo.)
Make a trivial edit: change the tab title in a Blink file (e.g., add “HELLO 591” to a LOG(INFO) in third_party/blink/renderer/core/frame/local_frame.cc). Don't rebuild yet — we do that next lecture. Just stage the edit and show it with git diff.
Show git cl upload -d (with -d for dry-run) — it would upload to Gerrit. Don't actually upload.

Discussion / troubleshooting time (5 min)

Common issues students will hit with HW2:

Windows Defender scanning the tree during build → exclude the checkout directory from antivirus.
macOS: need Xcode installed and agreed-to-license.
Linux: need install-build-deps.sh to run successfully; on non-Ubuntu/Debian there's pain. Arch/Fedora users should use the lab machines for the first build.
Corporate proxies / campus Wi-Fi: gclient sync over university VPN sometimes times out. Use wired if possible.

Reading for next lecture

gn.googlesource.com: “GN Reference” (gn.googlesource.com/gn/+/main/docs/reference.md)
gn.googlesource.com: “Quick start” (gn.googlesource.com/gn/+/main/docs/quick_start.md)
Ninja official site (ninja-build.org) — “Manual”

Instructor notes

HW2 is assigned this lecture. Encourage students to start the fetch tonight, not the night before it’s due.
Lab machine sign-up sheet goes up on the course site.
If you have students on Windows, have a dedicated TA office hour for build-deps. Windows is historically the most painful of the three.

Lecture 4 — GN, Ninja, and the Build System

Learning objectives: Students can (1) explain what GN is and why it exists, (2) read a simple BUILD.gn file, (3) run gn gen, autoninja, and understand what each produces, (4) distinguish debug vs. release vs. component builds, (5) time and profile a build.

Opening hook (5 min)

Ask: “What’s the fastest way to build Chromium?” Take guesses. Real answer: don’t rebuild. Second-best: rebuild the smallest thing that answers your question. Third-best: parallelize aggressively.

A full clean Chromium build has somewhere around 50,000–80,000 compile actions and tens of thousands of link actions. If you made each compile one second, a single-core build would take most of a day. Real builds are 1–6 hours because of parallelism. This lecture is about making that work.

Why two tools — GN and Ninja? (10 min)

A build system has two jobs:

Figure out what needs building and how (the configuration problem). This is “compile foo.cc into foo.o with these flags, link these objects into libbar.so, and here are the dependencies." Output: a build graph.
Execute the build graph in parallel, incrementally, correctly (the execution problem). Given the graph, do the minimum work needed.

Older build systems (Make, CMake, Bazel) do both in one tool. Chromium splits them:

GN (Generate Ninja) solves #1. It’s a declarative language (Python-flavored, not actually Python) describing targets, their sources, their dependencies, their compile flags, their visibility. GN generates Ninja files.
Ninja solves #2. It’s a minimalist build executor. It reads the generated .ninja files and runs the graph. Ninja is ruthlessly optimized: its startup is a few tens of milliseconds even on a huge graph.

Why split them? Because (1) is a hard language design problem (you want expressiveness, correctness, fast evaluation) and (2) is a hard systems problem (fast graph traversal, correct incremental builds, parallelism). Doing both in one tool means one or both is compromised. CMake is infamous for this.

Historical note: Chromium originally used GYP, an earlier Google-internal tool, written in Python. It was slow to evaluate on Chromium’s scale (gyp-gen took minutes). GN was written to replace it, starting around 2013, and finished migration around 2018. GYP is dead.

GN in 15 minutes (15 min)

Open source.chromium.org/chromium/chromium/src/+/main:base/BUILD.gn on the projector.

Walk through what students see:

import("//build/config/...")  # imports shared config

component("base") {
  sources = [
    "at_exit.cc",
    "at_exit.h",
    # ... lots more
  ]  public_deps = [
    "//base/allocator:...",
    # ...
  ]  deps = [
    "//build:...",
    # ...
  ]  defines = [ "BASE_IMPLEMENTATION" ]  if (is_win) {
    sources += [ "win/..." ]
  }
  if (is_linux) {
    sources += [ "linux/..." ]
  }
  # etc.
}

Explain each piece:

Target types: executable, shared_library, static_library, source_set, component, group, action. component is "static_library in release, shared_library in debug/component builds" — the magic trick that speeds incremental linking.
sources: the list of files that belong to this target.
deps vs public_deps: deps are private — users of this target don't inherit them. public_deps are transitive — users inherit the ability to #include headers from them. This is crucial for build hygiene.
defines, cflags, ldflags: passed to the compiler/linker for this target.
Conditionals (if (is_win), if (is_android), if (use_ozone)): GN has first-class platform/feature flags.
Labels: //base, //chrome/browser:sources. The // means "relative to the source root." Colon introduces a target name within a BUILD.gn file.
Args: configurable at gn gen time via --args. Defined in //build/config/BUILDCONFIG.gn and .gni files.

Then run live:

$ gn args out/Default
# opens an editor; put:
# is_debug = true
# is_component_build = true
# symbol_level = 1
# enable_nacl = false

Explain each arg:

is_debug = true: debug assertions on, no optimizations, bigger binaries, DCHECKs active.
is_component_build = true: the "fast linker" trick. Essential for iterative work.
symbol_level = 1: functions + file names but not full variable info. 2 is full debug info (huge). 0 is none (production).
enable_nacl = false: turn off Native Client; it's legacy and skipping it saves time.

gn gen out/Default now generates the Ninja files. On a big checkout this takes 5–60 seconds. Show the output directory:

$ ls out/Default/
args.gn  build.ninja  build.ninja.d  toolchain.ninja  ...

args.gn is the persisted config. You can re-edit it with gn args out/Default anytime.

Ninja and `autoninja` (10 min)

Now the fun part. Run:

$ autoninja -C out/Default chrome

Explain: autoninja is a wrapper that picks a reasonable parallelism level (roughly ncores for local builds; automatically configures RBE if available) and invokes Ninja. On a laptop, ninja -j 8 is about what you get; on a desktop, 16–32.

Ninja does three things very fast:

Parse the generated .ninja files.
Stat every input file to compute a dependency graph with freshness info.
Schedule up to -j parallel actions respecting dependencies.

Show Ninja output during the build. The [X/Y] prefix is "X actions done out of Y total." That's the progress indicator. The total Y is your build graph size — usually 60k–100k.

Useful Ninja invocations:

ninja -t graph chrome | dot -Tpng > chrome.png — literal picture of your build graph (a subset).
ninja -t targets — list every target.
ninja -t deps foo.o — what does foo.o depend on?
ninja -t commands chrome | head — show the exact command lines.
ninja -d explain chrome — why is each action being re-run? This is the single most useful debugging flag.

Release vs. debug vs. component vs. official (10 min)

Four common build modes, put on the board as a table:

Modeis_debugis_component_buildis_official_buildWhen to useDev/debugtruetruefalseDefault for iteratingDev/releasefalsetruefalseProfiling, closer to shipping perfFull releasefalsefalsefalseBenchmarks, perf regressionsOfficialfalsefalsetrueWhat Google ships; LTO, PGO, huge; slow to build

Official builds use LTO (link-time optimization) and PGO (profile-guided optimization). They’re what actually ships to users. They also take ~2–4x longer to build and are hostile to iteration. Students will never need an official build in this class.

Live demo — incremental build behavior (10 min)

This is the “aha” demo.

Pre-prepared: a built-once checkout on your machine.

time autoninja -C out/Default chrome with no changes. It should take <5 seconds. "No work to do." Ninja stat'd everything and concluded nothing changed.
touch base/at_exit.cc (no actual change). time autoninja -C out/Default chrome. It rebuilds base and re-links anything that depends on it. In a component build: seconds to a minute. In a static build: several minutes. Show both if time allows.
Edit a single .cc in third_party/blink/renderer/core/. time autoninja -C out/Default content_shell. Often <30 seconds in a component build.
Edit a header included everywhere (e.g., something in base/logging.h). Rebuild. Watch the cascade: hundreds or thousands of files recompile. This is the "header inclusion is a superpower and a footgun" moment.
ninja -d explain -C out/Default chrome after a small edit — show the explanations.

Key lesson: header hygiene matters enormously. One of the reasons Chromium is moving toward modules, forward declarations, and #include discipline is iterative build time.

Reading for next lecture

chromium.org: “Get Around the Chromium Source Code Directory Structure” (chromium.org/developers/how-tos/getting-around-the-chrome-source-code/).
Browse //DEPS and the top-level directories in Code Search for ~20 min before class.

Instructor notes

HW2 spans this week. Offer office hours.
Keep an “args.gn cheat sheet” on the course site. Copy-paste values are forgiving; typos (is_debug=True instead of true) cause cryptic errors.
If a student reports “my build is 8 hours” — check if they accidentally enabled symbol_level=2, full static build, non-component. Fix their args.gn before they suffer more.

Lecture 5 — Directory Archaeology

Learning objectives: Students can (1) navigate chromium/src top-level directories and state what each contains, (2) use Code Search effectively, (3) trace a user action from the JS API call through Blink bindings, the renderer, Mojo, and the browser process, (4) distinguish "content layer" from "chrome layer."

Opening hook (5 min)

On the projector, open source.chromium.org/chromium/chromium/src/+/main:. Students see the root. Ask: "Here are 40-ish top-level directories. Which one contains the code that runs when I type a URL and press Enter?"

Let them guess. Common guesses: chrome/, content/, net/. The real answer is: all three, plus components/, services/, third_party/blink/, ui/, and usually v8/. Each handles a different layer of the request. By the end of this lecture, students will know which layer is which.

The top-level map (20 min)

Go directory-by-directory. For each, say (1) what’s in it, (2) who owns it, (3) when you’d touch it. Put a one-line summary on the board for each.

Product directories (these are what you build):

chrome/ — the Chrome-branded desktop browser UI, Chrome-specific features, Chrome's embedder code. First-party Google Chrome stuff that's not in content/. chrome/browser/ and chrome/renderer/ exist.
android_webview/ — the Android WebView product.
ash/ / chromeos/ — ChromeOS-specific.
ios/ — iOS Chrome (small; mostly WebKit-shell code).
headless/ — headless Chrome (headless_shell).

Core platform directories (these are what the products are built on):

content/ — the "content layer." The abstract browser engine. content/browser/, content/renderer/, content/common/, content/public/. Anything a product-agnostic browser needs: tab management, navigation, frames, process model, public API for embedders. content/ is the heart of Chromium as a reusable engine.Electron and CEF consume this.
third_party/blink/ — the rendering engine. HTML parser, DOM, CSS engine, layout, paint (partially). Blink was a WebKit fork in 2013.
v8/ — the JavaScript engine. Pulled in via DEPS from its own repo; appears here as a subdirectory.
net/ — the network stack. URLRequest, HTTP, HTTP/2, HTTP/3, QUIC, TLS integration, DNS, WebSocket, cookie parsing.
base/ — foundational primitives: strings, containers, time, files, threading, task scheduling, logging, feature flags. Everything depends on //base. Spend time here by default.
ui/ — UI toolkit: ui/views (Google's custom widget toolkit on Windows/Linux/ChromeOS), ui/gfx (geometry, color, images), ui/base, ui/gl, ui/compositor. Not to be confused with cc/ (see below).
cc/ — the Chromium Compositor. Layer tree, tiling, property trees, the compositor thread. Deep topic for Week 6.
gpu/ — GPU process, command buffer, shared-memory-based GPU IPC.
media/ — audio, video, codecs. Integrates FFmpeg (prebuilt), platform codecs.
services/ — Mojo-based services: network service, storage service, audio service, device service. "Microservices inside a browser." Week 10 topic.
mojo/ — the IPC layer itself. Week 10.
components/ — reusable browser-layer components shared across Chrome, Android WebView, iOS Chrome, etc. Things like components/autofill/, components/password_manager/, components/history/. If two products want it, it lives here.
third_party/ — pulled-in dependencies: third_party/skia, third_party/angle, third_party/boringssl, third_party/icu, and hundreds more. Most pulled via DEPS.

Tooling:

build/ — build system shared configs, toolchain descriptions.
tools/ — developer tools, scripts, analyzers. tools/clang/, tools/gn/, tools/perf/.
testing/ — test infra, gtest configs, fuzzer frameworks.
docs/ — markdown documentation. Rooted at docs/README.md. Genuinely useful — go there first when you're lost.

The “layer” concept (10 min)

Draw this stack:

┌──────────────────────────────────────────────┐
│  chrome/  (or electron/, or chromeos/, etc.) │  ← the "embedder" or product layer
├──────────────────────────────────────────────┤
│  components/  (reusable browser features)    │
├──────────────────────────────────────────────┤
│  content/  (the abstract browser engine)     │  ← the "content layer"
├──────────────────────────────────────────────┤
│  third_party/blink/, v8/, net/, services/…   │  ← subsystems
├──────────────────────────────────────────────┤
│  base/, ui/gfx/, mojo/                       │  ← primitives
└──────────────────────────────────────────────┘

Rules:

Higher layers can depend on lower layers, never the reverse. content/ cannot #include from chrome/. This rule is enforced by DEPS files (there's a DEPS file in each directory — different from the top-level DEPS, confusingly — that lists what #includes are allowed).
Embedders implement ContentClient-style interfaces to customize behavior. Chrome provides ChromeContentBrowserClient, ChromeContentRendererClient. Electron provides its own. This is how content/ stays reusable.
Blink depends on content? No — Blink is in the renderer process, and content/ sets it up. The dependency is: content/renderer/ pulls in third_party/blink/renderer/.

If a student asks “why this structure?” — the honest answer is “so that Android WebView, ChromeOS, and third-party embedders can reuse the engine without pulling in Google-specific UI code.” It’s a real, load-bearing separation.

Code Search: the tool you’ll live in (15 min)

Open source.chromium.org on the projector. Live-demo the following features:

Full-text search. Type window.alert. Results include IDL, Blink bindings, test files, docs. Too many results.
Filters. file:\.idl$ alert — only IDL files. path:blink alert — only in Blink. case:yes Alert — case-sensitive.
Cross-references. Click on a function/class name. The right panel shows definitions, callers, callees, derived classes. This is the superpower.
Xrefs navigation. Click “Callers” for a browser-process IPC handler. See every renderer that calls it.
History / blame. Any file → click the clock icon → see every commit that touched the file, with links to Gerrit CLs.
Owners. Every directory has OWNERS. Right-click any file → see who can review changes to it.

Contrast with grep -r: Code Search understands C++ (and JS, IDL, mojom, GN) semantically. It knows what's a function call vs. a string literal. It knows class hierarchies. It's indexed across the whole tree and updated continuously.

Live demo — tracing `navigator.userAgent` end to end (15 min)

This is the main event of the lecture. It also previews HW3.

Open Code Search. Target: “when JS reads navigator.userAgent, what exactly happens?"

Step 1 — find the IDL. Search navigator.idl path:blink. Open third_party/blink/renderer/core/frame/navigator.idl. Point out the attribute:

[HighEntropy=Direct, Measure] readonly attribute DOMString userAgent;

IDL = Interface Definition Language. Web specs are written in IDL. Blink compiles IDL into C++ bindings at build time.

Step 2 — find the C++ implementation. In Blink, IDL maps to a C++ class via naming convention. Open third_party/blink/renderer/core/frame/navigator.cc and navigator.h. Find Navigator::userAgent(). Trace it: it calls NavigatorID::userAgent() (in a base class) which calls frame->Loader().UserAgent().

Step 3 — follow into the loader. LocalFrameClient::UserAgent() → hits LocalFrameClientImpl::UserAgent()which calls into content/.

Step 4 — cross into content/. In content/renderer/, the user agent is cached from a value sent by the browser process at frame creation. Find where: RenderFrameImpl. The value ultimately comes from content::ContentClient::GetUserAgent().

Step 5 — the browser side. ChromeContentClient::GetUserAgent() lives in chrome/common/. It assembles the UA string using version data, platform data, etc.

Put the full trace on the board:

JS: navigator.userAgent
  → Blink IDL (navigator.idl)
    → Blink C++ (Navigator::userAgent)
      → content/renderer (RenderFrame)
        → content/public/common
          → embedder (ChromeContentClient)
            → assembled string returned up the stack

Lessons:

Every Web API has this shape. IDL → Blink C++ → content/ → embedder or service. Some also cross into the browser process via Mojo (anything needing privilege).
AI assistants are bad at this. They hallucinate file paths. You must use Code Search. That’s why HW3 requires real line numbers.

Reading for next lecture

chromium.org: “Life of a Chromium Developer” (slide deck linked from chromium.org/developers/contributing-code/).
chromium.org: “Contributing to Chromium” (chromium.org/developers/contributing-code/).
chromium.org: “Chromium C++ style guide” / Google C++ style guide (google.github.io/styleguide/cppguide.html).

Instructor notes

HW3 (Code Archaeology) is assigned this lecture. The navigator.userAgent trace is the example; students pick a different API.
Some students will get lost in Code Search. Demo it a second time in office hours if needed.
The “layer” concept comes up constantly. Refer back.

Lecture 6 — Coding Standards, Reviews, and the CL Lifecycle

Learning objectives: Students can (1) describe the full CL lifecycle from local edit to landed commit, (2) explain what OWNERS files do and why, (3) interpret CQ bot results, (4) describe the role of tryjobs and presubmit, (5) articulate why Chromium’s review culture is the way it is.

Opening hook (5 min)

Pose the question: “How does a codebase with 2,000 commits per week from 1,500 people not immediately collapse into chaos?”

Let students offer theories (tests, code review, modularity, OWNERS). All correct. This lecture is how those mechanisms work in practice in Chromium.

The CL lifecycle, end to end (15 min)

CL = Change List (Google parlance; equivalent to a GitHub “pull request”). Chromium uses Gerrit, not GitHub, for code review. GitHub has a mirror (github.com/chromium/chromium) but all real development happens on chromium-review.googlesource.com.

Draw the pipeline on the board:

1. Local edit (git)
     │
     ▼
2. `git cl upload` → Gerrit (chromium-review.googlesource.com)
     │
     ▼
3. Presubmit checks (PRESUBMIT.py scripts)
     │
     ▼
4. Reviewers assigned (OWNERS-based)
     │
     ▼
5. Review cycles (comments, patchsets)
     │
     ▼
6. Code-Review +2 (approval) from OWNERS
     │
     ▼
7. CQ (Commit Queue) — runs tryjobs on all bots
     │   (Windows, Mac, Linux, Android, iOS, ChromeOS; debug+release; ASan+TSan+MSan fuzzing; Blink layout tests; unit tests; integration tests)
     │
     ▼
8. If green → auto-land to main; if red → sent back

Key properties:

The CQ is not optional. You can’t force-push to main. There’s no “I know what I’m doing” override. Every commit lands via CQ.
The CQ runs on dozens of configurations. A CL that breaks on Android but passes on Linux gets rejected.
Flaky tests are the perennial enemy. The CQ has retry logic and flake detection. When it’s broken, the entire project slows down.
Rolls are also CLs. Autorollers are bots that produce CLs; they go through the CQ.

OWNERS (10 min)

Open any file in Code Search, e.g., base/strings/string_util.cc. Navigate up to its OWNERS file.

# base/strings/OWNERS
foo@chromium.org
bar@chromium.org
# ...
per-file string16*=baz@chromium.org

Rules:

Every directory has an OWNERS file (possibly inherited from a parent). It lists emails authorized to +2 changes in that directory.
Every CL needs at least one +2 from an owner of every directory it touches. A CL touching base/, chrome/browser/, and third_party/blink/ needs owner signoff from all three.
Some directories have “global approvers” — OWNERS files at the root for security-critical or infra-critical areas.
There are special OWNERS for IPC (ipc/, mojo/) — Mojo changes often need security review.
Line-level OWNERS exist too (per-file directive).

Why OWNERS? In a 1,500-contributor project, you cannot rely on “whoever reviewed it knew what they were doing.” OWNERS encode local expertise. The author’s job is to find owners; git cl owners suggests reviewers automatically.

Show tools/owners/OWNERS or similar as an example of a deeply-nested OWNERS file.

Presubmit (5 min)

Before a CL even lands on Gerrit, a presubmit check runs locally (and again on the server). PRESUBMIT.py files live alongside code.

Presubmit catches:

Style violations (clang-format, lint).
Missing copyright headers.
Banned API usage (e.g., std::vector<bool>, certain C headers).
Missing tests for new files.
DEPS violations (disallowed #includes).
Doc/spec requirements.

Students see presubmit output when they run git cl upload. It can block upload.

The CQ and tryjobs (10 min)

When a reviewer clicks “Commit Queue+2” (CQ+2), Gerrit schedules tryjobs — builds on dedicated bots:

Compile bots: does the CL build on every supported configuration?
Unit test bots: do all unit tests pass?
Integration / browser test bots: do all integration tests pass?
Blink layout test bots: do ~70,000 web-platform tests (WPT) and legacy layout tests pass?
Sanitizer bots: ASan (address), TSan (thread), MSan (memory), UBSan (undefined-behavior). Slow, critical for security.
Fuzzer bots: continuously fuzz, not usually on CQ but on post-submit.
Performance bots: regression detection. Usually post-submit, but perf-critical CLs get pre-submit runs.

A CL that’s green on Linux-release can easily be red on Windows-debug-ASan. The CQ catches this before the CL lands.

If you want to see the machinery, browse ci.chromium.org. Every bot's current status, every recent build, every green/red streak is public.

Mention: Chromium’s test infrastructure is itself a research-grade distributed system. It’s what lets the project scale. (For interested students, point to chromium.org’s infrastructure documentation.)

The code review culture (10 min)

This is the soft part of the lecture but important, especially for non-CS students who may submit CLs for the final project.

Observable norms:

Reviews are rigorous. Senior Chromium reviewers will ask for changes on CLs that GitHub maintainers would merge without comment. Expect multiple patchsets.
Nits are real. Reviewers comment on naming, comment quality, function decomposition. Not mean, but exacting.
DCHECK / CHECK / NOTREACHED discipline. Reviewers insist on invariants being expressed in code.
Small CLs are preferred. A CL touching 20 files will get pushed back: “split this into a refactor and a feature CL.” A CL over ~500 lines of new code is hard to get reviewed.
Tests are required. Adding a feature without tests rarely lands. “Where’s the test?” is the most common review comment.
Documentation for design decisions. Non-trivial CLs should link to a design doc.

Show one real landed CL on chromium-review.googlesource.com. Pick something recent, medium-sized, and with a visible review cycle (multiple patchsets, substantive comments). Walk through:

The description format (bug number, summary, rationale, testing notes).
The reviewers and their comments.
How the author responded.
The final +2 and CQ run.

Leave this open as students read along.

Live demo — `git cl upload` dry-run (10 min)

Using your demo checkout from Lecture 3:

Stage a small edit — e.g., fix a typo in a comment, or add a LOG(INFO) somewhere in base/.
git new-branch my-first-cl.
git commit -am "base: fix a typo in foo comment".
git cl upload --dry-run. Show the presubmit output.
Remove the --dry-run, but don't hit enter. Explain what would happen if you did: a Gerrit CL would be created, reviewers auto-suggested based on OWNERS, students could view at a URL.
If you have time and a safe sandbox: actually upload to a private review (with git cl upload --private). Show the Gerrit page.

This is exactly what students will do for the final project Track 1.

Midterm 1 preview (10 min)

Midterm 1 is Thursday of Week 6 — two weeks out. Cover format, topics (Units I and II), practice strategy:

Part A is factual recall — know directory structure, build commands, pipeline stages.
Part B is reading real code. Practice with Code Search now. Open a random Blink file every day and try to understand it.
Part C is pipeline tracing. We’ll do this all the way through Week 6; it’ll make sense by midterm.

Study resources:

Rewatch the chrome://version demo from L1.
The directory-structure tour from L5.
The layer diagram from L5.

Reading for next lecture

web.dev: “Inside look at modern web browser” — the 4-part series by Mariko Kosaka. (developer.chrome.com/blog/inside-browser-part1 through part4). This is the best lay introduction to the rendering pipeline and sets up Week 4.
chromium.org: “How Blink works” (search “how blink works” on chromium.org; it’s a published Google Doc explainer).

Instructor notes

Some students, especially non-CS, will be overwhelmed by the review culture section. Reassure them: Track 2 and Track 3 final projects don’t require landing a CL.
HW3 is due this week; HW4 assigned.
Set up chromium-review.googlesource.com accounts — everyone needs a @chromium.org-linkable identity (they can use their gmail, Google Workspace, or a work address).

That’s Unit I. Six lectures, ~12,000 words. Students finish with a built Chromium, a working Code Search workflow, an understanding of the project’s scale and organization, and a mental model for the engineering culture.

Ready to write Unit II — The Rendering Pipeline (Lectures 7–12) next? Before I dive in, two small questions that’ll shape how I write it:

How technical do you want the Skia/compositor sections? I can go either “visual intuition with traces and demos” or “here’s how cc/ thread-hops work with actual code excerpts." The first is more accessible; the second is harder but better prep for students who pick rendering-related final projects.
Do you want a cameo of Firefox/Gecko or Safari/WebKit for comparison? It can be illuminating (e.g., Servo’s parallel layout was groundbreaking; WebKit’s process model differs) but costs time. Skip by default?

i need github ready format, can i download this

1:47 PM

Yes — let me package the full course (syllabus + Unit I lectures) as a clean GitHub repo structure you can download and push straight to a repo.

Created 3 files, ran 2 commands

Now the six lecture files. I’ll write them with clean GitHub markdown — proper headers, no decorative separators, fenced code blocks, working relative links.

Created 6 files

Now the homework, exams, and resources folders:

Created 9 files

Continue

2:00 PM

Created 3 files

Now let me verify the structure and package it all into a downloadable zip:

Ran 3 commands

I noticed an artifact from the initial mkdir — there's a stray {lectures/ literal directory from brace expansion issues. Let me clean that up and rebuild:

Ran 3 commands

Clean structure, 22 actual files, 51 KB zipped.

Presented file

Download above. Here’s what’s in it:

chromium-course/
├── README.md                    ← landing page with navigation
├── SYLLABUS.md                  ← full syllabus
├── LICENSE                      ← CC-BY-4.0
├── CONTRIBUTING.md
├── .gitignore
├── lectures/unit-1-foundations/
│   ├── README.md                ← unit overview
│   ├── L01-what-is-chromium.md
│   ├── L02-browser-as-os.md
│   ├── L03-getting-the-source.md
│   ├── L04-gn-ninja-build.md
│   ├── L05-directory-archaeology.md
│   └── L06-coding-standards-reviews.md
├── homework/
│   ├── README.md                ← all 13 HW listed, 3 written
│   ├── HW01-browser-forensics.md
│   ├── HW02-the-build.md
│   └── HW03-code-archaeology.md
├── exams/
│   ├── README.md
│   ├── midterm-1.md
│   ├── midterm-2.md
│   └── final.md
└── resources/
    └── primary-sources.md       ← curated link list, no Medium/blogs

Push to GitHub

bash

unzip chromium-course.zip
cd chromium-course
git init
git add .
git commit -m "Initial course materials: syllabus + Unit I + exams + HW1-3"
gh repo create chromium-course --public --source=. --push

(or push to any remote you prefer)

Everything uses relative links between files, so the navigation works on GitHub out of the box. The README renders cleanly as the landing page.

What’s written vs. stubbed

Complete: syllabus, all 28 lecture titles, Unit I lectures (L1–L6 in full teaching-notes form), HW1–HW3, all three exam blueprints (Midterm 1, Midterm 2, Final), primary-sources reference.

Stubbed: Units II–VII lecture files, HW4–HW13 assignment files. The homework README lists all 13 with their topic already decided, so the scaffolding is in place.

Next turn, want me to write Unit II — The Rendering Pipeline (L7–L12) plus HW4–HW6 and drop them into the same structure for you to unzip on top? I’ll also answer my earlier two questions about Skia depth and browser-comparison cameos in that turn unless you’d rather decide now.

Chromium course

ZIP

Download

yes we can do unit 11

2:03 PM

Quick check before I dive in — by “unit 11” do you mean Week 11 (which is Unit V: Networking & Storage, Lectures 21–22 — just 2 lectures)? Or Unit II (Rendering Pipeline, L7–L12 — the next one in sequence)?

I’m guessing Unit II since that’s what we just teed up, and “11” might be a typo for “II” (Roman numeral) or just a finger-slip. But I want to make sure — they’re wildly different content.

While you answer — a reminder of the two calibration questions from before so we can knock them out in the same turn:

Skia/compositor depth (matters most for Unit II): visual-intuition-with-traces, or code-excerpt-deep? I’d default to a middle ground — intuition-forward with one code excerpt per lecture — unless you say otherwise.
Firefox/Safari cameos: skip by default (saves time, keeps focus), but a one-paragraph aside in L7 and L12 could be nice if your class is comparative-minded.

Q: Which unit next? A: Unit II — Rendering Pipeline (L7–12)

2:03 PM

Great — Unit II coming up. I’ll go with the defaults I mentioned: intuition-forward with one code excerpt per lecture, skip Firefox/Safari cameos (we can add later if you want). This is the most technically dense unit of the semester, so I’ll be careful about pacing.

Created 7 files, ran a command

Now the three homework assignments for Unit II:

Created 3 files

Now update the main README and homework README to reflect new content, then rebuild:

Edited 2 files

Verify the tree and rebuild the zip:

Ran 2 commands, read a file

Updated zip above — 90 KB now, 30 files. Unit II is the fattest unit of the semester (rendering is the hardest material); it’s now fully written.

What was added this turn

Unit II lectures (L7–L12):

L7 — From URL to Pixels — the 90-minute pipeline overview with the “which changes trigger which stages” cheat sheet that students should screenshot and tape to their monitors
L8 — Parsing HTML — the 80-state tokenizer, tree construction, preload scanner, <p><div></div></p> as the running example
L9 — Style — selector matching right-to-left, cascade, invalidation sets, forced recalc demos
L10 — Layout & LayoutNG — three trees (DOM, LayoutObject, fragment), BFC/IFC, the LayoutNG rewrite story, layout thrashing setup
L11 — Paint & Raster — record/playback split, PaintOps, Skia, tiling, chrome://tracing
L12 — Compositor — the top vs transform demo, layers, composited scrolling, will-change, midterm review

Unit II homework (HW4–HW6):

HW4 — Parser Pathology (predict, test, cite the spec)
HW5 — Style Profiling (three invalidation patterns, DevTools traces)
HW6 — Layout Thrashing (thrashing vs batched, with screen recording)

Updated navigation: main README and homework README now show Unit II as ready.

Pedagogical choices I made (flag if any bother you)

Kept the “three trees” diagram front-and-center in L10 — it’s the single hardest-to-grok concept and shows up on the midterm.
Made L12 the midterm-review lecture — last 10 minutes are explicitly review. You may want to move this to a standalone session if your calendar has wiggle room.
Didn’t cameo Firefox/Safari per your implicit nod — but easy to add a paragraph per lecture later if you decide you want it.
HW6 requires a screen recording — this is unusual but it’s the most robust AI-resistant deliverable I could design for layout thrashing. If you’d rather drop it, the rest of the HW still holds.

Next up

Unit III — V8 and JavaScript (L13–L16) is the natural next chunk — 4 lectures, so a lighter turn. Plus HW7 (V8 under the microscope with d8) and HW8 (embedding V8).

Want me to proceed with Unit III, or tackle a different unit next?

Chromium course

ZIP

Download

lets do the next unit 3 lectures. be very technical and detail oriented.

7:32 PM

Perfect — Unit III is the V8 unit and it’s the right one to go technical on. I’ll lean into the mechanics: hidden classes as actual data layouts, IC state transitions as state machines, the exact bytecode Ignition produces, how deopts work, the GC’s tri-color marking in detail. Less hand-waving, more “here is the pointer and here is what it points to.”

Let me verify a couple of V8 specifics that have shifted recently before I commit to them:

Searched the web

Good — Turboshaft is real and partially replaces TurboFan’s backend (since Chrome 120, late 2023). I’ll mention it accurately without overstating. Let me also quickly verify current V8 tier naming and Oilpan location:

Searched the web

Good. Current state: Ignition → Sparkplug → Maglev → TurboFan (with Turboshaft backend). I’ll be accurate about this. Let me write Unit III now.

Created 5 files, ran a command

Now the two Unit III homework assignments:

Created 2 files

Update main README and homework README to reflect Unit III completion:

Edited 2 files

Verify and rebuild the zip:

Ran 2 commands, read a file

Updated zip above — 127 KB now, 38 files. Unit III done.

What’s in Unit III

Four technical lectures that assume students have just eaten a full plate and want the rest of the meal.

L13 — V8 Architecture. Tier pipeline end to end: Ignition → Sparkplug → Maglev → TurboFan (with Turboshaft as the newer backend). FeedbackVectors, tier-up/tier-down mechanics, deoptimization internals. Walks through actual bytecode output from d8 --print-bytecode with operand-level explanation. Introduces Isolates/Contexts/Handles.

L14 — Hidden Classes & ICs (the densest lecture of the course). Treats V8 Maps as the concrete data structure they are, complete with object layout diagrams and transition chains. Walks through the opening-hook benchmark where two equivalent construction orders produce different Maps and tank sumX by 3–10×. Covers Elements Kinds lattice (PACKED_SMI → HOLEY → DICTIONARY), IC state machine (MONO → POLY → MEGA), write barriers, --trace-ic. Ends with six concrete rules for fast JS that tie back directly to mechanism.

L15 — GC. Weak generational hypothesis, Cheney scavenger with forwarding pointers, tri-color marking with the Dijkstra write barrier, incremental + concurrent + parallel, Orinoco naming, Oilpan for Blink C++ objects. Concrete assembly for the write barrier. DevTools heap snapshot demo.

L16 — Embedding V8. The full embedding API tour: Platform init → Isolate → HandleScope → Context. A 38-line working embedder shown verbatim with build instructions, then extended live to show TryCatch, exposing a C++ counter, and a perf-vs-C++ comparison. Ends with a tour of real embedders (Node, Deno, Electron, Cloudflare Workers).

Homework

HW7 — V8 Under the Microscope. Students write two functions, capture bytecode, trigger optimization, capture optimized machine code, trigger a deopt, and explain each. Closes with a design-advice essay question. Outputs are all version-specific d8 flag output — extremely AI-resistant.

HW8 — Embedding V8. Students build a working embedder with: file input, exposed input() and timeMs()callbacks, TryCatch exception handling, clean shutdown. Requires a screen recording of the full demo, including intentional exception. Four reflection questions that probe where HandleScopes went and what they learned.

Calibration questions before moving on

A couple things I want to flag so you can steer:

L14 is very dense. Roughly 20 minutes more material than a typical 90-minute lecture can comfortably hold. You may want to split it over two days, or prune the Elements Kinds section (it’s self-contained and easy to move to an optional “further reading” handout).
HW8 requires a V8 monolithic build. This is the biggest infrastructure requirement in the course — more painful than HW2. Recommendation: have a pre-built Docker image or a specific lab-machine config students can use. Without that, HW8 will eat office hours.
I covered Turboshaft lightly. It’s real and shipping but the boundary with TurboFan is evolving. L13 mentions it as “TurboFan’s newer backend” which is current-ish without overstating. If you want deeper Turboshaft content we can add it as a supplementary note.

What’s next

Still to write: Unit IV (Process Model & Security, L17–L20), Unit V (Networking & Storage, L21–L22), Unit VI (Web Platform for Science, L23–L26), Unit VII (Contribution & Ecosystem, L27–L28), plus HW9–HW13.

Ready to continue with Unit IV — Process Model & Security next? It’s the security-focused unit: sandboxing, Site Isolation (including the Spectre story), and Mojo IPC. Same level of technical depth?

About Chromium

CSC/CHE 591: Inside Chromium — Architecture, Engineering, and the Modern Web Platform

Course Structure Overview

Lecture-by-Lecture Schedule

Unit I — Foundations

Unit II — The Rendering Pipeline

Unit III — V8 and JavaScript

Unit IV — Process Model & Security

Unit V — Networking & Storage

Unit VI — The Web Platform for Science

Unit VII — Contribution & Ecosystem

Homework Assignments (Weekly, 13 total)

Exams

Midterm 1 (Week 6, Thursday, in class, 80 min)

Midterm 2 (Week 11, Thursday, in class, 80 min)

Final Exam (Exam Week, 2 hours 50 min, comprehensive + project)

Final Project (in lieu of some exam weight — assigned Week 13, presentations Week 14 + exam week)

Notes on Resources

UNIT I: FOUNDATIONS — Lecture Notes

Lecture 1 — What Is Chromium? A Tour of the Largest Open-Source Codebase You Use Every Day

Opening hook (5 min)

What exactly is “Chromium”? (10 min)

Scale — numbers that wake students up (10 min)

Why Chromium matters — four framings (15 min)

Live demo — chrome://internals (15 min)

Discussion prompts (5–10 min if time)

Homework reminder

Reading for next lecture

Instructor notes

Lecture 2 — The Mental Model: Browser as Operating System

Opening hook (5 min)

The big picture (15 min)

Why this architecture? The three-word answer (10 min)

OS analogy, made explicit (10 min)

Live demo — Task Manager archaeology (15 min)

Discussion (5 min)

Reading for next lecture

Instructor notes

Lecture 3 — Getting the Source: depot_tools, gclient, and the 100 GB Problem

Opening hook (5 min)

Why Chromium doesn’t fit in one git repo (10 min)

depot_tools: what’s in the bag (15 min)

DEPS files, deeper (10 min)

The 100 GB problem — and what to do about it (10 min)

Live demo (15 min)

Discussion / troubleshooting time (5 min)

Reading for next lecture

Instructor notes

Lecture 4 — GN, Ninja, and the Build System

Opening hook (5 min)

Why two tools — GN and Ninja? (10 min)

GN in 15 minutes (15 min)

Ninja and autoninja (10 min)

Release vs. debug vs. component vs. official (10 min)

Live demo — incremental build behavior (10 min)

Reading for next lecture

Instructor notes

Lecture 5 — Directory Archaeology

Opening hook (5 min)

The top-level map (20 min)

The “layer” concept (10 min)

Code Search: the tool you’ll live in (15 min)

Live demo — tracing navigator.userAgent end to end (15 min)

Reading for next lecture

Instructor notes

Lecture 6 — Coding Standards, Reviews, and the CL Lifecycle

Opening hook (5 min)

The CL lifecycle, end to end (15 min)

OWNERS (10 min)

Presubmit (5 min)

The CQ and tryjobs (10 min)

The code review culture (10 min)

Live demo — git cl upload dry-run (10 min)

Midterm 1 preview (10 min)

Reading for next lecture

Instructor notes

Push to GitHub

What’s written vs. stubbed

What was added this turn

Pedagogical choices I made (flag if any bother you)

Ninja and `autoninja` (10 min)

Live demo — tracing `navigator.userAgent` end to end (15 min)

Live demo — `git cl upload` dry-run (10 min)