Mozilla · 2026-04-30 · major
Mozilla Goes 'Position: Negative' on Chrome's Prompt API — Vendor Lock-In and Fingerprinting Cited
Mozilla formally opposes Chrome's proposed window.ai / Prompt API. Reasons: prompts get tightly coupled to one vendor's model, Google's Prohibited Uses policy adds extra-legal restrictions, and the API enables LLM-based browser fingerprinting.
Mozilla labels Chrome's Prompt API 'position: negative', citing model coupling, fingerprinting risk, and Google's Prohibited Uses policy.
Key specs
| Hn points | 508 |
|---|---|
| Mozilla position | negative |
What is it?
Chrome's Prompt API (also surfaced as window.ai) is Google's proposal for a JavaScript interface that lets a webpage call a built-in browser LLM with a string prompt. It's been shipping under origin trial for months. Mozilla's standards-positions tracker just flipped the issue to 'position: negative' and Mozilla engineer Jake Archibald posted a detailed rationale that hit the HN front page with 500+ points.
How does it work?
Archibald's argument is interoperability-focused. A system prompt tuned for Gemini Nano performs poorly on a different model — meaning sites will inevitably target one vendor's model behavior. Google's terms add a 'Generative AI Prohibited Uses Policy' that restricts content beyond legal requirements (including 'misleading claims related to governmental processes'), turning a web platform API into a vendor content gate. And because LLM responses leak which model is loaded, the API becomes a strong fingerprinting vector.
Why does it matter?
If a Chrome-only AI primitive ships at the platform layer, the rest of the web has to either ship its own incompatible LLM or accept Chrome behaviour as the spec. Mozilla pushing back early is the cleanest way to keep AI access on the web open and model-agnostic — closer to fetch() than to webGL extensions. Worth watching whether WebKit follows.
Who is it for?
Web developers and standards watchers tracking how AI lands in the browser