Para qué sirve WebUSB y cómo sacarle partido en la web

Inicio » Internet » Para qué sirve WebUSB y cómo sacarle partido en la web

La primera vez que oyes hablar de WebUSB suena casi a ciencia ficción: una página web hablando directamente con un dispositivo USB sin instalar drivers raros ni aplicaciones de escritorio. Sin embargo, esta tecnología lleva varios años funcionando en producción y, aun así, sigue siendo una gran desconocida para muchos desarrolladores.

En este artículo vamos a ver con calma para qué sirve WebUSB, cómo funciona, qué problemas viene a resolver y qué implicaciones tiene en seguridad, privacidad y desarrollo real. Si vienes del mundo del hardware, de los Arduinos o de las extensiones de Chrome, te va a resultar especialmente interesante, pero incluso si solo haces front-end clásico, merece la pena tenerla en el radar.

Qué es WebUSB y cuál es su objetivo

WebUSB es una API del navegador que permite a las aplicaciones web comunicarse directamente con dispositivos USB. En lugar de instalar drivers nativos o software específico para cada sistema operativo, la lógica de conexión y control se lleva a la web mediante JavaScript.

No forma parte aún de una especificación formal del W3C, pero la está impulsando activamente el Web Incubator Community Group (WICG), donde dos desarrolladores de Google (Reilly Grant y Ken Rockot) han ido publicando y puliendo la propuesta. El soporte real hoy en día es especialmente sólido en Chrome y navegadores basados en Chromium.

El objetivo principal es proporcionar un método estándar y seguro para exponer servicios de dispositivos USB a la web. Esto ataca de frente un problema histórico: muchos dispositivos USB no estándar (sensores, equipos industriales, gadgets personalizados, etc.) dependen de SDKs y drivers nativos para cada plataforma, lo que complica muchísimo su adopción en la web.

Con WebUSB, se pretende que los fabricantes puedan ofrecer SDKs en JavaScript, multiplataforma y listos para usar directamente desde el navegador, reduciendo tiempos de desarrollo y haciendo que el hardware «hable» con la web casi desde el minuto uno sin esperas eternas de integración.

Qué problema real resuelve WebUSB

Cuando piensas en USB seguramente te vengan a la cabeza teclados, ratones, memorias USB, webcams, auriculares o discos externos, incluidos los tipos USB 3, USB 3.1 y USB 3.2. Todos esos dispositivos siguen funcionando como siempre, apoyándose en clases estándar de USB para las que el sistema operativo ya trae drivers.

El lío aparece con dispositivos USB personalizados o no estandarizados: hardware médico, máquinas de laboratorio, dispositivos de diagnóstico, placas electrónicas hechas a medida, aparatos audiovisuales concretos, etc. Cada uno de ellos suele requerir un driver propio por sistema operativo y un SDK nativo para integrarlo con tu software.

Ese modelo provoca varios problemas: código específico por plataforma, tiempo de desarrollo largo, mantenimiento complejo y cero accesibilidad desde la web. La consecuencia práctica es que muchos dispositivos quedan fuera del alcance de aplicaciones web modernas, obligando a crear clientes de escritorio o soluciones híbridas.

La API WebUSB se diseñó precisamente para esto: exponer esos dispositivos y sus servicios directamente a la web, con un modelo de permisos controlado por el navegador, evitando la instalación masiva de drivers que pueden romper el sistema o suponer un riesgo de seguridad.

Gracias a esta API, un flujo ideal de uso sería algo así: compras un dispositivo USB, lo enchufas, el navegador te sugiere la página adecuada, entras y te conectas desde ahí con un clic. Sin descargas, sin instaladores, sin ventanas de advertencia del sistema operativo y sin basura que se quede instalada para siempre por haber usado el dispositivo una sola vez.

Cómo es realmente la experiencia de uso con WebUSB

Imagina que compras un nuevo dispositivo USB compatible con WebUSB. Cuando lo conectas al ordenador, el propio dispositivo puede anunciar una URL de «página de destino». Chrome detecta esta información y muestra una notificación con el sitio web recomendado para gestionar ese hardware.

Al hacer clic en la notificación, llegas a la página del fabricante o de la aplicación web. Allí, normalmente habrá un botón o gesto que inicia el flujo de permisos, y Chrome abre un selector de dispositivos USB para que el usuario elija exactamente con qué dispositivo quiere conectar.

Una vez aceptado, la web obtiene acceso restringido a ese dispositivo a través de la API de WebUSB. Desde ese momento, la aplicación web puede enviar y recibir datos con el dispositivo USB en tiempo real, sin necesidad de que el usuario instale ningún software adicional.

Si comparamos esto con el modelo clásico, la diferencia es enorme: antes tenías que buscar el driver correcto, descargarlo, rezar para que fuera compatible con tu sistema operativo, instalarlo y reiniciar si hacía falta. Y si el uso era puntual, ese software se quedaba ocupando espacio y potencialmente generando conflictos.

Con WebUSB, ese «cliente» vive en la web. Cuando dejas de usarlo, simplemente cierras la pestaña. No hay nada que desinstalar y el navegador recupera los recursos automáticamente con el paso del tiempo.

Privacidad y seguridad en WebUSB

Dar acceso desde la web al bus USB no es ninguna broma, así que la API se ha diseñado con varias capas de protección y requisitos de seguridad muy claros. Este punto es clave para entender por qué WebUSB no es un coladero.

Funcionamiento sólo en contextos seguros (HTTPS)

Por la potencia de esta característica, WebUSB solo se puede usar desde páginas servidas mediante HTTPS (o equivalentes seguros). Si tu sitio no va por TLS, olvídate de la API. Esta decisión garantiza que los datos entre navegador y servidor estén cifrados y evita ataques básicos de tipo «man-in-the-middle» cuando hablamos con el dispositivo indirectamente.

Gestos del usuario obligatorios

Para evitar que una web maliciosa empiece a escanear tus dispositivos USB a escondidas, la llamada a navigator.usb.requestDevice() solo puede ejecutarse en respuesta a un gesto del usuario, como un clic o un toque. Esto significa que tiene que estar detrás de un botón, enlace o interacción explícita; no puede dispararse en segundo plano al cargar la página.

Política de permisos / Feature Policy

Los desarrolladores web y los propietarios de sitios pueden controlar dónde y cómo se expone la API WebUSB mediante cabeceras HTTP o atributos allow en iframes. Esto se hace a través de lo que antes se llamaba Feature Policy (actualmente Permissions Policy).

Por ejemplo, un sitio puede decidir deshabilitar WebUSB completamente con una cabecera de política, o permitirla solo en ciertos iframes de confianza. Del mismo modo, una extensión de Chrome que integre WebUSB puede limitar cuidadosamente dónde se usa la API.

Desde el punto de vista de seguridad, la idea es que el acceso USB no esté disponible por defecto en todos los contextos, sino solo donde el desarrollador lo autorice de manera explícita. Esto minimiza la superficie de ataque.

Modelo de origen y CORS aplicado a dispositivos

Otro aspecto interesante es cómo se tratan los dispositivos a nivel de origen. En WebUSB, cada dispositivo USB se maneja como si fuera un origen separado, de manera similar a cómo funciona CORS con recursos remotos.

De esta forma, un desarrollador solo manda peticiones al dispositivo concreto para el que tiene permiso, y el navegador garantiza que esa autorización no se extienda a otros dispositivos ni a otros orígenes. Este enfoque reduce el riesgo de que un sitio pueda fisgonear en hardware para el que el usuario no ha concedido acceso.

Primeros pasos: acceso básico a dispositivos con JavaScript

Desde el punto de vista del código, WebUSB se integra a través del objeto navigator.usb. La API está pensada en clave moderna, apoyándose de forma intensiva en Promesas y, por extensión, en async/await.

Para solicitar acceso a un dispositivo, la función clave es navigator.usb.requestDevice(). Esta llamada requiere un objeto con filtros, donde se indican cosas como el identificador de proveedor (vendorId) y, de forma opcional, el identificador de producto (productId) o parámetros más detallados como classCode, protocolCode, serialNumber o subclassCode.

Un caso típico es trabajar con una placa Arduino. El desarrollador utiliza un vendorId concreto (por ejemplo, 0x2341 para ciertos dispositivos Arduino) en los filtros, de manera que solo se muestren en el selector aquellos dispositivos que coincidan con ese identificador.

Cuando el usuario concede permiso y selecciona el dispositivo, la promesa se resuelve con una instancia de USBDevice. Ese objeto contiene información fundamental: versión USB soportada, tamaño máximo de paquete, IDs de proveedor y producto, número de configuraciones disponibles y, en general, todos los campos del descriptor del dispositivo.

Además de requestDevice(), la API ofrece navigator.usb.getDevices(), que devuelve una lista de todos los dispositivos USB a los que el origen actual ya tiene acceso concedido. Esto es útil, por ejemplo, cuando se vuelve a abrir la aplicación web y se quiere recuperar conexiones previas sin pasar de nuevo por todo el flujo de permisos si no hace falta.

Comunicación con una placa Arduino usando WebUSB

Uno de los ejemplos más populares y didácticos es el uso de WebUSB con placas Arduino configuradas para exponer compatibilidad con esta API. Hay una biblioteca específica en GitHub (proyecto webusb/arduino) que permite adaptar los sketches para que el dispositivo se anuncie como WebUSB y exponga, por ejemplo, un puerto serie accesible desde el navegador.

El flujo típico en JavaScript consiste en pedir el dispositivo, abrir una sesión con device.open(), seleccionar la configuración adecuada con device.selectConfiguration() y, a continuación, reclamar una interfaz concreta mediante device.claimInterface().

Reclamar la interfaz implica que tienes control exclusivo sobre ella mientras dure la sesión, lo cual es necesario porque los datos solo pueden fluir a través de una interfaz USB cuando esta ha sido reclamada por un cliente concreto (en este caso, la web).

Después se suelen enviar comandos de configuración con transferencias de control (controlTransferOut), que son muy útiles para parámetros pequeños y tienen prioridad en el bus. Una vez preparado el dispositivo, se puede empezar a recibir datos mediante transferencias de tipo bulk o interrupt, usando métodos como transferIn() para leer información del endpoint correspondiente.

En el sketch del lado de Arduino, la biblioteca de WebUSB de terceros se encarga de dos cosas clave: hacer que la placa actúe como dispositivo WebUSB con una URL de destino que Chrome pueda detectar y exponer una API de comunicación serie compatible con el navegador, de forma que puedas tratar el dispositivo en JavaScript casi como un puerto serie clásico pero integrado en la web.

Tipos de transferencias USB soportadas por WebUSB

La API WebUSB permite trabajar con la mayoría de los tipos de transferencias definidos por el estándar USB, lo que da bastante juego a la hora de diseñar protocolos personalizados sobre diferentes endpoints.

En primer lugar están las transferencias de CONTROL, pensadas para enviar y recibir parámetros de configuración o comandos cortos. En WebUSB se manejan con controlTransferIn(setup, length) y controlTransferOut(setup, data). Son ideales para cosas como cambiar modos, ajustar velocidades o leer estados internos.

Luego tenemos las transferencias de INTERRUPCIÓN, utilizadas para pequeñas cantidades de datos que deben llegar con baja latencia, como notificaciones de botones o eventos rápidos. En la API se gestionan con los mismos métodos que las transferencias masivas: transferIn(endpointNumber, length) y transferOut(endpointNumber, data), simplemente variando el tipo de endpoint.

Las transferencias ISOCRONAS se usan para flujos continuos, como audio o vídeo, donde es más importante mantener el ritmo de datos que garantizar la entrega perfecta de todos los paquetes. WebUSB proporciona isochronousTransferIn(endpointNumber, packetLengths) e isochronousTransferOut(endpointNumber, data, packetLengths) para este tipo de comunicación.

Por último están las transferencias BULK, pensadas para mover grandes cantidades de datos no críticos en tiempo pero que sí necesitan fiabilidad, como ficheros o buffers extensos. También se manejan con transferIn() y transferOut(), especificando el endpoint adecuado y el tamaño de los bloques.

WebUSB en extensiones de Chrome

Además de usarse en páginas web tradicionales, WebUSB está disponible en extensiones de Chrome a partir de la versión 118, con algunos matices importantes respecto a su uso en páginas normales.

No es necesario declarar permisos específicos de WebUSB en el manifiesto de la extensión: la API sigue activando el flujo de permisos gestionado por el navegador, igual que en una web. Sin embargo, hay diferencias notables en cómo se combina con los service workers de las extensiones.

En particular, no se permite llamar a WebUSB.requestDevice() directamente desde un service worker de extensión. Esto se debe a que la solicitud de permisos requiere un gesto de usuario y una interfaz visible, algo que un service worker, por definición, no tiene.

El patrón habitual es iniciar requestDevice() desde una página de la extensión (por ejemplo, un popup o una página de opciones), esperar a que el usuario seleccione el dispositivo y, a continuación, notificar al service worker mediante chrome.runtime.sendMessage(). Una vez recibido el mensaje, el service worker puede recuperar el dispositivo con navigator.usb.getDevices() y abrir la conexión.

Mientras haya una sesión USB activa desde el service worker, esa conexión ayuda a mantenerlo vivo, lo que encaja bien con el modelo de extensiones que necesitan escuchar datos de un dispositivo de forma continua en segundo plano.

Limitaciones prácticas y gestión de grandes transferencias

En el mundo real, la comunicación por USB se ve afectada por limitaciones impuestas por el sistema operativo, el propio hardware y los ajustes de ahorro de energía en USB. Muchos sistemas restringen el tamaño máximo de los datos que pueden incluirse en transacciones pendientes o el número de transferencias que se pueden tener en vuelo al mismo tiempo.

Para sortear estos límites, las buenas prácticas recomiendan dividir los datos en bloques más pequeños y enviarlos en varias transferencias sucesivas, en lugar de intentar mandar de golpe un buffer gigantesco. Esto reduce el uso de memoria y encaja mejor con las restricciones internas del sistema.

También es habitual mantener varias transferencias encadenadas en paralelo hasta un máximo razonable. De esta forma, se mejora el rendimiento porque se minimiza el tiempo muerto entre transferencias individuales, manteniendo el bus ocupado de manera eficaz.

Un ejemplo típico de helper en JavaScript establece un tamaño de bloque (por ejemplo, 16 KB), un número máximo de transferencias pendientes (por ejemplo, 3) y va lanzando transferOut() para cada fragmento mientras va haciendo await sobre las más antiguas cuando se alcanza el límite. Al terminar de programar todos los fragmentos, espera a que se resuelvan las últimas promesas restantes.

Este patrón encaja muy bien con async/await y permite que la lógica de alto nivel siga limpia, mientras el envío real de datos se optimiza silenciosamente bajo el capó.

Depuración y entorno de desarrollo

Chrome incluye varias herramientas internas muy útiles para quien esté trabajando con WebUSB. La primera es about://device-log, una página interna donde se concentran todos los eventos relacionados con dispositivos, incluyendo USB. Es especialmente práctica para ver qué está pasando cuando algo no termina de conectar o cuando se pierden sesiones. Si trabajas en Windows, además existen guías para mapear dispositivos USB con PowerShell que facilitan la depuración.

También existe la página about://usb-internals, pensada para inspeccionar y simular dispositivos WebUSB. Esta herramienta permite, por ejemplo, probar la interfaz de usuario de tu aplicación sin disponer de hardware real, algo muy cómodo en fases tempranas del desarrollo o cuando compartes el proyecto con gente que no tiene los dispositivos físicos.

En entornos Linux suele añadirse una complicación adicional: los dispositivos USB se crean por defecto con permisos de solo lectura o de acceso restringido. Para que Chrome pueda abrirlos correctamente, muchos desarrolladores necesitan crear una regla udev específica.

Esa regla suele ir en un archivo del estilo /etc/udev/rules.d/50-nombredispositivo.rules, donde se indican el idVendor (y opcionalmente idProduct) del dispositivo, el modo de permisos (por ejemplo 0664) y el grupo (por ejemplo plugdev). Tras asegurarse de que el usuario pertenece a ese grupo, basta con reconectar el dispositivo para que Chrome pueda trabajar con él sin problemas.

En el caso concreto de algunos ejemplos con Arduino, se utilizan descriptores de Microsoft OS 2.0 para mejorar la experiencia en Windows 8.1 y posteriores. En versiones más antiguas, todavía puede ser necesario instalar manualmente un archivo INF para que el sistema operativo reconozca adecuadamente el dispositivo.

Casos de uso reales y ventajas para fabricantes y desarrolladores

WebUSB no es solo una curiosidad técnica. Hay proyectos en producción desde hace años, por ejemplo aplicaciones web de punto de venta que se conectan directamente a impresoras térmicas mediante USB o red local usando la API.

Para el desarrollador, esto significa evitar implementar y mantener aplicaciones de escritorio específicas por sistema operativo. Basta con una aplicación web bien diseñada, que el usuario abre en Chrome, concede permisos al dispositivo y se pone a trabajar.

Para los fabricantes de hardware, el cambio de enfoque es brutal: pueden crear SDKs en JavaScript que funcionan igual en Windows, macOS, Linux o incluso ChromeOS, siempre que el navegador soporte WebUSB. Esto reduce costes, acelera lanzamientos y simplifica el soporte técnico.

Además, hay proyectos que exploran hardware diseñado expresamente para ser controlado por la web, como dispositivos LED tipo WebLight, donde se documentan el diseño físico, el firmware y el software de control vía WebUSB. Este enfoque facilita que otros desarrolladores extiendan o personalicen el producto sin pelearse con drivers nativos.

Conviene recordar, eso sí, que WebUSB no abre el acceso directo a cualquier dispositivo USB que conectes al ordenador. La filosofía es que los dispositivos se diseñen o actualicen teniendo en cuenta esta API, adoptando descriptores y firmware adecuados para que la integración con la web sea segura y controlada.

Revocación de permisos y limpieza de accesos

Además del flujo de concesión inicial de permisos, la API contempla la necesidad de revocar el acceso a un dispositivo USB cuando ya no es necesario, algo especialmente importante en entornos compartidos o educativos.

Para ello, cada instancia de USBDevice dispone del método forget(), que permite a la propia web «olvidar» el dispositivo de forma voluntaria. De esta forma, la próxima vez que alguien quiera usarlo desde ese origen, tendrá que pasar de nuevo por el selector de permisos de Chrome.

Este método está disponible a partir de Chrome 101, por lo que conviene comprobar su existencia antes de usarlo, verificando si «forget» está presente en USBDevice.prototype. Así se evita romper compatibilidad en navegadores o versiones anteriores.

Este mecanismo ayuda a mantener una experiencia de usuario limpia cuando se trabaja con muchos dispositivos distintos, evitando acumulaciones de permisos antiguos que ya no tienen sentido y que podrían confundir al usuario.

En entornos donde varios usuarios comparten la misma máquina, como aulas o laboratorios, es buena práctica que la propia aplicación web ofrezca un botón o flujo para revocar el acceso a dispositivos que ya no se van a utilizar, garantizando que las sesiones se cierran correctamente.

Mirando todo el panorama, WebUSB se ha convertido en una pieza clave para acercar el hardware personalizado y los dispositivos USB no estándar al mundo de las aplicaciones web modernas. Permite que proyectos que antes exigían software nativo pesado pasen a funcionar directamente en el navegador, con un modelo de seguridad robusto y un flujo de permisos claro para el usuario, lo que abre la puerta a nuevas generaciones de hardware «web-first» y a experiencias más sencillas tanto para desarrolladores como para usuarios finales.