Stable as Trust Boundary

Chromium’s Stable channel is an explicit trust boundary: a feature on Stable is considered generally suitable for the full user population, including users with no tolerance for instability, data loss, or security regression.

An IT director writing a Chrome deployment policy reaches for the word “stable” and assumes the ordinary product meaning: tested, supported, unlikely to change underfoot. Stable in the Chromium sense warrants something narrower. It means the project has authorized general exposure for the full user population, through a specific release and governance process. That boundary explains why Zombie Origin Trial, Experiment That Became Permanent, and Supply-Chain Vulnerability Lag are not separate mistakes. Each misreads what Stable does and does not promise.

What It Is

The Chromium project treats Stable as a contract with the general user population. Once a feature defaults on in Stable, the project is committing that it has cleared a launch review whose explicit bar is general suitability. The feature has to work on supported operating systems and architectures, against representative production traffic, and without data loss. It must not weaken the security posture established by prior decisions (Site Isolation, the V8 Heap Sandbox, the Untrusted Renderer Axiom). It also must not break web-platform backward compatibility for content the field is known to be running.

The asymmetry between Canary and Stable is the fact that does the work. A change reaches Canary on the same working day its code lands. It needs no review beyond OWNERS approval and a green commit queue; the population is around 1% of installs, so the stability bar is low.

Reaching Stable requires the Intent to Ship gate: three API owner LGTMs on the blink-dev thread, addressed compatibility, privacy, and security review, plus documented launch readiness across the four-channel soak. The same source tree feeds both channels. The same patch can produce both behaviors through the feature flag’s channel-dependent default. What separates them is the standing claim the project makes about each population.

Reversal on Stable is rare and high-bar by design. Routine bugs are addressed by a security or stability patch on the next milestone. A regression severe enough to warrant pulling a feature server-side calls for Finch kill-switch traffic and produces an incident review. The rarest case, a code-level revert on Stable, is handled by a backport CL with release-engineering approval and typically Chrome VP-level signoff. The bar is high because the trust-boundary claim is what the bar protects. If Stable could be reverted casually, the standing claim would mean nothing, and downstream consumers who depend on Stable as a predictable artifact would plan against a moving target.

The boundary is not symmetric in time. Stable’s claim begins the moment a feature defaults on at 100% of the channel and persists until the feature is deprecated through the Deprecation Trial machinery or removed under web-platform-backward-compatibility constraints. It does not begin when the feature appears in the Stable build’s source tree behind a flag, because that is exposure-controlled. It also does not begin during a Finch experiment below 100%, because that is rollout-controlled. Locating a feature on the rollout curve is the practical test for whether the trust-boundary claim has attached.

Why It Matters

Without this boundary, release decisions collapse into vague channel labels. A team cannot tell whether a feature is generally launched, merely present behind a flag, temporarily exposed through Finch, or still protected by a trial. That distinction is what makes release policy, deprecation planning, and downstream security response specific enough to operate.

The boundary anchors the section’s antipatterns by negation. Supply-Chain Vulnerability Lag rests on the misreading “we ship from stable, so we are safe.” That treats Stable as patched against known vulnerabilities, erasing the calendar gap between upstream Stable and downstream Stable. Zombie Origin Trial rests on the misreading “stable means stable, so a deployed token will keep working.” That collapses the trust-boundary claim onto a permanence claim and erases the distinction between trial-period exposure and Stable suitability.

Experiment That Became Permanent rests on the inverse misreading at the project’s own scale. A trial that accumulates dependents until removal is prohibitive has reached Stable in fact without having cleared the Stable suitability gate in form. Each antipattern is the same boundary read incorrectly from a different seat.

The boundary also calibrates the cost of the project’s own decisions. Web-platform backward compatibility binds in part because the trust-boundary claim binds. A feature that has reached Stable is one the project has committed to keep available to dependent sites unless it is deliberately and visibly deprecated through the Deprecation Trial machinery. Removing a Stable feature costs more than adding one: UseCounter measurement, a deprecation-trial window, a warning campaign, and a final flip. That cost is why every new web-platform addition is gated more heavily than additions in a typical software product.

For an enterprise organization deploying a Chromium-based product, the boundary is what makes “deploy Stable” a meaningful policy. Stable warrants what the launch review establishes. It does not warrant a feature set frozen against Finch rollouts, against per-channel security patches between milestones, or against a downstream-vendor configuration that consumes upstream Stable on its own lag. A policy that treats Stable’s claim as broader than its actual content discovers the gap during an incident; a policy that treats it as narrower over-invests in tests for guarantees the project already underwrites.

How to Recognize It

The clearest indicator that the trust boundary is in operation is the asymmetric procedural bar at the channel transitions. A Canary regression is filed against the Tree Sheriff and addressed within days; a Stable regression escalates to the release-engineering team within hours, names a release-blocker priority, and typically produces a post-mortem. The procedural weight is what the boundary’s standing claim is worth.

In an Intent to Ship thread on blink-dev, the boundary surfaces as the language API owners use to evaluate the request. “Suitable for general use,” “we have sufficient compatibility data,” “no known regressions in Beta soak,” and “ready to default on in Stable” are claims the API owner LGTM is signing off on. The thread that does not address those claims explicitly does not clear the gate. The thread that addresses them with citations to Origin Trial data, UseCounter measurement, and Finch rollout results is the canonical shape of an approved Intent.

In a Finch experiment configuration, the boundary surfaces as the difference between the rollout curve and the launch state. A feature defaulted-on at 100% of Stable has reached the boundary; a feature defaulted-on at 1% of Stable is inside the rollout window the boundary explicitly tolerates because reversal is fast and per-population. Reading a chromiumdash.appspot.com rollout curve and identifying where the 100% line is reached is identifying when the trust-boundary claim attaches.

In a Chrome Releases blog post, the boundary surfaces as the distinction between “is now available on the Stable channel” and “is defaulted on for all users on Stable.” The first is a release-engineering claim: the binary is built and rolling out. The second is a trust-boundary claim: the project is standing behind the feature for the general population. Reading these phrases interchangeably loses the distinction the boundary names. Reading them apart calibrates policy against the right surface.

How It Plays Out

A web standards engineer at a major browser-engine vendor is shepherding an API addition through the Chromium Intent process. The Intent to Experiment cleared three months earlier and the Origin Trial has produced compatibility data from a dozen partner sites. The engineer files an Intent to Ship; two API owners LGTM within a week, the third asks for a UseCounter measurement showing the API’s polyfill usage on the open web before approving. The engineer runs the UseCounter for two milestones, returns with the data, and receives the third LGTM. The feature defaults on at 100% of Beta in milestone N+1, defaults on at 1% of Stable for the first three days of milestone N+2, and reaches 100% of Stable a week later. The trust-boundary claim attaches at the 100% Stable moment, not earlier; the engineer’s launch checklist documents that moment as the launch date because the boundary is the operational definition of the launch.

A downstream Chromium-based enterprise browser vendor maintains a Stable build that tracks upstream Chrome Stable on a seven-week lag (per the Four-Channel Pipeline and Supply-Chain Vulnerability Lag entries). The vendor publishes a security bulletin for each Chromium CVE patched between the vendor’s previous Stable and the upcoming Stable. The bulletin’s standing claim is calibrated against the trust boundary: upstream Stable’s patch date, the vendor’s own Stable date, and the gap as the exposure window the vendor commits to closing. The vendor’s customer documentation doesn’t say “Stable is patched”; it says “Stable’s claim is what reaches the user with each milestone release.”

An enterprise security engineer is writing a Chrome deployment policy. The first draft says “Deploy Chrome Stable to all employees.” A peer reviewer asks the engineer to specify what Stable’s claim covers and what it does not.

The revised policy keeps the Stable default but names exceptions. Feature X is disabled because it is incompatible with legacy application Y. Feature Z’s Finch rollout is monitored via IT-side telemetry before the default is allowed. Security patches outside the four-week milestone cadence follow the standing emergency-release schedule. The boundary’s standing claim is what the policy depends on. The boundary’s edges are what the exceptions enumerate.

Consequences

Naming the boundary gives release work a sharper vocabulary. A team can read a Stable launch and identify whether the trust-boundary claim attaches yet. It can write an enterprise deployment policy whose claims line up against the standing-claim shape. It can interpret a downstream-vendor security bulletin as a calibrated commitment against the boundary rather than an unconditional guarantee. It can engage a blink-dev Intent thread in the procedural register the thread is written in, naming what the API owner LGTMs are signing off on instead of treating the gate as an opaque approval step.

The cost of the vocabulary is calibration. The trust-boundary claim is narrower than the consumer-product sense of “stable” and wider than the engineering-purity sense. An IT administrator who assumed Stable was a frozen feature set learns that Finch rollouts run inside the boundary continuously. An engineer who assumed Stable was just “the last channel” learns that the channel transition carries a standing claim with procedural weight. Neither reader can import the ordinary meaning of “stable” and be done.

The boundary’s content also evolves. The Stable cadence shortened from six weeks to four weeks in Chrome 94 (2021) when the project judged that the security-patch-delivery half of the claim outweighed the stability half at the longer cadence. The bar for API additions has tightened as the standards community’s compatibility-review machinery matured. The Privacy Sandbox’s launch sequence has tested whether the boundary can absorb features that affect every site on the web.

Treating the boundary’s content as static loses accuracy over the medium term. Its shape is more stable: a standing claim of general suitability gated by the Intent process and enforced by Finch and feature flags. With that shape in view, every cadence change is a calibration of the same boundary rather than a redefinition of it.

Release-discipline practices operate on the boundary from different sides. Feature Flag Guarding enforces it in code. Finch Variations is the rollout infrastructure it tolerates. Origin Trial Token Deployment is the operator-side surface that issues tokens against channel scope. Zombie Origin Trial is the failure mode the boundary has to resist.

Notes for Agent Context

For launch-state code, treat “defaulted-on at 100% of Stable” as the operational definition of launch; never collapse it with Stable-build availability or any sub-100% Stable rollout. For enterprise deployment policy, name the channel and Finch rollout state the policy depends on; never assert a frozen Stable feature set or treat Stable as immune to mid-milestone security patches. For Intent to Ship summaries, identify what the three API owner LGTMs are signing off on: general suitability claims about Stable, not a generic approval step. For downstream-vendor security bulletins, calibrate the claim against the upstream Stable date the patch reached, reject the downstream build date as the security reference point, and surface the lag as part of the trust-boundary calibration.

Related Articles

Sources

The Chromium project’s Intent to Ship process documentation at chromium.org/blink/launching-features is the most direct source for the procedural shape of the Stable suitability claim; the documented requirements (three API owner LGTMs, compatibility review, privacy review, security review, launch readiness) are what the trust-boundary claim is procedurally backed by. The page describes the gate in the project’s own working language and is the source of the “general use” framing the trust-boundary concept names.

The Chrome Releases blog at chromereleases.googleblog.com is the working historical record of the boundary’s operational events: every channel promotion to Stable, every emergency security release outside the milestone cadence, every published rollback. The four-week Stable cadence introduced in Chrome 94 was announced on the Chromium blog in March 2021; the post explains the project’s reasoning about the security-versus-stability tradeoff inside the boundary’s two-sided claim.

Chromium Dash and the Chrome Platform Status “Available on” column expose the channel-state and rollout-curve data the trust-boundary lens depends on for distinguishing pre-100% rollouts from launch. Chrome Enterprise’s Manage Chrome browser releases page articulates the enterprise-pilot warranty on Beta and the deployment-warranty content of Stable in the project’s own language for an IT-administrator audience; the page is the closest the project comes to a vendor-side statement of the trust-boundary claim.

Technical Drill-Down

• Chromium project — Launching Features — the procedural map of the Intent process and the project’s own statement of what reaching Stable warrants; the three-LGTM gate is documented here.
• Speeding up the release cycle (Chromium Blog, March 2021) — the project’s reasoning behind the four-week Stable cadence; the post is the trust-boundary’s most recent calibration on the record.
• Chrome Releases blog — the working historical record of channel promotions, emergency releases, and the rare Stable rollback; the empirical surface against which the boundary’s operational content is verifiable.
• Chromium Dash — chromiumdash.appspot.com — release-engineering surface; rollout curves and channel-promotion history.
• Chrome Platform Status — chromestatus.com — per-feature channel state; “Available on” column carries the trust-boundary-attaching vocabulary.
• Chrome Enterprise — Manage Chrome browser releases — the project’s vendor-side articulation of what Stable warrants for an enterprise audience.