How Chromium API Owners Review Controversial Web APIs

This article provides an overview of the critical role played by the API Owners group within the Chromium project's governance model, specifically focusing on how they evaluate, mediate, and approve or reject controversial additions to the web platform. Acting as the final gatekeepers for the Blink rendering engine, the API Owners balance rapid technological innovation with interoperability, privacy, security, and cross-browser consensus before any new web capability is shipped to billions of users.

Who Are the API Owners?

The API Owners are a small, designated group of senior Chromium contributors who serve as the benevolent stewards of Blink, the rendering engine that powers Google Chrome, Microsoft Edge, Brave, and several other browsers. Their primary responsibility is to oversee the Blink launch process. No new web-exposed feature, API, or significant change to existing web behavior can be enabled by default in Chromium without their explicit approval.

The Three-LGTM Rule

When developers want to add a feature to Chromium, they must follow a public process that culminates in an "Intent to Ship" email sent to the blink-dev mailing list. For a feature to pass this stage, it must receive at least three "LGTMs" (Looks Good To Me) from the API Owners. While routine features pass through quickly, controversial proposals trigger intense scrutiny from this group.

Evaluating Controversial Features

Controversy around a new web API usually stems from privacy concerns, security risks, architectural disagreements, or fear of browser engine monoculture. When reviewing a contentious "Intent to Ship," the API Owners evaluate several strict criteria:

1. Cross-Browser Signals and Interoperability

API Owners require feature authors to request formal feedback from other browser engines, specifically Mozilla (Gecko) and Apple (WebKit). If rival vendors flag a feature as "harmful" or "worth prototyping" rather than "supportive," the API Owners investigate the underlying objections. While competitors do not have veto power over Chromium, the API Owners will block a feature if the opposing vendors highlight valid architectural flaws or severe interoperability risks that the feature authors have ignored.

2. W3C TAG Review

Controversial features must undergo a review by the World Wide Web Consortium’s Technical Architecture Group (W3C TAG). The API Owners heavily weigh the TAG's feedback to ensure the proposed API aligns with the fundamental principles of the open web and does not break existing web architecture.

3. Privacy and Security Trade-offs

Many controversial APIs—such as those granting hardware access (like WebUSB or WebBluetooth) or those related to advertising and identity—pose significant privacy and security questions. API Owners ensure that these features have undergone rigorous internal security reviews and that they include strong user-consent models and mitigations against fingerprinting or abuse.

4. Web Developer Demand

When other browser vendors oppose a feature, API Owners look for strong positive signals from the broader web developer community. They often require the feature to go through an "Origin Trial," which allows developers to test the API on live websites for a limited time. The API Owners then review this real-world data to determine if the utility of the feature justifies shipping it despite the controversy.

De-escalation and Veto Power

When consensus is lacking, the API Owners act as mediators. Instead of outright rejecting a controversial API, they frequently withhold their LGTMs and instruct the engineering team to return to the standards bodies to resolve disputes. They may demand that an API's scope be reduced, its syntax be altered to match a competitor's counter-proposal, or its privacy guardrails be strengthened.

Ultimately, the API Owners possess absolute veto power within Chromium. Even if a controversial feature is heavily backed by Google's business interests, the API Owners are empowered—and expected—to block it from shipping if they believe it will ultimately harm the health, security, or interoperability of the open web.