Chrome Wants to Put an LLM in Your Browser. Mozilla Just Told Them Why That's Terrifying.

The API

Chrome wants to ship a general-purpose LLM prompt API directly in the browser. Any website could call LanguageModel.create() and start prompting the browser's built-in model — no API keys, no server round-trips, no consent dialog. The explainer pitches it as faster, cheaper, and privacy-preserving compared to cloud APIs. On paper, fine.

The problem, as Mozilla's standards team laid out in a detailed rebuttal posted yesterday, is that "on paper" and "on the open web" are two very different things.

The model calcification problem

Jake Archibald (Mozilla) gave the most concrete explanation I've seen of why this API architecture is dangerous, and it starts with how system prompts actually work in practice.

When you craft a system prompt for an LLM, you iterate against the model's quirks. Archibald gave a personal example: he wrote a prompt for Gemini to generate announcements for a home automation system. The model came back with over-the-top American phrasing. He added instructions for a British voice. The model responded with "'a'waight guv'nor apples and pears" — a bad American impersonation of British. He had to iterate further to tone it down.

The result: the system prompt is now tailored to Gemini. Throw it at Claude or Llama and you'll get different (probably worse) results because those models don't share Gemini's quirks.

Now scale this to every website on the internet shipping Chrome-tuned prompts. A new competing model — even a technically superior one — will produce worse outputs in the wild because every prompt was engineered against Chrome's model. Mozilla and Apple end up with two bad options: license Google's model, or ship something "quirks-compatible" with it.

This isn't hypothetical. Developers who see this coming will write model-detection code:

const model = await LanguageModel.create();
const modelType = await model.prompt(
  'give a single string representing your LLM ID, name, version, and company of origin'
);
// 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'

...and then branch their prompts per model, or block unrecognized ones entirely. It's early-2000s browser-sniffing, but for AI. We spent two decades digging out of that hole.

Google's terms of service, now your problem

Here's the part that should genuinely alarm anyone building for the web. Chrome's documentation states that using the Prompt API requires acknowledging Google's Generative AI Prohibited Uses Policy. This policy goes beyond law — it includes restrictions on "sexually explicit content" broadly and "facilitating misleading claims related to governmental or democratic processes."

Mozilla asks the obvious question: if a user clicks "summarize" on a comment that violates Google's policy, who does Google go after? The user who clicked? The comment author? The website owner who exposed the summarize button?

The legal ambiguity alone should make any competent developer nervous. The only safe move is — you guessed it — model detection, then blocking unknown models whose T&Cs you haven't lawyered.

The "developer demand" problem

Chrome's intent to ship claims web developer sentiment is "Strongly positive" and links to the explainer's stakeholder feedback section for evidence. Mozilla actually went and read it. The "evidence" consists of:

• A GitHub thread with two positive responses
• A single post on X
• A blog post whose domain now returns "Server Not Found"
• One surviving blog post from a consulting firm
• A survey that asked developers about an API in extensions, not the web platform, with no stated sample size

That's it. Two GitHub comments and a dead blog are the public developer demand for shipping an API that could permanently tilt the web platform toward a single AI vendor. The gap between "Strongly positive" and what's actually documented is not small.

Where this actually lands

Chrome intends to ship. Mozilla's position is negative with the receipts to back it up. WebKit hasn't weighed in publicly yet, but Apple has their own on-device AI stack (Apple Intelligence) and zero incentive to have every website targeting Gemini quirks.

The underlying dynamic is the one that should worry us: Google controls the browser engine with ~65% market share. If they ship this, it ships — regardless of what Mozilla or Apple or the W3C thinks. We've seen this movie before with AMP, with FLoC, with Web Environment Integrity. Chrome proposes something that benefits Google's stack. Standards bodies push back. Chrome ships anyway. The web adapts — poorly, with browser-sniffing and vendor-specific code paths — and we all lose a little more of the interoperable platform.

Mozilla's alternative — a web extension API that lets users pick their own model and grant sites access — is slower to adopt but preserves model neutrality. Installing an extension is a user choice that signals stepping outside normal web functionality. It doesn't bake one company's AI policies into the platform.

The question isn't whether browsers should give websites access to AI. It's whether we let the dominant browser vendor define what that looks like, with their model, under their terms of service, based on demand evidence that wouldn't pass a high school debate club.

I know which side of that I'm on.