Extension WebUSB pour Firefox

• Une extension qui permet d’utiliser l’API WebUSB, auparavant prise en charge uniquement par Chrome, dans Firefox, en communiquant avec un programme externe au navigateur via le mécanisme de Native Messaging
• Nécessite l’installation conjointe de l’extension de navigateur (.xpi) et d’un stub natif pour fonctionner
• Conçue avec pour objectif la compatibilité avec l’implémentation WebUSB de Chrome, mais inutilisable dans les Web Workers ; l’API n’est exposée que sur la page principale
• Android n’est pas pris en charge, car Native Messaging n’y existe pas
• Fournit des binaires précompilés pour 6 plateformes, dont macOS (x86_64/ARM64), Linux (x86_64/aarch64) et Windows (AMD64/ARM64)
• Les scripts d’installation (install.sh / install.bat) automatisent la copie des fichiers et la configuration du manifeste natif
• Le stub natif est entièrement écrit en Rust, avec prise en charge native de la compilation croisée
• Configuration système requise : macOS 10.15+, Windows 10+, noyau Linux 4.8+ (udev requis)
• Licence : 0BSD

[GN⁺]

Commentaires sur Hacker News

• Avant, je détestais assez fortement WebUSB/Bluetooth pour des raisons idéologiques, mais j’ai changé d’avis en voyant des cas comme les applis de contrôle de panneaux d’escalade ou netMD pour transférer vers un MiniDisc en USB. Installer une appli native me semblait excessif pour ce genre d’usage, donc je suis content de voir qu’il existe maintenant une option aussi dans Firefox

  • Même ressenti ici. J’étais sceptique au début, mais après avoir utilisé WebUSB dans une appli web de configuration de clavier mécanique, jusqu’au flash du firmware directement dans le navigateur, j’ai trouvé ça franchement pratique et convaincant. Avec ZSA flash, des tâches qui demandaient autrefois de télécharger un fichier de disposition puis de le flasher avec un programme dédié peuvent maintenant être faites uniquement avec un navigateur basé sur Chromium, ce qui simplifie énormément les choses
  • Moi, c’est justement pour ça que je ne veux pas de WebUSB. Si les fabricants de matériel finissent par dépendre uniquement d’applis web pour les mises à jour et la configuration, je crains qu’un jour, si le service disparaît ou ne peut plus être exécuté en local, on ne puisse même plus configurer de vieux appareils pourtant encore en parfait état. Quand on pense à du matériel qu’on garde plus de 10 ans, comme des appareils photo, instruments de musique ou interfaces audio, c’est un scénario particulièrement regrettable
  • Le fait que toutes sortes d’outils jusque-là réservés à Windows puissent fonctionner sur n’importe quel OS grâce à webusb me semble être une énorme amélioration
  • Aujourd’hui, installer une appli native peut sembler excessif, mais dans 20 ans, si le site web qui servait à gérer cet appareil a disparu, on risque de se retrouver avec les mêmes désagréments
  • J’ai aussi trouvé marquant que, pour installer GrapheneOS sur un téléphone, WebUSB soit en pratique la voie principale

• Je trouve WebUSB vraiment excellent. On peut distribuer des applis cross-platform qui accèdent au matériel sans gérer tous les écarts entre plateformes, et les pilotes peuvent être sandboxés de manière raisonnable. Pour renforcer encore la sécurité, il serait aussi envisageable de n’autoriser par défaut que les appareils avec des descripteurs WebUSB, avec un avertissement supplémentaire pour les autres

  • Sur des imprimantes thermiques achetées récemment, le support Chromebook — autrement dit le support WebUSB — a beaucoup pesé dans ma décision d’achat. Sur des appareils dont la prise en charge par les pilotes d’impression natifs est floue, le fait de pouvoir passer par une extension Chrome aux permissions limitées plutôt que par un pilote douteux avec accès à tout le système m’a beaucoup rassuré. J’ai aussi apprécié de pouvoir tester des applis RTL-SDR sans compiler les sources, et je trouve ça assez frustrant de devoir passer de Firefox à Chrome dès que WebUSB ou Web Serial est nécessaire
  • Cette limitation me paraît trop stricte. Au pire, afficher un avertissement suffirait, et pour des usages comme le retrocomputing, on utilise souvent aussi des appareils non balisés, donc ce serait gênant de les bloquer
  • Rien qu’au cours des 3 derniers mois, j’ai flashé des FlipperZero, des appareils Android et des talkies-walkies portables chinois sans avoir à installer d’applis douteuses hors sandbox. Franchement, ça ressemble presque à une révolution

• J’ai récemment installé GrapheneOS sur le Pixel d’un ami, et j’ai été assez surpris qu’on puisse faire tout le processus depuis le navigateur avec WebUSB seulement. Le seul inconvénient, c’était qu’il fallait lancer Chromium

  • On peut même installer GrapheneOS d’un Pixel vers un autre Pixel, donc aucun PC n’est nécessaire. C’est précisément le genre d’expérience qui m’a convaincu de l’utilité concrète de WebUSB, et sur un appareil GOS, on peut aussi utiliser Vanadium au lieu de Chrome
  • Je trouve Web USB et Web Bluetooth tous les deux excellents. J’ai utilisé Web MiniDisc pour gérer des MiniDisc, et j’ai aussi flashé depuis le web un firmware personnalisé pour thermomètre/hygromètre BLE Xiaomi afin de l’intégrer à Home Assistant. J’apprécie particulièrement le fait que ce genre d’opérations soit devenu possible sans lancer de scripts douteux ni de binaires locaux
  • Moi, je l’ai aussi utilisé deux fois sans problème dans Firefox. J’utilise nextdns sur le routeur, donc je ne sais pas si ça a aidé, mais en tout cas ça a fonctionné

• Des projets comme GrapheneOS, ESPHome et Meshtastic exploitent déjà très bien WebUSB, et Google l’a aussi utilisé pour transformer les manettes Stadia en périphériques Bluetooth standard. Même chose pour les outils de configuration des fabricants de claviers. Comme l’utilisateur doit sélectionner explicitement l’appareil, le modèle de sécurité me paraît raisonnable, et je trouve regrettable que Mozilla refuse cela nativement, dans une attitude qui rappelle assez ce qu’on a vu chez eux ces 10 dernières années

  • Honnêtement, je pense qu’une extension est la forme la plus appropriée pour ce genre de fonctionnalité. Laisser des sites web accéder directement aux piles USB ou Bluetooth reste un usage trop de niche pour être intégré par défaut ; un modèle opt-in me semble plus adapté. Comme avec les applis séparées de type navigateur Bluetooth sur iOS, avoir un chemin distinct qu’on n’utilise qu’en cas de besoin me paraît être une meilleure ingénierie, car cela réduit à la fois la surface d’attaque et l’embonpoint du navigateur. J’aimerais que davantage de ces énormes API web en JS deviennent des plugins

• Aujourd’hui, même des applis locales sont de plus en plus distribuées sous forme de html & js réservés à Chrome. Indépendamment de ce qu’on pense de l’accès USB depuis le navigateur, je déteste encore plus l’idée de se voir à nouveau imposer Chrome, comme à l’époque où IE était incontournable

  • J’ai toujours envie de reconstruire le web comme un lecteur de documents hypertextes sans kitchen sink. Avec les LLM, j’ai l’impression que ce genre de prototype est plus réaliste qu’avant

• Sur des plateformes matérielles éducatives comme le BBC Microbit, WebUSB a changé la donne. Pour faire découvrir le matériel aux élèves, ça fonctionne simplement, et grâce à des IDE web comme MakeCode ainsi qu’aux URL de référence du code, le partage et le débogage deviennent aussi beaucoup plus simples

• Cette implémentation ressemble à une excellente proof of concept. Faire tourner un exécutable séparé à côté du navigateur n’est pas la forme finale de WebUSB que j’aimerais, mais je suis déjà content de voir que quelqu’un travaille réellement à résoudre ce problème

  • À l’inverse, je n’aime pas vraiment l’idée de gérer l’USB directement dans le navigateur

• Ma première réaction a été de penser que c’était une idée affreuse. Je n’aime pas que des sites web accèdent au matériel, et l’accès à la webcam est déjà largement assez pénible comme ça

  • Je vois ça un peu différemment. Avant, pour mettre à jour le firmware d’un appareil, il fallait télécharger une appli C++ sortie de nulle part et lui donner l’ensemble des permissions de l’utilisateur sur le système. Avec WebUSB, on ouvre un site, on exécute un flux dans une sandbox, et quand le navigateur le demande, on peut donner l’autorisation en sélectionnant exactement ce seul périphérique USB. Il ne peut pas accéder aux autres périphériques USB, au système de fichiers, aux API système, à l’inscription au démarrage ni installer des mises à jour automatiques, donc je trouve la posture de sécurité plutôt meilleure
  • Qu’on aime ou non, la frontière entre applis et pages web est déjà devenue très floue, et je pense qu’elle va continuer à l’être. Même les applis locales utilisent de plus en plus le navigateur comme interpréteur au lieu de Python et Qt
  • Le problème est simple : il suffit de ne pas accorder l’accès. En revanche, je préférerais qu’on n’essaie pas d’empêcher les autres de faire ce qu’ils veulent avec leur matériel. Un monde où il ne reste que des écosystèmes fermés d’entreprise serait une bien pire direction
  • Si ça ne vous plaît pas, il suffit de ne pas sélectionner l’appareil et de ne pas cliquer sur le bouton allow
  • Les sites web utilisent déjà le CPU et la RAM ; ça fait déjà partie de leur mode de fonctionnement

• Pour l’instant, la spécification est encore à l’état de draft, et tant que les inquiétudes de sécurité ne seront pas suffisamment levées, je ne me réjouis pas de la voir arriver dans les navigateurs

  • À l’inverse, j’estime que le problème de sécurité quand WebUSB n’existe pas, c’est qu’il faut installer des pilotes natifs peu dignes de confiance chaque fois qu’on veut utiliser un périphérique USB
  • Dans ce cas, j’aimerais comprendre quelles sont exactement les implications de sécurité supplémentaires qu’introduit WebUSB, par rapport à des situations comme le flash de smartphone où il faut déjà télécharger un programme natif
  • Je partage l’idée que si la spécification est encore en draft, c’est parce qu’Apple bloque toute avancée. Des API comme WebUSB et WebBluetooth entrent en concurrence avec l’App Store, donc ils semblent les voir d’un mauvais œil pour des raisons de revenus. Dans les faits, le modèle de sécurité n’est pas très différent d’autres API navigateur à permissions, puisque l’utilisateur doit explicitement autoriser l’accès à l’appareil pour chaque site
  • C’est pour ça que, quand Firefox n’intègre pas ce genre de fonction de base, je garde un instance Chrome séparé que je n’ouvre qu’en cas de besoin

• Si WebUSB et WebBLE étaient pris en charge partout, je pourrais distribuer mon appli IoT uniquement via le web, ce qui ferait énormément monter ma productivité. La réduction des tracas liés aux app stores est particulièrement attirante

  • Je viens juste de découvrir ça, et je me demande maintenant si le DVR de CCTV que j’ai en tête pourrait fournir une appli web sur téléphone, avec même du streaming vidéo. Pour chercher, on trouve de meilleurs résultats avec Web Bluetooth API qu’avec webble