Mozillas Widerspruch gegen die Prompt API von Chrome

• Die Prompt API, die browserinterne Sprachmodelle als Web-API bereitstellt, kann in allgemeiner Form nützlich sein, fördert aber Implementierungen, die auf modellspezifisches Verhalten zugeschnitten sind, und erhöht damit das Risiko für Interoperabilitätsprobleme
• Wenn Entwickler Prompts und Funktionen auf eine konkrete Implementierung wie Edges Phi-4-mini abstimmen, kann es in anderen Browsern oder Modellen zu Qualitätsverlust oder gesperrtem Website-Zugriff kommen
• Mozilla ist der Ansicht, dass vor einer direkten Auslieferung als Web-API zunächst mehr Validierung im Userland erfolgen sollte, und sieht die trial web extension API sowie den web-extension-Vorschlag der Web Machine Learning Group als frühe Kanäle für Feedback
• Wenn sich System-Prompts verbreiten, die auf die quirks eines bestimmten Modells abgestimmt sind, können auch neue Modelle schlecht wirken, und Browser könnten unter Druck geraten, Google-Modelle oder quirk-kompatible Modelle einzubauen
• Chrome nennt als Gegenmaßnahmen JSON-Schema- und regex-basierte Antwortbeschränkungen, Diskussionen in der WebML CG und Experimente mit alternativen Modellen, dennoch ist Mozillas Position zur Prompt API als negative markiert

---

Mozillas negative Bewertung der Prompt API

• Die Prompt API wurde nach dem intent-to-prototype von Blink in Mozillas standards-positions geprüft; der Explainer verweist auf das README von webmachinelearning/prompt-api
• Mozillas Feedback ist fast identisch mit Writing Assistance APIs #1067: Eine Prompt API in allgemeiner Form kann nützlich sein, fördert aber modellspezifisches Verhalten und vergrößert damit das Risiko für Interoperabilität
• Entwickler können Prompts und Funktionen auf ein bestimmtes Modell zuschneiden; wenn sie auf Implementierungen wie Edges Phi-4-mini zielen, kann die Qualität in anderen Browsern oder Modellen sinken oder der Zugriff auf die Website blockiert werden
• Statt direkt als Web-API auszuliefern, sollte die Funktion länger im Userland validiert werden; Mozillas trial web extension API und der web-extension-Vorschlag der Web Machine Learning Group dienen dabei als Wege für frühes Feedback
• Auf Basis der zugehörigen Diskussion und #1067 ist die Position zur Prompt API als negative markiert

Warum Web Extensions gegenüber Origin Trials bevorzugt werden

• Modellauswahl und Timing der Standardisierung

  • Die Funktion, ein genaues Modell aus einem Model Hub auszuwählen, gilt als zentral, weil sie eine Seiteneigenschaft ist und der Browser dabei kein bestimmtes Modell auswählt
  • Diese Funktion setzt Implementierungsdetails in einem sich schnell verändernden Bereich voraus und gilt daher noch nicht als bereit für eine Standardisierung
  • Extensions sind eine niedrigschwellige Möglichkeit, tatsächliche Nutzungsmuster jenseits des aktuell vorgeschlagenen Umfangs schnell zu erkunden und browserübergreifende Funktionen zu testen, ohne die Kosten einer Abstimmung für ein Shipping mit noch nicht gefestigter Semantik über alle drei Engines hinweg

• Für Nutzer sichtbare Grenzen

  • Die Installation eines Add-ons signalisiert dem Nutzer, dass hier eine Grenze gewöhnlicher Webfunktionen überschritten wird; in diesem Fall betrifft das gemeinsam genutzten Cross-Origin-Speicher
  • Diese Einschätzung folgt einer ähnlichen Logik wie die Ergänzung der Position „WebMIDI Add-On Gated“ #704 in einem anderen Kontext
  • Der betreffende Extension-Vorschlag stellt Seiten eine Prompt-ähnliche API bereit und nutzt lokale Inferenz sowie vom Entwickler vorgegebene Modelle, um ein gemeinsam genutztes Model Repository und frühes Nutzerfeedback zu erhalten

Das Risiko einer Verfestigung auf ein einzelnes Modell

• System-Prompts und Modell-quirks

  • System-Prompts werden tendenziell wiederholt an die quirks des jeweils verwendeten Modells angepasst
  • Bei einem System-Prompt zur Erstellung von Ansagen für die Heimautomatisierung antwortete ein Gemini-Modell zunächst sehr amerikanisch, was nicht zu einer britischen Sprecherstimme passte
  • Als in den System-Prompt aufgenommen wurde, dass mit britischer Stimme gesprochen werden solle, kam eine amerikanisierte Imitation des Britischen wie „a'waight guv'nor apples and pears“ heraus; anschließend war weitere Nachjustierung nötig, um näher an tatsächliches britisches Englisch zu kommen
  • Korrekturen für ein Modell können bei anderen Modellen zu Überkorrekturen führen; das Problem verschärft sich bei gebrandeten voices oder Ausgabeformaten, die sich nicht in JSON-Schemas oder regulären Ausdrücken ausdrücken lassen

• Belastung durch neue Modelle und Browser-Updates

  • Wenn System-Prompts, die auf die quirks bestehender Modelle zugeschnitten sind, weit verbreitet werden, können auch bessere neue Konkurrenzmodelle bei Entwicklern und Nutzern schlecht wirken
  • Mozilla und Apple könnten sich für Interoperabilität in der Lage wiederfinden, Google-Modelle zu lizenzieren oder Modelle einzusetzen, die zu den quirks der Google-Modelle kompatibel sind
  • Aus demselben Grund könnte es auch für Chrome schwierig werden, eigene Modelle zu aktualisieren

• Modell-ID-Erkennung und Browser-Verzweigungen

  • Entwickler können mit LanguageModel.create() ein Modell erzeugen und mit model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') nach Modell-ID, Name, Version und Herkunftsunternehmen fragen
  • Ein Beispiel für die Rückgabe ist 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
  • Entwickler können Bündel von System-Prompts für bestimmte Modelle erstellen und unbekannte Modelle blockieren oder Nutzer darauf hinweisen, dass die Ausgabequalität geringer sein könnte
  • Das wird als Rückfall in die Code-Verzweigungen der frühen 2000er-Jahre gesehen, die eigentlich vermieden werden sollten

Googles Richtlinien und das Problem der Modellneutralität

• Laut der Chrome-Dokumentation muss vor der Nutzung der Prompt API Googles Generative AI Prohibited Uses Policy anerkannt werden
• Teile dieser Richtlinie gehen über gesetzliche Anforderungen hinaus; verboten sind unter anderem die „Erstellung oder Verbreitung von Inhalten, die sexuell explizite Inhalte fördern“ und die „Förderung irreführender Behauptungen im Zusammenhang mit Regierung oder demokratischen Prozessen“
• Es ist problematisch, wenn Web-Plattform-APIs in eine Richtung gehen, in der nutzeragent-spezifische Nutzungsregeln verlangt werden; das könnte einen Präzedenzfall schaffen, bei dem weitere APIs UA-spezifische Regeln bekommen
• Wenn ein Nutzer bei einem Artikelkommentar auf „summarize“ klickt und das Ergebnis gegen Googles Richtlinie verstößt, ist unklar, wer verantwortlich wäre: der Nutzer, der den Button klickt, der Kommentator, der den problematischen Inhalt verfasst hat, oder der Website-Betreiber, der die Funktion gebaut hat, um den Kommentar an das LLM im UA des Nutzers weiterzugeben
• Entwickler könnten wissen wollen, mit welchem LLM sie kommunizieren, um Modellbedingungen einzuhalten und rechtliche Schritte des Modellanbieters zu vermeiden; unbekannte Modelle können unbekannte Nutzungsbedingungen bedeuten, sodass eine Blockierung eine rationale Wahl wird
• Es gibt keine Grundlage dafür, dass ein bestimmter Browser solche Bedingungen gegenüber Website-Entwicklern durchsetzt; diese Richtlinienfrage sollte getrennt vom API-Vorschlag selbst behandelt werden

Updates und Gegenmaßnahmen von Chrome

• Das Chrome-Prompt-API-Team teilte das blink-dev I2S sowie ein Update zu Risiken für Interoperabilität und Kompatibilität auf ChromeStatus
• Die Teilnahme und Diskussion in der WebML CG soll fortgesetzt werden; dazu kommen Folgeexperimente wie interoperable sampling parameters
• Chrome erklärt als Motivation, von Browsern und Betriebssystemen bereitgestellte Language Models zu einer nützlichen Option für Webentwickler und Nutzer zu machen und dabei die langfristige Gesundheit und Neutralität der Web-Plattform zu erhalten
• Die Oberfläche der Prompt API habe sowohl mit Google- als auch mit Microsoft-Modellen eine gewisse Kompatibilität gezeigt; zudem würden objektive Antwortbeschränkungen eingesetzt, damit Ausgaben bekannten JSON-Schemas oder regex-Mustern entsprechen
• Diese Beschränkungen dienen als Gegenmaßnahme, um den Bedarf an modellspezifischen Hacks zur Behandlung unvorhersehbarer Ausgaben zu verringern
• Nachgelagerte Chromium-Projekte prüfen alternative Modelle und Framework-Backends, darunter Microsofts Integration von Android MLKit und frühe Prototypen für die Integration von Apple foundational models
• In der API-Trial-Phase wurden experimentell verschiedene Modellversionen ausgeliefert; Modell-Updates und Verbesserungen bleiben notwendig, und auch Unterstützung für neuere Gemma 4 open models wird untersucht
• Zur Feinabstimmung eines stärker interoperablen Verhaltens über unterschiedliche zugrunde liegende Architekturen hinweg werden auch categorical sampling modes untersucht
• Die Formulierung zu Interoperability and Compatibility auf blink-dev besagt, dass Variationen in Verhalten und Antworten für Entwickler, die diese Technologie einsetzen, eine bekannte Erwartung seien und dass diese API auf ein Interoperabilitäts-Framework für einen konsistenten Web-Plattform-Zugang über Browser und Modelle hinweg ziele

Gründe für die Unterstützung durch Webentwickler und Kritik am Shipping

• Das blink-dev intent to ship markiert die Haltung der Webentwickler als „Strongly positive“ und verweist als Beleg auf das stakeholder feedback im Explainer
• Dieser Beleg wird als nicht besonders passend für die Bewertung „Strongly positive“ behandelt

• Aufgelistete Belege

  • Ein GitHub-Thread mit zwei positiven Antworten
  • Ein einzelner Beitrag auf X
  • Ein nicht mehr existierender Blogbeitrag mit dem Status Server Not Found
  • Ein weiterhin verfügbarer Blogbeitrag
  • Eine Umfrage, die Entwickler offenbar fragte, ob diese API auch dann in Ordnung wäre, wenn sie nur in Extensions existierte; Zahlen oder Zielgruppe der Umfrage werden nicht genannt
  • Der verschwundene Blogbeitrag ist über einen Wayback-Machine-Link archiviert
  • Selbst wenn in der Dokumentation deutlich hervorgehoben würde, worauf man sich „nicht verlassen sollte“ und worauf man sich „verlassen kann“, bleibt unklar, ob dann noch genug reale Einsatzmöglichkeiten für die API übrig wären
  • In der Praxis kann man sich bis zu einem gewissen Grad auf das Verhalten des konkret getesteten Modells verlassen; wenn dieses Modell das Chrome-Modell ist, kann eine Website Nutzer einfach zur Verwendung der neuesten Chrome-Version auffordern
  • Problematisch bleibt, dass Google den unfertigen Charakter des Bereichs zwar breit anerkennt, aber die aktuellen Gegenmaßnahmen dennoch für ausreichend hält, um zu shippen

Diskussion in den Kommentaren: Alternativen, Schadensmessung und nachträgliche Abmilderung

• Browser-Automatisierung und Lynx mode

  • Mit Hermes Agent und Qwen3.6 sei der Großteil der Aufgaben möglich gewesen; statt der Prompt API solle man stärker auf browser automation APIs und den Lynx mode für Chat achten
  • Einige Workflows funktionieren so, dass sich ein Mensch auf einer Website anmeldet und per AJAX-Erweiterung Dateien sichtbar macht, woraufhin ein Agent mit chromedriver/webdriver Dokumente herunterlädt, taggt und zusammenfasst
  • Dieser Ansatz könnte ohne externe POSIX-Shell direkt im Browser integriert werden
  • Lynx-mode-Chat legt Inhalte, die Agents sehen, schnell offen und spart auf beiden Seiten Ressourcen, weil nicht alle Medienressourcen heruntergeladen oder gerendert werden müssen
  • Ebenfalls diskutiert werden feinere robots-Markierungen auf HTML-Ebene, ein Handoff zwischen Lynxmode-Shell und klassischem Browser sowie ein agentgesteuerter Browser, der selektiv Links im Stil des alten Google AdWords anzeigt

• Open Web und FOMO

  • Es gibt Widerspruch gegen die Annahme, das Open Web konkurriere auf dieselbe Weise mit Chatbot-Super-Apps oder werde verschwinden
  • Statt ständiger FOMO brauche es eher die Haltung, zuerst zu fragen, wofür man eigentlich stehen wolle
  • Auch der Sorge, dass Commerce oder Journalismus das Open Web verlassen könnten, wenn das Web agentic computing nicht schnell und wirksam genug unterstützt, wird teilweise widersprochen, ähnlich wie das Web auch das Mobile-App-Paradigma nicht vollständig unterstützt hat

• Chromium-Shipping und Schadensmessung

  • Einer der blink API owner approver in Chromium teilt Mozillas Bedenken, bevorzugt aber einen Weg über Experimente, Lernen aus Fehlern und die Förderung von Wettbewerb
  • Um künftige reale Schäden bewerten zu können, müsse man konkrete Ergebnisse definieren; als Kontext wird angeführt, dass es hilfreich gewesen sei, kontroverse API-Entscheidungen wie EME fünf bis zehn Jahre später mit den tatsächlichen Folgen zu vergleichen
  • Der Schaden, wenn Websites auf ein Google-spezifisches Modell festgelegt werden, könne über Anzahl und Umfang der site-compat-Bugs beim Shipping anderer Browser sowie über die Art der Bugs beim Modell-Update in Chrome gemessen werden
  • Es wird vorgeschlagen, Bugs danach zu unterscheiden, ob sie das Modell „intelligenter machen“ oder nur einen „seltsamen quirk bewahren“, und sie gesammelt mit Labels auf webcompat.com zu erfassen
  • Laut blink-dev I2S liefert auch Edge diese API mit einem anderen Modell aus; damit gibt es bereits erste Daten
  • Ein Schadensindikator für Bedenken rund um die TOS wäre, ob es wegen Verstößen tatsächlich zu Klagen oder Drohungen gekommen ist; entsprechende Belege sollten gesammelt werden

• Nachträgliche Abmilderung und Reaktion von Chrome

  • Der Ansatz, mögliche Schäden erst real zu beobachten, ist plausibel, aber nur dann sinnvoll, wenn es nach Eintritt des Schadens noch wirksame Gegenmaßnahmen gibt
  • Für den Fall, dass Websites auf ein Google-spezifisches Modell festgelegt werden, werden Optionen wie feature unship, Modelländerungen, die überangepasste Site-Prompts aufbrechen, random model rotation oder offene Standards für On-Device-Model-Weights als Fragen aufgelistet
  • Falls sich zeigt, dass andere Browser die seltsamen quirks des Chrome-Modells kopieren müssen, werde man aus einer Chromium-Führungsposition heraus darauf drängen, dass Chrome diese quirks bricht
  • Als Präzedenzfall wird genannt, dass Mobile GMail von fehlerhaften WebKit-border-image-quirks abhing und Firefox das Gefühl hatte, diese kopieren zu müssen; daraufhin wurde Chrome so geändert, dass GMail kaputtging, und GMail wurde schnell aktualisiert, ohne dass Nutzer es bemerkten

[GN⁺]

Hacker-News-Kommentare

• Die Gegenargumente scheinen ziemlich klar zu sein: die enge Kopplung von Prompt und Modell sowie das Problem der Modellneutralität in den Nutzungsbedingungen.
  Wie im persönlichen Beispiel unter https://github.com/mozilla/standards-positions/issues/1213 beschrieben, antwortete Gemini beim Erstellen eines System-Prompts für Benachrichtigungen zur Heimautomatisierung anfangs zu amerikanisch; als man ihm sagte, es solle mit britischer Stimme sprechen, kam stattdessen ein unbeholfener britischer Akzent aus amerikanischer Sicht heraus, etwa „a'waight guv'nor apples and pears“, sodass weiter nachjustiert werden musste.
  In diesem Prozess wird der System-Prompt auf ein bestimmtes Modell zugeschnitten, und da andere Modelle andere quirks haben, kann eine Korrektur für ein Modell bei einem anderen zur Überkorrektur werden.

  • Das Ergebnis klingt im adversarial mode wie Spott.
  • Wenn das ein guter Grund wäre, LLM-Funktionen nicht zu unterstützen, dann dürfte man sie in keine einzige Plattform-API aufnehmen. Tatsächlich wurden sie aber bereits zu unzähligen Plattformen hinzugefügt.
    Dass Modelle sich unterscheiden, ist eine Kerneigenschaft dieser Technologie. Es ist ähnlich wie unterschiedliche canvas-Größen je nach Gerät oder Ausrichtung, unterschiedliche Genauigkeit der geolocation API oder unterschiedliche Speech-Synthesis-Stimmen je nach Gerät.
    Das wirkt weniger wie konstruktive Kritik als eher wie eine anti-AI-Haltung. Im Moment braucht es eine Berechtigungs-UI, und irgendwann kommen vielleicht IQ-Stufen wie low/medium/high dazu, aber Entwickler, die sich dafür interessieren, werden sich ohnehin zu 90 % auf ein bestimmtes Modell stützen.
    Wenn mit der Zeit die AI-Feindseligkeit nachlässt und die Menschen erkennen, dass es hilfreich ist, könnte das Fehlen dieser Funktion in Firefox als Scheitern bei der Autonomie über persönliche Daten erscheinen. Wenn die zugehörigen TOU von Chrome das Problem sind, ist das eher ein Grund, warum Firefox die Funktion mit unproblematischen Modellbedingungen einführen sollte.

• Ich wusste nicht, wer den Widerspruchsbeitrag geschrieben hat, aber es war der langjährige Googler aus dem Chrome-Team Jake Archibald, der zu Mozilla gewechselt ist und nun einen Beitrag gegen eine Chrome-API geschrieben hat. Es überrascht nicht, dass die Kritik gut strukturiert ist, und vermutlich war es befreiend, diesmal nicht der Parteilinie folgen zu müssen.

  • Danke, aber ich glaube nicht, dass er auch bei Google der Parteilinie gefolgt ist. Dadurch wurde es intern für ihn jedoch zunehmend schwieriger, und schließlich ging er.
    Wenn man hört, was Leute sagen, die noch im Team sind, scheint die Lage in dieser Hinsicht exponentiell schlimmer geworden zu sein.
  • Mit dem standards-positions-Repo dürfte er bestens vertraut sein, und es liest sich wie die typische Abwehr, wenn Google etwas ohne ausreichende Konsultation durchdrücken will.
    Statt Änderungsvorschläge zu machen, wird versucht, das Ganze zu verwerfen; wenn es verworfen wird, scheint die Hoffnung zu sein, dass es aus Sicht des Google-Chrome-Teams nicht mehr der Startpunkt ist und man stattdessen von Anfang an kollaborativ neu schreiben kann. Ich habe allerdings nicht oft gesehen, dass das gut funktioniert, daher wäre es wohl besser, einfach konkrete Änderungsvorschläge zu machen.

• Dagegen bin ich.

  1. Es wird zu neuer Fingerprinting-Information und kann missbräuchlich für „device verification“ verwendet werden, weil man Fingerprinting-Skripte schwer täuschen kann. Man sollte Browser nicht „verifizieren“ können, und jeder sollte jeden Browser emulieren können.
  2. LLMs verbrauchen viel Speicher und CPU, und angesichts der aktuellen RAM-Preise sind Upgrades teuer. Wenn Websites von lokalen Modellen abhängen, laufen sie auf günstigen Geräten langsam.
  3. Die API scheint auf bestimmte LLMs wie OpenAI zugeschnitten zu sein.
  4. Sie könnte im Browsermarkt Konkurrenten ohne eigenes AI-Modell verdrängen. Wenn Websites in Erwartung von Google-Gemini-Modellen gebaut werden, können sie mit anderen Modellen oder in nationalen Browsern ohne AI-Modell kaputtgehen, und es darf keine Browser erster und zweiter Klasse geben.
     Der explainer sagt, Daten könnten lokal verarbeitet werden, ohne irgendwohin gesendet zu werden; dann ist aber fraglich, warum ein lokales Google-Gemini-Modell eine Prohibited Use Policy braucht. Warum sollte Google sich für Prompts und Antworten interessieren, die es gar nicht kennen kann?
     Offline-Zugriff auf LLMs an sich klingt gut, aber dafür muss man kein LLM in den Browser einbauen; Websites könnten stattdessen WebGPU nutzen oder WebGPU für die Verarbeitung von ML-Modellen verbessern. Oder alle sollten dasselbe Open-Source-LLM verwenden.
  • Google zeigt wie andere Bakterien einfach in die Richtung, in der Geld ist, bewegt seine Geißel und schwimmt dorthin. Ich verstehe nicht, warum irgendwer glaubt, Google werde etwas tun, das dem Web oder der Menschheit guttut.
  • Der Aussage „Man sollte Browser nicht verifizieren können“ widerspreche ich entschieden. Die AI-Branche hat den gesellschaftlichen Konsens rund um anti-scraping und anti-botting aus der Zeit vor Corona vollständig zerrissen.
    Dass robots.txt keine zwingende Vorgabe ist und vollständig umgangen werden kann, gilt inzwischen als Allgemeinwissen und hat das offene Web faktisch zu einem dark forest gemacht.
    Es ist gut möglich, dass Methoden entstehen werden, mit denen sich verifizieren lässt, dass eine Browser-Sitzung nicht manipuliert wurde oder „trusted“ ist. Das ist wirklich unerquicklich, aber letztlich haben wir uns das teilweise selbst eingebrockt.
  • Was die Fingerprinting-Sorgen angeht, gehe ich davon aus, dass es sowohl in Chrome als auch natürlich in Firefox eine Option geben wird, „niemals ein LLM herunterzuladen und alle LLM-Funktionen zu deaktivieren“.
    Es wäre möglich, dass Websites kleine LLM-Anfragen schicken, um das Modell selbst zu fingerprinten, aber wenn man es abschalten kann, scheint mir das kein großes Problem zu sein.
    Allgemeiner gibt es die Sorge in der Form „die Webplattform sollte das nicht können dürfen“. Aus dieser Sicht kann man sagen, dass auch mit abschaltbarer Funktion Websites entstehen, die bei fehlendem LLM den Browser als nicht unterstützt behandeln, und dass dadurch das Web schlechter wird.
    Aber das ist am Ende eine Entscheidung des Website-Betreibers, die Seite ohne LLM abzuschalten, und nicht die Schuld der Plattform oder ihrer Maintainer, die die Funktion gebaut haben. Es ist ähnlich wie wenn etwas in Firefox gut funktioniert, man den Support aber abschaltet, weil das Testen lästig ist.
    Das Web ist die erfolgreichste Anwendungsplattform der Welt in einer Welt, in der es nicht mit PDF konkurriert, sondern mit SwiftUI. Die Vorstellung, man könne „das Web einfach so statisch lassen wie jetzt“, ist eine Illusion; die echte Wahl ist, das Web an die sich ändernden Anforderungen der Nutzer anzupassen oder zuzulassen, dass das Web scheitert und SwiftUI oder WinUI den Platz einnehmen. Letzteres wäre deutlich schlimmer.
  • Beim Lesen der Antworten in diesem Thread wurde mir klar: Sie werden es ohnehin tun, und Leute, die bereits von LLMs abhängig sind oder denen die Fähigkeit zum vernünftigen Urteil fehlt, werden es auch noch loben.
    https://news.ycombinator.com/item?id=47960596
    Die Schlussfolgerung ist, dass es Zeit ist, weiterzugehen. Wir müssen über ein Format für Online-Informationsaustausch und Medienwiedergabe nachdenken, das besser ist als der Webbrowser. Wenn wir die Ware sind, dann sollten auch die Werkzeuge, die wir benutzen, das direkt widerspiegeln, statt sich wie ein Proxy zu verhalten, der heimlich Werbeeinnahmen an unzuverlässige Herrscher weiterleitet.

• Je länger ich darüber nachdenke, desto mehr stimme ich diesmal der API-Gestaltung von Google zu.
  Die enge Kopplung von Prompt und Modell ist eine reale Sorge und ein tägliches Problem. Wenn die Lösung aber eine API ist, die den Prompt, der evaluiert werden soll, noch enger an das Modell im Browser des Nutzers koppelt, landet man bald bei Situationen wie „Unser Prompt wurde nur mit Gemini getestet, daher braucht diese Website Chrome“.
  Noch schlimmer wäre „das verwendete AI-Modell kann nicht erkannt werden“. Wenn eine 2026 erstellte Website bis 2030 nicht aktualisiert wird, ist das absolut realistisch.
  Das hängt auch mit dem Problem der Nutzungsbedingungen zusammen, das ein Mozilla-Ingenieur im Hintergrund erwähnt hat. Wenn es Browser geben soll, bei denen man bestimmten AI-Modellbedingungen nicht zustimmen muss, etwa Browser mit guten Open-Source-Modellen, dann ist es besser, wenn Big Models nicht fingerprintbar sind.
  Natürlich werden viele Websites ohnehin Aufrufe wie isChrome() machen. Trotzdem bin ich im Allgemeinen gegen Änderungen, die die Möglichkeiten zum Browser-Fingerprinting erweitern. Der Vorteil, Modelle anonym zu halten, ist größer als der Nachteil gelegentlich seltsamer Ausgaben wegen kleiner Unterschiede zwischen Modellen wie Gemini und Qwen.

• Ich verstehe nicht, warum Google nicht riesige Ressourcen dafür aufwendet, strukturelle Schwächen bei den vielen Dingen zu beheben, die Browser bereits können, sondern stattdessen immer weiter Kram draufsetzt und den Browser in ein Homermobile verwandeln will.
  Warum konzentriert man sich nicht auf grundlegende Dinge, die die Lebensqualität auf der gesamten Webplattform verbessern würden, von statischen Blogs über E-Commerce bis hin zu modernsten Web-Apps?
  https://simpsons.fandom.com/wiki/The_Homer

  • Google baut Chrome nicht, um ein besseres Web zu schaffen. Einen guten Browser um des guten Browsers willen zu bauen, hieße, Milliarden Dollar für goodwill auszugeben; das Ziel von Chrome ist es, zur Plattform zu werden, die das Betriebssystem des Nutzers ersetzt, wenn dieser auf seinem Gerät etwas tut.
    Mit Android und ChromeOS versucht Google das direkt, aber Chrome sorgt auch in Umgebungen wie Windows dafür, dass Durchschnittsnutzer die meiste Zeit innerhalb der Google-Welt verbringen.
  • Um bei Google befördert zu werden, muss man eine prompt API veröffentlichen.
  • Dass man die prompt API nicht implementiert, heißt nicht, dass dadurch Ressourcen in andere Dinge fließen würden, die man vorher nicht wichtig fand. Das wirkt wie eine false dichotomy.

• Ich bin stark der Meinung, dass die heutigen LLM- und API-Harnesses technisch noch nicht ausgereift genug sind, damit eine solche API standardisiert werden sollte.
  Wenn man es trotzdem macht, dann sollte es zumindest eine standortspezifische Opt-in-Berechtigung sein, und es sollte eine Möglichkeit geben festzustellen, an welches Modell Prompts gesendet werden. Selbst kleine Anpassungen am System-Prompt gehören zu dieser Identität.
  Als Nutzer brauche ich die Sicherheit, dass ich beim Besuch irgendeiner Website nicht ohne Erlaubnis über diese API fingerprinted werde.
  Als Entwickler muss ich wissen, welche Modelle Nutzer verwenden, damit ich die Möglichkeit habe, modellspezifische Prompts zu bauen.

• „Es wird zunehmend erwartet, dass Browser und Betriebssysteme auf Sprachmodelle zugreifen“? Wirklich?
  https://github.com/webmachinelearning/prompt-api/blob/main/R...

  • Ich denke, das ist die falsche Richtung. Ich will nicht, dass das OS oder der Browser auf LLMs zugreift, aber ich will, dass LLMs auf den Browser oder das OS zugreifen, und genau das passiert bereits.
    Deshalb sollte man nur eine standardmäßig deaktivierte Schnittstelle für LLMs bereitstellen, die der Nutzer einschalten kann, wenn er möchte.
    Dann wäre man auch nicht an das von Apple ins OS eingebaute LLM gebunden und könnte wählen, welchen LLM provider man nutzen will. Zum Beispiel würde ich gern Claude Zugriff auf dieselben Dinge geben, auf die auch Apple Intelligence zugreifen kann.
  • Ich hatte diesen Satz ursprünglich geschrieben und nicht erwartet, dass er so missverstanden würde. Gemeint war nicht die Erwartung von Nutzern oder Entwicklern, sondern der Branchentrend, dass OS- und Browser-Anbieter LMs einbauen oder vorbereiten.
    Inzwischen könnte man statt „es wird erwartet, dass sie zugreifen“ wohl sagen „sie werden eingebaut“. Viele scheinen das misszuverstehen; es wäre gut, wenn das Projekt-Maintainer-Team das entsprechend aktualisieren würde.
  • macOS, iOS und Windows haben lokale Modell-APIs für Drittentwickler, und Chrome experimentiert ebenfalls damit. Firefox erzeugt mit einem Modell Alt-Text, hat aber keine API.
    Theoretisch ist das nützlich. Wenn Entwickler sich auf lokale Modelle verlassen können, wird es privater und dezentraler, und es sinkt die Notwendigkeit, Geld an AWS oder Anthropic zu schicken. Weil es lokal läuft, offline möglich ist und kostenlos sein kann, ergeben sich auch sinnvolle low-stakes Anwendungsfälle.
    In der Praxis habe ich jedoch kaum gesehen, dass native Apps Apple Foundation Models übernehmen. Ich würde gern hören, ob Mac-/iOS-Entwickler dazu Erfahrungen teilen können.
  • AI gibt Leuten, die sonst nur bikeshedding betreiben können, enorme Macht. Wahrscheinlich ist AI selbst auch ein bikeshed, aber es gibt legitime Anwendungsfälle, und sie verleiht auch die Kraft, nutzlose Ideen länger und lauter durchzudrücken als der Widerspruch dagegen.
    Jetzt scheint alles immer mehr bikeshed zu erwarten. CVE wohl auch.
  • Offenbar ist die Browser-API-Oberfläche immer noch nicht obszön breit genug.

• Das Gute an offenen Protokollen ist, dass man keine bestimmte Implementierung unterstützen oder verwenden muss, aber dennoch bleibt das Browser-Monopol ein fortdauerndes Dilemma.
  Es gibt gute Projekte wie ungoogled chromium und Tor, aber das größte Problem ist der Mangel an Projekten mit einer Stimme für Durchschnittsnutzer und mit Verbindung zur breiten Öffentlichkeit.
  Viele weniger informierte Nutzer sind sowohl gegenüber der Sache selbst als auch gegenüber der Art, wie man sie vermittelt, gleichgültig und reagieren stärker auf etwas, das „Spaß“ macht und wenig Reibung erzeugt, als auf Freiheit und Kontrolle.
  Wie lässt sich das lösen? Wie können wir den Browser zu etwas machen, das uns gehört, von Menschen und für Menschen ist? Immer wenn ich darüber nachdenke, werde ich einfach traurig.

  • Wenn man den Browser selbst kompiliert, wird es sogar noch schlimmer. Wer Spotify oder Netflix will, braucht Widevine mit Attestation und muss am Ende Google bezahlen.
    Wenn der Browser-Agent-String nicht Chrome oder Firefox ist, landet man in endlosen Cloudflare-CAPTCHAs oder 403-Fehlern.
  • Man sollte damit anfangen, die Plattform-APIs zu lernen, statt Chrome in „native“ Anwendungen hineinzustecken.
    Danach sollte man Webanwendungen auf Basis von Webstandards bauen statt danach, was Chrome tut, und sich nicht darüber beschweren, dass Firefox und Safari nicht mithalten.
  • Ganz einfach. Man braucht Kartellrecht und muss alle großen Tech-Konzerne zerschlagen. Das sind die robber barons unserer Zeit.
  • Leider lautet die Antwort fast immer echte öffentliche Finanzierung.
  • Gute Browser gibt es bereits, und Durchschnittsnutzer verwenden Chrome. Wer sich interessiert, wechselt zu Ersteren. Welches Problem muss also gelöst werden?
    Du sagst, es brauche Projekte, die Durchschnittsnutzer erreichen, und zugleich, dass sie weniger auf Freiheit und Kontrolle reagieren als auf geringe Reibung. Darin steckt ein Widerspruch. Durchschnittsnutzer orientieren sich eher an less friction als an Kontrolle.

• Ich frage mich, wofür der use case dieser API eigentlich sein soll.
  Meine Erfahrung mit lokalen LLMs ist, dass ich llama-server starte, ihn bei Bedarf auf einer separaten Maschine laufen lasse und dann andere Anwendungen so konfiguriere, dass sie auf diesen OpenAI-kompatiblen Server zeigen statt auf OpenAI oder einen ähnlichen Dienst.
  Ich möchte nicht, dass der Browser eine LLM-Instanz erstellt oder ausführt. Die betreffende Maschine hat womöglich gar nicht die Fähigkeit oder die freien Ressourcen dafür.

• Ich frage mich, ob das der Unterschied zwischen einer jungen Generation ist, die ohne LLMs schon nicht mehr leben kann, und einer älteren Generation, die keinen datenschutzverletzenden Webbrowser betreiben will, für den man gleich einen Supercomputer braucht.
  Für mich klingt das wie der Punkt, an dem Menschen anfangen werden, Alternativen zu Browsern/zum Web zu suchen und zu entwickeln.

  • Das heißt nicht, dass Mozilla eine Position gegen AI bezogen hat.
    Es erklärt nur klar und logisch, warum die vorgeschlagene API in ihrer derzeitigen Form schlecht für die Interoperabilität des Webs ist.
  • Ich denke, der Widerspruch hier hat nichts damit zu tun, ob man LLMs mag oder nicht. Es geht darum, ob dieser konkrete Vorschlag für eine offene Web-API umsetzbar ist.
    Ich selbst nutze LLMs für Coding-Hilfe und Heimautomatisierung, aber ich halte diese API nicht für gut fürs Web.
  • Meiner Erfahrung nach hassen junge Leute AI eher.
  • Das führt etwas weg vom Thema, aber ich glaube, überarbeitet werden muss weniger die Browser-Oberfläche als vielmehr das Konzept des Betriebssystems selbst.
    Ich habe keine endgültige Antwort, aber nachdem ich Niri/Wayland, GNOME, Windows und Mac benutzt habe, werde ich nie wieder zu einem non-tiling desktop oder einem nicht keyboard-zentrierten Workflow für Desktop-Fensterverwaltung zurückkehren.
  • Das Schiff „datenschutzverletzender Browser, der einen Supercomputer braucht“ ist schon 2008 abgefahren.