Planteamiento y contexto
Una página HTTPS ayuda a los usuarios a configurar un dispositivo USB. Después de que el usuario hace clic en “Conectar dispositivo”, el navegador debe mostrar un diálogo de permisos explícito. La página debe gestionar navegadores no compatibles, iframes embebidos, desconexiones, permisos denegados y la recuperación tras actualizar la página.
Explica la detección de capacidades, los gestos del usuario, el origen y Permissions Policy, los filtros de dispositivos, la minimización de datos, los errores, la mejora progresiva y las pruebas. La página no debe escanear silenciosamente al cargar ni enviar datos sin procesar del dispositivo a servicios de analítica de terceros.
Qué evalúa el entrevistador
El entrevistador espera que trates a WebUSB como una API web potente controlada por permisos, no como una lista de dispositivos del DOM ordinaria. MDN describe una solicitud del navegador al pedir un dispositivo; el resultado de la Permissions API se ve afectado por el contexto seguro, Permissions Policy, la interacción del usuario y el estado del diálogo de permisos.
Las respuestas sólidas conectan el origen que otorga el permiso, la página de nivel superior, la política de embebido, los filtros de dispositivos y el ciclo de vida de la conexión. Chrome recomienda configurar explícitamente Permissions Policy y deja la decisión final de permitir en manos del usuario. La mejora progresiva brinda a los usuarios sin WebUSB una explicación legible, un enlace a una herramienta nativa o una vía de soporte.
Respuesta en 30 segundos
“Primero detecta HTTPS y navigator.usb; ofrece documentación o una herramienta nativa cuando no haya soporte. Llama a requestDevice() únicamente a partir del botón Conectar accionado por el usuario y usa filtros precisos de proveedor y producto. Establece una Permissions Policy de respuesta que permita solo orígenes de confianza; los frames embebidos también deben verificarse. Tras la conexión, accede solo a las interfaces necesarias para la tarea, valida las respuestas y escucha los eventos de desconexión. Trata la denegación, el bloqueo por políticas, la falta de coincidencias y los navegadores no compatibles como estados procesables distintos, no como errores del servidor.”
Diseño paso a paso
Paso 1: Establecer el límite de confianza y el objetivo
Define los comandos y datos que la página realmente necesita, si el dispositivo contiene información confidencial y si WebUSB es obligatorio. Prefiere una API del navegador más específica o una herramienta nativa cuando exista. No leas todas las interfaces por simple comodidad.
Paso 2: Detectar la capacidad y aplicar mejora progresiva
Comprueba HTTPS, la compatibilidad del navegador y los métodos requeridos. Si no hay soporte, proporciona documentación, orientación sobre controladores o aplicaciones nativas, y soporte humano. La detección elige una rama de mejora; que una API exista no implica que haya permisos o compatibilidad con el dispositivo.
Paso 3: Vincular el permiso a un gesto del usuario
Llama a requestDevice() a partir de un clic claro o una acción del teclado, y explica que aparecerá un diálogo de permisos del navegador. Nunca lo solicites durante la carga, mediante un temporizador, en un iframe oculto o en un callback asíncrono no relacionado. Distingue entre la cancelación, el bloqueo por políticas, los navegadores no compatibles y la ausencia de dispositivos coincidentes, ofreciendo a la vez un siguiente paso útil.
Paso 4: Restringir orígenes y Permissions Policy
Configura un encabezado explícito como Permissions-Policy: usb=(self) o una lista más restringida de orígenes de confianza. Para un elemento embebido, verifica conjuntamente el origen de nivel superior, el atributo allow del iframe y la política; no otorgues acceso a todos los terceros. CSP, Trusted Types y la revisión de dependencias siguen protegiendo la página en sí.
Paso 5: Filtrar dispositivos y minimizar el acceso
Filtra por proveedor, producto o protocolo para que no se muestren dispositivos no relacionados. Tras la conexión, enumera únicamente las configuraciones e interfaces requeridas, aplica límites de tiempo de lectura/escritura y restricciones de tamaño de mensaje, y valida los formatos de respuesta. Libera las interfaces después de la tarea y mantén los números de serie, paquetes sin procesar y datos de identidad fuera de la analítica.
Paso 6: Manejar conexión, desconexión y actualización
Escucha connect y disconnect, mostrando el nombre del dispositivo, el paso actual y una acción para reconectar. Detén el sondeo y limpia los identificadores al desconectar. Una reconexión repite el filtrado y la confirmación de la tarea. Tras actualizar la página, no asumas que la conexión previa o el permiso siguen siendo utilizables; permite que el usuario seleccione de nuevo.
Paso 7: Diseñar la experiencia de usuario (UX) ante errores y de privacidad
“Cancelaste el permiso” no debe parecer una caída del servidor. Un bloqueo por políticas debe remitir a un administrador o al propietario del contenedor embebido; la falta de coincidencias debe explicar cómo conectar el modelo previsto. Registra categorías estables e IDs de correlación, no datos sin procesar del dispositivo. Obtén un consentimiento por separado antes de enviar diagnósticos anonimizados a un tercero.
Paso 8: Verificar entornos y regresiones de seguridad
Prueba contextos no seguros, múltiples navegadores, iframes, bloqueos por políticas, denegaciones, ausencia de coincidencias, clics dobles, desconexiones, suspensión y reactivación, así como respuestas maliciosas del dispositivo. Verifica que cada solicitud siga a un gesto del usuario, que las políticas permitan solo los orígenes previstos y que el mecanismo de reserva aún complete la vía de ayuda.
Compensaciones, límites y ganancia de información
Los filtros estrictos reducen las selecciones erróneas y la exposición de la privacidad, pero pueden excluir firmware antiguo; las reglas de compatibilidad versionadas hacen que esa compensación sea explícita. La reconexión automática mejora la UX, pero no debe eludir una nueva elección del usuario ni tratar un identificador antiguo como un estado de confianza.
Permissions Policy restringe los orígenes embebidos, pero no es una autorización del dispositivo; el navegador todavía le pregunta al usuario. La mejora progresiva requiere tiempo de diseño y pruebas, pero convierte las diferencias de capacidad en un siguiente paso claro en lugar de una página en blanco.
Respuesta modelo de alta calidad
“Trataría a WebUSB como una mejora condicionada por el origen y el permiso del usuario. Detectaría la API en HTTPS y ofrecería una herramienta nativa cuando no haya soporte. Solo el botón Conectar llama a requestDevice(), con filtros precisos. El encabezado de respuesta permite USB a orígenes de confianza; los frames embebidos deben cumplir con la política de nivel superior y el atributo allow.
Tras la conexión, accedería únicamente a las interfaces requeridas, validaría las respuestas, limitaría el tiempo y el tamaño de los mensajes, y nunca registraría paquetes sin procesar. Escucharía las desconexiones, limpiaría los identificadores y pediría al usuario que se reconecte; tras actualizar la página, le pediría que seleccione de nuevo. La cancelación, el bloqueo por políticas, la falta de coincidencias y los navegadores no compatibles reciben cada uno una acción de seguimiento específica. Las pruebas cubren navegadores, iframes, desconexiones, respuestas maliciosas y la UX del mecanismo de reserva.”
Errores comunes
- Llamar a
requestDevice()al cargar la página. Las solicitudes de permisos deben seguir a un gesto explícito del usuario. - Tratar WebUSB como una enumeración ordinaria. El contexto seguro, las políticas y el permiso del navegador son fundamentales.
- Usar filtros vacíos o amplios. Los usuarios pueden seleccionar dispositivos no relacionados y exponer datos innecesarios.
- Otorgar USB a todos los iframes. Los orígenes de terceros obtienen una mayor superficie de ataque sobre el dispositivo.
- Restaurar un identificador antiguo automáticamente. La actualización, la desconexión y el estado de los permisos pueden haber cambiado.
- Registrar paquetes sin procesar del dispositivo. Los diagnósticos pueden contener datos confidenciales o números de serie.
- Soportar solo un navegador. Los usuarios sin WebUSB necesitan una alternativa funcional.
- Mostrar una denegación como un error del servidor. El usuario necesita una acción de reintento o de administración.
Preguntas de seguimiento y respuestas
¿Por qué el permiso debe seguir a un gesto del usuario?
El acceso a dispositivos afecta la privacidad y la seguridad. El navegador necesita que el usuario sepa qué origen solicita qué dispositivo, y el gesto restringe cuándo puede aparecer un aviso.
¿Cómo se relaciona Permissions Policy con el aviso del navegador?
La política decide si el documento es apto para utilizar la funcionalidad. Incluso cuando se permite, el navegador evalúa el origen, el contexto y la elección del usuario antes de mostrar una solicitud. Ambas capas deben ser superadas.
¿Cómo reconectas después de una desconexión?
Detén la E/S y el sondeo, limpia los identificadores, escucha la reconexión y pide al usuario que confirme un dispositivo coincidente. Nunca reintentes indefinidamente en segundo plano.
¿Por qué no leer todas las interfaces para diagnósticos?
El acceso mínimo reduce los riesgos de privacidad, errores de operación en el protocolo e incompatibilidades de controladores. Los diagnósticos deben requerir una acción clara, campos mínimos y un consentimiento independiente para el registro.
¿Qué haces si no hay soporte para WebUSB?
Ofrece documentación, controladores o una herramienta nativa, orientación de compatibilidad y soporte humano. El objetivo principal no debe reducirse a “usa otro navegador”.