Live data from Hacker News

Mozilla's opposition to Chrome's Prompt API

github.com

81–90 of 248 posts

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

#81

Earlier quoted context omitted.

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

No, you don't understand. LLMs will never be capable of knowing what questions to ask, only how to ask the questions. /s

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

#82

Extremely glad to see Mozilla taking a stance here.

28th of april 2025, isn't this before mozilla added lots of AI feature in their browser?

The objection is not anti-AI. It’s anti this specific API, for nuanced web compatibility reasons.

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

#83

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…

It's somehow even worse when you compile your own browser. Want Spotify or Netflix? You need Widevine with attestation. Go pay Google.

Your Browser Agent string isn't Chrome or Firefox? Enjoy endless Cloudflare captchas or just a 403 error.

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

#84
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."

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

#85

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…

You have a decent browser. The average person has Chrome. Those who do care switch to the former. What needs to be solved?

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

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

#86
post #75

Earlier quoted context omitted.

I think the objection here is unrelated to the love or hate of LLMs. It's about the viability of this particular proposed open web API. 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.

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

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

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

#87

Earlier quoted context omitted.

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.

This channel should definitely get more visibility ;)

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

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

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

#89

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…

You have a decent browser. The average person has Chrome. Those who do care switch to the former. What needs to be solved? > 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 contro…

I understand what you’re saying, though there’s a quote that hurts me whenever I try and reason about it this way, which is:

"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”

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

#90

Earlier quoted context omitted.

You have a decent browser. The average person has Chrome. Those who do care switch to the former. What needs to be solved? > 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 contro…

I understand what you’re saying, though there’s a quote that hurts me whenever I try and reason about it this way, which is: "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”

You don't have to be indifferent. I think making GNU etc. more accessible for the person who is average except that they prefer control is noble.
Post reply on HN