Mozilla's opposition to Chrome's Prompt API
jaffathecake
607 points
221 comments
April 30, 2026
Related Discussions
Found 5 related stories in 91.8ms across 8,303 title embeddings via pgvector HNSW
- Chrome looks set to ship an LLM Prompt API to the web. We oppose this API Vinnl · 23 pts · April 30, 2026 · 76% similar
- The Prompt API gslin · 59 pts · April 27, 2026 · 64% similar
- Partnering with Mozilla to improve Firefox's security meetpateltech · 19 pts · March 06, 2026 · 55% similar
- Hardening Firefox with Claude Mythos Preview HieronymusBosch · 126 pts · May 07, 2026 · 50% similar
- Hardening Firefox with Anthropic's Red Team todsacerdoti · 539 pts · March 06, 2026 · 50% similar
Discussion Highlights (20 comments)
shevy-java
> This will result in Mozilla and Apple having to licence Google's model, or ship a model that's quirks-compatible with the Google model in order to be interoperable. It may also become difficult for Chrome to update its own model for the same reasons. Google is again doing Evil. I am very annoyed that Google kind of de-facto controls the www (through chrome, let's be honest here). We really need to change this. I don't have a good solution here, but it can not continue that way.
croes
So the next anti trust case for the EU. Chrome is clearly dominating the browser market and now they try to abuse that (again)
varun_ch
I wonder if it makes sense for browser vendors to agree upon and ship various ‘standard models’ that are released into the public domain or something, and the API lets you pick between them. The models themselves would be standardized and the weights and everything should be identical between browsers. They’d be standard and ‘web-safe’ like CSS colors or fonts. Probably would help to give them really boring/unbranded names too. These would work identically across browsers and web developers can rely on them existing on modern setups. If you want more models, you could install them as a user or your browser could ship them or the web developers could bundle them through a CDN (and another standard for shared big files across domains would probably be needed)
benterix
> 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...
fg137
If every browser vendor already has their experimental APIs that can work with different models, it might be a good idea to standardize this in WhatWG living standards (which would still be bad user experience on today's consumer hardware) But if no browser other than Chrome supports this, and only Google's (proprietary) model (edit: plus Microsoft's Phi-4 mini in Edge), it should be clear it's Google abusing its position. There is nothing worth standardizing. And we have seen that too many times -- FLoC/Privacy Sandbox/Topics API, Web Environment Integrity just to name a few. Google has been relentless in using its dominant position to push terrible ideas that harm both users and other browser vendors but help only Google's business. Surprised this did not really come up in previous discussion in https://news.ycombinator.com/item?id=47917026 PS: looks like Google's fanboys have arrived. Someone better finds good counterarguments, especially technical ones, instead of just downvoting.
OuterVale
Extremely glad to see Mozilla taking a stance here.
jaffathecake
When I posted this, I linked to the latest statement https://github.com/mozilla/standards-positions/issues/1213#i... , which is the content relevant to the title (the details of our opposition to the API). Unfortunately someone removed the link to the specific post.
swyx
^ 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.
austin-cheney
I wonder if this is a generational thing of fresh young people that already cannot live without LLMs versus crusty old people that don’t want to require a super computer just to run a web browser that violates all their privacy. To me this sounds like the point where people start looking at and developing alternatives to the browser/web.
Wowfunhappy
> According to Chrome's documentation, to use the prompt API you must 'acknowledge' Google's Generative AI Prohibited Uses Policy. Elements of this policy go beyond law. For example: >> Do not engage … generating or distributing content that facilitates … Sexually explicit content Do not engage in misinformation, misrepresentation, or misleading activities. This includes … Facilitating misleading claims related to governmental or democratic processes > This seems like a bad direction for an API on the web platform, and sets a worrying precedent for more APIs that have UA-specific rules around usage. I will say this more strongly—I think it is completely insane , and a violation of free expression principles, for a browser API to have content restrictions.
hmokiguess
The nice thing about open protocols is that we don't have to endorse or use one implementation over another, yet, somehow, the browser monopoly continues to be a standing dilemma. There are nice projects, like ungoogled chromium, tor, and many more, but I find the biggest issue is that there isn't a voice out there for the average person and a project that connects with the masses. I think another issue is that a lot of the uninformed users have a strong apathy for the causes and ways the message is delivered, they rather engage and connect with things that are "fun" and want less friction rather than freedom and control. How do we solve this? How do we make the browser ours, by the people, and for the people? Sorry, I'm just sad whenever I think of this.
wg0
This seems like that infamous <marquee> tag [0] to me that felt good and amazing at the time but later turned out not to be a good idea. [0]. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
heresie-dabord
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. The Gemini model I was using initially responded in a very US-American way, which didn't fit the British voice of my speaker. I told the model, via the system prompt, that the output was being spoken in a British voice, but the result was a bad US-American impersonation of British ("a'waight guv'nor apples and pears" etc etc), so I had to iterate further to 'tone it down' and speak actual British. In this process, the system prompt becomes tailored to the model. Other models will have different quirks. Things added to the system prompt for one model may be an overcorrection for another."
moron4hire
Web API features should be things that are necessary to enable features in Web applications. We don't need the browser to have a Prompt API to enable web applications to have goofy chatbots lurking in the corner. WebDevs are perfectly capable of ruining their websites on their own.
the42thdoctor
This reminds me of the speech to text API, which already uses AI and is available on almost all browsers. So there's already precedent. But most importantly this would enable us to finally write JavaScript like this: const a = prompt("how much is 31c in Fahrenheit") The future looks bright!
AntiUSAbah
I find this a weird discussion at the current point. Shouldn't be there a basic process for allowing such an API as a alpha people can play around with and then there will be adjustments? No one will start using this in production if they don't have a very good and specific use case. I mean you don't just run 2gb ML models in your browser today on a massive scale.
economistbob
That discussion has a quote about querying the LLM for version information. If the models hallucinate/make up court citations, work and facts, what makes them believe that the model provided a genuine version number as opposed to an generatively constructed string?
Havoc
Alas we’re in a lovely near monoculture once again.
righthand
So we can’t have XSLT fast and efficient templating syntax but Prompt APIs with potential attack injection vectors are cool as long as they’re generic enough for all megacorps to drop in? No security risks here huh? Not trying to increase the attack surface huh?
xnx
Is this going to be another situation, like WebSQL, where Firefox torpedos a broadly useful feature?