Permissions WebHID et limites de confidentialité des appareils

WebHID permet à une page de demander un périphérique d’interface choisi par la personne, mais l’autorisation n’est ni un inventaire ni une preuve de propriété. BotBrowser peut exercer la branche de permission de la page et son repli dans un contexte contrôlé ; il ne fabrique pas de contrôleur physique, n’accorde pas l’autorisation hors médiation du navigateur et ne prouve pas une E/S matérielle. Le contrat sûr est explicite : demander après une action, inspecter les seules collections nécessaires, borner chaque rapport, réconcilier les déconnexions et garder la tâche utilisable sans HID.

TL;DR

• navigator.hid.requestDevice({ filters: [{ usagePage: 0x01 }] }) exige un contexte sécurisé et une activation utilisateur transitoire.
• Une autorisation du sélecteur expose un HIDDevice ; elle ne prouve ni connexion, ni sécurité, ni propriété, ni compatibilité avec toutes les collections.
• Inspectez device.collections avant l’ouverture et traitez les octets de inputreport comme des données non fiables.
• disconnect termine la relation actuelle ; fermez les listeners, préservez le travail et exigez une nouvelle tentative délibérée.
• Conservez des résultats comme granted, unsupported ou disconnected, jamais des numéros de série ou un historique de rapports.

Sommaire

• Demander au point d’utilisation
• Inspecter les collections avant les rapports
• Borner les rapports et réconcilier les déconnexions
• Minimiser les métadonnées et garder un repli
• Classer les résultats avec un tableau
• Capacité et limite de BotBrowser
• Conclusion pratique

Demander au point d’utilisation

WebHID est limité aux contextes sécurisés et requestDevice() doit s’exécuter pendant l’activation transitoire. Placez la demande derrière un contrôle clairement nommé. La détection indique seulement qu’une méthode existe ; elle n’ouvre pas le sélecteur et n’accorde pas l’accès. Une politique, une iframe, le système ou la plateforme peuvent encore refuser la demande.

async function connectHid() {
  if (!window.isSecureContext || !navigator.hid) return showHidState('unsupported');
  setHidState('requesting');
  try {
    const devices = await navigator.hid.requestDevice({
      filters: [{ usagePage: 0x01, usage: 0x06 }],
    });
    if (devices.length === 0) return showHidState('no-device');
    await openSelectedHid(devices[0]);
  } catch (error) {
    showHidState(error.name === 'NotAllowedError' ? 'denied' : 'failed');
  }
}

connectButton.addEventListener('click', connectHid);

N’ouvrez pas le sélecteur au chargement et ne bouclez pas après une annulation. Conservez le brouillon et proposez une nouvelle demande après une action. Accès WebUSB : permissions, interfaces et confidentialité sépare autorisation, ouverture, revendication et nettoyage. Permissions Web Bluetooth, choix d’appareil et confidentialité applique la même limite d’intention à un autre modèle.

Inspecter les collections avant les rapports

Après la sélection, HIDDevice expose les métadonnées et collections. N’ouvrez qu’un appareil pris en charge et comparez usagePage, usage et les descripteurs avec l’opération prévue. Un nom de produit n’autorise pas tous les rapports et ne prouve ni identité, ni lieu, ni proximité.

Gardez une liste autorisée des usages et tailles de rapport. Refusez une collection incompatible au lieu de demander un accès plus large. Évitez de copier productName, vendorId, productId ou serialNumber dans les URL, comptes, analyses ou journaux courants : ces valeurs peuvent distinguer une unité sans révéler son propriétaire.

La carte des collections est une vue vivante. L’appareil peut s’ouvrir puis échouer, changer de descripteur après un firmware ou disparaître avant le premier rapport. Décrivez l’opération prise en charge et gardez une page ordinaire si aucune collection adaptée n’est exposée.

Borner les rapports et réconcilier les déconnexions

inputreport livre des octets du périphérique sélectionné. Vérifiez reportId, longueur, plages et fraîcheur avant de modifier l’état. Fixez un maximum, refusez les IDs inattendus et limitez la fréquence avant l’affichage ou l’envoi.

const MAX_REPORT_BYTES = 64;

function acceptInputReport(event) {
  const bytes = new Uint8Array(event.data.buffer);
  if (bytes.length === 0 || bytes.length > MAX_REPORT_BYTES) return;
  if (event.reportId !== 1 || bytes[0] > 100) return;
  updateControllerState({ reportId: event.reportId, value: bytes[0] });
}

device.addEventListener('inputreport', acceptInputReport);

Enregistrez navigator.hid.addEventListener('disconnect', ...) et rendez le nettoyage idempotent. Marquez la tâche déconnectée avant d’attendre close(), retirez les listeners, conservez les données et affichez un contrôle de reconnexion. Un rapport tardif ne doit pas repeindre la page comme prête. Ne reconnectez ni ne renvoyez automatiquement la dernière commande.

Minimiser les métadonnées et garder un repli

Séparez permission, session HID et consentement d’envoi. Lire localement n’autorise pas un envoi serveur. Demandez séparément, décrivez les champs sortants et laissez la tâche locale se terminer si l’envoi est refusé.

Un enregistrement opérationnel a généralement besoin de unsupported, denied, no-device, connected, invalid-report ou disconnected, avec date et environnement testé. Les rapports bruts, identifiants stables et carte complète des collections sont rarement nécessaires. Une capture de diagnostic doit être courte, visible, contrôlée et supprimée.

Gardez un formulaire clavier, une valeur manuelle, un import de fichier ou une configuration statique comme repli accessible. Ne rendez pas la connexion, la facturation, la récupération de compte ou le contenu obligatoire dépendants d’un HID physique.

Classer les résultats avec un tableau

Étape observée	Ce qu’elle établit	Action sûre
API absente, contexte non sûr ou politique	WebHID ne peut pas démarrer ici	Garder la tâche sans HID et expliquer la limite
Sélecteur annulé ou permission refusée	Aucun accès utilisable pour cet essai	Préserver le brouillon et attendre une action explicite
Appareil choisi mais collection incompatible	La capacité requise manque	Fermer, afficher les exigences et ne pas élargir les filtres
Longueur, ID ou plage invalide	L’entrée ne respecte pas le protocole	Ignorer, enregistrer invalid-report et continuer
Événement disconnect	La relation actuelle est terminée	Retirer les listeners, fermer et proposer une nouvelle tentative
Rapport valide et borné	Une valeur applicative a été acceptée	Rapporter cette valeur seulement ; ne pas inférer l’identité

Chaque ligne doit aboutir à un état compréhensible. Une permission n’est pas une connexion, une collection n’est pas un contrôleur de confiance et un rapport valide ne prouve pas une action physique.

Capacité et limite de BotBrowser

Les contextes contrôlés BotBrowser peuvent vérifier un bouton de connexion, la détection, le filtrage de collections, les rapports bornés, le nettoyage après déconnexion et le repli sans HID. La documentation des fonctionnalités avancées décrit les capacités révisables dans ce contexte. Le résultat reste une preuve de page : BotBrowser ne fournit pas d’appareil HID, n’accorde pas la permission du système, ne garantit pas un rapport et ne prouve pas qu’une personne possède ou touche le contrôleur.

{
  "api": "navigator.hid",
  "permission": "denied",
  "collectionsAccepted": 0,
  "reportsAccepted": 0,
  "rawIdentifiersRetained": false,
  "physicalDevice": "not-asserted"
}

Répétez le fixture après un seul changement : version du navigateur, politique du contexte sécurisé, résultat de permission, filtre de collection ou déconnexion simulée. Comparez la première divergence visible sans promettre un support matériel universel.

États observables

Le test conserve la séquence visible et ne transforme pas un résultat de page en affirmation matérielle.

Limites matérielles

L’acceptation physique exige un appareil approuvé et un environnement distinct du fixture de page.

Sources

• Spécification WebHID
• MDN : WebHID API
• Fonctionnalités avancées BotBrowser

Conclusion pratique

Utilisez une action explicite, inspectez les collections prises en charge, validez chaque rapport et fermez les listeners après déconnexion. Gardez la tâche complète sans HID et journalisez l’étape de l’échec plutôt que des identifiants. Rejouez le fixture après un changement de navigateur, de politique, de firmware ou de permission ; un succès de page ne promet pas un comportement matériel.