Permisos de Web Bluetooth, selección de dispositivos y privacidad
Comprende cómo la activación del usuario, los permisos, la disponibilidad y la selección de dispositivos de Web Bluetooth forman una experiencia web respetuosa con la privacidad.
Quieres la documentación estructurada de Huella digital?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Web Bluetooth permite que una aplicación web se comunique con un dispositivo Bluetooth de baja energía después de que una persona lo elija y conceda acceso. Es una capacidad mediada por el usuario, no una vista general del hardware cercano. Un diseño fiable parte de una página útil, solicita acceso durante una acción deliberada y trata el rechazo, la cancelación, la falta de Bluetooth y las desconexiones como resultados normales. Un dispositivo elegido no demuestra quién lo posee, dónde está ni quién usa el navegador.
Este alcance limitado facilita una ayuda coherente: el navegador concede acceso para la tarea, la persona puede detenerlo y la página sigue siendo útil cuando la capacidad falta.
Para qué sirve Web Bluetooth
La especificación de Web Bluetooth define una forma web de solicitar e interactuar con servicios Bluetooth de baja energía. El navegador media el acceso y expone solo los dispositivos y servicios permitidos por la solicitud y la plataforma. La API no es un directorio de dispositivos cercanos, y la aplicación no debe tratar el nombre, identificador o servicio como una señal de identidad.
La referencia de Web Bluetooth en MDN describe la superficie pública. Los requisitos deben empezar por un resultado visible: configurar un accesorio autorizado, leer un valor solicitado o actualizar un ajuste del dispositivo elegido. Mantén disponible la página principal y una ruta equivalente sin Bluetooth cuando ese resultado no pueda completarse.
Activación del usuario, selector y permiso
El acceso está pensado para seguir un gesto claro, como pulsar un botón de conexión. La solicitud debe ejecutarse en un contexto seguro y puede requerir activación transitoria del usuario; una llamada durante la carga, desde un temporizador no relacionado o después de que expire la activación puede fallar. El selector del navegador es donde la persona elige el dispositivo, y el resultado del permiso define lo que ese origen puede usar. Cancelar o rechazar es una decisión de la persona, no una anomalía de identidad.
Explica qué permite la conexión antes de pulsar el botón. No disimules la solicitud como navegación, no abras de nuevo el selector tras una cancelación y no pidas debilitar un control de privacidad. Si el navegador rechaza la solicitud, conserva los datos y muestra la página normal; ofrece reintentar solo cuando tenga sentido. La guía de Chrome Web Bluetooth describe expectativas específicas, pero no hace universal la API.
El permiso está limitado por la política del navegador y del origen, y concederlo no garantiza que el dispositivo siga disponible. Puede estar fuera de alcance, apagado, desconectado o bloqueado por el sistema operativo. Trata la pérdida de conexión como un estado recuperable, con un reintento acotado y una alternativa sin Bluetooth. No infieras características de la persona a partir de un rechazo o una desconexión.
La disponibilidad es una rama de compatibilidad
La compatibilidad depende del navegador, sistema operativo, contexto seguro, pila Bluetooth, política administrada y capacidades del dispositivo. navigator.bluetooth puede faltar, la solicitud puede rechazarse y la conexión posterior puede fallar. La API no promete el mismo selector, permisos, servicios o eventos en todos los navegadores. Detecta la capacidad y documenta el entorno probado, sin prometer soporte para una familia de navegadores.
La disponibilidad puede cambiar mientras la página está abierta. Puede perderse el adaptador, el dispositivo puede quedar inaccesible o una política administrativa puede desactivar la función. Mantén controles y estados en HTML normal para que la tarea siga siendo comprensible. La guía de privacidad de permisos del navegador explica por qué un permiso no es un atributo estable de identidad.
No uses la disponibilidad de Bluetooth para bloquear autenticación, pagos, recuperación de cuenta ni contenido esencial. Si el accesorio es opcional, ofrece formulario local, entrada manual, importación de archivo u otra representación. La conexión debe ser explícita y los reintentos limitados; la ausencia de la API no debe producir un bucle de avisos.
Minimiza los datos del dispositivo y del servicio
La relación con un dispositivo elegido para una tarea debe ser temporal, salvo que la persona pida recordarlo. Guarda solo el estado necesario para reanudarla, como una etiqueta visible elegida por el usuario o un estado de permiso acotado. No copies por defecto identificadores, nombres, listas de servicios, valores de características ni historial de conexiones a perfiles, URL, etiquetas analíticas o registros de soporte.
La relación no demuestra propiedad, ubicación, salud ni identidad. No combines detalles Bluetooth con cuenta, red, fuentes, almacenamiento o tiempos para crear un perfil. Si soporte necesita un dato de diagnóstico, explica el fin, limita el acceso, fija una retención breve y elimínalo al cerrar el caso. Revisa SDK, informes de errores, trabajadores de servicio y cachés para que un valor local no llegue a un evento remoto.
Separa la comunicación local de una carga o sincronización opcional. Leer un valor no autoriza a enviarlo a un servicio. Explica qué saldrá del navegador y solicita una decisión separada cuando corresponda; conserva la tarea local si se rechaza. Para operaciones suele bastar un resultado como connected, denied o fallback, en vez de un inventario persistente.
Construye y prueba la alternativa
Prueba la API ausente, una solicitud fuera de la activación, la cancelación del selector, el rechazo, Bluetooth no disponible, una desconexión, un servicio requerido ausente y una reconexión. Cada caso debe llegar a un estado conocido con mensaje, siguiente acción y datos conservados. No dependas de un identificador, nombre, radio o distancia concretos.
Los controles de conectar, desconectar, reintentar y olvidar deben ser accesibles con teclado y tener etiquetas claras. Anuncia los cambios de estado con texto, conserva el foco y ofrece los mismos datos esenciales sin Bluetooth. Un valor estático, entrada manual o configuración descargable puede ser una alternativa equivalente. Respeta la reducción de movimiento y no escondas el fallo en una animación.
Usa un único reintento acotado cuando el fallo pueda ser transitorio. No vuelvas a mostrar el selector tras una cancelación sin una nueva acción ni crees bucles tras un rechazo. Registra el resultado y la fase del fallo, no un inventario. Revisa la especificación W3C de Web Bluetooth y la documentación actual antes de cambiar una promesa de compatibilidad o permisos.
Consulta también la guía de privacidad del navegador para la minimización general.
Antes de conectar, explica la tarea y conserva los datos tras una desconexión. El permiso técnico no autoriza por sí solo analítica, cuentas ni almacenamiento remoto. Explica qué saldrá del navegador y pide una elección separada; rechazar debe ser válido. Valida tipo, unidad, frescura y rango de cada valor recibido. Permite cambiar, desconectar y olvidar una preferencia recordada. Los mensajes deben indicar una acción inmediata sin identificadores completos. Respeta las políticas administradas y ofrece una ruta alternativa. Una conexión correcta no demuestra ubicación física; el alcance y el sistema cambian el resultado. Mantén el foco cuando aparece o se cierra el selector y anuncia los estados con texto. El flujo principal debe seguir funcionando para quien no puede usar la radio. Usa dispositivos de prueba controlados y comprueba resultados visibles y datos conservados. Después de cada cambio revisa SDK, informes, cachés y serialización. La lectura local y la carga son pasos distintos; un error remoto no debe pedir permiso otra vez.
Las promesas de compatibilidad deben ser más estrechas que la evidencia: el permiso puede revocarse, una política de plataforma puede desactivar Bluetooth y una versión futura puede cambiar la disponibilidad. Documenta el entorno probado y conserva una alternativa útil en cada caso.
El permiso no equivale al consentimiento para analizar o subir datos.
Los valores del dispositivo requieren validación de la aplicación.
La persona debe poder olvidar una relación guardada.
Los mensajes de estado deben indicar el siguiente paso.
Las políticas administradas merecen respeto.
Conectar no demuestra ubicación.
El foco debe conservarse antes y después del selector.
El flujo principal debe funcionar sin Bluetooth.
Las pruebas deben usar dispositivos controlados.
Cada cambio requiere revisar el flujo de datos.
Al restaurar la página, cambiar la política o elegir otro accesorio, recalcula la decisión local, explica la nueva limitación y conserva la tarea normal. No conviertas una observación temporal en una etiqueta permanente de la cuenta.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.