Mozilla's opposition to Chrome's Prompt API

jaffathecake 607 points 221 comments April 30, 2026
github.com · View on Hacker News

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?

Semantic search powered by Rivestack pgvector
8,303 stories · 78,303 chunks indexed