Identité réseau et confidentialité WebRTC

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.

La question n'est pas de supprimer WebRTC par principe. De nombreuses personnes en ont besoin pour communiquer. Il faut plutôt vérifier que les informations présentées par WebRTC correspondent à l'identité réseau choisie pour le contexte. Une politique claire choisit un mode, explique le compromis et garde cette décision compréhensible pendant toute la session.

BotBrowser propose trois modes : profile, real et disabled. profile coordonne les informations réseau WebRTC avec le profil chargé. real conserve l'identité réseau de l'hôte. disabled retire la capacité WebRTC lorsque le flux n'a pas besoin de communication en temps réel. 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 peut contenir l'adresse d'une interface locale, d'une route publique associée ou d'un relais. Les statistiques peuvent fournir une autre vue des adresses engagées dans la session. Ces vues ont des rôles différents, mais elles appartiennent à la même limite de confidentialité.

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é.

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.

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 : coordonner l'identité choisie

profile convient à un contexte dont l'identité réseau est définie. WebRTC reste disponible, tandis que ses informations d'adresse sont coordonnées avec cette identité. Les candidats et les statistiques doivent correspondre à la même route choisie.

Ce mode est pertinent lorsqu'un flux a besoin d'appels et d'une frontière de confidentialité prévisible. Il conserve la communication, mais ne remplace pas l'examen du fournisseur réseau, de la région ou des règles de conservation. La route retenue doit rester clairement attribuée au contexte.

La valeur principale de profile est la cohérence. Les requêtes, les candidats et les statistiques représentent une seule identité réseau. Un changement de proxy, de profil ou de route doit être traité comme une nouvelle décision, surtout pour une session longue.

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.

Pourquoi les candidats et les statistiques doivent être cohérents

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 cohérence est donc une propriété de la politique. Avec profile, les deux vues doivent rester compatibles avec la route du profil. Avec real, elles doivent être comprises comme des informations du réseau hôte. Avec disabled, aucune capacité WebRTC ne doit produire ces vues. Le but n'est pas une adresse particulière, mais une relation claire entre le mode choisi et l'information exposé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.

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éfinissez aussi la relation attendue entre candidats et statistiques avec une règle simple : les deux vues doivent rester compatibles avec la même identité. 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é. Il faut vérifier que le mode choisi garde les adresses des candidats et des statistiques compatibles avec l'identité prévue.

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.

Pour finir

La confidentialité WebRTC est une décision d'identité réseau. profile, real et disabled proposent trois choix lisibles. L'essentiel est de choisir consciemment et de garder les adresses des candidats et des statistiques compatibles avec le même mode. Consultez la prévention des fuites WebRTC et les fonctions réseau en gardant ce choix près de la documentation du flux.