L’opposition de Mozilla à la Prompt API de Chrome

• La Prompt API, qui expose un modèle de langage intégré au navigateur via une API web, peut être utile sous une forme générale, mais elle encourage des implémentations adaptées au comportement propre à chaque modèle, ce qui accroît les risques d’interopérabilité
• Si les développeurs ajustent les prompts et les fonctionnalités à une implémentation précise comme Phi-4-mini d’Edge, cela peut entraîner une baisse de qualité ou bloquer l’accès à un site dans d’autres navigateurs ou avec d’autres modèles
• Mozilla estime qu’il faut davantage de validation côté userland avant un déploiement direct comme API web, et considère sa trial web extension API ainsi que la proposition de web extension du groupe Web Machine Learning comme des voies initiales de retour d’expérience
• Si des prompts système se diffusent en étant adaptés aux quirks d’un modèle précis, de nouveaux modèles peuvent aussi paraître moins bons, et les navigateurs pourraient subir une pression pour intégrer des modèles Google ou des modèles compatibles avec ces quirks
• De son côté, Chrome a proposé comme mesures d’atténuation des contraintes de réponse fondées sur les JSON schema et les regex, les discussions du WebML CG et des essais avec des modèles alternatifs, mais la position de Mozilla sur la Prompt API est marquée comme negative

---

Évaluation négative de Mozilla sur la Prompt API

• La Prompt API a été examinée dans Mozilla standards-positions après l’intent-to-prototype de Blink, et l’explainer renvoie vers le README de webmachinelearning/prompt-api
• Le retour de Mozilla est presque identique à Writing Assistance APIs #1067 : une Prompt API générique peut être utile, mais elle encourage des comportements spécifiques à chaque modèle, ce qui augmente les risques d’interopérabilité
• Les développeurs peuvent ajuster leurs prompts et fonctionnalités pour un modèle donné, et si cela vise une implémentation comme Phi-4-mini d’Edge, la qualité peut se dégrader ou l’accès au site peut être bloqué dans d’autres navigateurs ou avec d’autres modèles
• Plutôt qu’un déploiement immédiat comme API web, Mozilla estime qu’il faut une validation plus longue dans le userland ; sa trial web extension API et la proposition de web extension du groupe Web Machine Learning servent de canal initial pour recueillir des retours
• Sur la base des discussions associées et de #1067, la position sur la Prompt API est indiquée comme negative

Pourquoi Mozilla préfère les Web Extensions à l’Origin Trial

• Choix du modèle et calendrier de standardisation

  • La capacité à choisir le modèle exact dans un model hub est considérée comme essentielle, car elle relève de la page elle-même et parce que le navigateur ne doit pas imposer un modèle spécifique
  • Cette capacité repose sur des détails d’implémentation dans un domaine qui évolue rapidement, et elle n’est pas encore jugée prête pour la standardisation
  • Les extensions offrent un moyen peu contraignant d’explorer rapidement des usages réels au-delà du périmètre actuel de la proposition, et d’expérimenter des fonctionnalités entre navigateurs sans le coût de coordination nécessaire pour livrer dans trois moteurs des sémantiques qui ne sont pas encore stabilisées

• Des frontières visibles pour l’utilisateur

  • L’installation d’un add-on signale à l’utilisateur qu’il sort du cadre d’une fonctionnalité web ordinaire ; ici, cela concerne notamment le stockage cross-origin partagé
  • Ce raisonnement rejoint la logique suivie dans un autre contexte avec l’ajout de la position Add-On Gated pour WebMIDI #704
  • La proposition d’extension en question expose à la page une API proche de Prompt, et repose sur l’inférence locale ainsi que sur des modèles choisis par le développeur afin d’obtenir un stockage de modèles partagé et des retours utilisateurs précoces

Le risque de se figer sur un seul modèle

• Prompts système et quirks des modèles

  • Les prompts système ont tendance à être ajustés de manière répétée pour correspondre aux quirks du modèle en cours d’utilisation
  • Dans un prompt système servant à générer des consignes de domotique, un modèle Gemini répondait au départ de manière très américaine, ce qui ne convenait pas à une voix de haut-parleur britannique
  • En ajoutant au prompt système qu’il devait parler avec une voix britannique, la réponse est devenue une imitation caricaturale de l’anglais britannique du type “a'waight guv'nor apples and pears”, et il a fallu d’autres ajustements pour obtenir quelque chose de plus authentique
  • Une correction pensée pour un modèle peut devenir une surcorrection pour un autre, surtout avec des voix de marque ou des formats de sortie qui ne peuvent pas s’exprimer via JSON schema ou regex

• Charge liée aux nouveaux modèles et aux mises à jour du navigateur

  • Si des prompts système ajustés aux quirks d’un modèle existant se répandent largement, de nouveaux modèles concurrents pourtant meilleurs peuvent sembler mauvais aux yeux des développeurs et des utilisateurs
  • Mozilla et Apple pourraient se retrouver forcés de licencier des modèles Google, ou d’intégrer des modèles compatibles avec les quirks des modèles Google, pour préserver l’interopérabilité
  • Pour la même raison, Chrome pourrait lui aussi avoir du mal à faire évoluer ses propres modèles

• Détection d’ID de modèle et branchement selon le navigateur

  • Les développeurs peuvent créer un modèle avec LanguageModel.create() puis lui demander, avec quelque chose comme model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string'), son ID, son nom, sa version et l’entreprise d’origine
  • L’exemple de retour est 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
  • Les développeurs peuvent alors préparer des ensembles de prompts système pour des modèles précis, puis bloquer les modèles inconnus ou avertir l’utilisateur que la qualité de sortie risque d’être inférieure
  • Mozilla y voit un retour à une forme de code branching du début des années 2000 qu’il faudrait éviter

Politique de Google et problème de neutralité des modèles

• Selon la documentation Chrome, il faut accepter la Google Generative AI Prohibited Uses Policy avant d’utiliser la Prompt API
• Une partie de cette politique couvre un champ qui va au-delà du droit, en incluant parmi les usages interdits la “génération ou diffusion de contenu promouvant des contenus sexuellement explicites” et la “promotion d’affirmations trompeuses liées au gouvernement ou aux processus démocratiques”
• Il est problématique qu’une API de plateforme web exige des règles d’usage propres à chaque UA, car cela pourrait créer un précédent pour d’autres API assorties de règles spécifiques à chaque UA
• Si un utilisateur clique sur “summarize” dans les commentaires d’un article sur un site web, et que le résultat enfreint la politique Google, il devient flou de savoir si la responsabilité revient à l’utilisateur qui a cliqué, à l’auteur du commentaire ayant écrit le contenu litigieux, ou au propriétaire du site qui a conçu une fonction transmettant ce commentaire au LLM de l’UA de l’utilisateur
• Les développeurs peuvent vouloir savoir avec quel LLM ils communiquent afin de respecter ses conditions d’utilisation et d’éviter des actions juridiques du propriétaire du modèle ; un modèle inconnu peut signifier des conditions inconnues, ce qui rend un blocage d’usage rationnel
• Certains estiment qu’un navigateur donné n’a aucune base pour imposer ce type de conditions aux développeurs de sites web, et que cette question de politique devrait être traitée séparément de la proposition d’API elle-même

Mises à jour côté Chrome et mesures d’atténuation

• L’équipe de Chrome Prompt API a partagé le blink-dev I2S ainsi qu’une mise à jour sur les risques d’interopérabilité et de compatibilité dans ChromeStatus
• Elle souhaite maintenir sa participation et les discussions au sein du WebML CG, ainsi que poursuivre des expérimentations annexes comme les sampling parameters interopérables
• Chrome explique vouloir faire des Language Models fournis par le navigateur et l’OS une option utile pour les développeurs web et les utilisateurs, tout en préservant la santé à long terme et la neutralité de la plateforme web
• La surface de la Prompt API aurait montré un certain degré de compatibilité à la fois avec les modèles de Google et de Microsoft, et applique déjà des contraintes de réponse objectives pour faire correspondre les sorties à des JSON schema ou des regex connus
• Ces contraintes sont présentées comme une mesure d’atténuation destinée à réduire le besoin de hacks spécifiques à chaque modèle pour gérer des sorties imprévisibles
• Des projets Chromium downstream explorent des modèles alternatifs et des backends de framework, y compris des travaux de Microsoft sur l’intégration d’Android MLKit et les premiers prototypes d’intégration de foundational models d’Apple
• Durant la phase de trial de l’API, plusieurs versions de modèles ont été déployées à titre expérimental ; des mises à jour et améliorations restent nécessaires, et la prise en charge des Gemma 4 open models plus récents est aussi à l’étude
• Des categorical sampling modes sont également explorés pour ajuster les comportements de manière plus interopérable entre différentes architectures sous-jacentes
• Le texte de Interoperability and Compatibility sur blink-dev indique que la variabilité du comportement et des réponses est une attente bien connue des développeurs utilisant cette technologie, et que cette API vise un cadre d’interopérabilité pour une approche cohérente de la plateforme web à travers les navigateurs et les modèles

Fondements du soutien des développeurs web et critiques du shipping

• L’intent to ship de blink-dev qualifie la position des développeurs web de “Strongly positive” et renvoie, comme justification, au stakeholder feedback de l’explainer
• Cette base justificative est présentée comme ne correspondant pas vraiment à une évaluation “Strongly positive”

• Éléments listés comme preuves

  • Un thread GitHub contenant deux réponses positives
  • Un post unique sur X
  • Un billet de blog qui n’existe plus, en état Server Not Found
  • Un billet de blog encore accessible
  • Le sondage semble demander aux développeurs si cette API serait acceptable même si elle n’existait que dans des extensions, mais ni les chiffres ni la population interrogée ne sont précisés
  • Le billet de blog disparu est conservé via un lien Wayback Machine
  • Même si la documentation affichait très visiblement ce dont il ne faut pas dépendre et ce qui est fiable, il reste flou de savoir si l’API conserverait alors des usages réellement utiles
  • En pratique, il est possible de dépendre dans une certaine mesure du comportement du modèle effectivement testé ; si ce modèle est celui de Chrome, le site peut toujours afficher un message recommandant d’utiliser la dernière version de Chrome
  • Le fait que Google identifie largement ce domaine comme inachevé tout en estimant les mesures d’atténuation actuelles suffisantes pour le shipping reste un problème

Discussion dans les commentaires : alternatives, mesure des dommages, atténuation a posteriori

• Automatisation du navigateur et mode Lynx

  • Avec Hermes Agent et Qwen3.6, la plupart des tâches étaient déjà possibles, et certains estiment qu’il faut s’intéresser davantage à une browser automation API et à un mode Lynx pour le chat qu’à la Prompt API
  • Dans certains workflows, un humain se connecte au site, rend les fichiers visibles via une extension AJAX, puis un agent utilise chromedriver/webdriver pour télécharger, taguer et résumer des documents
  • Cette approche pourrait être intégrée dans le navigateur sans shell POSIX externe
  • Le chat en mode Lynx expose rapidement ce que voient les agents et économise des ressources des deux côtés en évitant de télécharger ou de rendre tous les médias
  • Sont également évoqués un balisage robots plus fin au niveau HTML, un handoff entre un shell Lynxmode et un navigateur classique, ainsi qu’une présentation sélective de liens façon Google AdWord old-school dans un navigateur piloté par agent

• Web ouvert et FOMO

  • Certains rétorquent que le web ouvert n’est pas en concurrence, de la même manière, avec des cibles comme les chat bot super apps, et qu’il ne va pas disparaître
  • Une autre position affirme qu’au lieu d’un FOMO permanent, il faut d’abord se demander ce que l’on veut représenter
  • D’autres ne partagent pas l’inquiétude selon laquelle, si le web ne prend pas rapidement et efficacement en charge l’agentic computing comme il n’a pas complètement pris en charge le paradigme des apps mobiles, le commerce ou le journalisme pourraient quitter le web ouvert

• Shipping dans Chromium et mesure des dommages

  • L’un des approvers blink API owner de Chromium dit partager les inquiétudes de Mozilla, tout en préférant un chemin qui favorise l’expérimentation, l’apprentissage par l’erreur et la concurrence
  • Pour évaluer d’éventuels dommages réels plus tard, il faut définir des résultats concrets ; dans ce contexte, il a été utile de comparer, cinq à dix ans plus tard, les effets réels de décisions controversées de shipping d’API comme EME
  • Le dommage lié au fait qu’un site se fige sur un modèle spécifique à Google peut se mesurer au nombre et à l’ampleur des bugs de compatibilité rencontrés par les autres navigateurs lors du shipping, ainsi qu’au type de bugs apparaissant quand Chrome met à jour son modèle
  • Il est proposé de distinguer les bugs relevant de “rendre le modèle plus intelligent” de ceux visant à “préserver un quirk étrange”, puis de les regrouper avec des labels sur webcompat.com
  • D’après le blink-dev I2S, Edge livre déjà cette API avec un autre modèle, et des données initiales existent donc déjà
  • Pour les inquiétudes liées aux TOS, le bon indicateur de dommage serait l’existence effective de poursuites ou de menaces juridiques dues à des violations ; certains proposent donc de constituer un dossier de telles preuves

• Atténuation a posteriori et réponse de Chrome

  • L’idée de vérifier d’abord si des dommages apparaissent réellement est jugée valable, mais seulement s’il existe des mesures d’atténuation significatives une fois les dommages constatés
  • Sont alors listées comme questions des options telles que le unship d’une feature si un site se fige sur un modèle Google donné, un changement de modèle qui casse des prompts de site surajustés, une rotation aléatoire des modèles, ou encore la standardisation ouverte des poids de modèles on-device
  • Si des preuves montrent que d’autres navigateurs doivent copier les quirks étranges du modèle de Chrome, une voix indique que, depuis une position de leadership dans Chromium, elle pousserait Chrome à casser ces quirks
  • Un précédent est cité : lorsque GMail mobile dépendait de quirks bogués de WebKit autour des border images et que Firefox estimait devoir les copier, Chrome a été corrigé d’une manière qui a cassé GMail, puis GMail a été rapidement mis à jour sans que les utilisateurs ne s’en rendent compte