Accès aux appareils WebUSB : permissions, interfaces et vie privée

Pour une nouvelle permission WebUSB, l’action de l’utilisateur doit ouvrir le sélecteur du navigateur ; un appareil déjà autorisé peut aussi être rendu au même origin plus tard. Aucune de ces voies ne prouve que l’appareil est prêt. BotBrowser peut exercer le contrôle de capacité d’une page et son parcours de repli dans un contexte de navigateur provisionné, mais il ne fournit pas d’appareil USB, n’accorde pas l’accès au système d’exploitation et ne prouve pas une E/S matérielle. Traitez l’ouverture, la sélection de configuration, la revendication d’interface et l’opération terminée comme des résultats distincts, avec un parcours sans USB toujours disponible.

TL;DR

• requestDevice() est une permission médiée par l’utilisateur, pas un inventaire des appareils proches.
• Un appareil autorisé peut ne pas s’ouvrir ou ne proposer aucune interface revendicable.
• WebUSB ne rend pas les classes d’interfaces protégées accessibles à une page ordinaire.
• Libérez les interfaces et fermez la session à la fin ; fermer ne révoque pas la permission.
• Stockez le résultat de la tâche, pas les numéros de série ni un historique durable.

Contents

• Choisir l’accès au moment voulu
• Séparer permission et disponibilité
• Garder les interfaces protégées
• Fermer le cycle et minimiser les métadonnées
• Classer les échecs
• Conclusion pratique

Choisir l’accès au moment voulu

WebUSB exige un contexte sécurisé et requestDevice() une activation utilisateur transitoire. Placez la demande derrière un contrôle nommé qui explique l’action de l’appareil. Le sélecteur accorde l’accès à l’origin choisi ; un simple contrôle de fonctionnalité ne le fait pas. Le navigateur ou Permissions Policy peut aussi rendre la demande indisponible.

navigator.usb.getDevices() renvoie les appareils déjà autorisés sans nouveau sélecteur ; il ne liste pas tous les appareils connectés. Réservez-le à un parcours de retour explicite et ne prenez jamais son résultat pour une preuve de connexion. Ne lancez pas le sélecteur au chargement ni en boucle après un refus. Une annulation doit préserver le brouillon et une nouvelle demande attendre une action utilisateur.

Une permission n’est pas une connexion : elle ne prouve ni que l’appareil est branché, ni qu’il possède la configuration requise, ni qu’un transfert réussira. Signalez chaque étape séparément.

Séparer permission et disponibilité

Après la sélection, USBDevice.open() démarre une session. Il peut ensuite falloir sélectionner une configuration et revendiquer une interface. Chaque opération peut échouer pour une déconnexion, une configuration absente ou une interface non revendicable.

Arrêtez le parcours si l’interface requise ne peut pas être revendiquée et expliquez que l’appareil n’est pas pris en charge dans cet environnement. N’élargissez pas l’accès et ne relancez pas automatiquement la sélection.

La guide Playwright BotBrowser décrit l’automatisation de parcours possédés. Dans un contexte provisionné, un test peut vérifier la branche de capacité, le message d’état et le parcours de repli d’une page. Cela ne fournit aucun appareil physique et ne prouve aucune E/S matérielle.

BotBrowser peut vérifier la capacité et le parcours de repli d’une page, mais il ne peut pas fournir un appareil physique ni prouver l’E/S matérielle.

Garder les interfaces protégées

Pour les pages ordinaires, WebUSB bloque les classes protégées, notamment audio, interface humaine, stockage de masse, hub, carte à puce, vidéo et contrôleur sans fil. Les règles d’applications web isolées ne sont pas couvertes ici. Un appareil peut être sélectionné alors que son interface nécessaire reste inaccessible.

Traitez cette indisponibilité comme une limite de prise en charge. Ne demandez pas de désactiver les protections du système et ne présentez pas un sélecteur réussi comme l’autorisation de toutes les fonctions d’un appareil composite. Utilisez une voie native revue avec son propre consentement lorsque l’interface sort du périmètre WebUSB.

Fermer le cycle et minimiser les métadonnées

Écoutez disconnect sur navigator.usb, arrêtez le travail dépendant et préservez le brouillon. Tentez la libération et la fermeture en nettoyage best-effort, sans les présenter comme une libération physique garantie. Une reconnexion doit demander une action explicite. En fin de tâche, libérez les interfaces revendiquées et fermez la session.

close() termine la session et libère les interfaces ; forget() supprime la permission de la page. Ne dites pas que fermer a effacé la permission : expliquez le contrôle d’oubli ou les réglages du site.

Après autorisation, USBDevice peut exposer numéro de série, noms et identifiants fournisseur/produit. N’écrivez pas ces valeurs dans l’analytique, les URL, les comptes, captures ou journaux courants. Préférez selected, unsupported ou disconnected; si une étiquette est nécessaire, faites-la choisir par l’utilisateur et expliquez sa conservation.

Classer les échecs

Classez la première étape en échec et conservez la même voie sans USB ; un timeout seul ne donne pas sa cause.

Étape observée	Ce qu’elle établit	Action suivante
API absente, contexte non sûr ou politique restrictive	La page ne peut pas lancer la demande ici	Garder la tâche utilisable et expliquer la limite
Sélecteur refusé ou fermé	Aucune sélection utilisable pour cet essai	Préserver le brouillon et attendre une action explicite
open(), configuration ou revendication refusée	Pas de session ou d’interface utilisable	Arrêter USB, montrer la voie prise en charge
Événement de déconnexion	La connexion active est terminée	Arrêter, nettoyer, préserver la saisie, proposer un nouvel essai délibéré
Opération réussie	Le résultat USB attendu a été observé	Rapporter seulement ce résultat, sans inférer stockage ou association

Chaque ligne doit revenir à un état compréhensible, sans rouvrir le sélecteur ni enregistrer d’identifiants. BotBrowser vérifie ces états propres à la page dans son contexte déclaré ; il ne transforme pas cela en preuve d’un appareil réel.

Vérifications d’implémentation et de vie privée

Séparez les états de la page de la permission, rendez le nettoyage asynchrone idempotent et testez l’annulation, la déconnexion et les interfaces non prises en charge comme des branches attendues. Examinez la télémétrie au moment de la collecte, distinguez close() de forget() et publiez le navigateur, la classe d’appareil et l’opération pris en charge. BotBrowser peut vérifier ces états et le parcours de repli dans un contexte de navigateur explicitement configuré, mais il ne fournit pas de matériel et ne prouve pas l’E/S physique.

Conclusion pratique

Utilisez une action explicite, séparez permission, session et interface, et rendez le nettoyage prévisible. Vérifiez un flux pris en charge, un flux refusé ou indisponible et un flux déconnecté dans les environnements requis. La tâche normale doit rester complète sans USB.

FAQ

Une permission du sélecteur signifie-t-elle que l’appareil est connecté ?

Non. Il peut être débranché, ne pas s’ouvrir ou ne pas proposer d’interface revendicable.

close() révoque-t-il la permission ?

Non. Utilisez forget() ou les contrôles du site.

Faut-il conserver serialNumber ?

Seulement pour un besoin précis compris par l’utilisateur ; il distingue une unité physique et ne doit pas devenir un identifiant analytique par défaut.

Que doit afficher l’interface après un échec ?

Elle doit nommer la première étape observée et garder la tâche utilisable par la voie sans USB.

BotBrowser peut-il tester l’appareil physique ?

Il peut vérifier les états et le parcours de repli d’une page, mais il ne peut pas fournir l’appareil et ne prouve pas l’E/S matérielle.

Sources

• Norme USB WHATWG : requestDevice()
• Norme USB WHATWG : getDevices()
• Norme USB WHATWG : liste d’interfaces protégées
• Norme USB WHATWG : Permissions Policy
• Norme USB WHATWG : déconnexion
• Norme USB WHATWG : close()
• Norme USB WHATWG : forget()
• MDN : API WebUSB
• MDN : USBDevice

Pour les limites associées, voir Permissions Policy et capacités du navigateur et vie privée des permissions du navigateur.