Mozilla's opposition to Chrome's Prompt API
Google’s plan to standardize a browser “Prompt API” for built‑in language models in Chrome is drawing strong pushback, especially from Mozilla, over fears of de facto model lock‑in, poor interoperability, and new fingerprinting and performance risks. Critics argue that tying web features to a specific AI model and its terms of use effectively gives Google more control over the web platform and could recreate an IE‑style monoculture, while also imposing content restrictions at the API level. Supporters counter that local LLM access can improve privacy and user experience, but even some of them question whether such capabilities belong in core web standards rather than opt‑in services or low‑level primitives like WebGPU.
Context and Proposal
- Discussion centers on Chrome’s proposed Prompt API, which exposes local or cloud LLMs to websites via a standardized web API.
- Some see this as a natural next step, analogous to existing non-deterministic APIs (speech, geolocation); others see it as scope creep and unnecessary for the web.
Mozilla’s Objections
- Main technical concern: prompts quickly become tuned to a specific model’s quirks, breaking interoperability across browsers and future model versions.
- Worry that this creates “quirks-compat” with Google’s model, similar to past problems (IE, WebSQL/sqlite).
- Criticism of Chrome tying API usage to a “prohibited uses” policy that restricts content (e.g., sexual content, political misinformation) as inappropriate for a neutral browser API.
Interoperability and Model Lock-In
- Fear that sites will optimize for Gemini (or another dominant model) and effectively require Chrome, marginalizing other browsers and national/“sovereign” browsers without comparable models.
- Some argue exposing model identity or version is necessary for developers; others argue that would increase fingerprinting and lock-in.
Privacy, Fingerprinting, and Resource Costs
- Concerns that local models add powerful new fingerprinting vectors and can become de facto “device verification.”
- Local LLMs demand large downloads, disk space, and RAM/VRAM; users on modest hardware may see slowdowns and battery drain.
- Some see local models as a privacy win vs. cloud APIs; others ask why browsers should run LLMs at all instead of letting sites call remote APIs explicitly.
Security and Abuse Risks
- Worries about “LLM botnets”: malicious pages using the API for unconsented compute (similar to cryptomining).
- Prompt injection and expanded attack surface are seen as inevitable; calls for strict permissions and sandboxing, though some doubt this can be done confidently.
User Demand and “AI Everywhere” Skepticism
- Repeated pushback that “browsers and OSes are expected to gain LLMs” reflects vendor and shareholder expectations, not clear user demand.
- Many anecdotes of users turning off Copilot/AI features and distrusting AI-infused platforms, especially for sensitive tasks.
Alternatives and Standards Process
- Suggestions: keep AI support low-level (WebGPU-style), or use libraries like WebLLM rather than standardizing a high-level prompt API now.
- Some see this as another example of Google using Chrome’s dominance (after FLoC, Privacy Sandbox, WEI) to push self-serving standards; others say early shipping plus iteration is how web standards often mature.
- Broader frustration about browser monoculture, DRM, attestation, and lack of truly user-controlled browsers underpins the debate.