Live data from Hacker News

Mozilla's opposition to Chrome's Prompt API

github.com

141–150 of 248 posts

Re: Mozilla's opposition to Chrome's Prompt API

#141
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.

Re: Mozilla's opposition to Chrome's Prompt API

#142
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.

Re: Mozilla's opposition to Chrome's Prompt API

#143

> 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 go…

Why is Google doing this? They would need to moderate the use of the API, right? What they could gain having to moderate use of a browser's API?

A blank cheque to restrict access to any website they want.

Re: Mozilla's opposition to Chrome's Prompt API

#144

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!

I know you're probably joking, but I was curious how hard it would be.

const cToF = c => c * 9/5 + 32; const a = cToF(31);

Re: Mozilla's opposition to Chrome's Prompt API

#145

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 m…

Yeah I wonder, who says I can't build a "cryptominer like" script that injects into many websites and just uses this local LLM api, performs a request from a queue and sends the response to a server, practically creating my very own LLM botnet?

Re: Mozilla's opposition to Chrome's Prompt API

#147
post #7

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

(I wrote those words originally.) 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 "shi…

I thought it was clear and am also surprised by the reaction (en-US speaker). "Is/are expected" is generally used as a passive-voiced form of "we/they predict" (obviously without having to specify a specific pronoun). E.g. "It's expected to rain tomorrow" means a weather forecast says it will rain tomorrow and usually not that people want it to rain tomorrow.

I wonder if this phrase has different connotations among other English readers? A lot of these comments are fairly early for US timezones.

Re: Mozilla's opposition to Chrome's Prompt API

#148
post #7

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

Apparently the browser API surface is not obscenely wide enough.

Re: Mozilla's opposition to Chrome's Prompt API

#149

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 w…

I just wonder how a highly non-deterministic API like the Prompt API can work in a system that heavily focuses on interop between new and old websites.

What's going to happen is that people build stuff with the current iteration and a few years later a model update will work entirely differently and break the existing implementations. I understand that every once in a while OpenAI also shuts off older models through API but that's a central process.

What if I have Firefox 150 users that haven't updated yet and Firefox 155 users that have different models, while Chrome 160 and Chrome 170 users also exist and have different models. Is it expected that I build entirely different implementations for every browser version out there? Don't the work groups try to prevent exactly that within HTML & CSS through feature gating?

Re: Mozilla's opposition to Chrome's Prompt API

#150
post #116

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

I think every aspect within their opposition is sound and generally to keep the web open and predictable (unlike other oppositions like the Filesystem API).
Post reply on HN