HN

Comments (161)

• Menu

  codedokode
  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 browser. This is the most important point, I thought Google people are smart enough to see it.2) LLMs use lot of memory and CPU time, for many users they would slow down their system significantly, and given current RAM prices, upgrades are very expensive. If the website relies on local model, it would work slow on cheap devices.3) The API seems to be tailored for specific LLM like OpenAI.4) This can be used to push competitors who do not have an AI model from the browser market - the sites would break because they will be made with expectation of having Google Gemini model and would not work with other models. For example, the sites would break in national browsers not having an AI model. There should be no "first-class" and "second-class" browsers.The explainer claims that this would allow the user to process the data locally without sending it anywhere. But why does Google Gemini local model have "Prohobited Use Policy" then? Why should they bother about prompts and responses they never learn about?While offline LLM access seems like a good idea, the website could use WebGPU for this without building LLM into the browser (or they could improve WebGPU for better handling ML models). Or everyone should use the same, open source, LLM.
• Menu

  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.
• Menu

  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."
• herf
  Chrome seems to use a custom inference runtime also (in addition to Gemini Nano). It would be better if this were all interoperable. The WebGPU alternatives like WebLLM do not have the same access.I've been trying these models out for the last year, and it seems to me that we want them to work in a 5-10W "laptop" power envelope, but they really work best with a 50-500W GPU instead - i.e. they eat batteries. This means things work better in a "plugged in" gaming laptop/desktop rather than a typical web client. At least for now.
• isodev
  Google on their proposal:> Browsers and operating systems are increasingly expected to gain access to language models.I think this is only true amongst “AI all the things” folks. Both tech and non-tech people around me are more focused on turning these features off. Some even avoid sensitive actions like banking from LLM infused browsers.So I think Mozilla is right to object. This API is not in the interest of the user/agent.
• Menu

  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...
• Menu

  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.
• Menu

  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.
• Menu

  OuterVale
  Extremely glad to see Mozilla taking a stance here.
• Tepix
  I feel that a LLM that runs locally has its place in a modern browser. The alternative is sending your page contents to a server in the cloud with the associated loss of privacy. Of course issues like fingerprintability and vendor model lockin have to be taken into account. It seems to be too early to carve things in stone, so I agree with Brian Grinstead and the others.
• Menu

  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?
• Menu

  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.
• dbetteridge
  To paraphrase Mean GirlsStop trying to make browser llms happen, they're not going to happen.
• Menu

  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/...
• ilaksh
  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.
• Menu

  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.
• Havoc
  Alas we’re in a lovely near monoculture once again.
• Menu

  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!
• Menu

  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.
• kmeisthax
  My personal opinion is that if we are going to have any amount of AI capability in the browser, it should be something very low-level, akin to WebGPU. Ideally, it would work similarly to Apple's Accelerate framework, where your requests are just routed to whatever AI accelerator the device thinks makes sense, so that we can polyfill using WebGPU compute shaders.If a web developer wants to use a cloud model, with the associated legal requirements and business relationships of that model, we already have a way to do that: Use Fetch API on a CORS endpoint. There's no need to have the browser do cloud model brokering to a model you haven't tested with, run by a company you might not want to actually do business with.
• Menu

  pbronez
  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.
• Menu

  domenicd
  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!!)[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...
• Menu

  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)
• 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=47917026PS: looks like Google's fanboys have arrived. Someone better finds good counterarguments, especially technical ones, instead of just downvoting.
• 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.
• 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?
• aegiswizard
  [flagged]
• Menu

  xnx
  Is this going to be another situation, like WebSQL, where Firefox torpedos a broadly useful feature?
• Menu

  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)