Permissions Web Bluetooth, choix d'appareil et vie privée
Comprendre comment l'activation utilisateur, les permissions, la disponibilité et le choix d'appareil encadrent une expérience respectueuse de la vie privée.
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Web Bluetooth permet à une application web de communiquer avec un appareil Bluetooth basse consommation après que la personne l'a choisi et accordé l'accès. C'est une capacité médiée par l'utilisateur, pas une vue générale du matériel voisin. Une conception fiable part d'une page utile, demande l'accès lors d'une action délibérée et traite refus, annulation, absence de Bluetooth et déconnexion comme des résultats normaux. Un appareil choisi ne prouve ni sa propriété, ni sa position, ni l'identité de la personne.
Cette portée limitée rend l'aide cohérente : le navigateur accorde l'accès pour la tâche, la personne peut l'arrêter et la page reste utile lorsque la capacité manque.
À quoi sert Web Bluetooth
La spécification Web Bluetooth définit un moyen Web de demander et d'utiliser des services Bluetooth basse consommation. Le navigateur médiatise l'accès et n'expose que les appareils et services autorisés par la demande et la plateforme. L API n'est pas un annuaire des appareils proches, et un nom ou un identifiant ne doit pas servir de signal d'identité.
La référence Web Bluetooth de MDN décrit l'interface publique. Les exigences doivent partir d'un résultat visible : configurer un accessoire autorisé, lire une valeur demandée ou modifier un réglage. Gardez une page principale et un parcours équivalent sans Bluetooth.
Activation utilisateur, sélecteur et permission
L'accès doit suivre un geste clair, comme un bouton de connexion. La demande doit s'exécuter dans un contexte sécurisé et peut exiger une activation utilisateur transitoire ; un appel au chargement, depuis un minuteur ou après expiration peut échouer. Le sélecteur laisse la personne choisir l'appareil, et la permission définit ce que l'origine peut utiliser.
Expliquez la connexion avant le clic. Ne masquez pas la demande dans une navigation, ne rouvrez pas le sélecteur après annulation et ne demandez pas d'affaiblir la confidentialité. En cas de refus, conservez les données et affichez la page normale. Le guide Chrome Web Bluetooth décrit un navigateur précis et ne rend pas l API universelle.
Une permission reste limitée par les politiques du navigateur et de l'origine. Son octroi ne garantit pas la disponibilité : l'appareil peut être hors de portée, éteint, déconnecté ou indisponible pour le système. Traitez la perte comme un état récupérable avec une tentative bornée et une solution sans Bluetooth.
La disponibilité est une branche de compatibilité
La prise en charge dépend du navigateur, du système, du contexte sécurisé, de la pile Bluetooth, d'une politique administrée et des capacités de l'appareil. navigator.bluetooth peut manquer, la demande peut être rejetée et la connexion peut échouer. Détectez la capacité et documentez l'environnement testé au lieu de promettre une famille de navigateurs.
La disponibilité peut changer pendant la visite : l'adaptateur peut disparaître, l'appareil devenir indisponible ou une politique désactiver la fonction. Gardez les contrôles en HTML ordinaire. Le guide de confidentialité des permissions rappelle qu'une permission n'est pas une identité stable.
N'utilisez pas Bluetooth pour bloquer authentification, paiement, récupération de compte ou contenu requis. Si l'accessoire est facultatif, proposez formulaire local, saisie manuelle, import ou autre représentation. La tentative doit être explicite et les reprises limitées.
Les promesses de compatibilité doivent rester plus étroites que les preuves : la permission peut être révoquée, une politique de plateforme peut désactiver Bluetooth et une future version peut modifier la disponibilité. Documentez l'environnement testé et gardez une solution utile dans chaque cas.
Réduire les données de l'appareil et du service
La relation avec un appareil choisi pour une tâche doit rester temporaire, sauf demande explicite. Conservez seulement l'état nécessaire à la reprise, comme un libellé choisi ou un état de permission limité. Ne copiez pas par défaut identifiants, noms, services, valeurs ou historique dans des profils, URL ou journaux.
Cette relation ne prouve ni propriété, ni lieu, ni santé, ni identité. Ne combinez pas les détails Bluetooth avec compte, réseau, polices, stockage ou temps pour former un profil. Si un diagnostic est nécessaire, expliquez son but, limitez l'accès et fixez une courte conservation.
Séparez communication locale et téléversement facultatif. Lire une valeur ne donne pas l'autorisation de l'envoyer. Indiquez ce qui quittera le navigateur et demandez un choix distinct ; gardez la tâche locale si la personne refuse.
Concevoir et tester la solution de repli
Testez API absente, demande hors activation, annulation, refus, Bluetooth indisponible, déconnexion, service manquant et reconnexion. Chaque cas doit atteindre un état connu avec message, action suivante et données préservées. Ne dépendez pas d'un identifiant ou d'une distance.
Les commandes de connexion, déconnexion, reprise et oubli doivent être accessibles au clavier et nommées. Annoncez les états en texte, conservez le focus et fournissez les données essentielles sans Bluetooth. Une saisie manuelle ou une configuration téléchargeable peut être équivalente.
N'effectuez qu'une reprise bornée si l'échec peut être transitoire. Après une annulation, n'affichez pas le sélecteur sans nouvelle action et ne créez pas de boucle après un refus. Relisez la spécification W3C Web Bluetooth avant de modifier une promesse.
Lorsqu'une page reprend après suspension, qu'une politique change ou qu'un autre appareil est choisi, recalculez la décision locale, expliquez la limite et gardez la tâche normale. Une observation temporaire ne doit pas devenir une étiquette permanente du compte.
Le cycle de connexion doit avoir des états clairs.
La permission ne vaut pas consentement pour analyser ou téléverser des données.
Les valeurs de l'appareil doivent être validées par l'application.
La personne doit pouvoir oublier une relation mémorisée.
Les messages d'état doivent indiquer l'étape suivante.
La connexion ne prouve pas une position.
Le focus doit rester stable avant et après le sélecteur.
Le parcours principal doit fonctionner sans Bluetooth.
Les tests utilisent des appareils contrôlés.
Chaque changement impose de revoir le flux de données.
La lecture locale et le téléversement restent distincts.
Consultez aussi le guide de confidentialité du navigateur.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.