Mozilla formally designated the Prompt API as 'harmful' — their strongest negative signal — arguing that a web standard must produce the same observable behavior across independent implementations. Since Chrome would ship Gemini Nano while Firefox would need a different model with different outputs, the same prompt would produce different or contradictory answers across browsers, violating the core principle of web interoperability.
The Firefox developer relations team amplified Mozilla's position on Mastodon, reinforcing that the Prompt API fails the basic test of what constitutes a web standard — two implementations cannot produce equivalent results when the underlying models differ in weights, training data, and capabilities.
The editorial frames Google's Prompt API as part of a broader 'Built-in AI' initiative to embed Gemini Nano into Chrome, offering developers zero-cost local inference with no API key. This creates a competitive moat — developers building against Chrome's AI get capabilities that other browsers cannot replicate equivalently, effectively locking the ecosystem to Chrome.
By surfacing the proposal on Hacker News where it received 619 points and 222 comments, the submission highlights the significant developer interest in the API's promise: calling ai.languageModel.create() for local inference with no server round-trip, no API key, and no per-token cost — a compelling developer experience that has attracted attention even in Chrome's early Canary/Dev flag implementations.
Mozilla has formally designated Google's proposed Prompt API as "harmful" — the strongest negative signal in Mozilla's standards-positions framework. The ruling, filed as [issue #1213](https://github.com/mozilla/standards-positions/issues/1213) in Mozilla's standards-positions repository, targets Chrome's "Built-in AI" initiative, which aims to expose on-device large language models to any web page through a JavaScript API.
The Prompt API, part of Chrome's broader push to embed Gemini Nano into the browser, would let developers call something like `ai.languageModel.create()` and then `model.prompt("...")` to run inference locally — no server round-trip, no API key, no cost per token. Google has been shipping early versions behind feature flags in Chrome Canary and Dev channels, and the API has attracted significant developer interest.
Mozilla's "harmful" designation is not a suggestion — it's a formal signal to other standards bodies that Firefox considers this proposal fundamentally unsuitable for the web platform. The position has drawn massive attention, hitting 619 points on Hacker News and sparking heated debate across developer communities.
### The standardization paradox
The deepest technical objection Mozilla raises cuts to the heart of what a web standard actually is. A standard works because two independent implementations produce the same observable behavior. `fetch()` returns the same response structure whether you're in Chrome, Firefox, or Safari. `document.querySelector()` traverses the same DOM.
A prompt API fundamentally cannot provide this guarantee. Chrome ships Gemini Nano. Firefox would ship... what? A different model with different weights, different training data, different capability boundaries, and different output distributions. The same prompt fed to Chrome's model and Firefox's model would produce different — potentially contradictory — answers. This isn't a minor interoperability gap like CSS rendering differences. It's a category error: the API's output is inherently implementation-dependent in a way no previous web API has been.
For developers, this means code that "works" in Chrome might produce nonsensical results in Firefox, not because of a bug, but by design. Feature detection doesn't help when the feature exists but produces arbitrarily different outputs.
### The moat question
Mozilla's second major objection is strategic, and it's harder to dismiss than it might seem. Google doesn't just happen to have an on-device model ready to ship — it has Gemini Nano, purpose-built for edge deployment, backed by Google's training infrastructure, and already integrated into Android and ChromeOS.
No other browser vendor has an equivalent on-device model, which means standardizing this API effectively standardizes Google's competitive advantage. Apple could theoretically ship its own models through Safari, but Mozilla — an organization that runs on a fraction of Google's resources — would need to either train, license, or integrate a comparable model into Firefox. The API becomes a standard that only one vendor can meaningfully implement.
This echoes a pattern web developers have seen before. ActiveX gave Internet Explorer capabilities no other browser could match. Flash gave Adobe outsized influence over web multimedia. In both cases, proprietary capabilities masquerading as platform features created developer lock-in that took years to unwind.
### The safety surface area
Exposing raw LLM access to any website opens a safety surface that's qualitatively different from existing web APIs. Any page — including malicious ones — could use the browser's built-in model to generate phishing text, craft social engineering attacks, or produce harmful content, all running locally with no server-side monitoring or rate limiting.
Google's counterargument is that on-device inference is actually *more* private than sending user data to cloud APIs. That's true in the narrow sense of data transmission, but it sidesteps the content generation risk. The safety guardrails would vary by implementation, and there's no mechanism in the proposed standard for consistent content policy enforcement across browsers.
### What the community thinks
The Hacker News discussion reveals a genuine split. One camp sees Mozilla as protecting the open web from another round of Google platform capture. The other camp sees Mozilla as an increasingly marginal browser vendor blocking innovation it can't compete with — a standards body wielding process as a substitute for product capability.
Both sides have a point. Mozilla's technical arguments about interoperability are sound. But there's also an uncomfortable question: if Mozilla had its own on-device model, would the standards position be different?
The more pragmatic developer response focuses on the alternative Mozilla proposes: task-specific APIs. Instead of a raw prompt endpoint, Mozilla argues the web should standardize APIs for specific capabilities — translation, summarization, rewriting — with well-defined inputs, outputs, and quality baselines. These could be implemented with different underlying models while still producing comparable results, because the success criteria are constrained.
If you've been experimenting with Chrome's built-in AI APIs behind feature flags, this is a clear signal: don't ship production features against these APIs yet. Without cross-browser support, you're building on a Chrome-only capability that may never reach the broader web platform. That's fine for Chrome extensions or PWAs targeting Chrome specifically, but it's a non-starter for general web applications.
The more durable bet is the task-specific API approach Mozilla advocates. Chrome already ships a Translation API that has broader standards support. If Google repositions its built-in AI work around constrained task APIs rather than raw prompt access, the path to cross-browser adoption gets much shorter. Watch for movement on the [Translator API](https://developer.chrome.com/docs/ai/translator-api) and [Summarizer API](https://developer.chrome.com/docs/ai/summarizer-api) — these have a better chance of achieving multi-vendor consensus.
For teams building AI-powered web features today, the practical architecture remains unchanged: use server-side AI APIs (OpenAI, Anthropic, Google Cloud) with your own safety layer, and treat browser-native AI as a progressive enhancement at best. Client-side inference via WebAssembly or WebGPU (running models like Phi-3 or Llama via libraries like Transformers.js) gives you more control and works across browsers, albeit with more engineering effort.
This fight is really a proxy war for a larger question: who controls the AI layer of the web platform? Google is betting that embedding AI into the browser — like it embedded V8 for JavaScript — will make Chrome indispensable for the next generation of web apps. Mozilla is betting that the standards process can prevent a repeat of the IE6 era, where one browser's capabilities became the de facto platform.
The likely outcome is a compromise neither side loves: task-specific APIs that constrain the interface enough for cross-browser implementation, while Google continues to offer the raw Prompt API as a Chrome-proprietary extension. Developers will route around the standards debate the way they always do — by shipping what works for their users, on whatever browser those users actually run.
^ didnt realize who posted the opposition - this is Jake Archibald, a longtime googler on the Chrome team, now joining Mozilla and posting opposition to the Chrome API. no wonder the criticism is so well argued. most be a relief to not have to toe the party line on this one.
I am against this.1) This will be a new source of fingerprinting information and this is difficult to fake to fool fingerprinting scripts, so it can be abused for "device verification". There should be no ability to "verify" a browser, and anyone should be able to emulate any bro
> Browsers and operating systems are increasingly expected to gain access to language models.[0]Are they?[0] https://github.com/webmachinelearning/prompt-api/blob/main/R...
Why is it that Google is fixated on bolting on ever more junk and turning browsers into Homermobiles[0] instead of putting those vast resources towards fixing the numerous structural weaknesses in everything that browsers are already capable of? Why not focus on foundational things that will improve
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
The objections seem clear: tight-coupling of prompts to models, and model neutrality in the TOU.From https://github.com/mozilla/standards-positions/issues/1213 :"A personal example: I created a system prompt for creating announcements for a home automation system.