Google Chrome Deploys AI Agents to Fix 1,000 Security Vulnerabilities
Anton A Chuvakin
As AI-assisted hacking compresses the exploit window from months to hours, Google Chrome is automating its vulnerability pipeline and developing dynamic, restart-free process patching to eliminate security debt.
Chrome resolved over 1,000 security vulnerabilities across milestones 149 and 150—surpassing the total fixes of the prior 23 releases combined—powered by an end-to-end multi-agent AI pipeline that discovers bugs, writes PoCs, and drafts candidate patches. (5:00)
A Gemini agent harness uncovered a 13-year-old sandbox escape rooted in a cross-subsystem logic flaw between file permissions and postMessage validation that traditional human reviews and fuzzing consistently missed. (0:00)
To counter the compression of the exploit gap from months down to hours, Chrome is transitioning toward two security updates per week alongside dynamic in-memory patching to replace running renderer processes without restarting active tabs. (6:45)
Chrome is actively mitigating C++ memory safety risks via MiraclePtr and spannification, while simultaneously rewriting isolated leaf components like the FreeType font parser into Rust with Fontations. (21:00)
Detailed notes
## Background
Published by Anton A Chuvakin on the Cloud Security Podcast RSS feed on August 25, 2026, this episode features Chrome Security leaders Jasika Bawa and Doug Turner. The discussion explores how Chrome is leveraging AI agents, Rust, and C++ hardening to combat a surge in vulnerabilities, while rethinking update cadences and tab preservation through dynamic patching.
## TL;DR
Host Tim Peacock talks with Doug Turner and Jasika Bawa about navigating the AI-driven 'vulnapocalypse,' where autonomous agents uncovered a 13-year-old sandbox escape and helped remediate over a thousand bugs across Chrome 149 and 150. To counter the shrinking patch gap from days to hours, Chrome is transitioning toward bi-weekly security releases and developing dynamic in-memory patching to update child renderer processes without disrupting users' tabs. At the systems level, the team is mitigating memory corruption through MiraclePtr and spannification across its massive C++ footprint while migrating leaf nodes like font rendering to Rust. Additionally, they discuss monitoring Chrome's 2,300 open-source dependencies via Google's internal 'Gossip' engine and the imperative to treat code hygiene as an end-user product to prevent technical debt from becoming security debt.
## Atmosphere & style
The conversation carries a lighthearted, conversational tone grounded in serious systems engineering, balancing inside developer jokes about tab hoarding and 'vibe coding' against genuine architectural rigor. Host Tim Peacock flies solo with playful banter, contrasting his own everyday tab anxiety with the guests' deep operational realities. Turner brings veteran perspective from decades in browser development, while Bawa provides sharp, empathetic product insights into developer burnout and threat acceleration, creating an engaging blend of technical depth, humor, and pragmatic urgency.
## Bulletin
- `05:00` Chrome resolved over 1,000 security vulnerabilities across milestones 149 and 150—surpassing the total fixes of the prior 23 releases combined—powered by an end-to-end multi-agent AI pipeline that discovers bugs, writes PoCs, and drafts candidate patches.
- `00:00` A Gemini agent harness uncovered a 13-year-old sandbox escape rooted in a cross-subsystem logic flaw between file permissions and postMessage validation that traditional human reviews and fuzzing consistently missed.
- `06:45` To counter the compression of the exploit gap from months down to hours, Chrome is transitioning toward two security updates per week alongside dynamic in-memory patching to replace running renderer processes without restarting active tabs.
- `21:00` Chrome is actively mitigating C++ memory safety risks via MiraclePtr and spannification, while simultaneously rewriting isolated leaf components like the FreeType font parser into Rust with Fontations.
## Key takeaways
- `00:00` A Gemini agent harness identified a 13-year-old sandbox escape caused by contradictory assumptions across disconnected subsystems handling file permissions and postMessage validation.
- `00:00` AI models excel at tracing multi-step logic vulnerabilities across disparate codebases where traditional permutation fuzzing and human audits struggle.
- `05:00` Chrome 149 and 150 resolved more than 1,000 security issues by pairing automated discovery, PoC creation, severity triage, and patch drafting agents with strict human two-party review rules.
- `06:45` AI and automated tooling have compressed the vulnerability-to-exploit window from 'Exploit Wednesday' to 'Exploit Tuesday afternoon', driving the pilot of bi-weekly security releases.
- `10:00` Enterprise administrators can moderate update velocity using Chrome Extended Stable—offering an eight-week milestone feature freeze with continuous security patching—and granular policy controls.
- `16:47` Chrome is developing dynamic patching to freeze vulnerable renderer child processes and route new tabs or navigations to patched binaries, eliminating disruptive browser restarts.
- `15:00` Advanced session restore aims beyond preserving open tabs to maintaining unsubmitted form states and precise document reading positions during opportunistic restarts.
- `21:00` To protect Chromium's massive C++ base, the team relies on MiraclePtr to turn use-after-free conditions into safe crashes and spannification to prevent out-of-bounds pointer arithmetic.
- `21:00` Runtime overhead introduced by memory-safety bounds checks is actively countered by a dedicated performance optimization team.
- `23:05` Chrome's Rust migration strategy focuses on isolated leaf nodes—such as replacing the FreeType font engine with Fontations—while building an internal SDK to expose browser core systems to Rust.
- `25:00` To safeguard over 2,300 third-party dependencies, Chrome utilizes an internal engine dubbed 'Gossip' to monitor CVE databases, OSV feeds, domain hygiene, and upstream repository changes.
- `27:00` Left unaddressed, internal technical debt and architectural neglect directly convert into security debt across massive software ecosystems.
- `30:00` Navigating the AI-driven 'vulnapocalypse' requires shifting static analysis into the commit queue to prevent new memory safety defects from merging, rather than playing endless bug whack-a-mole.
## Detailed walkthrough
### `00:00` Finding a 13-Year-Old Sandbox Escape with Gemini
Tim Peacock opens the episode flying solo—quipping that listeners will have to endure the show without the usual co-host banter—and introduces guests Doug Turner (Director of Engineering on Google Chrome) and Jasika Bawa (Group Product Manager for Chrome Security). Jumping straight into Google's recent blog post, Tim asks Doug about a headline finding: how Chrome's Gemini-powered agent harness managed to uncover a 13-year-old sandbox escape that had sat dormant in the codebase since roughly the browser's earliest years.
Doug admits the discovery is deeply humbling, noting: “I mean, it's humbling because, you know, for 13 years, people have walked over that codebase and not seen it.” He draws a parallel to Anthropic's disclosure about Project Mythos finding a decades-old vulnerability in OpenBSD. Inspecting the actual root cause, Doug explains that it was a classic logic flaw residing across disconnected subsystems: one component handled browser file permissions, while an entirely separate component evaluated incoming `postMessage` calls. System A operated on the assumption that System B had already validated the input, but System B never did. Because these parts of the codebase were so disjoint, human reviewers repeatedly missed the breakdown. Standard fuzzing could not easily catch it either, as triggering the vulnerability required a specific, complex sequence of multi-step events rather than simple input corruption.
```mermaid
flowchart LR
accTitle: Cross-subsystem logic bug flow
accDescr: Flow diagram showing how disjoint subsystems led to a 13-year-old sandbox escape missed by humans and fuzzers.
subgraph Subsystems["Disjoint Subsystems"]
A["Browser File Permissions"]
B["postMessage Handler"]
end
subgraph LogicBreakdown["Validation Failure"]
C["System A assumes System B validates"]
D["System B fails to validate"]
end
subgraph Discovery["Gemini Agent Pipeline"]
E["Detects multi-step logic violation"]
F["Builds reproducible PoC"]
G["Generates candidate patch"]
end
A -.-> C
B -.-> D
C & D --> E
E --> F --> G
```
When Tim presses him on the "multi-billion dollar question"—how Gemini was able to deduce the flawed interaction when standard permutation fuzzing running hundreds of thousands of test inputs failed—Doug acknowledges that tracing the exact internal reasoning of modern models is difficult. However, while human developers struggle to see cross-cutting assumptions across massive codebases, these models demonstrate an ability to reason across disjoint contexts far beyond conventional methods. Furthermore, the agent harness did not simply report an alert: it automatically generated a functional proof of concept (PoC) and provided a candidate fix to give developers an immediate head start on remediation.
`05:00` Autonomous Bug Pipelines and the "No Vibe Coding" Rule
Tim moves from the single 13-year-old bug to a staggering aggregate metric: across Chrome versions 149 and 150, the team resolved more than 1,000 security vulnerabilities—surpassing the total number of security fixes shipped in the prior 23 milestone releases combined. Tim asks how that volume of work was even possible without teams burning out or succumbing to an unvetted loop of robots rubber-stamping other robots.
Doug explains that the team built an end-to-end, multi-agent pipeline:
- An advanced model scans the codebase continuously to discover latent vulnerabilities.
- A PoC generation agent creates a working exploit to verify the bug is legitimate.
- A severity assessment agent categorizes the risk (distinguishing an urgent zero-day/critical issue that halts everything from a lower-priority S2 issue that can wait months).
- A patching agent generates a candidate fix.
- A triage agent identifies the relevant human developer and routes the patch to them to land the change.
Tim jokes about whether this setup is just two AI models grading each other on a curve or engaged in "vibe coding" Chrome into production. Doug firmly rejects this: “No, there no vibe coding, no.” He emphasizes that landing a fix generated by this pipeline still requires the strict Chromium review process: Developer A must thoroughly read, comprehend, and approve the generated patch, and a second Chromium committer must independently review and approve the changelist (CL) before it can merge into the tree.
`06:45` Shifting the Patch Cadence: From Exploit Wednesday to Exploit Tuesday Afternoon
Tim turns to Jasika Bawa to discuss the operational fallout of rapid patching. Chrome transitioned to piloting two security releases per week around June, a dramatic shift from the era when shipping browser updates was an infrequent, high-stakes milestone. Tim asks how Chrome balances software stability against security fatigue, and whether this pace risks burning out both Chrome developers and enterprise IT administrators.
Jasika explains that the update frequency is a direct response to a changed threat environment. Traditionally, attackers reverse-engineered binary patches following release days—recalling her time at Microsoft when "Exploit Wednesday" naturally followed "Patch Tuesday." Today, generative AI and automated tooling have slashed the manual effort required to analyze diffs, shifting the window to "Exploit Tuesday afternoon." Furthermore, attackers can now leverage AI to assist in chaining separate vulnerabilities into full exploit chains.
Rather than doubling release frequency by forcing engineers into double shifts, the team uses AI throughout the bug lifecycle:
- Models produce candidate patches so engineers spend time reviewing rather than writing repetitive code from scratch.
- AI automates the drafting of Common Vulnerabilities and Exposures (CVE) descriptions and external release notes, removing manual operational friction.
Addressing Tim's concern for IT admins, Jasika notes that enterprise administrators need flexibility rather than sudden surprises. Google provides centralized management tools:
- Chrome Enterprise Core and Chrome Enterprise Premium offer fleet-wide visibility dashboards across heterogeneous, non-homogeneous operating systems.
- Admins receive granular policy controls to schedule, defer, or target updates according to their specific organizational risk appetite.
- Automated release documentation provides clear, immediate transparency into what changed in each bi-weekly drop.
`10:00` Enterprise Update Policies and the Chrome Extended Stable Channel
Enterprises handle updates with varying degrees of tolerance for disruption. Jasika Bawa highlights that Chrome provides specific enterprise policies to help administrators push updates across fleets, including an escalation policy used internally at Google that gently nudges users to restart when a security patch lands, gradually escalating the urgency until a forced restart occurs. Tim Peacock jokes that this mechanism seems designed to strike at the worst possible time, though he admits that in 290 podcast episodes, Chrome has miraculously never rebooted mid-recording—a streak that has him nervously knocking on wood in the middle of the show.
For high-security or heavily regulated environments that require strict validation of every single release before deployment, Chrome provides the Chrome Extended Stable channel. While the standard release cycle increments major milestones every two weeks, the Extended Stable channel remains feature-frozen on a major milestone for eight weeks. Crucially, it continues to receive security fixes so organizations do not remain exposed to known vulnerabilities. Yet as Jasika explains, managing update cycles through administrative policies and release channels is merely an interim approach rather than the destination:
> “The long term goal for us is a Chrome that is continuously and dynamically patched and restarted automatically for users during opportune moments.”
- **Chrome Extended Stable:** Feature-frozen on a major milestone for eight weeks, while continuing to receive regular security updates.
- **Enterprise Restart Policies:** Escalating reminders that prompt end users over time before ultimately mandating a browser restart.
---
`12:05` Tab Anxiety and Opportunistic Restarts
Tim brings up the universal dread of restarting the browser, confessing that with around 50 open tabs, closing the window feels like tossing his short-term memory directly into a woodchipper. Jasika immediately validates this anxiety, noting that keeping numerous tabs open is completely normal compared to some of her own habits, such as typing quick notes directly into the Omnibox address bar and leaving them open as temporary reminders. She reflects on her frustration with the manual chore of browser maintenance, recalling an existential rant she delivered to her team:
> “I think it's so unfair that the AI gets to write poetry now. And like, I'm stuck just touching YubiKeys and like restarting Chrome all day.”
To eliminate the need for manual restarts, the Chrome team is pursuing a two-pronged strategy: dynamic patching and opportunistic restarts. The goal is to trigger restarts automatically during moments that cause the least possible friction for the user. Examples of these non-disruptive windows include macOS systems where all browser windows have been closed, instances where the operating system is locked while the user is away from their keyboard, or user-scheduled maintenance intervals.
---
`15:00` Advanced Session Restore Beyond Mere Tabs
Restoring a user's session safely is the critical foundation that makes opportunistic restarts tolerable. While Tim remarks that tab loss has become rare in recent years, Jasika emphasizes that preserving open URLs is merely baseline functionality. The engineering team is actively tackling far more complex forms of session state that cause painful data loss when interrupted.
Key challenges include safeguarding partially completed, unsubmitted web forms so users do not have to retype extensive text, as well as tracking reading progress in long-form media, such as remembering the exact page of a 400-page PDF of *The Odyssey*. When perfect state preservation is technically impossible, product decisions must balance security updates against the risk of disruption, though the ultimate ambition is eliminating work loss entirely.
```mermaid
flowchart TD
accTitle: Dynamic Process Patching Flow
accDescr: Diagram illustrating how Chrome transitions from old vulnerable renderer processes to patched binaries without killing active tabs.
subgraph ActiveState["Active Browsing Session"]
ActiveTab["Active Tab\n(e.g., Recording or Long Form)"]
OldRenderer["Old Renderer Process\n(Frozen against reuse)"]
ActiveTab --> OldRenderer
end
subgraph PatchEvent["Security Update Event"]
PatchLand["Security Patch Downloaded"]
ProcessMgr["Chrome Process Manager"]
PatchLand --> ProcessMgr
end
subgraph FutureState["Subsequent User Action"]
NewAction{"User Action"}
NewTab["New Tab Opened"]
Nav["New Navigation in Tab"]
PatchedRenderer["New Patched Binary\nRenderer Process"]
NewAction --> NewTab
NewAction --> Nav
NewTab --> ProcessMgr
Nav --> ProcessMgr
ProcessMgr --> PatchedRenderer
end
OldRenderer -.->|"Flushed on tab close"| Terminate["Process Terminated"]
```
---
`16:47` Dynamic Patching and Process Replacement Without Disruption
Beyond restarting the application, the team is actively developing dynamic patching, an architectural breakthrough designed to update the browser's binaries seamlessly during an active session. Because Chrome relies on a multi-process architecture where tabs run within isolated renderer processes, the browser can update behind the scenes without terminating active tasks.
When a security patch is downloaded, Chrome avoids killing the existing renderer running the user's active tab. Instead, that process is frozen against new assignments, allowing ongoing operations to proceed without interruption. The moment the user opens a new tab or navigates away from the existing page, Chrome's process manager directs the request to a newly launched renderer executing the patched binary. Over the course of a normal browsing session, vulnerable renderer processes naturally drain away and get replaced by secure ones without requiring a full browser reboot.
---
`18:41` Why Now? The Accelerating Patch Gap and Operational Hurdles
When Tim asks why this dynamic patching architecture is only arriving now instead of a decade ago, Doug Turner explains that the technical and operational complexity behind it is staggering. While isolating tabs into individual renderers is straightforward conceptually, orchestrating origin-isolation boundaries alongside hot-swapping running binaries presents severe logistical hurdles. Patches cannot simply be rolled out twice a week; the backend infrastructure must build, test, and safely deploy updated binaries on an almost daily cadence.
The urgency driving this engineering effort is the dramatic collapse of the patch gap. Historically, the delay between a patch being published in an open-source dependency and the emergence of an exploit in the wild was long enough to tolerate standard update intervals. Doug explains that the rapid rise of AI and LLM-assisted vulnerability discovery has completely compressed this timeline:
> “Jessica mentioned the entire landscape of security has changed with the rise of vulnerabilities being found by LLMs. So we need to close this patch gap. And we didn't have to worry about it like two years ago.”
- **Process Architecture Logistics:** Origin-to-renderer binding rules require granular process management when introducing newly compiled binaries into a running session.
- **Release Cadence Compression:** Shifting from weekly or bi-weekly milestone builds to automated, daily backend patch generation and deployment pipelines.
- **Threat Model Shift:** Machine-driven vulnerability discovery allows threat actors to operationalize open-source patch differences into functional exploits far faster than in previous years.
`20:00` Urgency, Dynamic Patching, and Closing the Exploit Gap
The conversation opens on the shrinking window between when a vulnerability is disclosed and when active exploitation begins. Back in 2018, defenders often had months to patch before an exploit landed in the wild; today, that window has compressed down to mere hours. This massive sense of urgency is why the Chrome team is pushing so aggressively toward two security releases a week and dynamic in-memory patching—workflows that simply were not viewed as necessary two years ago. Doug Turner jokes about accepting Jasika Bawa's code changes (CLs) the moment she gets back to her desk and starts cranking on Gemini CLs. While everyone acknowledges the immense technical complexity of replacing running browser child processes on the fly without breaking tabs, Turner emphasizes that it is a hard problem the team is determined to pull off, capturing the sheer pace of modern browser defense:
> “Used to be, like if you go back to 2018, it might be months. Now we're in the hours. And so there's a massive sense of urgency to close this patch gap.”
`21:00` Eliminating Bug Classes: MiraclePtr, Spannification, and C++ Hardening
The hosts pivot to the blog post's discussion of eliminating entire classes of vulnerabilities, a key focus within Google security engineering. Chromium is a behemoth consisting of 35 to 50 million lines of code. Because the vast majority is written in C++ and will remain in C++ for the foreseeable future, the team cannot simply wait for a rewrite; they must structurally eliminate the common bugs developers introduce daily.
```mermaid
flowchart TD
accTitle: Chrome C++ Memory Safety Mitigations
accDescr: Diagram showing how MiraclePtr and Spannification tackle use-after-free and out-of-bounds pointer errors, offset by performance optimizations.
subgraph MemoryBugs["Common C++ Bug Classes"]
UAF["Use-After-Free<br/>(Dangling Pointer Reuse)"]
OOB["Out-of-Bounds Access<br/>(Pointer + Length Arithmetic)"]
end
subgraph Defenses["Automated Safety Hardening"]
MP["MiraclePtr<br/>(Crashes safely on deleted pointer reuse)"]
SPAN["Spannification<br/>(Enforces bounds checks on buffers/spans)"]
end
Turner walks through the two primary mechanisms deployed to protect this C++ base:
1. **MiraclePtr:** In standard C++, deleting a heap allocation and later reusing that dangling pointer leads to use-after-free (UAF) vulnerabilities. MiraclePtr acts as a smart pointer that prevents that reuse; instead of letting an attacker exploit stale memory, it forces an immediate, safe crash.
2. **Spannification:** Historically, large C++ codebases pass around raw pointers alongside an integer length, relying on developer discipline never to read or write past that bounds. "You would hope," Turner notes, but human error inevitably causes out-of-bounds reads and writes. Spannification replaces raw pointer-length pairs with bounds-checked `base::span` structures.
Both mitigations carry runtime overhead because the compiler must inject instructions to validate pointers and check bounds prior to memory access. To ensure users do not pay for safety with billions of sluggish laptops, Chrome pairs these security efforts with a dedicated performance team that actively hunts down offsetting optimizations across the codebase.
`23:05` The Long Game: Rewriting Leaf Nodes and Building a Rust SDK
While C++ hardening protects existing code, Chrome's long-term architectural game is Rust. The migration follows two distinct parallel tracks: replacing untangled "leaf nodes" and enabling core engine development.
The first track targets standalone leaf nodes that possess strict, isolated APIs/ABIs and have no complex interdependencies with the rest of Chromium. Examples include image decoders, metadata parsers, and font libraries. Turner specifically points to FreeType, an ancient font-rendering library originally created back in the OS/2 days, which was ported from Pascal to C (with Turner clarifying that early contributor David Turner is of "no relation"). FreeType has historically been plagued by use-after-free bugs and scary metadata parsing flaws. Chrome is actively replacing it from the ground up with **Fontations**, an entirely Rust-based font implementation.
The second track focuses on the deep interior of the browser. Writing a feature inside Chromium requires interacting with core platform utilities: task dispatchers across threads, metrics logging, and user profile managers. These subsystems historically lacked Rust bindings:
> “The second thing we're doing with Rust is you can kind of think about it like a Chromium SDK. If you were going to write something in the middle of Chrome or in the middle of Chromium, you might need access to things that are like our metrics logging system or how to post the task to a different thread or, you know, what's the user's profile name. Like these are things that C++ developers take for granted. But if you write in Rust, you don't.”
To solve this, Chrome is actively building out this internal "SDK" tooling so engineers can write features in the middle of Chromium in Rust with a first-class developer experience.
`25:00` Securing the 2,300 Open Source Dependencies and the "Gossip" Engine
The discussion turns to supply chain security. An Allan Friedman-style question is posed: how does the team safely manage the staggering 2,300 third-party open-source dependencies shipped inside Chrome?
Turner characterizes this collection as an entire "continental scale biome." Some dependencies are massive, Tier-1 open-source cornerstones maintained by armies of engineers—such as the V8 JavaScript engine (used across Node.js and cloud runtimes), the Skia 2D graphics library, and ANGLE. But those canonical powerhouses sit alongside hundreds of smaller, niche libraries where maintenance is variable.
To police this intake, Chrome relies on an automated vetting pipeline powered by an internal Google system known by the acronym **Gossip** (Turner jokes that nobody ever remembers what it stands for, guessing something like "Global Open Source Software Intelligence Platform"). Gossip acts as a continuous quality and threat signal engine for ingested packages:
- Scans for published Common Vulnerabilities and Exposures (CVEs) and tracks whether they have been patched upstream.
- Ingests feeds from public security data sets, including the Open Source Vulnerability (OSV) database.
- Monitors domain and registry hygiene to detect domain takeovers or suspicious ownership changes—a classic supply-chain attack vector.
- Analyzes updates for structural anomalies before permitting any updated code into the Chromium ingestion pipeline.
`27:00` Closing Advice: Code Is a Product, and Tech Debt Is Security Debt
Wrapping up the interview with traditional closing questions, Turner reflects on his three decades working on giant open-source codebases, dating back to Netscape. He recalls being present when Jim Barksdale made the decision to open-source Mozilla, literally wheeling out a giant wagon wheel containing all of Netscape's source code printed out on reams of paper to present it to the world.
Having spent a decade at Mozilla and nearly another decade on Chrome, Turner offers a guiding philosophy for anyone managing large-scale open-source ecosystems:
> “The key thing and the ethos and the culture have to recognize that the software, the code, is actually a product to itself. So you have to have the same energy and the same care that you do with the end-user product, the feature, the UI, everything that shows up in release notes, as you do with how well the code is written, what C++ languages are you using, what compilers, the architecture, the internal toolings.”
When an open-source project supports thousands of downstream developers and millions of users, neglecting internal tooling, compiler versions, or code architecture carries dangerous consequences. Turner delivers the interview's parting takeaway on software rot: left unaddressed, technical debt directly and rapidly converts into security debt.
`30:00` Treating the Codebase as a Product and Shifting Left in the "Vulnapocalypse"
Reflecting on Doug Turner’s point that code must be treated like a product, host Tim marvels at the fact that Doug has been shipping browser code for almost as long as Tim has been alive. Doug jokes about the bittersweet feeling of time passing so quickly, reminding Tim to savor the journey and make plenty of memories, adding that building browsers has been one of the absolute best highlights of his career. Jasika Bawa agrees strongly with the philosophy of treating the codebase as an actual product, remarking that this mindset resonates deeply with product managers like herself and Tim. She observes that the industry has spent roughly six months inside what she terms the "vulnapocalypse," and Chrome is now entering a more normalized phase where the focus must shift to operationalizing and scaling their efforts.
Jasika highlights the absolute necessity of defending against the introduction of brand-new security bugs while simultaneously fixing existing ones and rolling out new features. To break the endless cycle, the Chrome team is pushing security guardrails directly into the commit queue. By enforcing automated static analysis before code can land in the main tree, they flag common pitfalls such as unsafe buffer usage, dangling pointers, and memory safety violations before they ever reach production. Tim compares software development unfavorably to aviation, pointing out that software engineering often feels sloppy because planes almost never crash while software is perpetually broken. Jasika laughs in agreement, sharing a memory of touring a data center and realizing how disciplined hardware engineers are compared to software developers who routinely rely on a "ship it and fix it later" mentality.
> “You have to treat the code as a product that you ship.” — Doug Turner
- Chrome is shifting security validations earlier into the commit queue (CQ) to catch unsafe buffer usages, dangling pointers, and memory safety issues before merges.
- The team is transitioning from initial emergency response mode into a sustainable, scaled operational model after six months navigating the AI-driven "vulnapocalypse."
---
`32:15` Eliminating Bug Classes and Treating Engineers as Customers
Beyond immediate defenses at commit time, Jasika stresses that the team must fiercely protect its long-term strategic investments in architectural safety, such as the ongoing migrations to Rust and C++ hardening via spannification. While the influx of AI-discovered bugs creates high stress and operational drama, she cautions that reactive triage cannot become the permanent status quo. The fundamental mission remains wiping out whole categories of vulnerabilities at the language and architectural levels so they can never occur again.
From a product management viewpoint, Jasika emphasizes viewing internal engineering teams as primary customers. The rapid rise of automated tools finding vulnerabilities has created acute friction and pain points across development workflows. Her focus is discovering how tooling can alleviate developer cognitive load and eliminate toil across the entire bug life cycle, particularly as machine intelligence fundamentally alters how vulnerabilities are surfaced and remediated.
> “Like, I really cannot emphasize this enough. Like, simply fixing bugs forever is not a sustainable strategy.” — Jasika Bawa
> “In this vulnapocalypse age, what are their pain points? There are several, let me put it that way.” — Jasika Bawa
---
`34:02` Reading Recommendations and Outro
When asked for reading recommendations, Jasika first points listeners to the newly published Chrome security blog post, *"Stronger with every update: How we're making Chrome and the web safer in the AI Era."* She describes it as an inspiring record of an exceptionally dedicated team working in the trenches over the previous six months to safeguard the browser during the vulnapocalypse. For non-security reading, Jasika offers a classic literary recommendation: Alexandre Dumas's *The Count of Monte Cristo*, describing it as an essential study in human character.
Tim expresses his admiration for the Chrome engineering team, noting that he has used Chrome continuously since 2008 and feels privileged to help share their technical story. The episode wraps with standard channel housekeeping: listeners are encouraged to subscribe, leave reviews on Apple Podcasts or Spotify, visit `cloud.withgoogle.com/cloudsecurity/podcast`, follow along on X at `@cloudsecpodcast`, and join ongoing discussions on the Google Cloud Community site.
> “I think everyone should read *The Count of Monte Cristo*. Huh, okay. Unrelated to the vulnapocalypse. But yeah, it's an important study on human characters.” — Jasika Bawa
## Notable quotes
> `32:15` Like, I really cannot emphasize this enough. Like, simply fixing bugs forever is not a sustainable strategy. — Jasika Bawa
> `30:00` You have to treat the code as a product that you ship. — Doug Turner
> `10:00` The long term goal for us is a Chrome that is continuously and dynamically patched and restarted automatically for users during opportune moments. — Jasika Bawa
## Mentioned
Google Chrome, Chromium, Doug Turner, Jasika Bawa, Tim Peacock, Gemini, Project Mythos, Anthropic, OpenBSD, Chrome Enterprise Core, Chrome Enterprise Premium, Chrome Extended Stable, MiraclePtr, Rust, C++, FreeType, Fontations, V8, Skia, ANGLE, Gossip, Open Source Vulnerability (OSV), Allan Friedman, Jim Barksdale, Netscape, Mozilla, The Count of Monte Cristo, The Odyssey, YubiKey, Google, Microsoft
## Video description
<p dir="ltr">Guests:</p> <ul> <li dir="ltr" role="presentation">Jasika Bawa, Group Product Manager, Chrome Security</li> <li dir="ltr" role="presentation">Doug Turner, Engineering Director, Chrome Security</li> </ul> <p dir="ltr">Topics:</p> <ul> <li dir="ltr" role="presentation">Gemini agent harness found a sandbox escape that survived in the codebase for 13 years! How did that happen and how did that bug get noticed among what's surely a tidal wave of bugs being found by the machines?</li> <li dir="ltr" role="presentation">Chrome 149 and 150 fixed over a thousand security bugs—surpassing the last 23 milestones combined. That is a massive spike! T<a href= "https://blog.google/security/chrome-stronger-with-every-update/">he blog</a> explains it's possible by having 'fixing agents' and 'critic agents' working in a loop that mimics human code reviews. I have to ask: how much of this is real, high-quality engineering, and how much of it is just two robots agreeing to grade each other on a curve?</li> <li dir="ltr" role="presentation">Historically, pushing updates was a monumental, scheduled event. Now, you're piloting two security releases a week to combat fast-moving attacks. That sounds like a direct route to developer burnout, and a complete nightmare for enterprise IT admins who just want their systems to stay stable. How are we balancing the need to protect users from N-day exploits versus making everyone play security whack-a-mole?</li> <li dir="ltr" role="presentation">I want to learn more about this long-term vision so let's address the elephant in the browser: nobody wants to restart Chrome. Personally, I have about 50 tabs open right now, and restarting feels like risking throwing my short-term memory into a woodchipper. You're talking about 'dynamic patching' that replaces background child processes on the fly without a restart, and you've rolled out a 'zero window auto-restart' on macOS. First off, are my tabs safe? Second, is dynamic patching actually going to work seamlessly, or is it just going to crash my Renderer mid-session and blame it on the GPU? If this is real, it's really amazing. </li> <li dir="ltr" role="presentation">Tell us about the "spannification" effort and the migration to Rust. There's two parallel technical safety efforts going on to–as we like to say at Google–eliminate classes of vulnerabilities. Tell us about the engineering efforts behind the C++ spans and the Rust journey! </li> <li dir="ltr" role="presentation">Ok I'd be a terrible Allan Friedman disciple if I didn't ask the supply chain question. First, Chrome has over 2,300 third-party dependencies. That's wild. How are we handling that?</li> </ul> <p dir="ltr">Resources:</p> <ul> <li dir="ltr" role="presentation"><a href= "https://youtu.be/pCXT8lQqg_U">Video version</a></li> <li dir="ltr" role="presentation"><a href= "https://blog.google/security/chrome-stronger-with-every-update/">"Stronger with every update: How we're making Chrome and the web safer in the AI Era"</a> blog</li> <li dir="ltr" role="presentation"><a href= "https://cloud.withgoogle.com/cloudsecurity/podcast/next-special-improving-browser-security-in-the-new-era-of-work/"> EP88 Improving Browser Security in the New Era of Work</a></li> </ul>
According to Chrome engineering leaders Doug Turner and Jasika Bawa, the rise of AI-assisted vulnerability research has compressed the window between patch disclosure and exploitation from months to hours, forcing Chrome to adopt automated agentic patching pipelines and zero-disruption dynamic updates. To move beyond perpetual bug fixing, the team is coupling autonomous remediation with structural memory safety initiatives in C++, targeted rewrites in Rust, and pre-commit guardrails.
Agentic Pipelines and Cross-Subsystem Logic Flaws (0:00)
Chrome's Gemini-powered agent harness uncovered a 13-year-old sandbox escape that originated in the browser's earliest years and evaded human review and permutation fuzzers. The bug stemmed from disconnected assumptions across disjoint subsystems: the file permissions system presumed an incoming postMessage handler had validated user input, while the handler never did. Turner explained that while tracing the internal reasoning of large models is difficult, the harness deduced the multi-step interaction, generated a reproducible proof of concept, and drafted a candidate patch.
This workflow reflects a broader operational shift across Chrome milestones 149 and 150, which resolved over 1,000 security vulnerabilities—exceeding the prior 23 releases combined. Google managed this volume by constructing a multi-agent pipeline spanning vulnerability discovery, exploit verification, severity categorization, patch drafting, and triage routing. Turner rejected the notion that Chrome relies on unverified 'vibe coding,' emphasizing that every machine-generated patch must still be independently understood, reviewed, and approved by two human Chromium committers before landing.
Compressing Patch Gaps and Dynamic Process Replacement (6:45)
The threat environment has accelerated from historical 'Patch Tuesday' and 'Exploit Wednesday' cycles to 'Exploit Tuesday afternoon,' as adversaries leverage generative AI to analyze binary diffs and construct exploit chains within hours. In response, Chrome piloted a twice-weekly security release schedule in June. For regulated or risk-sensitive organizations unable to accommodate rapid milestone deployments, Google maintains the Chrome Extended Stable channel, which freezes feature milestones for eight weeks while continuing to deliver backported security fixes.
To counter user 'tab anxiety' and eliminate disruptive restarts, Chrome is developing dynamic patching. Taking advantage of Chrome's multi-process architecture, the browser's process manager avoids terminating active tabs when a patch downloads. Instead, older renderer processes executing unpatched binaries are frozen against new assignments, while subsequent navigations and newly opened tabs launch within patched renderer processes. Over a session, vulnerable processes naturally drain without terminating active workflows or requiring an immediate browser reboot.
Eliminating C++ Bug Classes and Introducing Rust (21:00)
Because Chromium contains between 35 and 50 million lines of code primarily written in C++, Google cannot wait for a wholesale rewrite and must structurally eliminate memory safety flaws. Turner detailed two core C++ mitigations: MiraclePtr, a smart pointer implementation that prevents use-after-free exploitation by forcing an immediate, safe crash upon dangling pointer reuse; and 'spannification,' which systematically replaces raw pointer-and-length arithmetic with bounds-checked base::span structures. To counter compiler-injected runtime overhead, Chrome pairs these security controls with a dedicated performance engineering team.
Chrome's long-term strategy incorporates Rust along two parallel tracks. First, the team is replacing isolated, C-based leaf libraries that historically suffered memory corruption flaws, such as swapping out the ancient FreeType font library for Fontations, an end-to-end Rust implementation. Second, engineering teams are constructing an internal Chromium 'SDK' that exposes platform primitives—such as thread task dispatching, metrics logging, and user profile management—enabling developers to build core browser features in Rust with first-class ergonomics.
Supply Chain Monitoring and Pre-Commit Guardrails (25:00)
Chrome manages approximately 2,300 third-party open-source dependencies, ranging from massive tier-1 foundations like the V8 JavaScript engine and Skia graphics library down to niche utilities. To oversee this intake, Google relies on an internal system called 'Gossip.' The platform continuously scans upstream Common Vulnerabilities and Exposures (CVEs), ingests the Open Source Vulnerability (OSV) database, monitors domain and registry hygiene against hijacking, and screens package updates for structural anomalies before code enters the Chromium tree.
After navigating six months of an AI-driven 'vulnapocalypse,' Bawa noted that Chrome is transitioning from emergency triage into a sustainable operational model. To prevent new flaws from entering production, automated static analysis has been integrated into the commit queue, catching unsafe buffers, dangling pointers, and memory violations before merges occur. Turner concluded that code must be treated with the same rigor as an outward-facing product, warning that unattended technical debt directly converts into security debt.
While autonomous multi-agent pipelines and dynamic binary patching allow defenders to keep pace with hours-long exploit windows, Chrome leadership maintains that continuous reactive patching is unsustainable. Long-term defense depends on structurally eliminating vulnerability classes through C++ compiler mitigations, pre-commit enforcement, and incremental Rust migration.
## Background
本期节目由 Anton A Chuvakin 于 2026 年 8 月 25 日在 RSS 及网络平台上发布。根据页面介绍，节目邀请到 Chrome 安全团队的工程总监 Doug Turner 与安全产品负责人 Jasika Bawa，深入探讨了 Gemini 智能体如何发现潜伏 13 年的沙盒逃逸漏洞、Chrome 在短时间内借助 AI 修复上千个漏洞的幕后机制、动态补丁与无感重启技术、C++ 内存安全改造与 Rust 迁移，以及多达 2,300 个第三方依赖项的开源供应链安全治理。
## TL;DR
面对生成式 AI 大幅压缩 N-day 漏洞利用窗口的严峻现实，Chrome 团队详细拆解了如何利用端到端 AI Agent 流水线自动化挖掘、验证并生成候选补丁，同时坚持严格的双人代码审查以守住工程红线。针对困扰用户的频繁重启与“标签页丢失焦虑”，团队推出了零窗口静默重启与正在研发的渲染进程动态补丁（Dynamic Patching）技术，力求在不打断用户工作流的前提下快速交付安全更新。在底层架构层面，团队通过 MiraclePtr 与 Spannification 技术系统性根除 C++ 内存安全缺陷，推进 Fontations 等解耦模块向 Rust 迁移，并通过自研 Gossip 自动化流水线严防庞大第三方开源依赖的投毒与劫持风险。
## Atmosphere & style
整场访谈节奏轻快且极具极客幽默，主持人 Tim 与两位嘉宾在技术深度探讨与日常痛点吐槽之间切换得行云流水。讨论不仅涉及底层指针安全与复杂架构设计，还穿插着关于“50 个打开标签页被推进粉碎机”以及“AI 去写诗、人类忙着按 YubiKey 重启 Chrome”的存在主义式自嘲，令人捧腹且感同身受。三十年开源老兵的深厚积淀与应对“漏洞末日（vuln-apocalypse）”的前沿产品思维碰撞交融，既有战壕一线的紧迫感与硬核技术交锋，又流淌着对工程卓越与代码工匠精神的敬畏之情。
## Bulletin
- `00:00` 基于 Gemini 的智能体安全测试套件在 Chrome 代码库中发现了潜伏长达 13 年的沙盒逃逸漏洞，并自主完成了 PoC 验证与候选补丁生成。
- `05:00` Chrome 149 与 150 版本通过自动化 Agent 流水线结合人类双重审查，修复了超过 1,000 个安全漏洞，超越此前 23 个里程碑版本的修复总和。
- `06:50` 面对 AI 缩短漏洞利用窗口至数小时的现状，Chrome 转向每周双更，并正研发动态补丁（Dynamic Patching）技术以在不重启浏览器的前提下无缝替换渲染进程。
- `20:00` Chrome 正在推行 MiraclePtr 与 Spannification 以缓解 C++ 内存缺陷，同时采用“叶子节点优先”策略将图像与字体组件逐步迁移至 Rust。
## Key takeaways
- `00:00` Gemini 智能体成功定位了文件权限校验与跨窗口通信（postMessage）之间的跨子系统逻辑断层，解决了人类与传统 Fuzzing 长期未发现的 13 年老漏洞。
- `05:00` Chrome 大规模修复漏洞依托端到端 Agent 流水线，但每个 AI 生成的候选补丁仍须通过两名人类 Chromium 开发者的强制代码审查（Peer Review）才可合入。
- `06:50` 生成式 AI 使得攻击者从补丁逆向提取漏洞并拼接漏洞链的周期大幅压缩，迫使补丁发布周期提速至每周两次以应对 N-day 威胁。
- `06:50` 为减轻高频发布带来的开发者疲劳，Chrome 全面利用 AI 自动化生成发布说明（Release Notes）与 CVE 漏洞描述，使工程师角色转向审查与审批。
- `10:00` 针对企业环境，Chrome 提供扩展稳定版（Extended Stable Channel）以冻结功能 8 周，并结合策略弹窗与企业控制台平衡安全性与业务稳定性。
- `11:46` 解决标签页重启焦虑的短期策略是在零窗口、锁屏等最少干扰时机自动重启，并持续改进未提交表单等边缘状态的无损恢复能力。
- `15:00` 动态补丁（Dynamic Patching）通过冻结旧渲染进程并在新导航或新标签页中无缝调度新二进制文件，实现了用户无感的渐进式热补丁替换。
- `20:00` Chromium 绝大部分代码仍将长期保留为 C++，团队通过 MiraclePtr 防御释放后重用（UAF）、通过 Spannification（base::span）根除缓冲区越界。
- `20:00` 编译器在插入 MiraclePtr 与边界安全检查时会引入运行时性能开销，Chrome 专项性能团队通过在其他代码路径中深度优化完全抵消了这部分成本。
- `22:45` Rust 迁移优先从解耦的叶子节点切入，已启动纯 Rust 字体库 Fontations 研发以替代历史 UAF 重灾区 FreeType，并同步开发 SDK 支撑中间层业务互操作。
- `25:00` 面对超 2,300 个第三方依赖项，Chrome 依托内部代号 Gossip 的全自动准入流水线，实时核对开源漏洞库并监测域名变更等供应链投毒行为。
- `27:40` 工程团队必须树立“代码本身就是一款独立产品”的理念，技术债会在极短时间内演化为安全债，底层架构与工具链需要与前端功能同等的打磨心血。
- `30:00` 在机器自动化挖掘漏洞的“漏洞末日”常态下，团队核心战略是利用 Commit Queue 前置拦截新缺陷、通过 Rust/Spannification 彻底消灭整类漏洞，并将内部工程师视作客户进行工具赋能。
## Detailed walkthrough
### `00:00` Gemini Agent Harness 挖掘出潜伏 13 年的沙盒逃逸漏洞
主持人 Tim Peacock 独自主持本期播客，开场邀请到 Google Chrome 团队工程总监 Doug Turner 和 Chrome 安全产品负责人 Jasika Bawa。话题首先聚焦于 Google 最新发布的官方博客：基于 Gemini 的智能体安全利用测试套件（Gemini agent harness）在 Chrome 代码库中揪出了一个潜伏长达 13 年的沙盒逃逸（sandbox escape）漏洞。
这个漏洞之所以能瞒过所有工程师 13 年之久，根源在于软件架构中跨子系统的“逻辑校验断层”。Doug Turner 解释称，该漏洞涉及浏览器在检查文件权限与处理跨窗口通信 `postMessage` 时的逻辑错位。在 Chrome 极其庞大的代码库里，负责处理文件权限和处理消息通信的是两个极度解耦（disjoint）的独立子系统。两个系统互相假设对方会完成安全合规校验，最终却双双漏检，形成经典的“系统 A 以为系统 B 会校验，系统 B 却根本没有校验”的设计盲区。这种隐蔽的时序逻辑缺陷对人类审计者来说极难直观察觉，而传统 Fuzzing（模糊测试）技术因为需要极长且精确的特定事件序列才能触发该漏洞，也很难命中此类问题。Doug Turner 对此感叹道：“这令人感到谦卑，因为 13 年来，无数开发者在这段代码库上走过，却从未发现它。”
Gemini 智能体最惊艳的地方不仅是指出破绽，更在于它完成了一整套可复现的验证链条：
- **漏洞定点**：识别出孤立子系统间悬空的校验逻辑；
- **构建概念验证（PoC）**：自主编写完整的 Proof of Concept，让安全研究员能够切实看到漏洞被触发的全过程；
- **生成修复建议**：提供候选补丁（Suggested Fix），让负责该模块的工程师能够迅速理清攻击路径，以此作为起点快速落地修复。
```mermaid
flowchart LR
accTitle: Gemini 自动化漏洞挖掘与验证流程
accDescr: 展示 Gemini Agent 从跨子系统代码分析到生成 PoC 与候选补丁的闭环
A["Gemini 扫描分析<br/>(发现跨系统逻辑校验断层)"] --> B["构建 PoC 概念验证<br/>(证明漏洞可被触发)"]
B --> C["评估漏洞严重级别<br/>(区分紧急程度)"]
C --> D["生成候选修复补丁<br/>(供工程师审查落地)"]
```
### `05:00` Chrome 149/150 修复破千漏洞：全自动 Pipeline 与人类双重代码审查
紧接着，Tim Peacock 抛出了一个惊人的数据指标：在 Chrome 149 和 150 两个版本中，团队修复了超过 1,000 个安全漏洞，这一数字甚至超过了此前 23 个里程碑版本（Milestone）修复总数的总和。
面对如此巨大的激增，Doug Turner 透露了幕后的大规模端到端 Agent 流水线机制。这套系统不仅有前置的大模型在海量源码中扫描模式漏洞，还有专门的 Agent 负责复现编写 PoC、评判安全危害级别（明确这是需要立刻停下手中一切工作处理的 S0/S1，还是可以宽限几个月排期的 S2），并自动调用修补系统生成候选代码，甚至最终有一个专门的调度 Agent 匹配最合适的人类开发者来领任务并推动代码合入（land）。
为了打消外界对“两只 AI 机器人互相对账、给彼此打分”的纯黑盒信任担忧，Tim 追问这是否意味着 Chrome 开始“氛围写代码（vibe coding）”。Doug Turner 明确否定并强调，Chrome 严苛的工程交付标准没有任何妥协：
- 哪怕补丁是由大模型全自动生成的，它依然必须分配给第一位人类 Chromium 开发者；
- 该开发者必须完完整整阅读代码、彻底理解变更逻辑并确认背书；
- 随后补丁必须流转至第二位独立的人类 Chromium 开发者进行二次审查（Peer Review），达到团队原本就要求的两个真人审批标准才能合并合入。
### `06:50` 应对 AI 时代的攻击侧军备竞赛：每周双更与开发者防疲劳设计
安全攻防节奏正在被技术深刻重构。Jasika Bawa 指出，Chrome 从 6 月左右开始将安全补丁的发布节奏提速到了“每周推送两次”。过去业界普遍遵循类似微软的“周二补丁日（Patch Tuesday）”模式，攻击者会在“周三利用日（Exploit Wednesday）”快速逆向补丁寻找 N-day。但在生成式 AI 的武装下，攻击者逆向代码提取漏洞细节、甚至自动把几个零散漏洞链（Bug Chaining）拼接成高危武器化 Exploit 的门槛断崖式下跌，攻击窗口从天级直接缩短到了数小时之内（“周二午饭后利用”）。
为了不让高频发布演变成开发者的加班灾难与身心力竭（burnout），Jasika 强调团队全面借助 AI 剥离流程中的无意义摩擦：
- **角色演变为审批者**：开发者的职能重心从手工逆向编写冗长测试与补丁代码，转向对 AI 生成的候选方案进行“审查与批准”；
- **文档与元数据自动化**：版本发布说明（Release Notes）与 CVE 漏洞描述历来极其繁琐枯燥，目前已全面交由 AI 驱动的自动化工具生成。
对于企业 IT 管理员面临的更新频繁和稳定性担忧，Chrome 提供了配套治理支撑：
- **跨平台仪表盘能见度**：通过 Chrome Enterprise Core 与 Chrome Enterprise Premium 集中监控全量设备上的浏览器版本，适配现代异构操作系统环境；
- **细粒度更新策略控制**：为 IT 管理员提供阶梯式灰度管控选项，在组织的安全合规风险容忍度与生产业务稳定性之间取得平衡。
### `10:00` 企业更新策略与 Chrome 自动重启的终极愿景
在日常更新的管理上，Chrome 团队提供了多层机制来平衡安全与用户体验。对于需要严格管控环境的企业，团队提供了企业策略（Enterprise Policy），通过弹窗提醒用户在有可用安全补丁时主动重启 Chrome。这套提醒机制会在一定时间内逐步升级，最终在时限到达时强制执行重启。主持人 Tim 调侃道，这种重启提示似乎总是挑在他处理关键事情时跳出来，不过录制了 290 期播客下来，Chrome 还从未在录音中途崩溃或强制重启过，他笑称自己得“敲木头（knock on wood）”祈祷好运继续。此外，针对受监管合规要求极严、必须对每个软件版本进行全面审核的企业，Chrome 还推出了“扩展稳定版”（Extended Stable Channel）。常规版本的 Chrome 每两周递增一次大版本里程碑，而扩展稳定版则将主版本功能冻结长达 8 周；不过为了防止用户暴露于已知风险中，该通道在此期间仍会持续接收关键的安全补丁。
Jasika Bawa 强调，这些提示和分支管理只是过渡手段，绝非团队的长远目标：“说实话，在讨论完所有这些之后，我只想说明这并不是长期的终极目标，我们长期的目标是一个能持续、动态打补丁，并在合适时机为用户自动重启的 Chrome。”（“But, you know, like after discussing all this, I just want to mention that this is not the long term goal, right? Like the long term goal for us is a Chrome that is continuously and dynamically patched and restarted automatically for users during opportune moments.”）
### `11:46` 标签页焦虑与“最少干扰”的智能重启策略
聊到重启，Tim 直言浏览器重启是很多人的心病：他自己的屏幕上通常挂着约 50 个打开的标签页，每次被提示重启 Chrome，都感觉自己的短期记忆和思维成果要被“推进粉碎机”一样。Jasika 对此表示完全理解并认可这种焦虑，她甚至分享了自己更为“疯狂（unhinged）”的习惯——有时别人快速交代一件事需要记笔记，她会随手新开一个标签页，把内容打在多功能地址栏（Omnibox / Omnibar）里就放在那儿不管，权当便签本用。Jasika 幽默地感慨，现代工程师的生活充满讽刺：“去年有段时间我向团队发过一段存在主义式的牢骚，我说：‘我觉得这太不公平了，现在 AI 都能去写诗了，而我整天只能被困在按 YubiKey 和不停重启 Chrome 里面。’”（“I had this whole like existential rant to my team last year at some point where I was like, I think it's so unfair that the AI gets to write poetry now. And like, I'm stuck just touching YubiKeys and like restarting Chrome all day.”）
为了解决“没人愿意主动重启 Chrome”的根本难题，Chrome 团队的产品策略主要分为两大方向：
1. **寻找“最少干扰（least disruptive）”的时机代表用户自动重启**：
- **零窗口状态**：例如近期在 macOS 上线的功能，当检测到所有窗口均已关闭但 Chrome 仍常驻后台时，静默完成重启更新。
- **锁屏状态**：在用户锁屏、显然未操作浏览器的间隙进行重启。
- **用户预设时间**：根据用户自己的安排计划自动执行。
2. **超越标签页的状态无损恢复（Session Restore）**：
- Jasika 指出，标签页本身的重新恢复只是及格线（“Tabs is table stakes”），如今丢失标签页的情况已非常少见。
- 团队正在深入攻坚更复杂的边缘状态保留，例如用户花了大量时间填写但尚未提交的超长表单内容，或是像阅读 400 多页《奥德赛》PDF 时停留在哪个页面等。如果某些极端场景在工程上无法完美保留状态，团队才会艰难权衡是否以安全补丁优先。
### `15:00` 动态补丁架构（Dynamic Patching）与后 LLM 时代的安全竞速
除了在空闲时机智能重启，Chrome 团队最引人注目的突破在于其底层正在构建的**动态补丁（Dynamic Patching）**能力。以往更新必须杀死整个应用，但在多进程架构下，团队找到了更加优雅平滑的解决路径。
```mermaid
flowchart TD
accTitle: Chrome 动态补丁架构示意图
accDescr: 展示渲染进程如何在补丁下发时保持旧进程运行，并在新导航或新标签页时无缝指向新打补丁的二进制文件。
subgraph PatchTrigger["1. 安全更新到达"]
A["检测到新安全补丁"]
end
subgraph ActiveTabs["2. 既有标签页保持"]
B["正在运行的活跃标签页<br/>(例如播客录制中)"]
C["旧版本 Renderer 进程<br/>(冻结重用，维持当前会话)"]
B --> C
end
subgraph NewActions["3. 新行为与渐进淘汰"]
D["用户打开新标签页<br/>或在旧标签页执行新导航"]
E["Chrome Process Manager"]
F["全新打补丁的 Renderer 进程<br/>(运行安全二进制版本)"]
D --> E
E --> F
end
A -.-> C
C -.->|"标签页关闭或导航后自动释放"| E
```
Jasika 详细拆解了这一机制：当新的安全补丁推送到本地时，如果用户正开着标签页录制播客或进行重要操作，Chrome 并不会强行杀死驱动该标签页的渲染进程（Renderer process），而是将其标记为“不可复用（freeze）”，让现有的页面继续在旧进程中无干扰运行。一旦用户新开标签页，或者在已有标签页中发起新的导航跳转，Chrome 的进程管理器（Process Manager）就会将请求调度至已经加载补丁的全新二进制渲染进程上。随着用户日常浏览，旧的、存在安全隐患的进程会被渐进式动态剔除并替换，整个过程对终端用户完全透明无感。
面对 Tim 提出的“既然如此直观为什么 2026 年才做，而不是 2012 或 2016 年就做”的疑问，Doug Turner 指出，背后的技术与运维物流（logistics）复杂度极高：
- **进程与源隔离**：Chrome 本质上是由错综复杂的进程群（constellation of processes）组成，不仅标签页对应进程，特定站点源（origins）也必须严格隔离在特定的渲染器内，要安全地替换二进制实例极其困难。
- **每日构建发布的高昂运维成本**：要在后台生成这些细粒度补丁，意味着团队面对的不仅是一周发布两次更新，而是必须做到每天都能自动化构建并安全下发部署。
- **补丁时间窗口（Patch Gap）的剧变**：两年前安全环境相对单纯，而随着 LLM（大语言模型）挖掘漏洞的崛起，开源组件中从漏洞修复曝光到被攻击者利用的时间差（N-day 窗口）被前所未有地压缩，促使 Chrome 团队不得不彻底重塑补丁交付范式。
### `20:00` 缩短补丁时差与 C++ 内存安全治理：MiraclePtr 与 Spannification
在过去，漏洞从公开披露到被实际利用之间往往有相当长的缓冲期。Doug Turner 指出，如果回溯到 2018 年，这个时间差可能有几个月之久，而如今漏洞被武器化利用的时间窗口已被压缩到短短几个小时以内。因此，Chrome 团队有一种巨大的紧迫感去弥补这一补丁时差（patch gap）。两年前业界或许还感受不到这种对极速更新的迫切需求，但如今这已成为不可忽视的现实，正所谓“需要乃发明之母”。主持人 Tim 提到本期节目的核心主题正是 Google 如何系统性消除各类安全漏洞（eliminating classes of vulnerabilities），而 Chrome 的底层改造正处于这场变革的风口浪尖。
Chromium 代码库极其庞大，拥有 3500 万到 5000 万行代码，且绝大部分都是 C++。Doug Turner 直言，在可预见的未来，绝大多数代码仍然会保持 C++ 编写，因此团队必须从工程层面根除开发者每天都会面对的固有内存安全缺陷：
- **释放后重用（Use-After-Free）与 MiraclePtr**：在标准 C++ 中，释放指针后再去访问它会引发灾难性的安全漏洞。Chrome 引入了名为 MiraclePtr 的智能指针技术。一旦底层对象被释放，该指针便无法再次被重用，若强行访问系统会立即主动崩溃（crash），这完全符合现代高可靠软件系统的防御预期。
- **越界访问（Buffer Overflow）与 Spannification**：在大型软件系统中，函数间频繁传递裸指针（pointer）及其长度（length）。调用者理应保证访问不超出该长度界限，但人类开发者难免犯错。Spannification（跨度化改造）工程旨在将裸指针与长度配对的模式全面替换为安全的跨度类型（如 `base::span`），从而彻底终结缓冲区越界这类漏洞。
无论 MiraclePtr 还是 Spannification，编译器都需要在每次操作前插入前置安全检查指令（“在做此操作前，先校验那个条件”），这必然带来运行时性能开销（runtime cost）。为了不让全球数十亿台笔记本电脑因为安全防护而变卡，Chrome 内部由专门的性能团队（Performance Team）通过在其他代码路径中挖掘性能优化，完全抵消了这部分安全检查的开销。从终端用户的视角来看，浏览器没有变慢，却凭空获得了一个安全性大幅提升的 Chrome。
> Doug Turner 强调了内存安全在现存庞大架构下的严峻性与不可妥协：“Chromium is composed of, you know, anywhere between 35 and 50 million lines of code. And the majority of it is C++. And the majority of it will remain C++ for a while. Okay. And so we must do something to, you know, alleviate classes of bugs that developers face every single day.”
```mermaid
flowchart TD
accTitle: Chrome C++ 内存安全改造与性能平衡机制
accDescr: 展示 MiraclePtr 与 Spannification 如何分别防御 UAF 和越界，并通过性能优化抵消运行时开销。
subgraph DefenseMechanism ["安全防护机制"]
MP["MiraclePtr 智能指针"] -->|"防御释放后重用 (UAF)"| CrashSafe["非法重用时安全崩溃"]
Span["Spannification (base::span)"] -->|"防御越界访问"| BoundCheck["强制边界合规校验"]
end
subgraph TradeoffEngine ["性能与安全平衡"]
BoundCheck --> Cost["编译器前置检查指令 (运行时开销)"]
CrashSafe --> Cost
Cost --> PerfTeam["专项性能团队多维度系统优化"]
PerfTeam --> Result["终端用户无感：维持高性能并大幅提升安全性"]
end
```
---
### `22:45` 拥抱 Rust：叶子节点重构、Fontations 与中间层 SDK
尽管 C++ 的加固工作在稳步推进，但长期来看，转向 Rust 才是解决内存安全问题的终极方案。Doug Turner 解释称，Chrome 引入 Rust 采取了“双轨并行”的策略：
1. **叶子节点（Leaf Nodes）的独立重写**：叶子节点是指那些与 Chromium 核心逻辑完全解耦、不与其他模块相互缠绕的独立组件，例如图像编解码器（image codecs）和字体库（font libraries）。这类模块有极其严格明确的 API 或 ABI 边界，没有任何理由不用 Rust 重写。在图像处理领域，真正危险的往往不是解码像素本身，而是极其脆弱复杂的元数据解析过程。字体库更是重灾区，例如历史悠久的 FreeType 库（据传最早由 David Turner 编写，历经 OS/2、Pascal 再到 C 语言的反复移植）是历史上大量释放后重用（Use-After-Free）漏洞的源头。为了根治这一隐患，Chrome 团队正使用纯 Rust 从零构建名为 Fontations 的全套全新字体解析库。只要性能与功能不输给旧版，所有叶子节点都将以最快速度替换为 Rust 实现。
2. **中间层架构与 Chromium Rust SDK**：当开发者需要在 Chrome 核心中间层（middle of Chromium）编写业务功能时，挑战则严峻得多。在 C++ 体系下，开发者可以轻而易举地调用指标日志记录（metrics logging）、跨线程任务分派（posting tasks）、获取用户配置文件名称（user's profile name）等底层能力。但原生 Rust 代码并不天然具备访问这些深层内部系统的途径。为了解决这一痛点，Chrome 团队正全力打造一套类似“Chromium SDK”的机制，致力于打通 Rust 与 C++ 核心子系统之间的互操作通道，确保开发者未来使用 Rust 编写浏览器深层功能时同样拥有顺畅的开发体验。
> Doug Turner 阐述了将解耦模块迁移至 Rust 的明确战略：“The leaf nodes of Chrome. These are things that are not intertangled in the rest of Chromium. These are things like image codecs or font library. These things are leaf nodes. And they should be written in Rust. There's no reason not to.”
---
### `25:00` 2300 个第三方依赖项：开源供应链安全与 Gossip 自动化流水线
Chromium 内部引入了超过 2300 个开源第三方依赖组件。主持人 Tim 戏称这已经不仅是一个生态系统，而是一个“大陆级别的生物群系（continental scale biome）”。令人惊讶的是，就连大家熟知的 V8 JavaScript 引擎以及 2D 图形渲染引擎 Skia，在架构分类上也属于这 2300 个外部依赖之内。Doug Turner 解释称，V8 是一个独立的开源项目，被广泛应用于 Node.js 和各类云计算服务中；Skia 也是各方共同维护并在各类软件中广泛使用的基础库。
然而，除了这些由 Google 顶级工程师重点维护的明星开源项目之外，剩下的绝大多数外部依赖库在维护质量上参差不齐。为了保障依赖引入时的供应链安全，Chrome 团队建立了一套高度自动化的代码准入流水线。所有被引入（ingest）的第三方代码库都必须经过 Google 内部代号为 **Gossip** 的系统检测：
- **系统命名**：Doug Turner 调侃自己是个缩写词爱好者，尽管全称复杂难记（大约是“源情报平台” Source Intelligence Platform 之类的缩写），但其在代码准入中扮演着关键的把关角色。
- **漏洞库实时核对**：自动比对公共 CVE 记录以及开源漏洞数据库（Open Source Vulnerability Database），排查依赖库近期是否有未修复的已知风险。
- **供应链投毒与劫持检测**：实时监控上游项目的元数据异动，例如域名注册信息（domain name registry）是否发生了变更——这是开源供应链中极其典型的恶意劫持或社工攻击手段；同时利用分析模型识别代码变更模式是否存在异常投毒迹象。
该机制被全自动嵌入到 Chrome 每次拉取和升级这 2300 个外部库的工作流程中，筑牢软件供应链的入口防线。
> Doug Turner 概括了该自动化防线的作用：“And so what we have to do is make sure that every one of these libraries is is safe to incorporate. So we have an automated pipeline that looks at every software library that we ingest.”
---
### `27:40` 30 年开源老兵的箴言：代码即产品，技术债即安全债
在访谈尾声，主持人抛出传统收尾问题：对于正在管理超大规模开源项目的团队，有什么能够提升安全性的核心建议？
Doug Turner 回顾了自己长达 30 年的大型开源项目工程生涯：他早年在 Netscape 工作，亲眼见证了前 CEO Jim Barksdale 将全部软件代码打印在厚厚的纸质手推轮架上推到众人面前、正式宣布将 Mozilla 开源的历史时刻；此后他在 Mozilla 坚守了十余年，随后又在 Chrome 团队深耕近十年。结合跨越数十年的实战体会，Doug 给出了一条振聋发聩的核心理念：
必须在工程文化与组织价值观中深刻认识到——**“代码本身就是一款独立的产品”（The code is actually a product to itself）**。
团队在对待底层代码质量、C++ 语言规范演进、编译器选型、底层架构设计以及内部开发工具链时，必须倾注与打磨用户界面（UI）、打磨功能特性（Features）以及撰写对外发布说明（Release Notes）完全相同的热情、心血与严谨度。尤其在有数千名工程师协同开发的大型开源项目中，下游采用者（downstreams）本质上也是至关重要的核心客户。Doug 直言，软件行业中无数惨痛的教训早已证明：在许多组织内部，**“技术债会在极短的时间内直接转化为安全债”（Tech debt becomes security debt very quickly）**。唯有将代码架构作为一流产品去精雕细琢，才能从根本上阻断系统性安全崩塌的发生。
> Doug Turner 总结了其三十年开源生涯最重要的工程哲学：“So you have to have the same energy and the same care that you do, with the end-user product, the feature, the UI, everything that shows up in release notes, as you do with... how well the code is written, what C++ languages are you using, what compilers, the architecture, the internal toolings.”
### `30:00` 将代码库视作产品与应对“漏洞末日”的新常态
主持人 Tim 对 Doug Turner 的见解表示赞同，感慨 Doug 投身浏览器代码交付的年限几乎和自己的年龄一样长。Doug 幽默地回应称时间过得飞快，并提醒大家要珍惜时光、多留些回忆，同时由衷感叹打造浏览器是他职业生涯中最棒的事情之一。Tim 表达了诚挚的谢意，提到自己用过 Doug 列举过的每一款浏览器，那段探索互联网的岁月令人难忘。
随后讨论转向推荐读物与产品思维。Jasika Bawa 非常认同 Doug 所说的“必须把代码库当成发布的产品一样对待”，认为这对产品经理（PM）而言是非常契合的思考方式。Jasika 指出，团队目前正进入她所称的“漏洞末日（vuln-apocalypse）”常态化阶段——这种被大量机器挖掘出的漏洞席卷的状态已经持续了六个多月。针对如何实现工作流程化和规模化，她提出了团队当前最关注的三个核心方向：
1. **严防引入新漏洞**：在修复已知安全漏洞和上线新功能的同时，必须遏制新漏洞的引入。Chrome 团队正将更多安全检查前置到提交流程（Commit Queue），利用静态分析在代码合入主干前拦截不安全缓冲区使用（unsafe buffer usage）、悬挂指针（dangling pointers）以及内存安全缺陷等。
2. **彻底消灭整类漏洞**：结合前文讨论的 Rust 迁移与 C++ 缓解措施（如 Spannification），必须坚守消除整类漏洞的长期目标。Jasika 强调：“只是一味地永远修 Bug 绝不是一种可持续的策略（simply fixing bugs forever is not a sustainable strategy）”，不能因为当前高压、高戏剧性的修 Bug 现状而转移视线。
3. **将工程团队视为客户**：在“AI 能够挖掘安全漏洞”的全新时代，站在产品经理的角度，将内部研发工程师当成产品用户，精准识别他们的痛点，并利用现有及全新的自动化工具贯穿整个漏洞生命周期去减轻他们的负担。
Tim 对此补充道，如果将软件安全与航空安全对比，软件行业其实非常糟糕——飞机几乎从不坠毁，而软件却浑身是洞。Jasika 也深有同感地分享了自己参观数据中心的经历，感叹硬件工程师做事严谨周密，而软件行业却总是抱着“先上线、以后再修”的随意心态。
```mermaid
flowchart TD
accTitle: Chrome应对漏洞末日的工程策略
accDescr: 展示将代码库作为产品维护的三大核心支柱
subgraph Defense["1. 前置防御 (Commit Queue)"]
A["静态代码分析"] --> B["拦截悬挂指针"]
A --> C["拦截不安全缓冲区"]
A --> D["拦截内存安全缺陷"]
end
subgraph Architecture["2. 架构根治 (消除整类漏洞)"]
E["C++ Spannification 改造"]
F["内存安全语言 Rust 迁移"]
E & F --> G["从根源消除整类 Bug 类别"]
end
subgraph InternalTooling["3. 内部赋能 (工程师即客户)"]
H["识别开发痛点"] --> I["构建全生命周期 AI 工具链"]
I --> J["缓解开发维护疲劳"]
end
Defense & Architecture & InternalTooling --> K["健康的长期代码产品"]
```
- **漏洞末日持续时间**：大规模机器自动化漏洞挖掘的高压状态已持续超过 6 个月。
- **Commit Queue 强化防护**：把安全扫描门禁前置，在代码合入前自动化拦截悬挂指针和不安全缓冲区使用。
### `33:38` 推荐读物与尾声
在读物推荐环节，Jasika Bawa 推荐了团队刚发布的官方博客《Stronger with every update》（随着每次更新而更加强大）。她表示，这篇博文凝聚了团队极大的心血，记录了过去六个月里 Chrome 团队身处“漏洞末日”前线战壕中的真实经历与故事。如果跳出安全领域，Jasika 则出人意料地推荐了世界名著《基督山伯爵》（The Count of Monte Cristo），称其虽然与漏洞防御毫无关系，但对洞察人性具有极高的研究价值。
Tim 向 Doug 和 Jasika 的到来表达了由衷的感谢，坦言自己自 2008 年 Chrome 问世起就是忠实用户，一直极为钦佩背后的研发团队。最后，节目在订阅提示、多平台收听渠道（YouTube、Apple Podcasts、Spotify 等）以及 Google Cloud Security 社区与社交媒体的互动指引中圆满结束。
## Notable quotes
> `30:00` simply fixing bugs forever is not a sustainable strategy — Jasika Bawa
## Mentioned
Google, Google Chrome, Chromium, Gemini, Tim Peacock, Doug Turner, Jasika Bawa, Jim Barksdale, Netscape, Mozilla, David Turner, FreeType, Fontations, Rust, C++, MiraclePtr, V8, Skia, Gossip, Chrome Enterprise Core, Chrome Enterprise Premium, Stronger with every update, 基督山伯爵
## Video description
<p dir="ltr">Guests:</p> <ul> <li dir="ltr" role="presentation">Jasika Bawa, Group Product Manager, Chrome Security</li> <li dir="ltr" role="presentation">Doug Turner, Engineering Director, Chrome Security</li> </ul> <p dir="ltr">Topics:</p> <ul> <li dir="ltr" role="presentation">Gemini agent harness found a sandbox escape that survived in the codebase for 13 years! How did that happen and how did that bug get noticed among what's surely a tidal wave of bugs being found by the machines?</li> <li dir="ltr" role="presentation">Chrome 149 and 150 fixed over a thousand security bugs—surpassing the last 23 milestones combined. That is a massive spike! T<a href= "https://blog.google/security/chrome-stronger-with-every-update/">he blog</a> explains it's possible by having 'fixing agents' and 'critic agents' working in a loop that mimics human code reviews. I have to ask: how much of this is real, high-quality engineering, and how much of it is just two robots agreeing to grade each other on a curve?</li> <li dir="ltr" role="presentation">Historically, pushing updates was a monumental, scheduled event. Now, you're piloting two security releases a week to combat fast-moving attacks. That sounds like a direct route to developer burnout, and a complete nightmare for enterprise IT admins who just want their systems to stay stable. How are we balancing the need to protect users from N-day exploits versus making everyone play security whack-a-mole?</li> <li dir="ltr" role="presentation">I want to learn more about this long-term vision so let's address the elephant in the browser: nobody wants to restart Chrome. Personally, I have about 50 tabs open right now, and restarting feels like risking throwing my short-term memory into a woodchipper. You're talking about 'dynamic patching' that replaces background child processes on the fly without a restart, and you've rolled out a 'zero window auto-restart' on macOS. First off, are my tabs safe? Second, is dynamic patching actually going to work seamlessly, or is it just going to crash my Renderer mid-session and blame it on the GPU? If this is real, it's really amazing. </li> <li dir="ltr" role="presentation">Tell us about the "spannification" effort and the migration to Rust. There's two parallel technical safety efforts going on to–as we like to say at Google–eliminate classes of vulnerabilities. Tell us about the engineering efforts behind the C++ spans and the Rust journey! </li> <li dir="ltr" role="presentation">Ok I'd be a terrible Allan Friedman disciple if I didn't ask the supply chain question. First, Chrome has over 2,300 third-party dependencies. That's wild. How are we handling that?</li> </ul> <p dir="ltr">Resources:</p> <ul> <li dir="ltr" role="presentation"><a href= "https://youtu.be/pCXT8lQqg_U">Video version</a></li> <li dir="ltr" role="presentation"><a href= "https://blog.google/security/chrome-stronger-with-every-update/">"Stronger with every update: How we're making Chrome and the web safer in the AI Era"</a> blog</li> <li dir="ltr" role="presentation"><a href= "https://cloud.withgoogle.com/cloudsecurity/podcast/next-special-improving-browser-security-in-the-new-era-of-work/"> EP88 Improving Browser Security in the New Era of Work</a></li> </ul>
[Source](https://traffic.libsyn.com/secure/cloudsecuritypodcast/EP292_CloudSecurityPodcast_not288.mp3?dest-id=2641814)
Source quotes
[30:00] Jasika Bawa: simply fixing bugs forever is not a sustainable strategy
Source quotes
[32:15] Jasika Bawa: Like, I really cannot emphasize this enough. Like, simply fixing bugs forever is not a sustainable strategy.
[30:00] Doug Turner: You have to treat the code as a product that you ship.
[10:00] Jasika Bawa: The long term goal for us is a Chrome that is continuously and dynamically patched and restarted automatically for users during opportune moments.
Original transcript
[0:00] And with that, listeners, welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here is just myself today, Tim Peacock, a group PM in Google PsychOps. If you want to subscribe to the show, you can follow us on YouTube, youtube.com slash at CloudSecPodcast. Hosting by myself today, so no fun banter. Today, we are joined by Doug Turner, Director of Engineering on Google Chrome, and Jessica Bawa, somebody I've wanted to work with for years, never really had the chance to, but we've always been friends in Google Cloud. She's the product lead for Chrome Security, which is what a cool job. I wish I had that job. So, Doug, I want to talk about the blog post that just came out. It says your Gemini agent harness found a 13-year-old sandbox escape in Google Chrome. as we just established. So tell us, how did this bug lurk in the code base for so long? I know, that's a really good question. And it's kind of amazing... to see what AI can find. I mean, it's humbling because, you know, for 13 years, people have walked over that code base and not seen it. And it does remind me of Anthropics' post about Mythos finding things a similar bug, like a 20-year-old bug in OpenBSD, which is something we have to learn from. And I looked at the 13-year-old bug recently of what actually happened. And it's kind of a classic problem where it's a very specific logic bug where you have disjoint systems, one assuming that the other will validate, and it didn't. And so in this bug, we have the browser trying to look at file permissions, looking at a post message to make sure. In our code base, these are very, very disjoint parts of the system. And so, you know, when you kind of think about it, the classic problem, A assumes B is doing something, B doesn't do that. It's very hard for a person to see that. It's even hard for classic fuzzing techniques to see this because you need to have a certain large sequence of events to happen to facilitate that type of vulnerability. Now, what I'm really excited about is like, you know, humans didn't find this bug, like, you know, our Gemini vulnerability scanning harness found it. And it, it didn't just find the bug and point it out. It ended up building a proof of concept so that a human developer can say, oh, yeah, that is a bug, and I can see how it works. And, you know, we even built a suggested fix so that the developer could, like... reason about the vulnerability, see how it actually can be accomplished, and then have at least at a starting point of a fix for that particular vulnerability. So overall, I'm really excited about this space because these models are allowing us to see well past what the human capabilities are so that we can find these underlying security bugs. and fix them very, very, very quickly. Let me dig in on that for a second, because I think you said something interesting there about the contrast with fuzzing, where you would require kind of this combinatoric luck to stumble upon these two things interacting. How did Gemini figure out that these two things might interact in a way that violated our assumptions? Yeah, that's like the maybe multi-billion dollar question. So like, you know, these models have a brain and they have a set of reasons, but it's very hard to know how it is reasoning about these. So like in classic fuzzing, what you would say is, okay, here's an API, here's how generally it's supposed to be used. And as you mentioned, we run hundreds of thousands of permutations against that API on that. And so we still do that. It's still very, very important, especially on some of our language features. We do that all the time. problems, these models seem to be able to reason... Much better than the average software developer, as illustrated on this 13-year-old vulnerability. I think we have well above the average software engineer working on Chrome, I would hope. Heck yes, we do. So I want to talk about the fix then, because you mentioned that Gemini suggested a fix. And more broadly than this one 13-year-old bug, Chrome 149 and 150 fixed over 1,000 security bugs. which is more than the last 23 releases combined. Yes. First off, like, that's a lot of fixes. Right. How is that... How is that possible? How did you do this? Yeah, I mean, this is something I'm very proud of and proud of the team up. And so what we've built is a pipeline from vulnerability discovery. So we have, you know, advanced models looking at the software, trying to find the vulnerabilities, as I mentioned before. And then what we have is, you know, an agent that tries to build a proof of concept so that we can verify that it's a real bug. We have an agent that tries to determine the severity of the bug. So if it's
[5:00] bad that we should stop everything and work on? Or is this like an S2 that we can get to it, you know, in a few months? And then we have a system that builds a suggested fix and even an agent that will find a human developer to take on the work and actually land the code to fix the vulnerability. So, you know, you can do this at scale when you have these pipelines in place so that you can go from like, you know, autonomous, automatic, you know, vulnerability scanner all the way down to something that can give a developer a suggested fix. And so you basically do that at scale. That's amazing. And so it is still a developer agreeing to the fix at the end of the day. It's not just two robots, you know, grading each other on a scale and saying, yes, robot, you're awesome. No, robot, you're awesome. No, it's not token acting or something like that. So like, in fact, in Chrome, it still takes two developers. So like, you know, the suggested fix goes to developer A, and they have to read it completely understand it. And, you know, basically assert that yes this is a fix that I am comfortable with and then they hand it to a second chromium developer and that person has to review the changes so we still have you know the same type of engineering rigor no matter if it came from this automated pipeline or if it came from any other patch or cl that happened you know a year or two ago oh that good so we not totally vibe coding Chrome at this point No there no vibe coding no Okay good I like that I like hearing that. That makes me happy since we're doing this meeting on Chrome and literally everything I do is via Chrome. Thank you. Jessica, I want to talk about pushing updates. So you own Chrome from the product standpoint. Pushing updates used to be a pretty big thing and now you're pushing multiple security releases a week. Is this like developer burnout? Are you going to make IT admins really sad? How are you balancing stability with security? How are you developing the right intuition for that, the right framework for that? What does that look like for a PM? Yeah, good question. And yes, we have been pushing two security releases per week since about June timeframe. And I think it's important to start by establishing why are we in the situation the threat landscape has shifted so attackers have always worked very quickly to reverse engineer security bug fixes the moment they land right like this is not new i remember back when i worked at microsoft there was this tradition of exploit wednesday that used to follow our like patch tuesday cadence exactly yeah the natural order of things So this aspect is not new But now with AI tools the actual reverse engineering of the bug fakes is much easier than it has been before So it can be done with less tedium less manual work on the part of an attacker So exploit Tuesday afternoon, not exploit Wednesday. Yeah, yeah. Exploit Tuesday after launch. Exactly. Yeah. So I think the other thing is that we also have good reason to believe that AI tooling is going to make it easier for attackers to chain bugs together into functioning exploits. Right. Again, previously a task that attackers were doing, but pretty tedious and manual. So the threat landscape has fundamentally shifted and we need to be able to respond. But, you know, we haven't just doubled the release cadence and asked the engineering teams to work double shifts. So Doug talked a little bit about how we're using AI to generate candidate fixes for bugs and sort of trying to evolve an engineer's role towards more of like review and approve than, again, manual bug fixing. Another example I can provide is we've been using AI and automation to help generate release notes. and CVE descriptions, again, previously pretty manual process. So we really trying to look holistically across the security bug lifecycle and use AI and automation tooling to our advantage to really remove operational friction as much as possible and kind of avoid this like developer burnout issue that you mentioned. And what are you doing for the enterprise IT admin who's now getting updates to software twice a week? Yeah, fun times for them. They've always been very important in their organizations and they will continue to be very important and if not more in this brave new world that we're in so we have a bunch of options i would say for an enterprise it admin to choose kind of like depending on their organization's needs and risk tolerance so for one you know we have dashboards tim we've got dashboards galore you've got dashboards yeah yeah we've got them through like the chrome enterprise core and the chrome enterprise premium offerings really to provide it admins with visibility into like browser versions across their fleet. So this is OS agnostic because we understand that there's not such any homogeneity anymore in operating systems. And also to offer IT admins granular controls around how to control the updates. So that's important. I think visibility is very important. And also related to this visibility topic, I mentioned about release notes and
[10:00] verbose with, you know, what are these security bug fixes that are going into these releases. A second one, which you and Doug are probably very familiar with because we use it internally at Google, is that we offer an enterprise policy that sort of prompts end users to restart chrome when a security update is available right somehow it always restarts chrome when i'm in the middle of something important i was gonna ask like has it ever happened in one of your podcast recordings no no it never has actually 290 episodes it has never restarted chrome during a podcast and i feel like i need to knock on wood and not get kicked out right now it's the age of the phone apocalypse tim it might happen at this point but we know so yeah you know we have this and sort of escalates over a set amount of time until at the end of the day, of course, we start. And then finally, for organizations that are very sensitive environments or maybe there's some regulatory need to vet every single release before deploying it across your fleet, we also offer the Chrome Extended Stable channel. This actually stays on a major milestone for eight weeks. Normally, we have a two-week feature release cadence, so major milestones increment every two weeks. But this one will stay sort of feature frozen for eight weeks. It still receives security updates because we don't want to leave it vulnerable. But the feature sets. remains locked and stable. But, you know, like after discussing all this, I just want to mention that this is not the long term goal, right? Like the long term goal for us is a Chrome that is continuously and dynamically patched and restarted automatically for users during opportune moments. Okay, so let's talk about that because that was one of the things that really blew me away when I read the blog post. Like I read that listeners, this is so funny. Jessica and I have talked about doing a show together for ages and I, I happened to see this blog post about the Chrome stuff and I'll link in the show notes on LinkedIn a couple mornings ago. And, uh, Not moments later, Jessica pings me and says, hey, we're doing this stuff. Can we come on the show and talk about it? And so it was like the perfect timing for this to all come together. But one of the things that blew me away in the blog post, and maybe, Doug, you want to talk about this as well, is this conversation. dynamic patching thing. I'm looking at my screen, I've probably got 50 tabs open right now. And every time I restart Chrome, I have this fear that everything in my head slash in my Chrome is just going into the proverbial wood chipper. But now you've got a background tab process restart? What the heck did you invent and how does it work? Because that sounds amazing. I will take this one, Doug, if you don't mind, because I'm driving the patch gap product strategy. But yeah, please be free to jump in. First of all, Tim, I just want to address your about tabs. right? Like this is real. I'm here to validate your feelings. Yeah. Real anxiety. And I would also just postulate like worrying about tabs is, is actually quite a normal thing. I do much weirder things in Chrome that cause me anxiety. So here's a particularly unhinged behavior. Sometimes if someone tells me something really quick and I need to take a quick note, I open a new tab and I write this thing in the Omnibox and I simply leave it there. Do you use the Omnibar's notepad? Sometimes. And I'm like, I'll get to it later and move it to a more proper location. So I'm just saying tabs is a normal thing to worry about. That is unhinged. Yeah. Just to reassure you there. Look, I really want to, like, emphasize, like, the core problem which you identified, which is, like, no one wants to restart Chrome. I had this whole like existential rant to my team last year at some point where I was like, I think it's so unfair that the AI gets to write poetry now. And like, I'm stuck just touching YubiKeys and like restarting Chrome all day. Like it feels very like unfair, you know, I want to, I want to do the fun things that the AI is doing. So, Look, I mentioned a bit at the end, you know, the previous section, like our goal is like, you should not have to restart Chrome yourself. This is where we are today. But this is not where we want to be longer term. So I want to talk about like two aspects of the product strategy. Like one is... restarting Chrome, on your behalf during opportune moments. And then I also want to talk about the dynamic patching and Doug might have more like cool engineering to throw in here. So yeah, we want to invest in restarting Chrome when it is least disruptive to you. And when we feel quite confident that we can fully restore your session. So like least disruptive, let's talk about this first. Like what does least disruptive mean? We can use an example, like from one of our recent launches where we said like for Chrome on Mac, No windows open. We'll just restart Chrome. That's very less disruptive. You literally didn't have anything open. Another example could be Your machine is locked. So you're obviously not using Chrome. Maybe that's not a disruptive moment. Another example could be like you scheduled the restart yourself. So, you know, hopefully that was not
[15:00] a disruptive moment for you. So these are kind of examples of like what like least disruptive might look like. And then I want to also talk about like session restore. Cause this is, I mean, you know, you were asking kind of like, how are we making product decisions in the space? Like this is a pretty tricky one because, you know, We really want to balance, obviously, the importance. I mean, I'm a security PM at the end of the day, so... you know, the importance of like getting these updates out there and having users restart, but with also like causing as less disruption to the user as possible. So you know, your tabs for one, I would say, don't worry about these, like your tabs will reopen. This is the most important thing. They mostly come back these days. I haven't lost my tabs in a long time. Exactly. So you should not lose tabs. This is not even a thing we should be worrying about. But even beyond tabs, we're thinking about... other more complex cases of like losing state, right? So one example that my team is thinking about right now is unsubmitted form fields. Maybe you spend a bunch of time feeling out of long form and it's not submitted. How do we think about saving state in that case? I had that happen to me the other day. So these are currently kind of edge cases that we have to think very critically about. And I'm convinced that we can do better in terms of engineering solutions. Doug and his team are all over it. Another example is like, and this one is pretty dear to me. Let's say you're reading like a 400 and something page PDF of the Odyssey. Normal. And you don't remember what part. what major are you on? Like, so these are kind of like, we're really thinking very deeply about cases like this. So not just that, like I think tabs is table stakes. Like you should expect tabs from us. That's not a negotiable, but we're thinking even farther than that about restoring state as best as possible. And then wherever it's not technically feasible, then we have to make these difficult tradeoff decisions about like, okay, in this case, we would prioritize security and security. Maybe there's some work loss, but the goal is to avoid that altogether. But then you also mentioned our early foray into the exciting world of dynamic patching. Yeah. Yeah. So I think it seems like such a risky proposition, right? But the way the Eng team has sort of thought about this from an architectural perspective, I'm fully convinced this is going to work. So again, yeah, Doug and his team really need to make it happen. and you're recording this podcast or whatever. If like a security patch lands on your machine, we don't, kill the renderer process that is running this tab. We leave it be, we put like sort of a freeze on it to say like, don't reuse this renderer process at this point, but, you know, continue to do whatever's happening in this tab. So until that tab is closed by you, or you perform a new navigation within that tab, there's no disruption at all, and you're using the old renderer process. The minute you open a new tab, or you perform a new navigation within that old tab, Chrome's process manager will sort of point that new request to the new patched binary. So really what happens is like over the course of your browsing, The old processes sort of like get dynamically fleshed out, the vulnerable ones. And they get automatically replaced by... by the patched ones. It should be quite seamless, actually, to a user. That's really cool. And I think it's honestly such a cool architectural solution that the engine team is coming up with. Can I ask a dumb question? Like, why didn't we do that sooner? That seems so... intuitive when you explain it that way. Why is it 2026 and we're doing that, not 2016 or 2012 we're doing that? Doug, what do you think? I mean, this is a pretty hard problem, not only from the logistics. I mean, the logistics are the hard part of this problem. So what Jessica explained is right. So Chrome is a constellation of processes. A tab is associated with a process, Certain origins are forced to be in certain renderers. And so we can make these, you know, from a technical point of view, we can create a new renderer. and have it run a different, basically a different binary. So we can patch it. And the next time you launch the renderer, you'll get the safe version or the safer version with all the new vulnerability patches. Now, we also have to generate these patches on the back end. And so from the operational point of view, okay, it's not just shipping twice a week. It's like we have to spin something up like every day. And we have to deploy this in a safe way. And if you look back, well, Jessica mentioned the entire landscape of security has changed with the rise of vulnerabilities being found by LLMs. So we need to close this patch gap. And we didn't have to worry about it like two years ago. It was a simpler time where now what we're seeing is the time it takes to go from a vulnerability being patched in an open source project.
[20:00] to the time it's being exploited. Used to be, like if you go back to 2018, it might be months. Now we're in the hours. And so there's a massive sense of urgency to close this patch gap. And generally, that's why we kind of We didn't see a need for it two years ago. And so, yeah, and also like Jessica explained it perfectly. I'll accept her CLs as soon as she gets back to her desk and starts, you know, cranking on those Gemini CLs for us. Yeah. It is very technically complex. Like I think that's like one of the, yeah, it's a really hard problem, but I'm excited for a team to pull it off. It's a hard problem. And it sounds like this is one of those like necessity is the mother of invention things here where two years ago we didn't need this breakneck pace and now we truly do. So I appreciate that. I think that's a super reasonable answer. I want to talk about another one of the interesting technical things in the blog post, which was the spanification effort and the work that you're doing with Rust. So could you tell us about what's going on there? And is this really timely? Because this week's episode, when we're recording this on August 5th, this week's episode of the show is actually about eliminating classes of vulnerability at Google. So it sounds like you're engaged in that process once again, which is really exciting. Yeah, that's right, Tim. And so, you know, if you look at what we have, Chromium is composed of, you know, anywhere between 35 and 50 million lines of code. And the majority of it is C++. And the majority of it will remain C++ for a while. Okay. And so we must do something to, you know, alleviate classes of bugs that developers face every single day. So in C++, if you delete a pointer and go to reuse it, you might have a really bad time. It's a source of a lot of vulnerabilities. And so with something called Miracle Pointer, it's a smart pointer. So when things get deleted, you can't reuse that pointer, right? It'll crash, which is what you would expect to have happen in a modern software system. Spanification is a similar project where a lot of times in large software systems, you'll pass around a pointer. and its length. And, you know, the recipient of that pointer and that length should... not address the pointer past the length. You would hope. You would hope. But this happens and, you know, people make mistakes. And so spanification is an effort. to rid us of that class of vulnerabilities. Now, both of these two things, Miracle Pointer and Spanification, have runtime costs, right? Because the compiler is going to generate instructions to say, before you do this, check that. And so these things come at a cost to Chrome. And, you know, we have a systems problem where we want these things and we have to find ways to pay for their performance. So we have a performance team essentially covering the cost of these runtime performance with, with other optimizations. So from the user's point of view, they're just going to get a, a more secure version of Chrome. Now, The long game, though, is likely rust. And so, you know, we have... two paths here. So the leaf nodes of Chrome. These are things that are not intertangled in the rest of Chromium. These are things like image codecs or font library. These things are leaf nodes. And they should be written in Rust. There's no reason not to. There's strict APIs or ABIs that we can use, and we are doing that. And a class of bugs is not so much the decoding of an image, but the parsing of metadata, which is usually very scary. FreeType is a font library. It's an ancient library. I think it was made for OS2. It was ported to Pascal and then back to C. It's been a source of... You're scaring me. Oh, yeah. I think David Turner wrote the first version of FreeType back in the day. No relation. but it's been a source of a lot of use after freeze. And we, we have been rewriting that from the ground up in a library called fontations, which is, which is all rust. So, you know, we want these things in the leaf nodes as fast as we can take them as long as they're, you know, as capable as the former version and don't have huge performance penalties. And we're not seeing that. The second thing we're doing with Rust is you can kind of think about it like a Chromium SDK. If you were going to write something in the middle of Chrome or in the middle of Chromium, you might need access to things that are like our metrics logging system or how to post the task to a different thread or, you know, what's the user's profile name. Like these are things But if you write in Russ, you don't. And that is a challenge. And so, you know, we have another effort, you know, making sure that the Chromium developer using the Rust programming language will have a good time as they build their features in the middle of Chromium. Okay, very cool. I love the... Both the consideration of the need as well as the performance optimization, so we're not paying for the spans, the miracle pointers with billions of slower laptops.
[25:00] Friedman. You've got 2,300 third-party dependencies. How are you possibly managing your supply chain security for Chrome? Well, first, 2,300 open source dependencies is kind of incredible just to think about it. You download Chrome, and it comes with an ecosystem of lots of open source developers. An ecosystem, like a whole continental scale biome of things. A hundred percent. And so some of these libraries are really well taken care of. So if you think of things like V8, which is our JavaScript library, it's super fast, super awesome. It's one of these 2300 Skia 2D library angle. You count V8 as a third party dependency? I thought we built that for Chrome. Yeah, it is a separate open source project. And so like, you know, it's used all over the place. So like, I'm pretty sure it's used in Node and a whole bunch of like cloud services. You look at Skia, which is our 2D library, also built with a lot of Google engineers, open source. We have open source contributions to it. It's used basically in everything. you're using Skia. You might use other libraries like Cairo, but Skia is one of the better ones. But you have these really well-known canonical kind of open source projects that are well-maintained and awesome. And then you have the 2,300 others, right? And so it's a rounding error. And so what we have to do is make sure that every one of these libraries is is safe to incorporate. So we have an automated pipeline that looks at every software library that we ingest. And, you know, the paper, the white paper that we're talking about does describe this. Internally to Google, we have a system called Gossip. That's an acronym. Yeah. What's Gossip? Spill the tea on Gossip. So, I mean, I love acronyms, right? And, you know, people can never remember acronyms. I think it's source intelligence platform or something like this. Sure, post-nuff. Regardless of the name, it provides us a signal of, like, kind of safety or quality for all the libraries we ingest. So, you know, it certainly looks at things like CVEs. Have there been any recent CVEs that have been reported? And are they fixed in that particular library? They look at other public data sets, like there's an open source vulnerability database that it looks at. It also looks at things that are like, has the domain name registry changed, which is, you know, one of the more classic attacks. It also looks at, does it look And so this entire system is built into the process that we use to ingest updates to these 2300 libraries. Amazing. Amazing. Okay, so I hate to do it because I think we could talk about Chrome security all day and I would like to personally. But as I shared before the episode, I have some important things to go do. Traditional closing questions. One, do you have a piece of advice to help people who are managing gigantic open source projects like this be more secure? And then two, do you have recommended reading? And that recommended reading could be literally anything except Anton's blog. Well, I'll take the first question probably. are listening. So I've worked in large open source projects for like probably 30 years starting at Netscape. I was there when Jim Barksdale open source Mozilla, you know, they brought a basically a wagon wheel of all the printed software, they printed out all the software on paper and put it in front of us as like, now it's available to everybody. And then, you know, I've worked at Mozilla for like over a decade and now on Chrome for almost a decade. And, you know, the key thing and the ethos and the culture have to recognize that the software, the code. is actually a product to itself. So you have to have the same energy and the same care that you do, with the end-user product, the feature, the UI, everything that shows up in release notes, as you do with... how well the code is written, what C++ languages are you using, what compilers, the architecture, the internal toolings. All of that matters. just as much in these large open source projects. And keep in mind, typically you have thousands of developers working on this. It becomes your downstreams are really important and those customers are really important. So you have to take this really high, you know, ethos when you're talking about open source code. And I do think that's kind of the philosophy in Chromium. or for our software, our code. And I think... It shows up because, in my experience, tech debt becomes security debt in some places. Very quickly.
[30:00] any bugs that we have discovered. But I think that's really the most important thing. You have to treat the code as a product that you ship. Doug, I love that answer. And it's crazy to me that you've been shipping browser code for almost as long as I've been alive. Tim, I don't know how I feel about that. It goes by fast. And so, you know, I know we spoke about it before, but make sure you make a lot of memories because the time does go by fast. And I've loved every minute, like building browsers is like one of the best things I could have done in my career, for sure. Well, let me express my gratitude because I used every one of the browsers you named. Thank you. that era for me of exploring the internet was like, and yeah. Wild. Very cool. Jessica, do you want to take the reading question? I do. I also just really liked kind of how Doug said that, the code base is like a product. Mm-hmm. I quite like it. Tim, I think it bodes well for... pms of the flavor of you and i yeah it does you know that like to treat the code base of the product like i really like that that way of thinking i think yeah overall i would say like there's a few things that are top of mind and i will answer a reading question but i don't think you would like it i feel that as we are sort of entering what i'm considering the normalized phase of the bone apocalypse you know like we've been in this kind of for about over six months now. I'm thinking a lot about like operationalizing and scaling the work that we're doing. So a couple of like concrete things that, my team and I are thinking about. One, I think it's really, really important that we defend against the introduction of new security bugs. into the code base. Both as we're fixing security bugs, And as we're introducing new features. So I think this is something really important for all of us to be focusing on. On Chrome, we're doing this by moving more security checks into the commit queue. So, you know, static analysis, flagging things like unsafe buffer usage, dangling pointers, memory safety issues, you know, all our favorites before code ever lands really in the main tree. I think this is like really important, right? hamster wheel. Yeah. Yeah. Like, you know, we can't be doing what we've been doing. No, I love making that point about our industry that, you know, if you compare, say, software security to aviation safety, we're really bad at our jobs. Planes basically never crash and software is basically always broken. Yeah. Yeah. I had this feeling the one time I toured a data center. I was like, wow, the hardware guys really have their act together. And us software people, we're just all over the place. We're like, we'll just ship it and fix it later. But yeah. So I really shouldn't be introducing more bugs. The second piece, you know, we talked about it, like Doug walked us through kind of our strategy around Rust and C++ mitigations, but we really, really need to maintain our long-term focus on eliminating entire classes of bugs. Like, I really cannot emphasize this enough. Like, simply fixing bugs forever is not a sustainable strategy. Yeah. And so we cannot allow ourselves to be distracted in this moment of, like, you know, high drama, high stress. And that's all very good reasons. But we need to also maintain our focus on eliminating classes of bugs. It's really important. And the third thing is a bit PM-y, but... I'm really thinking of our engineering teams as customers. In this phone apocalypse age, what are their pain points? There are several, let me put it that way. Yeah, several. Yeah, so my team and I are really thinking about what are the pain points of the engineering teams and how can we use the tooling that we have at our disposal of new tooling to alleviate these pain points, again, across the entire bug lifecycle. AI can find security bugs era that we're in. So for reading, I'm going to go ahead and Yeah, please. I mean, look, I figured like because of the security podcast, I want to recommend that folks would read the blog that we published last week. As you mentioned earlier, it's stronger with every update. I think it would be so cool if everyone could give it a read. It really represents the work of a very passionate team. And it's kind of an honor to be able to tell the story of what the past, again, six months or so have been like in the trenches of the phone apocalypse here on Chrome. But if you were looking for more like non-security related reading. It could be anything. I mean, I think that's a great recommendation. I feel honored to help you guys tell the story today. So this is great to be a part of the story. I think everyone should read The Count of Monte Cristo. Huh, okay. Unrelated to the Volantocalypse. But yeah, it's an important study on human characters. Nice. Well, Doug, Jessica, thank you so much for joining me today. I love Chrome. I have used it since 2008. And I've
[35:00] really admired the team that puts it together. So it's really an honor to get to speak with you guys and host you on the show. So thank you. Thank you very much, Tim. Thanks for having us. And now we are at time. Thank you very much for listening. And of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice. You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website. cloud.withgoogle.com slash cloud security slash podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com. You can follow us on X, x.com slash cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode. See you on the next episode of the Cloud Security Podcast by Google. Thank you, honey.
