Extensión WebUSB para Firefox

• Una extensión que permite usar la API WebUSB en Firefox, antes disponible solo en Chrome, y que se comunica con programas externos al navegador mediante el mecanismo de Native Messaging
• Para funcionar, requiere instalar tanto la extensión del navegador (.xpi) como el stub nativo
• Fue diseñada con el objetivo de mantener compatibilidad con la implementación de WebUSB de Chrome, pero no puede usarse en Web Workers; la API solo se expone en la página principal
• Android no es compatible porque no cuenta con Native Messaging
• Ofrece binarios precompilados para 6 plataformas, incluyendo macOS (x86_64/ARM64), Linux (x86_64/aarch64) y Windows (AMD64/ARM64)
• El script de instalación (install.sh / install.bat) automatiza la copia de archivos y la configuración del manifiesto nativo
• El stub nativo está escrito completamente en Rust y admite compilación cruzada de forma predeterminada
• Requisitos del sistema: macOS 10.15+, Windows 10+, kernel Linux 4.8+ (requiere udev)
• Licencia: 0BSD

[GN⁺]

Comentarios de Hacker News

• Antes me disgustaban bastante WebUSB/Bluetooth por razones ideológicas, pero cambié de opinión al ver casos como apps para controlar muros de escalada o netMD para transferir a MiniDisc por USB. Instalar una app nativa me parecía excesivo para esos usos, y me alegra que ahora también haya una opción en Firefox

  • A mí me pasó algo parecido. Al principio era escéptico, pero después de usar WebUSB en una webapp para configurar teclados mecánicos e incluso flashear firmware directamente desde el navegador, me pareció bastante cómodo y bueno. Cosas como ZSA flash, que antes requerían descargar un archivo de layout y grabarlo con un programa dedicado, ahora se pueden hacer solo con un navegador basado en Chromium, y eso lo simplifica mucho
  • Justamente por eso no quiero WebUSB. Si los fabricantes de hardware hacen que las actualizaciones y la configuración dependan solo de una webapp, me preocupa que algún día el servicio desaparezca o deje de poder ejecutarse en local, y entonces ni siquiera se pueda configurar un equipo viejo aunque siga funcionando bien. Pensando en cámaras, instrumentos u interfaces de audio que uno usa por más de 10 años, sería un escenario especialmente triste
  • Me parece una mejora enorme que varias herramientas que hasta ahora eran solo para Windows puedan funcionar en cualquier sistema operativo gracias a webusb
  • Puede que hoy instalar una app nativa parezca excesivo, pero dentro de 20 años podríamos volver a sufrir el mismo problema si el sitio web que gestionaba ese equipo desaparece
  • También me impresionó que al instalar GrapheneOS en un teléfono, WebUSB sea prácticamente la vía principal

• A mí WebUSB me parece realmente excelente. Permite distribuir apps multiplataforma que acceden al hardware sin tener que manejar una por una las diferencias entre plataformas, y además los drivers se pueden aislar razonablemente en sandbox. Si se quisiera reforzar más la seguridad, también sonaría bien permitir por defecto solo dispositivos con descriptor WebUSB y mostrar advertencias adicionales para los demás

  • En unas impresoras térmicas que compré hace poco, el soporte de Chromebook bajo ese nombre de soporte WebUSB influyó mucho en mi decisión de compra. En dispositivos donde el soporte de drivers de impresión por defecto es dudoso, me dio mucha más confianza poder resolverlo con una extensión de Chrome con permisos limitados en vez de un driver sospechoso con acceso a todo el sistema. También me gustó poder probar apps de RTL-SDR de inmediato sin compilar desde el código fuente, y cada vez que tengo que pasarme de Firefox a Chrome por WebUSB o Web Serial me resulta bastante frustrante
  • Esa restricción me parece demasiado fuerte. Como mucho bastaría con mostrar una advertencia, y usos como retrocomputing dependen mucho de dispositivos sin etiquetas, así que bloquearlos sería problemático
  • Solo en los últimos 3 meses he flasheado FlipperZero, Android y radios portátiles chinas sin tener que instalar apps sospechosas fuera del sandbox. Eso de verdad se siente casi revolucionario

• Hace poco le instalé GrapheneOS al Pixel de un amigo, y me sorprendió bastante poder completar todo el proceso solo con WebUSB desde el navegador. La única desventaja fue tener que abrir Chromium

  • Incluso se puede instalar GrapheneOS desde un Pixel a otro Pixel, así que ni siquiera hizo falta una PC. Esa experiencia fue justo la que me convenció de la utilidad práctica de WebUSB, y en un dispositivo con GOS también se puede usar Vanadium en vez de Chrome
  • Tanto Web USB como Web Bluetooth me parecen excelentes. He usado Web MiniDisc para manejar MiniDiscs, y también flasheé desde la web firmware personalizado para termohigrómetros BLE de Xiaomi para integrarlos con Home Assistant. Me gusta especialmente que ahora se puedan hacer estas cosas sin ejecutar scripts sospechosos ni binarios locales
  • Yo incluso lo usé dos veces en Firefox sin problemas. No sé si ayudó que en el router uso nextdns, pero en cualquier caso funcionó

• Proyectos como GrapheneOS, ESPHome y Meshtastic ya aprovechan muy bien WebUSB, y Google también lo usó para convertir el control de Stadia en un dispositivo Bluetooth genérico. Lo mismo pasa con herramientas de configuración de fabricantes de teclados. Como el usuario tiene que elegir explícitamente el dispositivo, me parece que el modelo de seguridad es razonable, y la postura de Mozilla de rechazarlo de forma nativa me resulta decepcionante, en línea con lo que ha mostrado en los últimos 10 años

  • Sinceramente, creo que una extensión es la forma más adecuada para algo así. Que un sitio web acceda directamente al stack de USB o Bluetooth es un caso de uso demasiado de nicho como para venir incluido por defecto; me parece más correcto que sea opt-in. Como las apps separadas tipo Bluetooth browser en iOS, un camino aparte que se use solo cuando hace falta reduce mejor la superficie de ataque y el crecimiento excesivo del navegador. Ojalá más de estas enormes API web en JS se volvieran plugins

• Hoy en día incluso las apps locales se distribuyen cada vez más en formato html & js solo para Chrome. Más allá de si te gusta o no que el navegador acceda por USB, me molesta todavía más esta tendencia de volver a forzar el uso de Chrome, como en la época en que se imponía IE

  • Yo sigo pensando que me gustaría reconstruir la web como un lector de documentos de hipertexto sin kitchen sink. Hoy, con los LLM, ese tipo de prototipos se siente más realista que antes

• En plataformas educativas de hardware como BBC Microbit, WebUSB fue un antes y un después. Al introducir hardware a estudiantes, simplemente funciona, y gracias a un IDE web como MakeCode y a las URL de referencia del código, compartir y depurar también se vuelve fácil

• Esta implementación parece un gran proof of concept. Que funcione ejecutando un binario aparte junto al navegador no es mi forma ideal de WebUSB a largo plazo, pero me alegra que al menos alguien esté trabajando de verdad en resolver este problema

  • En cambio, a mí no me convence mucho la idea misma de manejar USB directamente dentro del navegador

• Mi primera reacción fue que esto era una idea terrible. No me gusta que los sitios web accedan al hardware, y con el acceso a la webcam ya me incomoda bastante

  • Yo lo veo un poco distinto. Antes, para subir firmware a un dispositivo, había que descargar una app cualquiera en C++ y darle de golpe todos los privilegios de usuario de mi sistema. En cambio, con WebUSB entras al sitio, ejecutas un flujo dentro del sandbox y, cuando el navegador te lo pide, puedes dar permiso eligiendo exactamente ese único dispositivo USB. No puede tocar otros dispositivos USB, ni el sistema de archivos, ni APIs del sistema, ni registrar programas al inicio, ni instalar autoactualizaciones, así que en realidad la postura de seguridad me parece mejor
  • Nos guste o no, la frontera entre apps y páginas web ya se ha difuminado bastante, y creo que se seguirá difuminando. Incluso las apps locales cada vez usan más el navegador como si fuera un intérprete, en vez de Python y Qt
  • Este problema es simple. Si no quieres, no des acceso. Pero tampoco me gustaría que se intentara impedir lo que otras personas hacen con su hardware. Un mundo donde solo queden ecosistemas corporativos cerrados sería peor
  • Si no te gusta, simplemente no elijas el dispositivo ni pulses el botón de allow
  • Los sitios web ya usan CPU y RAM. También hay que verlo como parte natural de cómo funciona todo esto

• Yo todavía no celebro que esto llegue al navegador mientras la especificación siga en estado draft y no se hayan resuelto lo suficiente las preocupaciones de seguridad

  • En cambio, yo veo que el problema de seguridad cuando no existe WebUSB es que cada vez que quieres usar un dispositivo USB tienes que instalar drivers nativos poco confiables
  • Entonces me pregunto cuál sería exactamente la implicación de seguridad adicional que introduce WebUSB, comparado con casos como flashear un smartphone, donde de todos modos ya habría que descargar un programa nativo
  • Estoy de acuerdo con la interpretación de que la especificación sigue en draft porque Apple bloquea el avance. Supongo que API como WebUSB y WebBluetooth compiten con la App Store, así que no les convienen por ingresos. El modelo de seguridad real, donde el usuario debe permitir explícitamente el acceso al dispositivo por sitio, no me parece muy distinto de otras API de navegador basadas en permisos
  • Por eso, para cuando Firefox no incluye este tipo de funciones básicas, yo mantengo una instancia de Chrome aparte solo para usarlas cuando hace falta

• Si WebUSB y WebBLE estuvieran soportados en todas partes, podría distribuir mi app de IoT solo como web y mi productividad subiría muchísimo. Me atrae especialmente que también se reducirían las complicaciones relacionadas con las app stores

  • Recién me entero de esto, y me hizo preguntarme si un CCTV DVR podría ofrecer una webapp al teléfono y hasta transmitir video. Al buscarlo, conviene usar Web Bluetooth API en vez de webble para encontrar mejores resultados