Candidats mDNS WebRTC et confidentialité du réseau local

WebRTC rassemble des candidats ICE pour trouver un chemin entre pairs. Un candidat hôte peut révéler une interface locale; le navigateur peut donc utiliser un nom mDNS au lieu d'une adresse privée. La RFC 8828 décrit cette orientation, sans promettre l'anonymat. BotBrowser peut rejouer un scénario autorisé et observer les candidats et l'état visible; il ne contrôle pas le pair distant ni sa conservation des journaux.

TL;DR

Considérez le nom mDNS comme une réduction d'exposition, pas comme la preuve qu'aucune information locale n'existe. Notez séparément la version du navigateur, la politique ICE, le type de candidat, l'origine finale et le résultat applicatif. Utilisez des médias synthétiques et des délais bornés. Ne publiez ni adresse, ni identifiant ICE, ni enregistrement.

BotBrowser peut rejouer un scénario WebRTC autorisé dans un contexte déclaré et observer des catégories de candidats expurgées ainsi qu'un état visible. Il ne contrôle pas le pair distant, ne fournit pas de caméra, n'inspecte pas la conservation du service et ne garantit pas le comportement de tous les navigateurs. Cette limite doit accompagner tout résultat utilisé pour une décision de version.

Sommaire

• Ce que change mDNS
• Séparer les preuves
• Exécuter un scénario borné
• Types de candidats en contexte
• Concevoir la comparaison
• Interpréter les résultats
• Conserver une preuve utile
• Classer les échecs et nettoyer
• Liste de contrôle
• Conclusion

Ce que change mDNS

Le candidat hôte décrit une interface locale. Avec mDNS, il contient un nom local plutôt qu'une adresse. Les candidats réflexifs peuvent encore montrer une correspondance publique et un relais peut révéler l'usage d'un relay. La liste des candidats n'est donc pas un rapport complet de confidentialité.

Séparer les preuves

Observation	À conserver	Ne prouve pas
Signalisation	origine finale et statut HTTP	la confiance envers le pair
ICE	type, protocole et nom mDNS abrégé	l'anonymat ou l'absence de journaux
Connectivité	paire sélectionnée et transition	la qualité de l'appel
Application	marqueur contrôlé et délai	une écriture serveur

Ne transformez pas un nom mDNS en inventaire. Abrégez le SDP et les secrets. Un changement de navigateur ou de TURN peut modifier les types sans modifier l'application.

Exécuter un scénario borné

Préparez une page de contrôle et une page candidate dont vous possédez les routes. Utilisez une piste générée, une signalisation limitée dans le temps et une assertion icegatheringstate. Distinguez DNS, certificat, permission, signalisation et connexion. Un délai dépassé signifie seulement qu'il manque une preuve.

Détails sur les candidats

Types de candidats en contexte

Les candidats host, réflexifs et relay répondent à des besoins différents. Host décrit une interface locale, réflexif un mappage vu via STUN et relay un transport TURN. Ce ne sont pas des niveaux de confidentialité: la visibilité dépend de la signalisation, du pair, du relais et du navigateur. mDNS remplace l'adresse locale par un nom dans la représentation, sans créer un identifiant stable ni un inventaire.

Concevoir la comparaison

Formulez une question étroite: «Cette version expose-t-elle un candidat host mDNS à ma page contrôlée, à configuration constante?». Comparez un contrôle et une candidate qui ne diffèrent que par un réglage déclaré. Gardez origine, route, navigateur, serveurs ICE, médias générés et permissions identiques; notez seulement les catégories expurgées, l'état et la version.

Champ	Contrôle et candidate	Pourquoi
Origine et route	même route HTTPS contrôlée	même contexte de sécurité
ICE et médias	configuration synthétique fixe	évite les variations STUN/TURN et appareils réels
Observation	catégorie de candidat expurgée	exclut adresses et identifiants
Résultat	état et catégorie de paire	sépare collecte et connectivité

Interpréter les résultats

Si une chaîne contient .local, consignez seulement mdns-host; ne conservez pas le nom. Une collecte terminée ne garantit pas une paire connectée, et une connexion ne dit rien de la conservation côté service ou pair. Ne déduisez pas une permission média de la collecte ICE. DNS, pare-feu, relais, description invalide ou assertion applicative peuvent expliquer un échec.

Conserver une preuve utile

Un reçu minimal contient la question, la version du scénario, le navigateur, la route, la configuration ICE, les catégories, l'état final, la catégorie de paire si disponible et l'heure. Il indique aussi ce qui reste inconnu: observation du pair, conservation de la signalisation, consentement réel et comportement universel. Excluez adresses, SDP, secrets, cookies et enregistrements des rapports ordinaires; les données brutes exigent un stockage restreint et une date d'effacement.

Classer les échecs et nettoyer

Attribuez chaque échec à son propriétaire: origine/navigation, signalisation, collecte ICE, portée du pair, relais/pare-feu ou assertion applicative. Chaque étape a un délai borné qui conserve le point d'arrêt. Fermez la connexion, arrêtez les pistes synthétiques et fermez le contexte en succès comme en erreur afin d'isoler l'essai suivant.

Liste de contrôle

• La page et la signalisation sont-elles contrôlées ou autorisées?
• La question sépare-t-elle représentation, connectivité, médias et service?
• Navigateur, origine, ICE et entrées synthétiques sont-ils déclarés?
• Noms, adresses, secrets, SDP et médias sont-ils absents des journaux?
• Chaque délai indique-t-il son étape et la portée reste-t-elle limitée?
• Connexions et pistes sont-elles fermées dans les deux chemins?

À retenir

Examinez l'origine, l'autorisation, la politique ICE, la rédaction des candidats, la route choisie et le résultat visible comme une chaîne. BotBrowser rejoue un parcours autorisé dans un contexte déclaré; il ne fournit pas de périphérique et ne garantit pas une conformité universelle.

Pour poursuivre, consultez le guide de prévention des fuites WebRTC et le guide UDP sur SOCKS5. Une preuve ne décrit que sa version, sa route et sa configuration déclarées.

Sources

• RFC 8828
• W3C WebRTC
• MDN RTCPeerConnection
• MDN connectivité WebRTC
• BotBrowser prévention des fuites WebRTC

BotBrowser Team