L’opposition de Mozilla à la Prompt API de Chrome

 (github.com/mozilla)
6 points par GN⁺ 2026-05-01 | 1 commentaires | Partager sur WhatsApp
  • La Prompt API, qui expose des modèles de langage dans le navigateur via une API web, peut être utile dans 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 le Phi-4-mini d’Edge, cela peut entraîner une baisse de qualité ou un blocage de l’accès au site sur d’autres navigateurs ou d’autres modèles
  • Mozilla estime qu’il faut davantage de validation en userland avant une mise à disposition directe en API web, et propose comme canaux de retours initiaux une trial web extension API et la proposition de web extension du groupe Web Machine Learning
  • Si les prompts système se diffusent en étant adaptés aux quirks d’un modèle donné, de nouveaux modèles risquent eux aussi de paraître mauvais, et les navigateurs pourraient subir une pression pour intégrer un modèle de Google ou un modèle compatible avec ses quirks
  • Côté Chrome, des garde-fous ont été proposés, comme des contraintes de réponse fondées sur des schémas JSON et des regex, les discussions du WebML CG et des essais avec des modèles alternatifs, mais la position de Mozilla sur la Prompt API reste marquée comme negative

L’avis négatif 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 à celui de Writing Assistance APIs #1067 : une Prompt API générale peut être utile, mais elle encourage des comportements spécifiques à chaque modèle, augmentant les risques d’interopérabilité
  • Les développeurs peuvent ajuster les prompts et les fonctionnalités à un modèle particulier, et s’ils ciblent une implémentation comme Phi-4-mini d’Edge, la qualité peut se dégrader ou l’accès au site être bloqué sur d’autres navigateurs ou d’autres modèles
  • Au lieu d’être directement livrée comme API web, elle devrait être validée plus longtemps en userland ; la trial web extension API de Mozilla et la proposition de web extension du groupe Web Machine Learning serviraient de voies initiales pour recueillir les 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 précisément un modèle dans un hub de modèles est considérée comme essentielle, tant pour les fonctionnalités dans la page que parce qu’un navigateur ne doit pas imposer un modèle donné
    • Cette capacité suppose des détails d’implémentation dans un domaine qui évolue vite, et 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 qu’impliquerait une sortie alignée entre trois moteurs sur une sémantique encore instable

  • Une frontière visible pour l’utilisateur

    • L’installation d’un add-on signale à l’utilisateur qu’il sort du périmètre des fonctionnalités web ordinaires ; ici, cela concerne notamment un stockage cross-origin partagé
    • Cette position suit une logique similaire à celle d’un autre contexte, WebMIDI Add-On Gated position add #704
    • La proposition d’extension exposerait à la page une API proche de Prompt, en utilisant une inférence locale et des modèles désignés par le développeur, afin d’obtenir un dépôt de modèles partagé et des retours utilisateurs précoces

Le risque d’un verrouillage sur un modèle unique

  • Prompts système et quirks des modèles

    • Les prompts système ont tendance à être ajustés de façon répétée pour correspondre aux quirks du modèle utilisé
    • Dans un prompt système destiné à générer des annonces pour la domotique, un modèle Gemini répondait d’abord de manière très américaine, inadaptée à une voix de haut-parleur britannique
    • Après avoir ajouté dans le prompt système qu’il devait parler avec une voix britannique, il s’est mis à produire des formulations comme “a'waight guv'nor apples and pears”, une imitation britannique très américaine, ce qui a nécessité des ajustements supplémentaires pour obtenir quelque chose de plus authentique
    • Un correctif 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 être exprimés via JSON schema ou regex

  • Charge liée aux nouveaux modèles et aux mises à jour des navigateurs

    • Si des prompts système adaptés aux quirks d’un modèle existant se diffusent largement, de nouveaux modèles concurrents pourtant meilleurs risquent aussi de sembler mauvais aux développeurs et aux utilisateurs
    • Mozilla et Apple pourraient se retrouver contraintes, au nom de l’interopérabilité, de licencier un modèle Google ou d’intégrer un modèle compatible avec les quirks d’un modèle Google
    • Chrome lui-même pourrait, pour la même raison, avoir du mal à mettre à jour ses propres modèles

  • Détection de l’ID du modèle et branchements par navigateur

    • Un développeur peut créer un modèle avec LanguageModel.create() puis demander model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') afin d’obtenir l’ID du modèle, son nom, sa version et l’entreprise d’origine
    • Exemple de retour : 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Le développeur peut alors préparer des ensembles de prompts système pour des modèles spécifiques, puis bloquer les modèles inconnus ou avertir l’utilisateur que la qualité de sortie peut être moindre
    • Cela est vu comme un retour aux branchements de code du début des années 2000 qu’il faudrait justement éviter

Le problème des règles de Google et de la neutralité des modèles

  • La documentation Chrome indique qu’avant d’utiliser la Prompt API, il faut reconnaître la Google Generative AI Prohibited Uses Policy
  • Une partie de cette politique va au-delà du droit strict ; parmi les usages interdits figurent la « génération ou diffusion de contenus promouvant des contenus sexuellement explicites » et la « promotion d’affirmations trompeuses liées au gouvernement ou aux processus démocratiques »
  • Il est jugé problématique qu’une API de la plateforme web impose des règles d’usage spécifiques à un UA, car cela pourrait créer un précédent où davantage d’API seraient assorties de règles propres à chaque UA
  • Si un utilisateur clique sur « summarize » dans les commentaires d’un article sur un site web et que le résultat viole les règles de Google, il n’est pas clair de savoir si la responsabilité incombe à l’utilisateur qui a cliqué, à l’auteur du commentaire problématique, ou au propriétaire du site qui a conçu la fonctionnalité transmettant ce commentaire au LLM du UA de l’utilisateur
  • Les développeurs peuvent vouloir savoir avec quel LLM ils communiquent afin de respecter les conditions d’utilisation du modèle et d’éviter d’éventuelles poursuites du détenteur du modèle ; un modèle inconnu peut signifier des conditions inconnues, ce qui peut rendre raisonnable le fait de le bloquer
  • Certains estiment qu’aucun navigateur n’a de base légitime pour imposer ce type de conditions aux développeurs de sites web, et que cette question de politique doit être traitée séparément de la proposition d’API elle-même

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

  • L’équipe Chrome Prompt API a partagé le blink-dev I2S ainsi que la mise à jour ChromeStatus sur les risques d’interopérabilité et de compatibilité
  • Elle souhaite maintenir la participation et les discussions au sein du WebML CG ; d’autres expérimentations doivent suivre, comme celles sur des sampling parameters interopérables
  • Côté Chrome, la motivation affichée est de faire des Language Model fournis par le navigateur et l’OS une option utile pour les développeurs web et les utilisateurs, tout en préservant à long terme la santé et la neutralité de la plateforme web
  • La surface de la Prompt API a montré un certain degré de compatibilité avec les modèles de Google comme de Microsoft, et des contraintes de réponse objectives sont appliquées pour forcer des sorties conformes à des schémas JSON ou à des regex connus
  • Ces contraintes servent de mesure d’atténuation pour réduire le besoin de hacks spécifiques à chaque modèle afin de gérer des sorties imprévisibles
  • Des projets Chromium downstream explorent des modèles alternatifs et des backends de framework, notamment un travail d’intégration de Android MLKit chez Microsoft et un prototypage initial d’intégration du foundational model d’Apple
  • Pendant la phase d’API trial, plusieurs versions de modèles ont été déployées à titre expérimental ; les mises à jour et améliorations de modèles restent nécessaires, et la prise en charge de modèles plus récents comme les Gemma 4 open models est également à l’étude
  • Des categorical sampling modes sont aussi explorés pour mieux ajuster le comportement interopérable entre différentes architectures sous-jacentes
  • Le passage Interoperability and Compatibility de blink-dev indique que la variabilité du comportement et des réponses est une attente bien comprise pour les 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

Les arguments de soutien des développeurs web et les critiques du lancement

  • 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 justification est présentée comme peu cohérente avec une évaluation « Strongly positive »

  • Éléments listés comme justification

    • Un thread GitHub avec 2 réponses positives
    • Un post unique sur X
    • Un billet de blog qui n’existe plus, renvoyant un état Server Not Found
    • Un billet de blog toujours disponible
    • Un sondage qui semble demander aux développeurs si cette API serait acceptable même si elle existait dans des extensions, sans préciser le nombre de réponses ni le public visé
    • Le billet de blog disparu est partagé via une archive Wayback Machine
    • Même si la documentation met fortement en avant ce sur quoi il ne faut pas compter et ce sur quoi on peut compter, il reste flou de savoir si, en suivant ces recommandations, l’API conserve encore un usage réellement utile
    • En pratique, on peut dans une certaine mesure s’appuyer sur le comportement du modèle précis testé, et si ce modèle est celui de Chrome, un site peut afficher une recommandation d’utiliser la dernière version de Chrome
    • Le fait que Google identifie largement les zones encore inachevées tout en jugeant les mesures d’atténuation actuelles suffisantes pour un lancement reste un point problématique

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 possibles, et certains estiment qu’il faut davantage regarder du côté d’une browser automation API et d’un mode Lynx pour le chat que de la Prompt API
    • Certains workflows reposent sur une connexion humaine au site, puis sur une extension AJAX qui rend les fichiers visibles, après quoi un agent utilise chromedriver/webdriver pour télécharger des documents, les étiqueter et les résumer
    • 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 assets média
    • Sont également évoqués un balisage robots plus fin au niveau HTML, un handoff entre le shell Lynxmode et le navigateur classique, et un affichage sélectif de liens façon Google AdWords old-school dans un navigateur piloté par agent

  • Web ouvert et FOMO

    • Certains rétorquent que le web ouvert n’est pas en concurrence avec les chat bot super apps sur le même terrain ni de la même manière, et qu’il ne va pas disparaître
    • D’autres estiment qu’au lieu de céder à une FOMO permanente, il faut d’abord se demander ce que l’on veut représenter
    • Il existe aussi un courant qui ne partage pas l’idée selon laquelle, si le web ne prend pas rapidement et efficacement en charge l’agentic computing comme il n’a pas su suffisamment embrasser le paradigme des applications mobiles, le commerce ou le journalisme basculeraient hors du web ouvert

  • Déploiement dans Chromium et mesure des dommages

    • L’un des approbateurs blink API owner de Chromium dit partager les inquiétudes de Mozilla, mais préfère une voie fondée sur l’expérimentation, l’apprentissage par l’erreur et la concurrence
    • Pour évaluer de futurs dommages réels, il faut définir des résultats concrets ; dans ce contexte, comparer 5 à 10 ans plus tard les effets réels de décisions controversées de lancement d’API comme EME a été jugé utile
    • Les dommages d’un verrouillage de sites sur un modèle spécifique à Google peuvent être mesurés par le nombre et l’ampleur des bugs de compatibilité rencontrés quand d’autres navigateurs lancent la fonctionnalité, ainsi que par la nature des bugs qui apparaissent lorsque Chrome met à jour son modèle
    • Il est proposé de distinguer les bugs relevant d’un « modèle rendu plus intelligent » de ceux relevant de la « préservation d’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 d’autres modèles, ce qui fournit déjà des données initiales
    • Pour les inquiétudes liées aux TOS, l’indicateur de dommage serait l’existence réelle de poursuites ou de menaces fondées sur des violations, avec l’idée de constituer un historique des preuves en ce sens

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

    • L’idée de vérifier concrètement les dommages potentiels est jugée valable, mais seulement s’il existe des mesures d’atténuation significatives une fois les dommages constatés
    • Sont alors posées des questions sur les options possibles si des sites se verrouillent sur un modèle Google précis : retirer la fonctionnalité, modifier le modèle pour casser des prompts de site trop optimisés, faire une rotation aléatoire des modèles, ou standardiser de manière ouverte les poids des modèles on-device
    • Il est aussi avancé que, si des preuves apparaissent montrant que d’autres navigateurs doivent copier un quirk étrange du modèle de Chrome, alors depuis une position de leadership dans Chromium, Chrome devrait être poussé à casser ce quirk
    • Un précédent est rappelé : Mobile GMail dépendait de quirks bogués de border-image dans WebKit ; quand Firefox a eu l’impression de devoir les copier, Chrome a été corrigé d’une manière qui cassait GMail, puis GMail a été rapidement mis à jour sans que les utilisateurs ne s’en aperçoivent

À lire aussi

1 commentaires

 
GN⁺ 2026-05-01
Réactions sur Hacker News

  • L’argument contre semble assez clair : un couplage fort entre le prompt et le modèle, ainsi qu’un problème de neutralité vis-à-vis des modèles dans les conditions d’utilisation
    Comme dans le cas personnel cité sur https://github.com/mozilla/standards-positions/issues/1213, lors de la création d’un prompt système pour des notifications de domotique, Gemini répondait au départ d’une manière trop américaine ; après lui avoir indiqué qu’il parlait avec une voix britannique, il s’est mis cette fois à produire une imitation britannique maladroite vue par un Américain, du genre « a'waight guv'nor apples and pears », ce qui a nécessité encore plus d’ajustements
    Au cours de ce processus, le prompt système se retrouve adapté à un modèle précis, alors que d’autres modèles ont d’autres quirks, si bien qu’une correction ajoutée pour un modèle peut devenir une surcorrection pour un autre

    • Le résultat donne l’impression de se faire tourner en ridicule en mode adversarial
    • Si c’est une bonne raison de ne pas prendre en charge les fonctionnalités LLM, il faudrait en conclure qu’il ne faut les mettre dans aucune API de plateforme. Or elles ont déjà été ajoutées à d’innombrables plateformes
      Le fait que chaque modèle soit différent est une caractéristique fondamentale de cette technologie. C’est comparable au fait que la taille d’un canvas varie selon l’appareil ou l’orientation, que la précision de l’API de géolocalisation diffère, ou que les voix de Speech Synthesis varient selon les appareils
      Cela ressemble moins à une critique constructive qu’à un sentiment anti-IA. Aujourd’hui il faut une UI de permissions, et un jour il y aura peut-être des niveaux de QI du type low/medium/high, mais les développeurs qui s’en soucient finiront de toute façon, à 90 %, par dépendre d’un modèle particulier
      Avec le temps, quand l’hostilité envers l’IA retombera et que les gens verront qu’elle est utile, l’absence de cette fonctionnalité dans Firefox pourrait passer pour un échec du point de vue de l’autonomie des données personnelles. Si les TOU concernées de Chrome posent problème, cela devient au contraire une raison pour que Firefox propose cette fonctionnalité avec des conditions d’utilisation du modèle qui ne posent pas ce problème

  • Je ne savais pas qui avait écrit l’opposition, mais c’était Jake Archibald, un ancien Googler qui a longtemps travaillé dans l’équipe Chrome, parti chez Mozilla et auteur d’un texte s’opposant à une API Chrome. Il n’est pas surprenant que la critique soit bien structurée, et il a sans doute dû se sentir soulagé de ne pas avoir à suivre la ligne du parti cette fois

    • Merci, mais je pense qu’il ne suivait déjà pas la ligne du parti quand il était chez Google. C’est juste que cela lui rendait la vie de plus en plus difficile en interne, et il a fini par partir
      D’après ce que disent des gens encore dans l’équipe, la situation se serait même dégradée de façon exponentielle sur cet aspect
    • Il connaît sûrement très bien le repo standards-positions, et cela se lit comme une défense typique quand Google pousse quelque chose sans consultation suffisante
      Au lieu de proposer des modifications, cela cherche à jeter l’ensemble, comme s’ils espéraient qu’en cas d’abandon on reparte de zéro de manière collaborative plutôt que depuis le point de vue de l’équipe Google Chrome. Cela dit, j’ai rarement vu ce genre d’approche bien fonctionner, donc il vaudrait probablement mieux proposer simplement des changements concrets

  • Je suis contre

    1. Cela devient une nouvelle information de fingerprinting, et comme il est difficile de tromper un script de fingerprinting, cela peut être détourné pour de la « vérification d’appareil ». On ne devrait pas pouvoir « vérifier » un navigateur, et tout le monde devrait pouvoir émuler n’importe quel navigateur
    2. Les LLM consomment beaucoup de mémoire et de CPU, et vu le prix actuel de la RAM, les upgrades coûtent aussi cher. Si des sites web dépendent d’un modèle local, ils seront lents sur les appareils d’entrée de gamme
    3. L’API semble pensée pour un LLM spécifique comme OpenAI
    4. Cela peut évincer du marché des navigateurs les concurrents qui n’ont pas leur propre modèle d’IA. Si des sites sont conçus en supposant le modèle Gemini de Google, ils risquent de se casser avec d’autres modèles, ou dans des navigateurs nationaux sans modèle d’IA, et il ne devrait pas y avoir de navigateurs de « première classe » et de « seconde classe »
      L’explainer dit que les données peuvent être traitées en local sans être envoyées nulle part, mais dans ce cas on peut se demander pourquoi un modèle local Google Gemini a besoin d’une Prohibited Use Policy. Pourquoi Google se soucierait-il de prompts et de réponses qu’il ne peut pas connaître ?
      L’accès à un LLM hors ligne semble intéressant en soi, mais il n’est pas nécessaire d’intégrer un LLM dans le navigateur pour cela : les sites peuvent utiliser WebGPU, ou on peut améliorer WebGPU pour le traitement de modèles ML. Sinon, il faudrait que tout le monde utilise le même LLM open source
    • Google fait comme une autre bactérie : il agite son flagelle dans la direction où se trouve l’argent et va simplement par là. Je ne comprends pas pourquoi qui que ce soit penserait encore que Google va faire quelque chose de bon pour le web ou pour l’humanité
    • Je suis fortement en désaccord avec l’idée qu’« on ne devrait pas pouvoir vérifier le navigateur ». Le secteur de l’IA a complètement déchiré le consensus social pré-Covid autour de l’anti-scraping et de l’anti-botting
      Le fait que robots.txt ne soit pas contraignant et puisse être entièrement contourné est désormais admis, ce qui a pratiquement transformé le web ouvert en dark forest
      Il est très probable qu’on finisse par voir apparaître des moyens de vérifier qu’une session de navigateur n’a pas été falsifiée ou qu’elle est « trusted ». C’est vraiment détestable, mais au fond nous l’avons aussi un peu provoqué nous-mêmes
    • Concernant l’inquiétude sur le fingerprinting, je pense qu’il y aura dans Chrome, et bien sûr aussi dans Firefox, une option « ne jamais télécharger de LLM et désactiver toutes les fonctionnalités LLM »
      Il est possible qu’un site envoie de petites requêtes à un LLM afin de fingerprint le modèle lui-même, mais si on peut désactiver cela, je ne pense pas que ce soit un énorme problème
      Plus largement, il y a une inquiétude de la forme « la plateforme web ne devrait pas pouvoir faire cela ». Dans cette logique, même si l’utilisateur peut désactiver la fonction, on dira que des sites du style « navigateur non pris en charge car pas de LLM » vont apparaître et dégrader le web
      Mais au final, c’est une décision de l’exploitant du site de couper son site en l’absence de LLM ; ce n’est pas la faute de la plateforme qui a créé la fonctionnalité ni de ses mainteneurs. C’est comparable au fait que cela fonctionne très bien sur Firefox mais que le support soit désactivé juste parce que tester est trop pénible
      Le web n’est pas en concurrence avec les PDF, il est la plateforme applicative la plus réussie au monde dans un univers où il est en concurrence avec SwiftUI. L’option « garder le web statique tel qu’il est » est une illusion ; en réalité, le choix est soit d’adapter le web aux besoins changeants des utilisateurs, soit de laisser le web échouer et voir SwiftUI ou WinUI prendre sa place. La seconde option est bien pire
    • En lisant les réponses de ce fil, j’ai réalisé quelque chose : de toute façon ils vont le faire, et des gens déjà dépendants des LLM ou incapables d’évaluer correctement la situation les applaudiront
      https://news.ycombinator.com/item?id=47960596
      La conclusion, c’est qu’il est temps de passer à autre chose. Il faut imaginer un meilleur format d’échange d’informations en ligne et de lecture de médias que le navigateur web. Si nous sommes la marchandise, alors les outils que nous utilisons ne devraient pas se comporter comme des proxys qui reversent subrepticement les revenus publicitaires à des maîtres peu dignes de confiance ; ils devraient refléter directement cette réalité

  • Plus j’y pense, plus je suis cette fois davantage d’accord avec la conception d’API de Google
    Le couplage fort entre le prompt et le modèle est une vraie inquiétude, et c’est un problème que je rencontre tous les jours. Mais si la solution consiste en une API qui couple encore plus fortement le prompt à évaluer avec le modèle présent dans le navigateur de l’utilisateur, on va vite arriver à des situations du type « notre prompt n’a été testé que sur Gemini, donc ce site nécessite Chrome »
    Pire encore, on peut aboutir à « impossible d’identifier le modèle d’IA utilisé ». C’est tout à fait plausible si un site créé en 2026 n’est pas mis à jour avant 2030
    Cela rejoint aussi le problème de conditions d’utilisation évoqué en coulisses par un ingénieur Mozilla. Si l’on veut qu’il existe des navigateurs dans lesquels on n’a pas à accepter les conditions d’utilisation d’un modèle d’IA donné — par exemple un navigateur utilisant un bon modèle open source — alors il est préférable de rendre le fingerprinting des Big Models impossible
    Bien sûr, beaucoup de sites feront de toute façon des appels du style isChrome(). Malgré cela, je suis en général opposé aux changements qui multiplient les moyens de fingerprinting du navigateur. Les avantages liés à l’anonymat du modèle l’emportent sur les inconvénients de sorties occasionnellement bizarres dues à de petites différences entre des modèles comme Gemini et Qwen

  • Je ne comprends pas pourquoi Google continue à dépenser des ressources énormes pour ajouter du bric-à-brac et transformer le navigateur en Homermobile, au lieu de corriger les faiblesses structurelles des très nombreuses choses que le navigateur sait déjà faire
    Pourquoi ne pas se concentrer sur les éléments fondamentaux qui amélioreraient la qualité de vie de toute la plateforme web, du blog statique au e-commerce en passant par les web apps de pointe
    https://simpsons.fandom.com/wiki/The_Homer

    • Google ne développe pas Chrome pour fabriquer un meilleur web. Faire un bon navigateur pour lui-même reviendrait à dépenser des milliards de dollars en goodwill, alors que l’objectif de Chrome est de devenir, pour l’utilisateur, la plateforme qui remplace son OS quand il fait quelque chose sur son appareil
      Ils essaient directement avec Android et ChromeOS, mais Chrome permet aussi qu’un utilisateur moyen sous Windows, par exemple, passe l’essentiel de son temps à l’intérieur du monde Google
    • Pour être promu chez Google, il faut lancer une prompt API
    • Le fait de ne pas implémenter la prompt API ferait-il vraiment réaffecter des ressources à d’autres sujets qui n’étaient pas jugés importants auparavant ? Cela ressemble à une fausse dichotomie

  • Je pense très fortement que les LLM actuels et leurs API harness ne sont pas techniquement assez mûrs pour qu’une API de ce type entre dans un standard
    Mais s’il faut vraiment le faire, cela devrait au minimum passer par une permission en opt-in par site, et il devrait exister un moyen d’identifier à quel modèle sont envoyés les prompts. De petits ajustements du prompt système devraient eux aussi faire partie de cette identité
    En tant qu’utilisateur, j’ai besoin d’être certain qu’en visitant un site quelconque je ne serai pas fingerprinté via cette API sans mon accord
    En tant que développeur, j’ai besoin de savoir quel modèle utilisent les utilisateurs afin d’avoir la possibilité de créer des prompts spécifiques à chaque modèle

  • « On s’attend de plus en plus à ce que les navigateurs et les systèmes d’exploitation accèdent à des modèles de langage » ? Vraiment ?
    https://github.com/webmachinelearning/prompt-api/blob/main/R...

    • Je pense que c’est la mauvaise direction. Je ne veux pas que l’OS ou le navigateur ait accès à un LLM, mais je veux qu’un LLM ait accès au navigateur ou à l’OS, et c’est déjà ce qui se passe
      Donc il suffirait à mon avis de ne fournir qu’une interface pour les LLM, désactivée par défaut et activable si l’utilisateur le souhaite
      Cela permettrait aussi de choisir quel LLM provider utiliser, au lieu d’être verrouillé sur le LLM intégré par Apple dans l’OS. Par exemple, j’aimerais que Claude puisse accéder aux mêmes choses qu’Apple Intelligence
    • C’est moi qui avais écrit cette phrase à l’origine, et je ne pensais pas qu’elle serait comprise ainsi. Je ne voulais pas parler des attentes des utilisateurs ou des développeurs, mais de la tendance de l’industrie à embarquer des LM dans les OS et les navigateurs, ou à s’y préparer
      On pourrait maintenant remplacer « on s’attend à ce qu’ils y accèdent » par « ils sont en train d’être embarqués ». Beaucoup de gens semblent se méprendre à ce sujet, donc ce serait bien que l’équipe de maintenance du projet mette cela à jour
    • macOS, iOS et Windows ont des API de modèles locaux pour les développeurs tiers, et Chrome est aussi en phase d’essai. Firefox génère de l’alt-text avec un modèle, mais sans API
      En théorie, c’est utile. Si les développeurs peuvent compter sur un modèle local, cela devient plus private et plus decentralized, et réduit aussi le besoin d’envoyer de l’argent à AWS ou Anthropic. Le local permet également des usages à faible enjeu qui n’ont de sens que si cela fonctionne hors ligne et gratuitement
      Mais dans les faits, j’ai très peu vu d’adoption de Apple Foundation Models dans des apps natives. Je serais curieux d’avoir des retours de développeurs Mac/iOS
    • L’IA donne un pouvoir énorme aux gens qui ne savent faire que du bikeshedding. L’IA elle-même est probablement aussi un bikeshed, mais il existe tout de même des usages légitimes, ainsi qu’un pouvoir nouveau pour faire durer plus longtemps des discussions en faveur d’idées inutiles que les arguments contre
      Désormais, tout semble attendre son bikeshed. Les CVE aussi, j’imagine
    • On dirait que la surface d’API du navigateur n’est toujours pas encore suffisamment obscènement large

  • Le bon côté des protocoles ouverts, c’est qu’on n’est pas obligé de soutenir ni d’utiliser une implémentation particulière, mais malgré cela le monopole des navigateurs reste un dilemme permanent
    Il existe de bons projets comme ungoogled chromium ou Tor, mais le plus gros problème est l’absence de projets qui portent une voix pour le grand public et parviennent à toucher les masses
    Une part non négligeable des utilisateurs peu informés se moque de la cause et de la façon de faire passer le message, et réagit davantage à ce qui est « amusant » et offre moins de friction qu’à la liberté et au contrôle
    Comment résoudre cela ? Comment faire du navigateur quelque chose qui nous appartienne, par les gens et pour les gens ? Chaque fois que j’y pense, cela me rend simplement triste

    • Compiler son propre navigateur rend en fait les choses encore pires. Si l’on veut Spotify ou Netflix, il faut Widevine avec attestation, et au final il faut payer Google
      Si la chaîne Browser Agent n’est ni Chrome ni Firefox, on se retrouve face à une interminable succession de CAPTCHA Cloudflare ou de 403
    • Il faut commencer par apprendre les API de la plateforme plutôt que d’embarquer Chrome dans des applications « natives »
      Ensuite, il faut construire des applications web sur la base des standards du web, pas sur la base de ce que fait Chrome, et ne pas se plaindre que Firefox et Safari ne suivent pas
    • C’est simple. Il suffit de démanteler toutes les grandes entreprises technologiques avec le droit de la concurrence. Ce sont les robber barons de notre époque
    • Malheureusement, la réponse est presque toujours un financement public substantiel
    • Il existe déjà de bons navigateurs, et l’utilisateur moyen utilise Chrome. Les personnes concernées basculent vers les premiers. Quel est exactement le problème à résoudre ?
      Tu dis qu’il faut des projets qui touchent le grand public, tout en disant que ce même public veut moins de friction plutôt que la liberté et le contrôle. Il y a une contradiction. L’utilisateur moyen est plus sensible au less friction qu’au contrôle

  • Je me demande quel est le use case de cette API
    Mon expérience avec les LLM locaux consiste à lancer llama-server, éventuellement sur une machine séparée, puis à configurer d’autres applications pour qu’elles pointent vers ce serveur compatible OpenAI au lieu d’OpenAI ou d’un service similaire
    Je ne veux pas que le navigateur crée ou exécute une instance de LLM, parce que la machine peut ne pas avoir la capacité ni la marge nécessaire pour faire tourner une telle instance

  • Je me demande si cela ne révèle pas un fossé entre une jeune génération qui ne peut déjà plus vivre sans LLM, et une génération plus ancienne qui ne veut pas qu’on lui impose jusqu’à un superordinateur juste pour faire tourner un navigateur web qui porte atteinte à la vie privée
    À mes yeux, cela ressemble au moment où les gens commencent à chercher et développer des alternatives au navigateur/web

    • Cela ne signifie pas que Mozilla a adopté une position anti-IA
      Cela explique simplement, de manière claire et logique, pourquoi l’API proposée dans sa forme actuelle est mauvaise pour l’interopérabilité du web
    • Je pense que l’opposition ici n’a rien à voir avec le fait d’aimer ou non les LLM. La question est de savoir si cette proposition précise d’API ouverte pour le web est viable
      Personnellement, j’utilise des LLM pour l’aide au code et la domotique, mais je ne pense pas que cette API soit bonne pour le web
    • D’après mon expérience, les jeunes détestent en général l’IA
    • C’est un peu hors sujet, mais je pense que ce qui doit être repensé se rapproche davantage du concept même de système d’exploitation que de l’interface des navigateurs
      Je n’ai pas la réponse, mais après avoir utilisé Niri/Wayland, GNOME, Windows et Mac, je ne reviendrai jamais à un desktop non tiling ni à un workflow de gestion de fenêtres orienté autrement que par le clavier
    • Le bateau du « navigateur intrusif pour la vie privée qui exige un superordinateur » a déjà quitté le port en 2008