Mozillas Ablehnung der Prompt API in Chrome

• Die Prompt API, die Sprachmodelle im Browser als Web-API verfügbar macht, kann in allgemeiner Form nützlich sein, fördert jedoch Implementierungen, die auf modellspezifisches Verhalten zugeschnitten sind, und erhöht damit das Interoperabilitätsrisiko
• Wenn Entwickler Prompts und Funktionen auf eine bestimmte Implementierung wie Edges Phi-4-mini abstimmen, kann es in anderen Browsern oder Modellen zu Qualitätsverlust oder blockiertem Site-Zugriff kommen
• Mozilla ist der Ansicht, dass statt einer direkten Auslieferung als Web-API erst mehr Validierung im Userland stattfinden sollte, und sieht eine Trial-Web-Extension-API sowie den Web-Extension-Vorschlag der Web Machine Learning Group als frühen Feedback-Kanal
• Wenn sich System-Prompts an die Quirks eines bestimmten Modells anpassen und verbreiten, können auch neue Modelle schlechter erscheinen, und es kann Druck auf Browser entstehen, Google-Modelle oder quirk-kompatible Modelle einzubauen
• Chrome nennt JSON-Schema- und regex-basierte Antwortbeschränkungen, Diskussionen in der WebML CG und Experimente mit alternativen Modellen als Gegenmaßnahmen, dennoch ist Mozillas Position zur Prompt API als negative markiert

---

Mozillas negative Bewertung der Prompt API

• Die Prompt API wurde in Mozillas standards-positions nach Blinks intent-to-prototype geprüft; der Explainer verweist auf das README von webmachinelearning/prompt-api
• Mozillas Feedback ist fast identisch mit Writing Assistance APIs #1067: Eine allgemeine Form der Prompt API kann nützlich sein, fördert aber modellspezifisches Verhalten und erhöht damit das Interoperabilitätsrisiko
• Entwickler können Prompts und Funktionen auf ein bestimmtes Modell zuschneiden; wenn für eine Implementierung wie Edges Phi-4-mini entwickelt wird, kann die Qualität in anderen Browsern oder Modellen sinken oder der Site-Zugriff blockiert werden
• Statt direkt als Web-API ausgeliefert zu werden, sollte die Technik länger im Userland validiert werden; Mozillas Trial-Web-Extension-API und der Web-Extension-Vorschlag der Web Machine Learning Group dienen dabei als frühe Kanäle für Feedback
• Auf Basis der zugehörigen Diskussionen und von #1067 ist die Position zur Prompt API als negative markiert

Warum Web Extensions gegenüber Origin Trials bevorzugt werden

• Modellauswahl und Zeitpunkt der Standardisierung

  • Die Möglichkeit, im Model Hub ein konkretes Modell auszuwählen, gilt als zentral, weil sie seiteninterne Funktionen ermöglicht 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 standardisierungsreif
  • Extensions sind ein niedrigschwelliger Weg, tatsächliche Nutzungsmuster über den aktuellen Vorschlagsumfang hinaus schnell zu erkunden und browserübergreifend Funktionen zu testen, ohne den Koordinationsaufwand, dass drei Engines Semantik ausliefern müssen, die noch nicht gefestigt ist

• Für Nutzer sichtbare Grenzen

  • Die Installation eines Add-ons signalisiert dem Nutzer, dass er die Grenzen normaler Webfunktionen verlässt; hier betrifft das insbesondere geteilten Cross-Origin-Speicher
  • Diese Einschätzung folgt einer ähnlichen Logik wie WebMIDI Add-On Gated Position Add #704 in einem anderen Kontext
  • Der betreffende Extension-Vorschlag exponiert gegenüber Seiten eine der Prompt API ähnliche API und verwendet lokale Inferenz sowie vom Entwickler angegebene Modelle, um gemeinsam genutzten Modellspeicher und frühes Nutzerfeedback zu erhalten

Das Risiko einer Verfestigung auf ein einzelnes Modell

• System-Prompts und Modell-Quirks

  • System-Prompts werden typischerweise wiederholt an die Quirks des jeweils verwendeten Modells angepasst
  • Bei einem System-Prompt zur Erzeugung von Anleitungen für Home-Automation antwortete ein Gemini-Modell anfangs sehr amerikanisch und passte nicht zu einer britischen Sprecherstimme
  • Nachdem in den System-Prompt aufgenommen wurde, dass mit britischer Stimme gesprochen werde, kam eine amerikanisierte Imitation von Britisch wie „a'waight guv'nor apples and pears“ heraus, sodass weitere Anpassungen nötig waren, um den Stil realitätsnäher zu machen
  • Eine Korrektur für ein Modell kann bei anderen Modellen zu Überkorrektur führen; das Problem ist größer bei gebrandeten Stimmen oder Ausgabeformaten, die sich nicht mit JSON-Schema oder regulären Ausdrücken ausdrücken lassen

• Belastung durch neue Modelle und Browser-Updates

  • Wenn sich System-Prompts verbreiten, die auf die Quirks bestehender Modelle abgestimmt sind, können auch bessere neue Konkurrenzmodelle bei Entwicklern und Nutzern schlechter wirken
  • Mozilla und Apple könnten sich aus Interoperabilitätsgründen in einer Lage wiederfinden, Google-Modelle lizenzieren oder mit Google-Modellen quirk-kompatible Modelle einsetzen zu müssen
  • Aus demselben Grund könnte es auch für Chrome schwierig werden, seine eigenen Modelle zu aktualisieren

• Erkennung von Modell-IDs 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 Ursprungsunternehmen fragen
  • Ein mögliches Rückgabeformat ist 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
  • Entwickler können Bündel von System-Prompts für bestimmte Modelle anlegen und unbekannte Modelle blockieren oder Nutzer darauf hinweisen, dass die Ausgabequalität geringer sein könnte
  • Das wird als Rückfall in die zu vermeidende Code-Verzweigung im Stil der frühen 2000er gesehen

Google-Richtlinien und das Problem der Modellneutralität

• Laut der Chrome-Dokumentation muss vor der Nutzung der Prompt API die Google Generative AI Prohibited Uses Policy anerkannt werden
• Teile dieser Richtlinie gehen über gesetzliche Anforderungen hinaus; zu den Verboten gehören etwa 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 Webplattform-APIs in eine Richtung gehen, in der pro User Agent eigene Nutzungsregeln verlangt werden; das könnte zum Präzedenzfall für weitere APIs mit UA-spezifischen Regeln werden
• Wenn ein Nutzer auf einer Website bei einem Artikelkommentar auf „summarize“ klickt und das Ergebnis dann gegen Googles Richtlinie verstößt, ist unklar, wer verantwortlich ist: der Nutzer, der den Button geklickt hat, der Verfasser des Kommentars mit dem problematischen Inhalt oder der Website-Betreiber, der die Funktion gebaut hat, welche den Kommentar an das UA-LLM des Nutzers weitergibt
• Entwickler könnten wissen wollen, mit welchem LLM sie kommunizieren, um Modellbedingungen einzuhalten und rechtliche Schritte des Modellinhabers zu vermeiden; unbekannte Modelle können unbekannte Nutzungsbedingungen bedeuten, weshalb eine Blockierung plausibel erscheint
• Es gibt auch die Sicht, dass ein bestimmter Browser keine Grundlage hat, Website-Entwicklern solche Bedingungen aufzuerlegen, und dass dieses Richtlinienproblem getrennt vom API-Vorschlag behandelt werden sollte

Updates und Gegenmaßnahmen von Chrome

• Das Chrome-Team zur Prompt API teilte ein blink-dev I2S sowie ein Update zu Interoperabilitäts- und Kompatibilitätsrisiken auf ChromeStatus
• Man möchte die Beteiligung und Diskussion in der WebML CG fortführen; dazu kommen Folgeexperimente wie interoperable Sampling-Parameter
• Chrome nennt als Motivation, die langfristige Gesundheit und Neutralität der Webplattform zu erhalten und zugleich vom Browser und OS bereitgestellte Language Models zu einer nützlichen Option für Webentwickler und Nutzer zu machen
• Die Oberfläche der Prompt API habe sowohl mit Google- als auch mit Microsoft-Modellen in gewissem Maß Kompatibilität gezeigt, und es würden objektive Antwortbeschränkungen eingesetzt, damit Ausgaben bekannten JSON-Schemata oder regex entsprechen
• Diese Einschränkungen dienen als Gegenmaßnahme, um den Bedarf an modellspezifischen Hacks für unvorhersehbare Ausgaben zu verringern
• Nachgelagerte Chromium-Projekte untersuchen alternative Modelle und Framework-Backends, darunter Microsofts Android-MLKit-Integration und frühe Prototypen für die Integration von Apples foundational model
• In der Trial-Phase der API wurden mehrere Modellversionen experimentell ausgeliefert; Modell-Updates und Verbesserungen bleiben nötig, und auch Unterstützung für neuere Gemma 4 open models wird geprüft
• Für eine stärker interoperable Verhaltensabstimmung über unterschiedliche Basisarchitekturen hinweg werden auch kategoriale Sampling-Modi untersucht
• Die Formulierung zu Interoperability and Compatibility auf blink-dev besagt, dass Variabilität bei Verhalten und Antworten für Entwickler dieser Technik eine bekannte Erwartung sei und dass die API ein Interoperabilitäts-Framework für einen konsistenten Webplattform-Zugang über Browser und Modelle hinweg anstrebe

Begründung der Unterstützung durch Webentwickler und Kritik an der Auslieferung

• blink-dev intent to ship markiert die Haltung von Webentwicklern als „Strongly positive“ und verweist zur Begründung auf das Stakeholder-Feedback im Explainer
• Diese Begründung wird als wenig passend für die Einstufung „Strongly positive“ betrachtet

• 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 in Extensions existieren dürfe; Teilnehmerzahl und Zielgruppe werden nicht genannt
  • Für den verschwundenen Blogbeitrag wird ein Archiv über die Wayback Machine verlinkt
  • Selbst wenn Dokumente deutlich markieren, worauf man sich „nicht verlassen“ und worauf man sich verlassen könne, bleibt unklar, ob bei Einhaltung dieser Empfehlung überhaupt noch genügend reale Anwendungsfälle für die API übrigbleiben
  • In der Praxis lässt sich vermutlich doch in gewissem Maß auf das Verhalten eines konkret getesteten Modells bauen; wenn das Chromes Modell ist, kann eine Site Nutzer einfach zur Verwendung der neuesten Chrome-Version auffordern
  • Problematisch bleibt, dass Google den unreifen Bereich zwar breit benennt, aber die aktuellen Gegenmaßnahmen dennoch als ausreichend für eine Auslieferung ansieht

Kommentardiskussion: Alternativen, Schadensmessung und nachträgliche Abhilfe

• Browser-Automatisierung und Lynx mode

  • Mit Hermes Agent und Qwen3.6 seien die meisten Aufgaben möglich gewesen; der Fokus solle eher auf Browser-Automatisierungs-APIs und dem Lynx mode für Chats liegen als auf der Prompt API
  • Einige Workflows sehen vor, dass ein Mensch sich auf einer Website anmeldet und per AJAX-Erweiterung Dateien sichtbar macht, worauf ein Agent mit chromedriver/webdriver Dokumente herunterlädt, taggt und zusammenfasst
  • Dieser Ablauf könne ohne externe POSIX-Shell vollständig im Browser integriert werden
  • Lynx-mode-Chat exponiere schnell das, was Agents sehen, und spare auf beiden Seiten Ressourcen, weil nicht alle Medieninhalte heruntergeladen oder gerendert werden müssen
  • Behandelt wurden außerdem feinere robots-Tags auf HTML-Ebene, Übergaben zwischen Lynxmode-Shell und bestehendem Browser sowie die selektive Anzeige von Links im Stil alter Google-AdWords in agentgesteuerten Browsern

• Offenes Web und FOMO

  • Es gibt Gegenpositionen, wonach das offene Web nicht auf dieselbe Weise mit Chatbot-Super-Apps konkurriert und auch nicht verschwinden wird
  • Statt ständiger FOMO brauche es eher die Frage, wofür man eigentlich stehen wolle
  • Der Sorge, dass Commerce oder Journalismus das offene Web verlassen könnten, wenn das Web agentisches Computing nicht schnell und effektiv genug unterstützt, wird nicht durchgängig zugestimmt, ähnlich wie das Web auch das Mobile-App-Paradigma nicht vollständig unterstützt hat

• Chromium-Auslieferung und Schadensmessung

  • Einer der Blink API Owner Approver in Chromium teilt Mozillas Sorge, bevorzugt aber einen Weg über Experimente, Lernen aus Fehlern und die Förderung von Wettbewerb
  • Um reale Schäden künftig zu bewerten, müssten konkrete Ergebnisse definiert werden; im Kontext umstrittener API-Auslieferungen wie EME habe es sich als nützlich erwiesen, Entscheidungen nach 5 bis 10 Jahren mit den tatsächlichen Resultaten zu vergleichen
  • Schäden durch eine Verfestigung von Sites auf Googles spezifisches Modell könnten anhand der Zahl und Größenordnung von Site-Compat-Bugs beim Ausliefern anderer Browser sowie anhand der Art der Bugs bei Modell-Updates in Chrome bewertet werden
  • Vorgeschlagen wird, Bugs danach zu unterscheiden, ob es um „das Modell intelligenter machen“ oder um das „Bewahren seltsamer Quirks“ geht, und sie mit Labels auf webcompat.com zu sammeln
  • Laut blink-dev I2S liefert auch Edge diese API bereits mit einem anderen Modell aus, sodass frühe Daten existieren
  • Als Schadensindikator für Bedenken rund um TOS gilt, ob es tatsächlich zu Klagen oder Drohungen wegen Verstößen gekommen ist; entsprechende Belege sollten gesammelt werden

• Nachträgliche Abhilfe und Reaktion von Chrome

  • Der Ansatz, mögliche Schäden real zu beobachten, gilt als sinnvoll, aber nur dann als nützlich, wenn es nach Eintritt des Schadens auch wirksame Gegenmaßnahmen gibt
  • Für den Fall, dass Sites auf Googles spezifisches Modell festgeschrieben werden, werden Optionen wie das Zurückziehen des Features, Modelländerungen zum Aufbrechen überangepasster Site-Prompts, zufällige Modellrotation oder offene Standards für On-Device-Modellgewichte als Fragen aufgeworfen
  • Falls sich zeigt, dass andere Browser die seltsamen Quirks von Chromes Modell kopieren müssen, gibt es die Haltung, aus einer Führungsposition in Chromium heraus darauf zu drängen, dass Chrome diese Quirks bewusst aufbricht
  • Als Präzedenzfall wird genannt, dass Mobile GMail von fehlerhaften WebKit-Border-Image-Quirks abhing; als Firefox eine Kopie für nötig hielt, korrigierte Chrome stattdessen den Fehler und brach GMail, das dann schnell aktualisiert wurde, ohne dass Nutzer es bemerkten