How Chromium Uses Finch for Gradual Feature Rollouts
This article explores the Finch experimentation framework and how it enables the Chromium web browser to safely deploy new features to subsets of users. By utilizing code-level feature flags, server-side configuration files, randomized user bucketing, and real-time telemetry, Finch allows developers to gradually roll out changes, conduct A/B testing, and instantly revert problematic updates without requiring a full browser patch.
Dormant Features in the Binary
Before Finch can manage a rollout, developers must wrap new code inside feature flags within the Chromium source code. When a user installs or updates their browser, the code for new features is already compiled into the binary, but the features remain dormant (turned off) by default. This approach decouples the code deployment process from the feature activation process, allowing the browser to hold inactive features until Finch instructs them to turn on.
Fetching the Finch Seed
Finch operates through a client-server architecture. Periodically, the Chromium browser requests a compressed configuration file—known as the "Finch seed"—from central variations servers. This lightweight file contains exact instructions on which dormant features should be enabled, disabled, or modified, and under what conditions. The browser downloads this seed silently in the background and applies the new configurations the next time the user restarts the application.
Targeting and Random Bucketing
To roll out a feature to a specific subset of users, the Finch seed defines strict eligibility criteria and rollout percentages.
First, the browser checks if it meets the high-level targeting rules defined in the seed. These rules can filter users by:
- Browser Channel: Canary, Dev, Beta, or Stable.
- Operating System: Windows, macOS, Linux, Android, or iOS.
- System Constraints: Hardware specifications, country, or enterprise policies.
If the browser meets the criteria, Finch uses a deterministic randomization algorithm to assign the browser instance to a specific "bucket" or study group. A locally generated randomization seed ensures that a user consistently stays in the same experimental group across browser restarts.
For example, a Finch configuration might instruct the browser to enable a new memory-saving feature for 1% of users on the Stable channel, while assigning another 1% to a designated control group, leaving the remaining 98% untouched.
Telemetry and A/B Testing
Gradual rollouts rely on continuous data collection to verify that a new feature works as intended. For users who have opted into sharing usage statistics, Chromium's User Metrics Analysis (UMA) system sends anonymized performance, stability, and crash data back to the servers.
This telemetry data is tagged with the active Finch study groups. Engineers compare the metrics of the experimental group (those with the feature enabled) against the control group (those with the feature disabled). This A/B testing reveals whether the new feature causes unexpected memory spikes, slower page loads, or increased crash rates.
Scaling Up and the Kill Switch
A typical feature rollout progresses through the browser channels—starting with high percentages in Canary, Dev, and Beta, before moving to a 1% rollout on the Stable channel. If the telemetry from the 1% Stable rollout shows no regressions, developers update the server-side Finch seed to expand the feature to 5%, 10%, 50%, and finally 100% of the user base. Once a feature reaches 100% and remains stable, the feature is permanently enabled in the source code, and the Finch configuration is retired.
Conversely, if a critical bug is discovered during the gradual rollout, Finch acts as an emergency kill switch. Engineers can modify the Finch seed on the server to drop the rollout percentage back to 0%. The next time affected users restart their browsers and fetch the updated seed, the broken feature is automatically disabled, resolving the issue without waiting for a full software patch to be compiled and distributed.