Identité réseau et confidentialité WebRTC

BotBrowser prend en charge des réglages contrôlés d'identité réseau WebRTC; il ne rend pas les connexions anonymes et ne garantit pas la confidentialité hors contexte.

Résumé

WebRTC rassemble des adresses que le proxy des pages ne voit jamais. Choisissez un mode par contexte (profile, real ou disabled) et consignez-le. Examinez les candidats ICE et getStats() de la connexion WebRTC, puis vérifiez séparément l'adresse publique avec un service externe autorisé ; ces observations sont distinctes.

Sommaire

• Pourquoi WebRTC appartient à la politique de confidentialité
• Ce que le navigateur peut révéler
• Les trois modes
• Interpréter les données des candidats et des statistiques
• Un modèle de gouvernance pratique
• Conclusion pratique

Pourquoi WebRTC appartient à la politique de confidentialité

WebRTC permet les appels, les réunions, le support en direct et les médias entre pairs depuis le navigateur. Il forme aussi une surface distincte pour l'identité réseau. Une page peut recevoir des informations sur les adresses envisagées pour une connexion et consulter des statistiques pendant la session. Ces informations restent sensibles même lorsque les requêtes ordinaires passent par un proxy. BotBrowser peut coordonner les informations réseau WebRTC avec un profil configuré dans un contexte contrôlé ; il ne peut pas rendre les connexions pair à pair anonymes ni garantir la confidentialité en dehors de ce contexte.

La question n'est pas de supprimer WebRTC par principe. De nombreuses personnes en ont besoin pour communiquer. Il faut plutôt comprendre quelles informations d'adresse les API WebRTC exposent selon la politique du contexte. Une politique claire choisit un mode, explique le compromis et réexamine les observations lorsque la route change.

BotBrowser propose trois modes : profile, real et disabled. Ils correspondent à la politique du profil configuré, au réseau de l'hôte et à l'indisponibilité de WebRTC. Avec profile, les contrôles SDP et ICE configurés visent à aligner les informations WebRTC sur l'identité déclarée du profil ; vérifiez les conditions applicables du proxy et d'UDP sans assimiler cette intention à une mesure de la sortie publique. Le bon choix dépend de l'objectif du contexte et de la limite de confidentialité acceptée par l'organisation.

La politique privilégie la confidentialité, la réduction des données et la cohérence entre les candidats et les statistiques. Consultez la prévention des fuites WebRTC et les fonctions réseau pour le contexte associé.

Ce que le navigateur peut révéler

Lors de la préparation d'une session WebRTC, le navigateur rassemble des chemins possibles pour les médias. Un candidat porte un type candidate : host pour une interface locale, srflx pour une correspondance réflexive côté serveur, relay pour une adresse TURN, avec l'adresse elle-même (RFC 8445). Pendant la session, RTCPeerConnection.getStats() annonce les entrées local-candidate, remote-candidate et candidate-pair ; la paire sélectionnée identifie le trajet qui transporte alors les médias (statistiques WebRTC). Ces données aident à comparer le routage WebRTC observé à la politique du contexte, mais ne mesurent pas indépendamment la sortie publique des requêtes de page.

Une adresse peut relier une session à un réseau, une région, une organisation ou un foyer. Une adresse privée peut décrire la forme du réseau local. Une adresse publique peut identifier la sortie de l'hôte. Une adresse de relais peut signaler un service ou une région. L'ensemble peut créer un lien durable entre des sessions même si chaque élément pris seul semble limité. Pour voir comment les candidats d’hôte mDNS modifient ce qu’une page peut apprendre du réseau local, consultez Candidats mDNS WebRTC et confidentialité du réseau local, qui traite des candidats mDNS et des objectifs de confidentialité de la RFC 8828.

Les requêtes ordinaires et le chemin WebRTC sont liés sans être identiques. Un proxy peut donner une identité publique aux requêtes de page alors que WebRTC suit une autre route. Une politique qui ne regarde que le trafic de page ne couvre donc pas toute la session. Pour voir comment garder alignés le routage proxy, le DNS et WebRTC dans un flux de travail, consultez Cohérence proxy, DNS et WebRTC pour le navigateur, qui traite de la cohérence entre proxy, DNS, fuseau horaire et WebRTC.

La disponibilité compte aussi. Bloquer toute communication réduit une surface, mais peut empêcher réunions, assistance et collaboration. La politique doit partir du but du contexte, choisir un mode et rendre l'exposition restante lisible.

Les trois modes

Profile : examiner la politique d'identité

profile convient à un contexte doté d'une politique réseau déclarée, que l'on peut comparer aux données des candidats et des statistiques. Si le proxy SOCKS5 prend en charge UDP ASSOCIATE et que BotBrowser établit l'association, STUN peut emprunter ce proxy et les candidats ICE peuvent refléter son adresse. La paire sélectionnée décrit le trajet média WebRTC ; elle ne mesure pas séparément la sortie publique des requêtes de page. L'organisation devrait documenter la route attribuée à chaque contexte et confronter les deux observations à cette route.

Ce mode peut convenir à un flux qui a besoin d'appels et d'une frontière de confidentialité documentée. Il garde WebRTC disponible tout en appliquant la politique configurée ; le résultat dépend toujours du proxy et du réseau. Il ne remplace pas l'examen du fournisseur, de la région ou des règles de conservation. Pour voir comment le trafic UDP de QUIC et de WebRTC peut suivre le même plan de proxy, consultez UDP sur SOCKS5 : routes privées pour QUIC et WebRTC, qui traite de la politique de proxy TCP et UDP par contexte.

En cas de changement de proxy, de profil ou de route, consignez une nouvelle décision. Examinez les candidats et les statistiques au regard de la politique du contexte, sans en déduire que les requêtes de page ont suivi la même route.

Real : utiliser l'identité de l'hôte

real choisit explicitement l'identité réseau fournie par l'environnement hôte. Il peut convenir au développement local, à une vérification interne ou à une communication qui doit utiliser cette route. Ce n'est pas un mode de confidentialité en soi. Le réseau de l'hôte peut être visible par l'autre partie ou par un service recevant les informations WebRTC.

Nommer ce choix est préférable à une décision implicite. L'hôte peut avoir plusieurs interfaces, une route publique changeante ou des règles d'entreprise particulières. L'organisation doit savoir qui possède ce réseau et si ses adresses conviennent à la session.

Une session de résolution autorisée peut aussi utiliser real. Elle doit avoir un responsable, une durée limitée et une trace du fait que l'identité de l'hôte a été choisie intentionnellement.

Disabled : retirer une capacité inutile

disabled convient à un flux qui ne fait pas appel à la communication en temps réel. Il réduit les informations disponibles pour une page, mais retire les appels, le partage de médias et les autres fonctions dépendantes de WebRTC.

Ce mode doit être une décision produit explicite, et non l'effet accidentel d'un environnement défaillant. L'utilisateur doit savoir pourquoi une réunion ne démarre pas. Si le besoin revient, il faut passer à un contexte documenté avec profile ou real.

Le coût est fonctionnel. Certaines pages changent d'expérience quand la communication manque. Ce compromis est acceptable si la confidentialité est prioritaire, à condition de distinguer la politique d'une panne.

Interpréter les données des candidats et des statistiques

Deux vues peuvent sembler plausibles tout en décrivant des réseaux différents. Les candidats peuvent montrer une route puis les statistiques une autre. Les requêtes peuvent passer par un proxy pendant que le canal de communication montre le réseau de l'hôte. Un profil peut indiquer une région alors que l'adresse observée appartient à une autre.

La comparaison sert à examiner la politique ; elle ne promet pas que deux vues de l'API coïncident. Avec profile, examinez les candidats et la paire sélectionnée, puis comparez ces observations à la route attribuée au contexte. Avec real, interprétez les adresses exposées comme des informations du réseau hôte. Avec disabled, vérifiez que WebRTC n'est pas disponible. Le résultat alimente la revue sans garantir une adresse ou une route donnée.

Une migration réseau, un remplacement de proxy ou un changement de profil peut modifier la route pendant la session. Il faut alors réexaminer le choix du contexte. Plusieurs contextes sur une même machine peuvent avoir des politiques différentes si leur objectif et leur responsable sont distincts.

Mode	Types de candidat ICE	Vue getStats()	À retenir quand
profile	Suivent le profil chargé	Examiner les candidats et paires sélectionnés	Les appels doivent fonctionner sous une identité déclarée
real	Adresses d’interface de l’hôte (host, srflx)	Examiner les candidats et paires de l'hôte	La route de l’hôte est l’identité voulue
disabled	Aucun candidat WebRTC	Transport WebRTC indisponible	Le flux n’a jamais besoin de médias en temps réel

Un modèle de gouvernance pratique

Attribuez à chaque flux un but : communication, développement local, vérification interne ou navigation sensible. Notez s'il a besoin de WebRTC, choisissez profile, real ou disabled, puis identifiez le responsable de la route.

Décidez quels candidats et enregistrements statistiques doivent être examinés. Comparez ces observations à la politique du contexte sans supposer qu'elles coïncident ni qu'elles identifient la sortie publique. Ne conservez pas plus de détails d'adresse que nécessaire pour une tâche approuvée. L'accès aux traces doit suivre les règles de minimisation appliquées aux cookies, aux comptes et à l'état de session.

Lors de la maintenance, un changement de proxy, de profil, d'interface ou de besoin de communication est un changement de politique. La personne qui démarre un appel doit savoir si le contexte utilise la route du profil, celle de l'hôte ou aucune capacité WebRTC. Une explication claire évite les solutions non gérées.

Questions fréquentes

Un proxy protège-t-il WebRTC automatiquement ?

Non. Il peut contrôler les requêtes ordinaires alors que WebRTC utilise un chemin séparé. Examinez séparément les candidats ICE et les statistiques de la paire sélectionnée, puis interprétez-les selon la politique du contexte ; aucune de ces vues ne mesure seule la sortie publique.

Tous les contextes doivent-ils utiliser profile ?

Non. profile correspond à un besoin WebRTC associé à une identité définie. real peut être approprié à un flux appartenant à l'hôte et disabled à un flux sans communication. Le mode suit l'objectif.

disabled est-il toujours le choix le plus privé ?

Il réduit une surface, mais retire aussi une capacité légitime. Si un appel est nécessaire, un contexte profile documenté peut offrir un meilleur équilibre qu'une solution non gérée.

Pourquoi comparer candidats et statistiques ?

Ce sont deux vues de la communication. Leur sens privé permet de voir si le contexte présente une identité cohérente ou mélange plusieurs routes. La revue doit rester autorisée et limiter les données.

Que faire si le réseau change ?

Une interface ou une route peut changer. Le changement doit déclencher une revue du contexte afin de ne pas relier des observations appartenant à des réseaux différents.

Que conserver pour la revue de confidentialité ?

Conservez le mode retenu, la finalité du contexte, le responsable de la route et la décision de revue. Les détails d'adresse ne doivent être conservés que pour un besoin opérationnel approuvé, avec le même contrôle d'accès que l'état de session.

Sources

• RFC 8445 : Interactive Connectivity Establishment
• RFC 8828 : exigences de traitement des adresses IP WebRTC
• Statistiques WebRTC du W3C
• W3C WebRTC 1.0

Conclusion pratique

La confidentialité WebRTC est une décision d'identité réseau. profile, real et disabled proposent trois choix lisibles. Choisissez consciemment, examinez les enregistrements de candidats et de statistiques et interprétez-les selon la politique du contexte, sans supposer qu'ils coïncident ou révèlent la sortie publique. Consultez la prévention des fuites WebRTC et les fonctions réseau avant de figer le mode d’un contexte.

Consignez un mode par contexte. Examinez les candidats ICE et les enregistrements getStats() dans la page de test autorisée, puis vérifiez l'adresse publique avec un service externe autorisé. Traitez un contexte real comme une décision assumée sur le réseau de l’hôte, pas comme un oubli, et un contexte disabled comme un flux où les API WebRTC sont indisponibles. Recommencez les deux contrôles après un changement de réseau, une rotation de proxy ou une version majeure du navigateur.