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.
^ 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.
Aww thanks! To be fair I didn't toe the party line when I was at Google (imo). Although, that caused me increasing amount of grief internally, until I left. From what I hear, things have gotten exponentially worse in that regard for folks still on the team.
Hey, Jake, not related with your post, but I just want to say that HTTP203 were one of the best web dev content that I've ever consumed. Amazing mix between humour and tech discussion. Thank you!
Aww thanks for saying that! I've been doing little videos on https://www.youtube.com/@FirefoxWebDevs (and accounts of the same name, pretty much everywhere). Although they're designed to be short, so they're pretty different to HTTP203.
"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."
If that was a good argument to not support an LLM feature, then it would be a reason to not add it to any platform API. And yet, it has been added to numerous platforms already.
Different models are just a core aspect of how the technology works.
It's like a canvas can have different possible width and height depending on the device or it's orientation. Or the geolocation API giving more or less accuracy depending on the device. Or Speech Synthesis sounding different depending on the device.
This is really just anti-AI sentiment rather than being constructive.
For now, it needs a permissions UI if it doesn't already have one. And maybe at some point they will add a n IQ level like low, medium, high or something. But developers are going to rely on the specific model 90% of the time anyway if they care about it.
What's going to change is really just that the AI hatred will die down some as people realize how much it helps them, and people will realize not having this feature in Firefox is a failure for personal data autonomy.
And the TOU that are related in Chrome being problematic is an argument FOR Firefox to add this feature, without problematic model terms.
We have different gps reliability per device because they have actual hardware doing that.
Why exactly couldn't models, iq levels, tuning and system prompts be interchangeable in an API for this? Why not let users and devs pick which model to bring or point to one they're paying for, or what have you?
I don't see a world where 90 percent of users of this API pick the same underlying model. It doesn't seem like there's any kind of centralization with ai like that yet.
The important part was the following paragraph(s) that explained why this coupling is a compelling problem. It's not the same as just having a platform API.
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?
We start by not shipping Chrome with "native" applications instead of learning the platform APIs.
Followed by creating Web applications based on Web standards, instead of whatever Chrome does, and then complain about Firefox and Safari not being up to the game.
I really don't see how Electron is connected here. When you're an Electron app, you really don't have to care about which web APIs Chrome implements, you can just use the native NodeJS equivalents, which will usually give you a better UX anyways.
But absolutely on the second point. A standard with one implementation is not a standard. Regardless of market share, in a market with three providers, if two out of three don't support something, you have no business using it. It unhealthy for everyone involved.
If those devs cared about Web standards, it would be a pure Web application, or an headless executable, system/daemon conecting to the system's browser.
I'm not saying the Electron UX is better than a native app. I'm saying Electron apps using NodeJS libs have better UX to Electron apps using Web APIs. At best there's no difference for the user, but at worst, they get permission popups and limited access just like they would in a browser.
This is why Electron app devs prefer NodeJS libs to Web APIs and consequently have no impact on the adoption of a large chunk of the new Web APIs (not counting DOM and CSS things because those are rarely controversial and usually broadly implemented).
So yes, those devs don't care about these kinds of new web "standards", because they don't work with them.
The people who use them are the ones who are dangerous and that's almost exclusively web app authors, because they can't just pull in a native library to do the same things.
I think this is the wrong way. I don’t want my OS or browser to have access to an LLM, but I do want my LLM to have access to a browser or OS (and they already have).
So they should provide an interface to LLMs, disabled by default, enabled when users want it, and that’s it imho.
That also gives me the choice of which LLM provider to use, rather than being locked in whatever LLM Apple decided to do put in their OS.
I want to give Claude access to the stuff Apple Intelligence has access to, for example.
Wow. I had no idea that people would misinterpret what I was saying in this way. I was not meaning to imply it was an expectation of users or developers. I was meaning it as a statement of what was currently a growing industry trend by OS and browser vendors, of shipping or preparing to ship LMs.
By now the statement could probably be amended from "expected to gain access to" to "shipping with".
I hope the team maintaining the project now makes such an update, since apparently it's confusing so many people!
Sure. macOS, iOS and Windows have local model APIs for third-party devs. Chrome is trialing it. Firefox uses models to generate alt-text, but no API.
In theory it's useful. If devs can rely on local models, it's more private and decentralized, they don't need to funnel money to AWS or Anthropic. There are low-stakes use cases that only make sense if they're local (available offline) and free.
But in practice I've seen zero adoption of Apple Foundation Models in native apps. I wonder if any Mac/iOS devs have anything to share on this.
In practice it’s useful too. The local translation in Firefox is quite good, and I love that I can translate pages entirely on my machine; without the contents going to another server.
As for Apple foundational models, I think the issue is more that they’re just not very intelligent or good; maybe WWDC will change that; but if you want to implement LLM functionality, you’re better off either calling an API, or shipping a better small on device model.
Yeah I looked into the Apple Foundation models and was surprised at their limited scope. On reflection it made sense though. They’re giving you the small part of the LLM capability surface that (1) can run with good performance on all their hardware and (2) works reliably.
It’s not enough for a chat-first research agent, but it’s definitely enough to unlock features that rely on natural language understanding. Seems like a small thing compared to Claude/ChatGPT and the general hype, but still magic in its own context.
I don't think thus is what was meant. I don't think they were questioning if OS and browser makers were embedding llm features but rather if people want them.
I find many frustrating. I had an iphone previously and the llm summaries of text messages are what drove me to finally drop ios. I have a family member who is undergoing cancer treatment. I can't explain to you the frustration of seeing wrong text summaries when an llm goes wild hallucinating test results when the actual text simply said taking a test. OS basics and communication should be trustable. Not perhaps hallucinations of a small shitty model.
Their whole argument is based on this sentence. So I'd expect some rationale. Instead, they provide as "example" links to Google, Microsoft and Apple. The funny thing is that the one by MS is probably the most criticized one, with the company partly backpedaling on it. And Apple is often criticized by LLM aficionados for being quite conservative. Google is the one proposing it.
So my question is: are browsers and operating systems really expected to gain access to language models? If so - by whom: the users or LLM vendors like Google?
That “are expected” is a euphemism for “are shoehorning AI in and trying to shove it down users’ throats”. Whereas the truth is nobody (actual end users, that is) wants it.
I hate having to “dodge” all the AI-enabled controls my phone (iOS) is sprouting - I don’t need that shit, but there’s also no alternative.
It's the typical "cart before the horse" kind of corporate tech talk. It's pretty standard if Silicon Valley wants to sell shit that nobody actually wants; they just assume that people will want it, regardless whether or not they actually want it. Most of the tech press is too obsessed with retaining their "access" to actually be critical of this sort of thing, and most of the regular press doesn't care enough to actually investigate.
We've seen this sort of song and dance before, crypto jumps to mind. Remember when social media sites suddenly were all about those hexagonal avatars? Most of this stuff is really in that same vein.
(Which to be clear, users don't want this. AI pushes by pretty much all recent user feedback metrics are largely tiring out users and reek of corporate desperation to sell shit. It's only a very specific subsection of Silicon Valley that wants to stuff AI in everything like this.)
These features are enabled by default, and in the case of iOS/macOS, desktop Chrome, probably also Copilot+ PCs, download 4 - 7 GB local models without properly explaining this to users. This doesn’t confirm any demand because if you just don’t use the features and don’t fill up your device, you may never notice.
I think this API is probably fine, but only if the user already has a model downloaded and wants these features. Naturally, case in point, Chrome quietly downloads Gemini Nano without any opt-out except through group policy. Things like this and Microsoft’s recent admission that they’ve overindexed on Copilot features in Windows make it increasingly difficult to trust that users actually want more than a few killer AI features, most of which are just ChatGPT.
Anecdotally, non-technical friends and family members know about ChatGPT and increasingly Gemini, get frustrated by Copilot, and don’t know Apple Intelligence exists.
The word "expected" is a weasel word in this context, especially given how muck backlash MS has received. I'd expect a link to a study where users say: "I'd like to have an LLM integrated with my operating system and my browser" and how it changes over time. Then you can seriously argue for "increasingly expected".
What this proves is that browsers and operating systems are increasingly integrating language models, not that they are expected to do so.
The only people who expect them to do so are big tech executives. The average user does not expect nor want Copilot shoved into every possible corner of Windows, and Microsoft themselves have acknowledged this.
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.
They said that ideally we give more time for this to shake out rather than head-long into a bad API that will need to be changed later anyway, and offered the extension route as a sort of proving grounds for the concept.
If the glaring hole is that there is no way to find out which model you’re promoting without asking the model to answer that for you, that seems like a pretty easy hole to fill IMO.
Right and that means people have to send their data to an external service.
Give it X months (or years??) and people will realize this is actually a privacy/data autonomy issue.
It's just dominated right now by the anti-AI/anti-technology sentiment in the west. That will gradually go away as more people use AI and robotics and realize how wrong they were about it.
So I guess the question would be, "What makes this acceptable Tech". I don't know how you get there without offering some type of "Search" like choice for open models. We all know how that turned out.
Maybe Mozilla can save itself by getting paid to serve Google's model as default rather than another providers. Would replace the revenue stream they lost.
Meaning you do not want text generation in the web API at all, or you think the prompt API needs to be different? And if so can you give one sentence on how it should change?
If you glance at that then you may see that I am for the idea of leaner alternatives to the current web platform.
But in the context of the existing web API which has just about everything and the whole kitchen sink in it (hundreds of sub-APIs), I do not think it will really help anyone at this point just just stop adding features, especially major ones.
The web is basically an overlay operating system and has been for many years.
> Meaning you do not want text generation in the web API at all, or you think the prompt API needs to be different?
Not OP but I think you are misunderstanding the interaction as a whole here. The Chromium team made a proposal, then the Chromium team asked the Firefox team for a position on the proposal. Whether or not the Firefox team or anyone on the Firefox team has any goals around AI or whatever, this response was simply "We do not like this proposal for these reasons..."
How to fix those issues really isn't the Firefox team's job and also wasn't part of the question asked by the Chromium team.
You didn't read my comment carefully enough. It was not about AI in general. It was about the text generation API. And it is perfectly reasonable to ask if he wants to reject the feature entirely or if he can give a one sentence overview of how it might be fixed.
There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable ask.
> There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable ask.
I do think it is a bit unwarranted, actually. This isn't a press release, it's a technical discussion somewhat deep into a technical process that's open for archival purposes. His audience is not people skimming through, it's the Chromium team and other members of the standards body.
You're sort of overhearing a conversation and injecting yourself into it.
And so are you injecting yourself and objecting to me even discussing on HN.
And this is not really a technical issue. It's a worldview issue no matter how much you or others try to pretend it's a technical problem or that I am violating etiquette or something.
> And this is not really a technical issue. It's a worldview issue no matter how much you or others try to pretend it's a technical problem or that I am violating etiquette or something.
I'm actually so curious what you think is going on here
A little off-topic, I honestly don't think it's as much as the browser interface that needs to be reworked as it is the idea of operating systems in general.
I don't know what the right answer is, but having used Niri/Wayland vs. GNOME vs. Windows vs. Mac... I will never go back to a non-tiling desktop and a none-kb driven workflow for desktop window management.
Young people love AI when it helps them cheat homework, or when used for roleplay and memes. Generating "content" with AI - is generally more hated, especially art and video.
Funnily enough, most of the young people I know fall somewhere between those two sides of the spectrum.
I know some actual luddite-tier AI haters that believe it's ontologically evil, and another majoring in Data Science that went to the most recent career fair and told a recruiter "AI will replace you" (I uh don't think he's getting that internship)
And of course many, many, others that fall between the two extremes.
The one thing we can all agree on, is it makes homework a hell of a lot easier :) (well, except the luddite-types, they refuse to use it in any capacity)
The biggest irony with telling a recruiter they'll be replaced, is how much easier a data scientist is to replace with LLMs. With their sycophantic nature, execs will eat up whatever "data" the LLMs make up, too.
I'm a member of a political action committee, where I was brought in as an expert in professional media applications of AI. I've got extensive experience using AI tools in the production of well known entertainment properties (think VFX for film and animation.) Anyway, within the political action committee where is a diverse mixture of people, with about 1/5th of them under age 30. The entire under age 30 set are so AI negative, to such an irrational degree, I have been asked to do nothing and offer no advice that incorporates any technology at all. They are so paranoid. In a not really emotional discussion, a bunch of them erupted in tears, they are so irrational about it.
Do they really? Hating on AI slop is a common sentiment on social media, but remember that the opinions you see on social media are often not representative of what the general population thinks at all.
I keep hearing stories about how homework is now useless because every student just gets ChatGPT to do it for them, and from personal experience, I'm inclined to believe them.
I don't believe every student uses a calculator to solve their math homework, so what makes ChatGPT unique here? For certain subjects the ability to cheat has been trivial for a long time, yet there was no crisis.
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?
The Prompt API has some advantages like being a little simpler for some things and some potential to standardize a little bit more in some way, but it looks like from this that it will be delayed unfortunately.
However, WebLLM (a library, not actual Web API) https://github.com/mlc-ai/web-llm is more capable and will already work using WebGPU.
Archibald is anti-AI. 70+% of his public statements have demonstrated that.
He is more or less aligned with the current most common sentiment in the west which is largely publicly against AI.
But realistically it's just slow adaptation, network effects, etc.
To give an example, before the MLB rolled out the Automated Ball Strike system this year, last year maybe 65+% of the sentiment in discussions about it was negative or in some cases just neutral.
Now that it has rolled out, 95% of the sentiment online about ABS is positive. The main comment by far is, why didn't they do this before, and why don't they do it automatically on all pitches now.
There are certain cognitive and informational flow limitations in society that will cause this to be delayed, just like all major technological advancements.
But once it rolls out, the perspective you hear online will be about digital sovereignty/personal data autonomy, now we aren't required to send our data to an external provider for AI, why wasn't this available before. People will probably assume it was blocked because it reduced a major source of data for advertising or something.
And overall AI and robotics in the future will be seen as the greatest enabling factor for increased equality in society.
It's really just this underlying dislike of and disrespect for technology that much of the western public has. Which may turn out to be one of the reasons that we lose our de facto leadership position in the world.
> 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.
I think it was subsumed by later developments (javascript), but the issue with it AFAIR was just that it wasn't useable in all browsers, not that the tag per se was a bad idea (as much as scrolling text can be).
The situation with the model api seems different, more like the AMP spec.
I’m kinda terrified by the security implications of the Prompt API.
This is a way for web services to make your computer complete large amounts of compute at their behest. Tokens have value. There will be incentive for bad actors to use your local LLM for their own purposes, much like hostile crypto mining payloads.
This is an obvious target for prompt injection attacks and other malicious remote code execution. In many ways, model prompts ARE programs. The browser / local device would need to provide an LLM with the same sandbox guarantees as the rest of the browser. Can they be trusted to do that? Does anyone understand this well enough to do that with confidence?
I’m a big fan of local models, but I would be very cautious about letting random websites call the model I’m hosting on my local machine with open source software.
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.
(Former Chrome team member who worked on this API, now retired.)
There was such a process! They shipped as first Dev Trial around 2025-04, then Origin Trial in 2025-05. Since then a number of people tried it and gave lots of feedback, leading to model quality improvements, language support expansion, API additions like structured responses and tool use, etc. You can find a lot of feedback and case studies if you search around.
> 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.
Chrome is not that good anymore compared to other browsers.
I switched long time ago and if the doesn't work with basic features I just leave the site out instead of letting it use chrome to control me
Being a web developer was not fun; and the web was absolutely being held back. Chrome did a lot of things right: per-origin sandboxing, properly implementing web standards, V8, developer tools, and back then Chromium was super close to Chrome.
Do I think Chrome is a net-negative for the web over the past ~3-5 years? Yes, especially with manifest v3, “privacy sandbox”, and them basically forcing through web APIs because they have the dominant marketshare.
But early Chrome was a technologically impressive and user-friendly browser that really did make the web massively better.
I remember happily putting Firefox and Chrome mini-banners (what are they called? Those little rectangular images) on my website, for free, because I recommended it.
The one you're using every day filled with web apps that runsl securely without you dowloading sketchy binaries or being locked into walled garden app stores.
For anyone working in the web area during the old IE days will know, not having to have a dedicated css and js for each browser type was a gamechanger.
Chrome's introduction, albeit through smoother, lighter browser experience at the time, pushed other browsers to standardize to google.
In one way it's bad to have a homogenous approach to all things web based, but in another way it did make the internet a better experience overall.
In the horror days of IE, I remember having to look up some DirectX filter to properly display PNG images with transparency. It was that bad, and that’s one example of 1000.
Some libraries/scripts helped normalise things a little, but never enough. Yuck.
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.
I was formerly the design lead / spec editor for this API while I worked at Google. I retired in 2025-09, before it got shipped. The following contains no inside knowledge.
I am sympathetic to all of Mozilla's concerns here, even though on balance I believe Chromium's decision to ship was the right one.
---
On interoperability, I agree that this is a tough case. But I am more optimistic than Mozilla that developers will use this API in a way that can work across different models.
First, they will be somewhat forced to, because Chrome will change the model over time. (It already changed from Gemini Nano 2 to 3, and I suspect it'll change to 4 soon if it hasn't already.) Edge is already shipping a Phi-based version. A small number of users are using other models via extensions like https://aibrow.ai/. And it's very possible Safari might join the party, exposing the Apple Foundation Models that ship with iOS via this API. (When the Foundation Models API came out, we were struck by how similar it was to the prompt API designs that preceded it, and were hopeful that Apple was going to do a surprise announcement of shipping the prompt API. It hasn't happened yet, but I still think it might soon.)
Second, we designed the API to steer developers in that direction as much as possible, e.g. encouraging the use of structured output constraints. There are also lots of clear error paths, that almost force developers to use this as a progressive enhancement. (E.g., the existence of low-memory/disk space devices.) So it's very unlikely we'll see developers build sites that are gated on this API existing. It'll mostly be used to sprinkle some AI magic, or let users do cool things without entering some cloud API keys.
I made similar arguments for the writing assistance APIs at [1]. As I said there, the prompt AI is trickier than the writing assistance APIs. But I believe it's a difference of degree, not kind. The web has many nondeterministic APIs that access some underlying part of the system, from geolocation to speech recognition/synthesis, all the way up to these AI-based ones. The question is where you draw the line. Mozilla seems to be giving some signals (not yet definite) that translation is on the OK side of the line, but summarization/writing/rewriting/prompting is not. That's a very reasonable position for them to take on behalf of their users. I imagine the Chromium project is hoping that over time, in-the-wild experience with these APIs shows that the benefits outweigh the risks and costs, and so Mozilla (and Apple) follow in shipping them as well. That's definitely happened in other cases, e.g., Mozilla recently indicating interest [2] in implementing WebBluetooth, WebHID, WebNFC, WebSerial, and WebUSB after years of taking a wait-and-see attitude.
You can learn more about my general thoughts on this question of shipping APIs first, and how the Chromium project takes on first-mover risks, at [3], which I wrote during my time on the Chrome team.
---
On the prohibited use policy, I agree that this is just absurd on Chrome's part. This is not how web APIs should work. It smacks of lawyers trying to throw something out there to cover themselves, or of corporate policy being set at the top level for "all AI uses" and then applied even for web APIs where that makes less sense.
The only saving grace is that I suspect it won't actually trigger. Because, as Mozilla points out, it's quite impractical to enforce. But it's still wrong.
I hope Chrome changes this, although I'm not holding my breath.
I did find it interesting that Gemma seems to have a similar terms of use [4]. (Open-weights, not open-source!) As do the Apple Foundation Models in iOS [5]. So unfortunately if the Chrome team were to push for a no-TOS API, they might be forging new ground, which is always difficult in a large company.
---
On the issue of insubstantial developer signals, I think this is just a failure of the current Chrome team in terms of collecting and collating signals. If one pokes around and knows where to look in various threads, you can find a lot more positive signals than the outdated ones in [6]. I wouldn't have let that Intent to Ship get out the door without properly updating that section of the explainer, for sure. (But hey, not my job anymore!!)
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?
It's exhausting having such reflexive thoughtless ragging anytime Chrome is mentioned.
Oh no! Chrome is trying to enhance user agency again! Oh no! Chrome is trying to make the web better for end users!
Mozilla's concerns aren't totally bogus, I'm not going to try to laugh them out of the room. But their pearl clutching & belly-aching about "oh no what if not all implementations of ai prompts work exactly the same" feels fucking tired and weak sauce to me.
This post really doesn't deserve our attention, my my view. But I'd challenge the haters to at least try to connect their reflexive hate meaningfully to what the topic at hand actually is, to provide something worth considering in some way. But that I think asks too much, for what posts like this seek: merely to inflame the world.
It's not pearl clutching to suggest that websites will build around quirks of a specific model and then we'll be stuck with it forever. This is an issue for future Google as much as it is for Mozilla and Apple.
We had WebSQL which defactor relied on a specific DB implementation, sqlite, and I suspect it also essentially couldn't be updated because people relied on the quirks of a specific version of sqlite.
Oh no, Chrome is adding something that shouldn't be in the browser in the first place.
Oh no, Chrome is adding Googles own AI as only possibilty what surely doesn't hinder competition.
Maybe you shouldn't reflexivly defend Chrome when they clearly abuse their market leading position to push their own AI.
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.
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)
It doesn't make sense at all. So as a user how do you choose which model to use? There could be 3824 models to choose from. The browser might as well set one as default, and we all know how that goes (see: search engine).
Not to mention many other UX questions the come with this, most importantly, how unusable these local models are on regular 3-year old laptops that are constrained in RAM, GPU/CPU capability and likely disk space despite what enthusiasts say here. (They have a Macbook Pro with 32+GB of RAM, reports it works great with xyz model -- fine -- but somehow thinks it works for everyone and local models are the future.)
The Chrome model requires either "16 GB of RAM or more and 4 CPU cores or more" or "Strictly more than 4 GB of VRAM", and "22 GB of free space" (it uses around 4.4GB but it doesn't want to use the remaining free space).
The model is pretty slow on my M4 Pro mac.
The API allows the browser to use a cloud service instead, but then privacy is lower. So, more privacy for the rich.
> It doesn't make sense at all. So as a user how do you choose which model to use? There could be 3824 models to choose from. The browser might as well set one as default, and we all know how that goes (see: search engine).
...what's the exact problem here? Believe it or not, most non-tech-savvy users use the search engine just fine.
With regards to search engines, Google paid billions of dollars [0] to become the default on major browsers. I guess GP's implying that something similar might happen with LLMs.
The rate of model development is an issue here. Once there are many cross-origin models, it becomes a fingerprinting vector. Also even the small models are many GBs.
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."
sounds like adversarial mode mocking
Different models are just a core aspect of how the technology works.
It's like a canvas can have different possible width and height depending on the device or it's orientation. Or the geolocation API giving more or less accuracy depending on the device. Or Speech Synthesis sounding different depending on the device.
This is really just anti-AI sentiment rather than being constructive.
For now, it needs a permissions UI if it doesn't already have one. And maybe at some point they will add a n IQ level like low, medium, high or something. But developers are going to rely on the specific model 90% of the time anyway if they care about it.
What's going to change is really just that the AI hatred will die down some as people realize how much it helps them, and people will realize not having this feature in Firefox is a failure for personal data autonomy.
And the TOU that are related in Chrome being problematic is an argument FOR Firefox to add this feature, without problematic model terms.
Why exactly couldn't models, iq levels, tuning and system prompts be interchangeable in an API for this? Why not let users and devs pick which model to bring or point to one they're paying for, or what have you?
I don't see a world where 90 percent of users of this API pick the same underlying model. It doesn't seem like there's any kind of centralization with ai like that yet.
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.
Your Browser Agent string isn't Chrome or Firefox? Enjoy endless Cloudflare captchas or just a 403 error.
Followed by creating Web applications based on Web standards, instead of whatever Chrome does, and then complain about Firefox and Safari not being up to the game.
But absolutely on the second point. A standard with one implementation is not a standard. Regardless of market share, in a market with three providers, if two out of three don't support something, you have no business using it. It unhealthy for everyone involved.
If those devs cared about Web standards, it would be a pure Web application, or an headless executable, system/daemon conecting to the system's browser.
This is why Electron app devs prefer NodeJS libs to Web APIs and consequently have no impact on the adoption of a large chunk of the new Web APIs (not counting DOM and CSS things because those are rarely controversial and usually broadly implemented).
So yes, those devs don't care about these kinds of new web "standards", because they don't work with them. The people who use them are the ones who are dangerous and that's almost exclusively web app authors, because they can't just pull in a native library to do the same things.
Simple. Break up all the big tech corporations via anti-trust legislation. They are the robber barons of our time.
Unfortunately, the answer is pretty much always "real public funding"
> voice out there for the average person and a project that connects with the masses
> they rather engage and connect with things that are "fun" and want less friction rather than freedom and control
Do you see the contradiction? The average person "connects with" less friction rather than control.
"We must all fear evil men, but there is another kind of evil, which we must fear most, and that is, the indifference of good men”
Are they?
[0] https://github.com/webmachinelearning/prompt-api/blob/main/R...
So they should provide an interface to LLMs, disabled by default, enabled when users want it, and that’s it imho.
That also gives me the choice of which LLM provider to use, rather than being locked in whatever LLM Apple decided to do put in their OS.
I want to give Claude access to the stuff Apple Intelligence has access to, for example.
Wow. I had no idea that people would misinterpret what I was saying in this way. I was not meaning to imply it was an expectation of users or developers. I was meaning it as a statement of what was currently a growing industry trend by OS and browser vendors, of shipping or preparing to ship LMs.
By now the statement could probably be amended from "expected to gain access to" to "shipping with".
I hope the team maintaining the project now makes such an update, since apparently it's confusing so many people!
In theory it's useful. If devs can rely on local models, it's more private and decentralized, they don't need to funnel money to AWS or Anthropic. There are low-stakes use cases that only make sense if they're local (available offline) and free.
But in practice I've seen zero adoption of Apple Foundation Models in native apps. I wonder if any Mac/iOS devs have anything to share on this.
As for Apple foundational models, I think the issue is more that they’re just not very intelligent or good; maybe WWDC will change that; but if you want to implement LLM functionality, you’re better off either calling an API, or shipping a better small on device model.
It’s not enough for a chat-first research agent, but it’s definitely enough to unlock features that rely on natural language understanding. Seems like a small thing compared to Claude/ChatGPT and the general hype, but still magic in its own context.
I find many frustrating. I had an iphone previously and the llm summaries of text messages are what drove me to finally drop ios. I have a family member who is undergoing cancer treatment. I can't explain to you the frustration of seeing wrong text summaries when an llm goes wild hallucinating test results when the actual text simply said taking a test. OS basics and communication should be trustable. Not perhaps hallucinations of a small shitty model.
What are you trying to say?
So my question is: are browsers and operating systems really expected to gain access to language models? If so - by whom: the users or LLM vendors like Google?
GP is clearly asking ”Are they?”
I hate having to “dodge” all the AI-enabled controls my phone (iOS) is sprouting - I don’t need that shit, but there’s also no alternative.
We've seen this sort of song and dance before, crypto jumps to mind. Remember when social media sites suddenly were all about those hexagonal avatars? Most of this stuff is really in that same vein.
(Which to be clear, users don't want this. AI pushes by pretty much all recent user feedback metrics are largely tiring out users and reek of corporate desperation to sell shit. It's only a very specific subsection of Silicon Valley that wants to stuff AI in everything like this.)
A lot of these products feel unguided by an “everything must become AI” FOMO movement, rather than actual thoughtful integrations.
Operating Systems: Windows (built-in Copilot), MacOS, iOS (Apple Intelligence)
So it's >90% desktop browser and OS, plus >30% mobile OS.
Yes, I think it's very safe to say "browsers and operating systems are increasingly expected to gain access to language models."
I think this API is probably fine, but only if the user already has a model downloaded and wants these features. Naturally, case in point, Chrome quietly downloads Gemini Nano without any opt-out except through group policy. Things like this and Microsoft’s recent admission that they’ve overindexed on Copilot features in Windows make it increasingly difficult to trust that users actually want more than a few killer AI features, most of which are just ChatGPT.
Anecdotally, non-technical friends and family members know about ChatGPT and increasingly Gemini, get frustrated by Copilot, and don’t know Apple Intelligence exists.
https://superuser.com/questions/1930445/can-i-delete-the-chr...
The only people who expect them to do so are big tech executives. The average user does not expect nor want Copilot shoved into every possible corner of Windows, and Microsoft themselves have acknowledged this.
To me this sounds like the point where people start looking at and developing alternatives to the browser/web.
It’s them articulating clear and logical reasons why the proposed API, in its current state, is bad for web interoperability.
If the glaring hole is that there is no way to find out which model you’re promoting without asking the model to answer that for you, that seems like a pretty easy hole to fill IMO.
Give it X months (or years??) and people will realize this is actually a privacy/data autonomy issue.
It's just dominated right now by the anti-AI/anti-technology sentiment in the west. That will gradually go away as more people use AI and robotics and realize how wrong they were about it.
Maybe Mozilla can save itself by getting paid to serve Google's model as default rather than another providers. Would replace the revenue stream they lost.
I personally use LLMs for coding assistance, and some home automation stuff, but I do not think this particular API is good for the web.
https://github.com/runvnc/tersenet
If you glance at that then you may see that I am for the idea of leaner alternatives to the current web platform.
But in the context of the existing web API which has just about everything and the whole kitchen sink in it (hundreds of sub-APIs), I do not think it will really help anyone at this point just just stop adding features, especially major ones.
The web is basically an overlay operating system and has been for many years.
Not OP but I think you are misunderstanding the interaction as a whole here. The Chromium team made a proposal, then the Chromium team asked the Firefox team for a position on the proposal. Whether or not the Firefox team or anyone on the Firefox team has any goals around AI or whatever, this response was simply "We do not like this proposal for these reasons..."
How to fix those issues really isn't the Firefox team's job and also wasn't part of the question asked by the Chromium team.
There are a lot of people reading his position. One or two additional clarifying sentences to spell it out for people skimming is not such an unreasonable ask.
I do think it is a bit unwarranted, actually. This isn't a press release, it's a technical discussion somewhat deep into a technical process that's open for archival purposes. His audience is not people skimming through, it's the Chromium team and other members of the standards body.
You're sort of overhearing a conversation and injecting yourself into it.
And this is not really a technical issue. It's a worldview issue no matter how much you or others try to pretend it's a technical problem or that I am violating etiquette or something.
I'm actually so curious what you think is going on here
I don't know what the right answer is, but having used Niri/Wayland vs. GNOME vs. Windows vs. Mac... I will never go back to a non-tiling desktop and a none-kb driven workflow for desktop window management.
I know some actual luddite-tier AI haters that believe it's ontologically evil, and another majoring in Data Science that went to the most recent career fair and told a recruiter "AI will replace you" (I uh don't think he's getting that internship)
And of course many, many, others that fall between the two extremes.
The one thing we can all agree on, is it makes homework a hell of a lot easier :) (well, except the luddite-types, they refuse to use it in any capacity)
I keep hearing stories about how homework is now useless because every student just gets ChatGPT to do it for them, and from personal experience, I'm inclined to believe them.
I don't believe every student uses a calculator to solve their math homework, so what makes ChatGPT unique here? For certain subjects the ability to cheat has been trivial for a long time, yet there was no crisis.
That shipped sailed in 2008.
However, WebLLM (a library, not actual Web API) https://github.com/mlc-ai/web-llm is more capable and will already work using WebGPU.
He is more or less aligned with the current most common sentiment in the west which is largely publicly against AI.
But realistically it's just slow adaptation, network effects, etc.
To give an example, before the MLB rolled out the Automated Ball Strike system this year, last year maybe 65+% of the sentiment in discussions about it was negative or in some cases just neutral.
Now that it has rolled out, 95% of the sentiment online about ABS is positive. The main comment by far is, why didn't they do this before, and why don't they do it automatically on all pitches now.
There are certain cognitive and informational flow limitations in society that will cause this to be delayed, just like all major technological advancements.
But once it rolls out, the perspective you hear online will be about digital sovereignty/personal data autonomy, now we aren't required to send our data to an external provider for AI, why wasn't this available before. People will probably assume it was blocked because it reduced a major source of data for advertising or something.
And overall AI and robotics in the future will be seen as the greatest enabling factor for increased equality in society.
It's really just this underlying dislike of and disrespect for technology that much of the western public has. Which may turn out to be one of the reasons that we lose our de facto leadership position in the world.
>> 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.
Like, that sounds daft, but it's not really far from what they're doing here.
[0]. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I think it was subsumed by later developments (javascript), but the issue with it AFAIR was just that it wasn't useable in all browsers, not that the tag per se was a bad idea (as much as scrolling text can be).
The situation with the model api seems different, more like the AMP spec.
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!
This is a way for web services to make your computer complete large amounts of compute at their behest. Tokens have value. There will be incentive for bad actors to use your local LLM for their own purposes, much like hostile crypto mining payloads.
This is an obvious target for prompt injection attacks and other malicious remote code execution. In many ways, model prompts ARE programs. The browser / local device would need to provide an LLM with the same sandbox guarantees as the rest of the browser. Can they be trusted to do that? Does anyone understand this well enough to do that with confidence?
I’m a big fan of local models, but I would be very cautious about letting random websites call the model I’m hosting on my local machine with open source software.
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.
There was such a process! They shipped as first Dev Trial around 2025-04, then Origin Trial in 2025-05. Since then a number of people tried it and gave lots of feedback, leading to model quality improvements, language support expansion, API additions like structured responses and tool use, etc. You can find a lot of feedback and case studies if you search around.
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.
Advocacy (against chromium and its forks) is one way.
Being a web developer was not fun; and the web was absolutely being held back. Chrome did a lot of things right: per-origin sandboxing, properly implementing web standards, V8, developer tools, and back then Chromium was super close to Chrome.
Do I think Chrome is a net-negative for the web over the past ~3-5 years? Yes, especially with manifest v3, “privacy sandbox”, and them basically forcing through web APIs because they have the dominant marketshare.
But early Chrome was a technologically impressive and user-friendly browser that really did make the web massively better.
I remember happily putting Firefox and Chrome mini-banners (what are they called? Those little rectangular images) on my website, for free, because I recommended it.
Chrome's introduction, albeit through smoother, lighter browser experience at the time, pushed other browsers to standardize to google.
In one way it's bad to have a homogenous approach to all things web based, but in another way it did make the internet a better experience overall.
Some libraries/scripts helped normalise things a little, but never enough. Yuck.
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.
I am sympathetic to all of Mozilla's concerns here, even though on balance I believe Chromium's decision to ship was the right one.
---
On interoperability, I agree that this is a tough case. But I am more optimistic than Mozilla that developers will use this API in a way that can work across different models.
First, they will be somewhat forced to, because Chrome will change the model over time. (It already changed from Gemini Nano 2 to 3, and I suspect it'll change to 4 soon if it hasn't already.) Edge is already shipping a Phi-based version. A small number of users are using other models via extensions like https://aibrow.ai/. And it's very possible Safari might join the party, exposing the Apple Foundation Models that ship with iOS via this API. (When the Foundation Models API came out, we were struck by how similar it was to the prompt API designs that preceded it, and were hopeful that Apple was going to do a surprise announcement of shipping the prompt API. It hasn't happened yet, but I still think it might soon.)
Second, we designed the API to steer developers in that direction as much as possible, e.g. encouraging the use of structured output constraints. There are also lots of clear error paths, that almost force developers to use this as a progressive enhancement. (E.g., the existence of low-memory/disk space devices.) So it's very unlikely we'll see developers build sites that are gated on this API existing. It'll mostly be used to sprinkle some AI magic, or let users do cool things without entering some cloud API keys.
I made similar arguments for the writing assistance APIs at [1]. As I said there, the prompt AI is trickier than the writing assistance APIs. But I believe it's a difference of degree, not kind. The web has many nondeterministic APIs that access some underlying part of the system, from geolocation to speech recognition/synthesis, all the way up to these AI-based ones. The question is where you draw the line. Mozilla seems to be giving some signals (not yet definite) that translation is on the OK side of the line, but summarization/writing/rewriting/prompting is not. That's a very reasonable position for them to take on behalf of their users. I imagine the Chromium project is hoping that over time, in-the-wild experience with these APIs shows that the benefits outweigh the risks and costs, and so Mozilla (and Apple) follow in shipping them as well. That's definitely happened in other cases, e.g., Mozilla recently indicating interest [2] in implementing WebBluetooth, WebHID, WebNFC, WebSerial, and WebUSB after years of taking a wait-and-see attitude.
You can learn more about my general thoughts on this question of shipping APIs first, and how the Chromium project takes on first-mover risks, at [3], which I wrote during my time on the Chrome team.
---
On the prohibited use policy, I agree that this is just absurd on Chrome's part. This is not how web APIs should work. It smacks of lawyers trying to throw something out there to cover themselves, or of corporate policy being set at the top level for "all AI uses" and then applied even for web APIs where that makes less sense.
The only saving grace is that I suspect it won't actually trigger. Because, as Mozilla points out, it's quite impractical to enforce. But it's still wrong.
I hope Chrome changes this, although I'm not holding my breath.
I did find it interesting that Gemma seems to have a similar terms of use [4]. (Open-weights, not open-source!) As do the Apple Foundation Models in iOS [5]. So unfortunately if the Chrome team were to push for a no-TOS API, they might be forging new ground, which is always difficult in a large company.
---
On the issue of insubstantial developer signals, I think this is just a failure of the current Chrome team in terms of collecting and collating signals. If one pokes around and knows where to look in various threads, you can find a lot more positive signals than the outdated ones in [6]. I wouldn't have let that Intent to Ship get out the door without properly updating that section of the explainer, for sure. (But hey, not my job anymore!!)
[1]: https://github.com/mozilla/standards-positions/issues/1067#i... [2]: https://github.com/whatwg/sg/pull/264 [3]: https://www.chromium.org/blink/guidelines/web-platform-chang... [4]: https://ai.google.dev/gemma/terms [5]: https://developer.apple.com/apple-intelligence/acceptable-us... [6]: https://github.com/webmachinelearning/prompt-api/blob/main/R...
Oh no! Chrome is trying to enhance user agency again! Oh no! Chrome is trying to make the web better for end users!
Mozilla's concerns aren't totally bogus, I'm not going to try to laugh them out of the room. But their pearl clutching & belly-aching about "oh no what if not all implementations of ai prompts work exactly the same" feels fucking tired and weak sauce to me.
This post really doesn't deserve our attention, my my view. But I'd challenge the haters to at least try to connect their reflexive hate meaningfully to what the topic at hand actually is, to provide something worth considering in some way. But that I think asks too much, for what posts like this seek: merely to inflame the world.
We had WebSQL which defactor relied on a specific DB implementation, sqlite, and I suspect it also essentially couldn't be updated because people relied on the quirks of a specific version of sqlite.
Maybe you shouldn't reflexivly defend Chrome when they clearly abuse their market leading position to push their own AI.
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)
Not to mention many other UX questions the come with this, most importantly, how unusable these local models are on regular 3-year old laptops that are constrained in RAM, GPU/CPU capability and likely disk space despite what enthusiasts say here. (They have a Macbook Pro with 32+GB of RAM, reports it works great with xyz model -- fine -- but somehow thinks it works for everyone and local models are the future.)
The model is pretty slow on my M4 Pro mac.
The API allows the browser to use a cloud service instead, but then privacy is lower. So, more privacy for the rich.
...what's the exact problem here? Believe it or not, most non-tech-savvy users use the search engine just fine.
[0] https://www.reuters.com/technology/google-paid-26-bln-be-def...