Énumération MediaDevices et confidentialité des caméras virtuelles

L’énumération des périphériques média aide à choisir une caméra ou un microphone, mais ne prouve pas que la page peut capter ce périphérique. enumerateDevices() expose une vue des entrées et sorties filtrée par les permissions et les règles ; getUserMedia() demande séparément l’accès et tente d’ouvrir une source réelle. Une caméra virtuelle dépend d’un logiciel externe. La liste est à la fois une surface de confidentialité et une aide de sélection limitée : expliquez le besoin, demandez uniquement le flux nécessaire et rendez la source active visible. BotBrowser contrôle la façon dont cette énumération est déclarée, mais ne crée pas la source, n’accorde pas de permission et ne garantit pas un flux utilisable.

Cette distinction compte lorsqu’on examine l’identité du navigateur. Une page peut savoir qu’une catégorie de caméra ou de microphone existe avant de recevoir un libellé utile, mais cela ne prouve ni le consentement, ni le bon fonctionnement du matériel, ni la disponibilité d’un flux. Pour aller plus loin, consultez l’empreinte liée aux permissions du navigateur et la confidentialité réseau de WebRTC.

Voir la vidéo

Cette vidéo en anglais suit un appel à enumerateDevices() dans une page de laboratoire contrôlée : le kind, le label et le deviceId reçus par une page, pourquoi les libellés restent soumis à autorisation, et en quoi le mode profil et le mode réel diffèrent comme sources de périphériques. Elle montre une observation sur un runner Ubuntu ; elle ne compare pas des machines, n'accorde aucune autorisation de capture et n'établit ni identité, ni anonymat, ni accès, ni la décision d'un site distant.

Résumé

L’énumération est une vue de découverte filtrée par les permissions, pas une preuve de capture. BotBrowser peut contrôler la liste d’appareils du profil déclarée à la page, mais l’autorisation, la disponibilité de la source et le flux restent des conditions distinctes du navigateur et du système.

Sommaire

• Voir la vidéo
• Ce que l’énumération des périphériques révèle
• Pourquoi la liste est limitée et sensible
• Énumérer ne signifie pas obtenir un flux
• Ce qu’ajoute une caméra virtuelle
• Parcours de décision pour la configuration et le diagnostic
• Contrôle d’énumération et limites de BotBrowser
• Conclusion pratique

Ce que l’énumération des périphériques révèle

La notification de changement n’est disponible que si le navigateur la prend en charge et son délai peut varier. L’interface doit pouvoir s’actualiser et gérer la disparition d’une source avant son ouverture.

navigator.mediaDevices.enumerateDevices() renvoie des enregistrements MediaDeviceInfo pour les entrées et sorties que le navigateur expose dans le contexte courant. kind distingue les entrées audio, les entrées vidéo et les sorties audio ; label fournit le nom affiché lorsque sa divulgation est permise. Le navigateur peut placer les périphériques de capture par défaut en premier. Le résultat est donc une vue ordonnée et liée au contexte, pas l’inventaire complet de l’équipement. Le premier élément n’est pas nécessairement « la caméra » : plusieurs types peuvent apparaître, et l’ordre par défaut ne représente pas la préférence de l’utilisateur.

Le contexte limite la liste. Les interfaces concernées nécessitent un contexte sécurisé ; Permissions Policy peut exclure certains types et les permissions influencent les périphériques et libellés révélés. Avant l’accès, des entrées peuvent manquer ou leurs noms être vides. Une autorisation peut rendre la vue plus informative, sans la rendre stable. Un casque branché, une caméra différente, une permission modifiée ou un réglage système peut changer le résultat.

Même sans libellé, la présence et le type des éléments peuvent indiquer si le contexte semble disposer de choix de caméra ou de microphone. Leur nombre, leur ordre ou l’évolution des noms donnent d’autres indices sur l’équipement. Recueillir ces données à répétition est donc un choix de confidentialité, pas un diagnostic anodin. Si l’utilisateur doit seulement sélectionner une source pour un appel, gardez la liste dans l’interface au lieu de l’envoyer aux outils d’analyse. Pour l’assistance, conservez le fait minimal qui aide à résoudre le problème plutôt que l’inventaire brut.

Considérez le résultat comme un instantané. Brancher un casque, activer une caméra virtuelle, modifier une permission ou changer d’ordinateur peut modifier la liste. La spécification Media Capture définit une notification de changement des périphériques visibles par le document ; l’application doit quand même actualiser ses choix à des moments utiles et gérer la disparition d’une source entre la sélection et la capture. Cette notification ne garantit pas que tous les changements matériels ou système seront immédiatement signalés dans chaque navigateur.

Pour rester lisible sur un écran étroit, présentez chaque résultat comme une fiche courte :

• Une entrée vidéo apparaît. Cela signifie que le navigateur signale un choix vidéo dans ce contexte. Cela ne prouve pas que la caméra est alimentée, autorisée ou capable de produire des images. Étape suivante : demander le flux voulu et traiter le résultat.
• Le libellé est vide ou générique. Le contexte ne reçoit pas de nom utile. Cela ne prouve pas que le périphérique manque ou soit défectueux. Vérifiez le contexte sécurisé, la politique, la permission et le comportement attendu.
• Plusieurs entrées ou un ordre différent apparaissent. Plusieurs choix sont signalés ou la vue a changé. Cela ne prouve pas que le premier soit préféré ou que la liste soit stable. Laissez l’utilisateur choisir et actualisez l’interface.
• Aucun choix adapté n’apparaît. L’énumération actuelle n’expose pas de choix correspondant. Cela ne prouve pas qu’aucune source physique ou virtuelle n’existe. Vérifiez le système, l’application source et la politique.

Ce tableau évite de transformer une observation du navigateur en affirmation excessive sur le matériel ou le consentement. MediaDeviceInfo.label sert à présenter un choix ; il ne prouve ni le propriétaire ni le contenu de la source. Ce n’est pas non plus le libellé de MediaStreamTrack.label, qui décrit une piste une fois la capture commencée.

Pourquoi la liste est limitée et sensible

L’accès dépend de plusieurs couches. Les interfaces pertinentes nécessitent un contexte sécurisé. Le navigateur applique ses permissions et le site qui intègre la page peut être limité par Permissions Policy. L’utilisateur peut refuser, tandis que le système d’exploitation peut bloquer l’appareil séparément. Une autorisation du navigateur ne signifie pas que le système peut fournir des images ; un réglage système ne donne pas, à lui seul, l’autorisation à l’origine web. Pour voir comment les politiques encadrent les capacités du navigateur de façon plus générale, consultez Permissions Policy, capacités du navigateur et vie privée.

Le navigateur peut ne montrer que les périphériques par défaut ou retenir leurs libellés tant que l’origine ne dispose pas d’une permission de capture. Ne promettez pas que l’énumération fournit toujours la liste entière et ne qualifiez pas tout libellé vide de panne. Expliquez l’étape utile : ouvrir la page en contexte sécurisé, vérifier la politique d’intégration pour le type demandé, consulter le réglage de permission du navigateur si nécessaire, puis réessayer à la suite d’une action de l’utilisateur. N’ouvrez pas un flux uniquement pour révéler des noms si le produit n’a aucun besoin de capture.

Les choix exposés peuvent varier selon l’environnement. Un site qui les recueille peut les ajouter à une empreinte plus générale du navigateur. La réponse consiste à limiter les données et à expliquer le besoin, pas à promettre que l’énumération est secrète ou identique partout. deviceId est propre à l’origine appelante et peut persister entre les sessions selon le modèle de confidentialité du navigateur, mais l’effacement du stockage ou la navigation privée peut le faire tourner. groupId est généré par document et n’est pas stable entre les sessions de navigation. Ni l’un ni l’autre ne constitue une identité permanente. Ne conservez pas les noms, le nombre ou les identifiants au-delà de la sélection ou de l’assistance nécessaire. N’utilisez pas la liste comme facteur d’authentification ni comme substitut à l’identité choisie par l’utilisateur.

Dans une intégration cross-origin, deux règles s’appliquent : l’en-tête de réponse de la page principale définit la liste autorisée et l’attribut allow de l’iframe délègue uniquement à l’intérieur de cette liste. Par exemple :

Permissions-Policy: camera=(self "https://meet.example"), microphone=(self "https://meet.example")
<iframe src="https://meet.example" allow="camera; microphone"></iframe>

Si l’en-tête exclut l’origine intégrée, allow ne peut pas ajouter d’accès. La politique omet de enumerateDevices() les types de caméra ou de microphone qu’elle bloque ; il s’agit de la vue filtrée de l’origine, pas d’une preuve que l’appareil est absent. getUserMedia() reste une étape distincte, soumise à l’autorisation et à la disponibilité de la source.

Les commandes visibles doivent correspondre à la demande : indiquez si la session a besoin de son, d’image ou des deux, qui recevra le contenu et s’il sera enregistré, ainsi que l’option restante en cas de refus. Un appel d’assistance audio ne doit pas exiger la caméra. Un écran de sélection ne doit pas lancer silencieusement un enregistrement. Permettez de changer de source ou d’arrêter la capture sans dépendre uniquement de l’aperçu visuel. Sur un sujet voisin, l’audio, consultez Accès à Web Audio API et flux audio pratiques.

Énumérer ne signifie pas obtenir un flux

Arrêter une piste média termine la capture active ; cela ne révoque pas à lui seul l’autorisation du site pour une demande ultérieure. Si les deux actions existent, leurs commandes doivent être distinctes.

enumerateDevices() indique quels enregistrements la page voit maintenant. getUserMedia() répond à une autre question : après la décision de permission applicable, le navigateur peut-il ouvrir une source audio ou vidéo et renvoyer un MediaStream ? Une énumération réussie n’est pas une capture réussie. La demande peut échouer si l’utilisateur refuse, si le navigateur ou le système bloque la capacité, si le contexte n’est pas admissible ou si aucune source n’est disponible. Elle peut aussi rester en attente tant que la personne n’a pas répondu.

Traitez le résultat comme un état de capture, pas comme un échec d’énumération. Gardez une option sans caméra ou microphone lorsque le produit le permet et ne répétez pas la même demande après un refus sans nouvelle action de l’utilisateur. Si la capture commence, affichez la source et son état actif. Si elle est déconnectée, informez-en la personne et laissez-la choisir une autre source ; un basculement silencieux peut modifier le contenu capté et dépasser son attente.

Séparez dans les journaux les choix énumérés, l’état de permission, le résultat de la demande, la piste sélectionnée et son état actif ou terminé. L’assistance peut alors distinguer une liste vide, un refus, un blocage système ou une piste terminée après déconnexion. Ne conservez pas le contenu média ni toute la liste pour départager ces cas. Pour une autre surface d’appareil soumise à permission, consultez Permissions Web Bluetooth, choix d’appareil et vie privée.

Ce qu’ajoute une caméra virtuelle

Le partage d’un onglet ou de l’écran suit une voie de capture distincte et nécessite un choix de l’utilisateur. Ce n’est ni un appareil caméra renvoyé par enumerateDevices() ni une caméra virtuelle.

Une caméra virtuelle est une source fournie par une application installée ou une intégration du système. Elle peut assembler une scène, une présentation, une mire de test ou une autre entrée approuvée. Le navigateur ne la crée pas en appelant enumerateDevices() ; voir son nom ne prouve pas que l’application correspondante fonctionne ou produit des images. Une demande utilisateur getUserMedia({ video: true }) constitue l’étape distincte qui demande au navigateur d’ouvrir une source caméra.

La source a son propre cycle. Si le parcours le nécessite, démarrez l’application approuvée avant la capture. L’utilisateur sélectionne ensuite la caméra par le parcours normal du navigateur, avec les mêmes permissions, et la capture dépend de la disponibilité réelle de la source. À la fin, arrêtez la piste puis fermez ou désactivez la source avec ses commandes habituelles. Ce sont deux actions distinctes : terminer le flux du navigateur ne quitte pas forcément l’application ; la fermer peut interrompre ou faire échouer la piste sélectionnée.

Choisissez un nom clair, comme « Caméra de présentation », et indiquez s’il s’agit d’une image en direct, d’une scène composée ou d’une mire. Vérifiez le contenu avant le partage : une scène préparée peut révéler des données de compte ou des documents internes comme une caméra physique peut montrer une pièce privée. Une caméra virtuelle convient à la production, à la formation, à l’accessibilité ou aux essais légitimes ; elle ne remplace ni le consentement ni la vérification du contenu.

Si la source est absente, examinez la chaîne dans l’ordre : vérifiez que l’application source fonctionne et produit la scène attendue, que le système la présente au navigateur, puis le résultat d’énumération et enfin une demande de capture initiée par l’utilisateur. Chaque étape répond à une question différente. Une entrée absente ne prouve pas qu’on puisse contourner l’API et modifier la liste ne garantit pas un flux fonctionnel. Après le démarrage, MediaStreamTrack.readyState indique si la piste choisie est toujours live ou terminée.

Parcours de décision pour la configuration et le diagnostic

Ce parcours choisit la vérification suivante sans confondre découverte, consentement et capture. Il convient à une page de réglages, à un guide d’assistance ou à une validation de version : chaque résultat mène à une action limitée.

Sur un écran étroit, utilisez le même parcours sous forme de fiches courtes :

• Le contexte n’est pas sécurisé ou l’interface manque. Le parcours média normal ne peut pas fonctionner ici. Ouvrez la page sécurisée prise en charge ou expliquez la limite.
• Le périphérique n’est pas listé. La vue filtrée par permissions et règles n’expose pas de choix. Vérifiez la politique d’intégration et la source système sans conclure à une absence matérielle.
• Le périphérique apparaît sans libellé. Le choix est découvert, mais son nom n’est pas divulgué. Continuez seulement si le choix reste sûr et revoyez les permissions si le nom est nécessaire.
• L’utilisateur refuse. La capture n’est pas autorisée. Gardez l’alternative prévue et respectez la décision.
• La permission est accordée, mais la capture échoue. L’autorisation n’a pas rendu la source utilisable. Vérifiez la confidentialité système, l’application source, la connexion et l’erreur exacte.
• La capture commence puis s’arrête. Une piste active s’est terminée ou a perdu sa source. Affichez l’arrêt, réinitialisez l’interface et demandez avant de remplacer la source.

Pour un nouveau parcours, commencez par la capacité minimale. Expliquez l’usage, ne demandez que le type nécessaire et testez le refus. Essayez ensuite une source absente ou déconnectée, une liste modifiée et l’arrêt correct du flux. L’événement devicechange peut déclencher une nouvelle lecture de la liste après le branchement ou le retrait d’un appareil, mais il n’accorde pas de permission et ne relance pas la capture. Gardez le même sens sur mobile et bureau même si l’interface de permission diffère. Vérifiez aussi les analyses et journaux : ne gardez que les faits nécessaires à l’exploitation, pas le contenu média ni la liste entière par défaut.

Pour une caméra virtuelle, ajoutez deux contrôles : l’application externe produit la scène attendue et le navigateur possède une piste réellement sélectionnée après le consentement. Le premier ne prouve pas le second. Confirmez la source affichée avant le partage et gardez la commande d’arrêt accessible durant la session. À la fin, stream.getTracks().forEach(track => track.stop()) arrête chaque piste du flux. Un résultat utile est un parcours observable, pas seulement une liste non vide.

Contrôle d’énumération et limites de BotBrowser

BotBrowser documente --bot-media-devices comme réglage de la façon dont navigator.mediaDevices.enumerateDevices() signale les périphériques audio et vidéo. Par défaut, le navigateur renvoie la liste du profil sans option supplémentaire. Cela peut aligner la vue des appareils rapportés sur le profil choisi lorsque le parcours en dépend. BotBrowser contrôle l’énumération rapportée, mais ne crée pas de caméra virtuelle, n’accorde pas de permission au navigateur ou au système et ne garantit pas que la source choisie produise un MediaStream.

Ce réglage concerne l’énumération rapportée. Il n’installe ni ne crée de caméra virtuelle, ne démarre pas l’application source, n’accorde pas de permission au navigateur ou au système et ne garantit pas qu’une source sélectionnée produise un MediaStream. La page et la plateforme appliquent toujours les règles normales de permission et de capture. Validez séparément la liste, l’autorisation et le flux ; décrivez uniquement le résultat réellement vérifié.

La liste d’un profil peut donc rendre prévisible la surface de découverte, tandis que le parcours visible reste chargé du consentement, du choix de source, des échecs de capture et de l’arrêt. Gardez ces limites explicites dans les instructions d’assistance et l’interface.

Suite sur Screen Capture

Screen Capture API ajoute une surface choisie par l'utilisateur; comparez son cycle de vie à cette limite d'énumération dans Screen Capture API : contrôle utilisateur et confidentialité.

Conclusion pratique

Traitez séparément l’énumération, l’autorisation et la disponibilité du flux. Utilisez le contrôle d’énumération fondé sur le profil BotBrowser seulement pour aligner la vue déclarée sur le profil prévu ; gardez visibles le consentement, le logiciel de caméra virtuelle, l’accès du système et l’arrêt du flux.

Sources

• Documentation BotBrowser sur les périphériques média
• MDN : MediaDevices.enumerateDevices()
• MDN : MediaDevices.getUserMedia()
• W3C : Media Capture and Streams
• W3C : Permissions Policy