Rapport WebRTC CreepJS : origine des champs

Le panneau WebRTC de CreepJS est un rapport composé, pas une capture de paquets ni un inventaire de tout ce que le navigateur peut faire. Le collecteur fixé au commit 10aa6724cd33a1015db1574211890518cd04f0cc combine l'énumération des types d'appareils, six requêtes de décodage multimédia, le SDP d'une offre et certaines données d'événements ICE. BotBrowser documente des commandes de candidat, de proxy et de serveur ICE pour les flux autorisés ; cette configuration ne garantit pas l'exactitude d'un rapport CreepJS et n'identifie ni interface physique ni personne.

TL;DR

• Le collecteur transforme les lignes de enumerateDevices() en types d'appareils et les trie ; ce helper ne lit pas les libellés.
• Il interroge decodingInfo() avec six configurations audio/vidéo fixes, conserve les lignes prises en charge et les réduit aux indications de fluidité et d'efficacité énergétique.
• Les ID numériques des extensions SDP sont retirés avant déduplication et tri des chaînes restantes. La liste affichée n'est pas le SDP d'origine.
• La première chaîne d'événement non vide fournit iceCandidate et foundation ; un autre événement peut compléter le résultat plus tard.
• Sans RTCPeerConnection, le résultat immédiat est null. Un délai distinct de trois secondes peut renvoyer des champs partiels ; null, résultat partiel et champ absent ne sont pas des verdicts équivalents.

Sommaire

• Périmètre du collecteur et révision épinglée
• Carte de provenance des champs
• Ce que les champs issus du SDP omettent
• Champs de candidat et résultats partiels
• Ce que représente le hash du rapport
• Un relevé de lecture limité
• Conclusion pratique

Périmètre du collecteur et révision épinglée

Les liens de code désignent une révision publique précise de CreepJS. Les affirmations décrivent ce code, pas une exécution du site CreepJS actuel, de BotBrowser ou de Chrome standard. Le périmètre est plus limité qu'un guide de configuration WebRTC : relier les valeurs visibles aux opérations qui les produisent et montrer où l'implémentation écarte, résume ou interrompt des données.

Cette distinction compte, car la comparaison des codecs WebRTC porte sur les API de codecs et la compatibilité, tandis que le regroupement des candidats ICE et le timing de confidentialité examine la précollecte et le calendrier des événements. La prévention des fuites WebRTC couvre la configuration du proxy et d'ICE. Cette page suit plutôt la construction du rapport d'un collecteur ; elle ne remplace pas ces guides opérationnels.

Carte de provenance des champs

Valeur ou groupe du rapport	Opération source fixée	Traitement ou état absent	Ce que cela permet d'affirmer
mediaDevices	navigator.mediaDevices.enumerateDevices()	Convertit chaque ligne en kind, puis trie ; API indisponible renvoie null	Types d'appareils reçus par ce helper, pas les libellés, les appareils physiques ou l'identité de l'utilisateur
codecsSdp	SDP de createOffer() et ID de formats multimédias	Résume type MIME, fréquences, canaux, paramètres de format et retours de contrôle	Vue analysée de capacités sélectionnées de l'offre, pas chaque ligne SDP ni une réussite de lecture
extensions	Lignes SDP a=extmap	Retire l'ID numérique, déduplique et trie	Chaînes d'extension restantes selon cet analyseur, pas leur ordre ni leurs ID d'origine
iceCandidate et foundation	Premier événement icecandidate non vide	Extrait foundation une fois ; la branche avec adresse remplace les valeurs connues, le délai garde la valeur brute	Première chaîne d'événement et valeur affichée selon la branche, pas un inventaire d'interfaces
address	connection.localDescription.sdp	Analyse d'abord une ligne de connexion, puis une sous-chaîne ressemblant à un candidat ; exclut 0.0.0.0	Adresse renvoyée par cet analyseur, pas preuve qu'aucune autre n'existe
foundationProp et stunConnection	Événement qui atteint la branche d'adresse valide	Renvoyés avec l'adresse analysée ; l'événement peut suivre celui qui a enregistré iceCandidate	Champs de l'événement qui termine cette branche, pas nécessairement de celui derrière iceCandidate
Hash affiché	codecsSdp, extensions, foundation, foundationProp, address et mediaDevices	Résume un sous-ensemble ; iceCandidate et stunConnection n'en font pas partie	Égalité de ces entrées sélectionnées dans cette implémentation, pas du rapport entier

Ce tableau est une carte du code source, pas une mesure. L'API RTCPeerConnection et la spécification WebRTC du W3C définissent l'interface du navigateur, mais les noms et traitements ci-dessus appartiennent à ce collecteur précis. Un champ portant le nom d'une API connue peut rester une projection avec perte de sa sortie.

Ce que les champs issus du SDP omettent

Le helper d'extensions extrait les lignes extmap, retire l'ID numérique de l'extension, puis déduplique avec Set et trie dans l'ordre lexical. Deux offres SDP dont les ID ou l'ordre d'origine diffèrent peuvent donc produire la même liste affichée si les chaînes restantes concordent. Cette liste ne permet pas de reconstituer les lignes initiales.

Elle facilite une question, « quels noms d'extension ont survécu à l'analyse ? », mais en rend deux autres impossibles : « quel ID numérique leur était attribué ? » et « dans quel ordre l'offre les a-t-elle présentés ? ». Il ne faut pas déduire ces valeurs supprimées des chaînes triées.

La sortie des codecs est également résumée. Le collecteur lit les ID de formats multimédias audio et vidéo, cherche les lignes rtpmap, fmtp et rtcp-fb correspondantes, puis regroupe les entrées par type MIME. Le résultat conserve des champs choisis, comme les fréquences, les canaux, les paramètres de format et les retours de contrôle. Cela permet de comprendre ce que le panneau affiche, mais ne constitue ni une archive SDP intacte ni une preuve qu'un pair distant a accepté chaque codec.

L'ordre de l'analyse compte. Le code cherche d'abord les ID de format des sections multimédias, puis parcourt tout le SDP de l'offre pour trouver les lignes contenant chaque ID. Une ligne rtpmap fournit un type MIME et une fréquence ; pour l'audio, un troisième composant séparé par des barres indique le nombre de canaux, avec une valeur par défaut de un s'il manque ou vaut zéro. Une ligne rtcp-fb rejoint les retours de contrôle. D'autres lignes correspondantes peuvent fournir des paramètres de format séparés par des points-virgules. Ce sont des champs d'affichage assemblés depuis les lignes reconnues, pas un validateur de normes.

Le collecteur limite aussi les détails de codecs répétés. Il traite les entrées RTX à part et un compteur évite d'ajouter une seconde description RTX par la même voie. Les entrées ayant le même type MIME sont fusionnées : les fréquences sont réunies en valeurs uniques, de même que les paramètres de format ou les retours de contrôle lorsqu'ils existent. Si une section n'a aucun ID de format ou aucune ligne correspondante, sa liste de descriptions peut être vide. Cela indique ce que cet analyseur a trouvé dans cette offre ; cela ne prouve ni l'absence d'un décodeur du navigateur ni l'échec de lecture.

Cette distinction est utile lorsque le panneau paraît plus court que le SDP. Une ligne plus brève peut provenir d'un regroupement, d'une déduplication, d'une sélection de champs ou d'une ligne manquante. Elle ne démontre pas à elle seule qu'un codec a été retiré de l'offre. Pour répondre à une question sur l'offre, examinez une capture SDP distincte, autorisée et expurgée ; ne la reconstruisez pas à partir du tableau du rapport.

Le helper séparé decodingInfo() construit six configurations fixes : quatre types audio et deux vidéo, avec des dimensions, débits, fréquences d'images, nombres de canaux et fréquences d'échantillonnage fixés. Les entrées audio sont Ogg Vorbis, Ogg FLAC, MP4/AAC et MPEG audio ; les entrées vidéo sont Ogg/Theora et MP4/AVC. L'objet vidéo utilise 1920 par 1080, 120000 bits par seconde et 60 images par seconde. L'objet audio utilise deux canaux, 300000 bits par seconde et une fréquence de 5200. Le code transmet l'objet audio aux entrées audio et l'objet vidéo aux entrées vidéo.

Seules les réponses ayant supported: true sont conservées ; les indications smooth et efficient sont émises si les booléens correspondants sont vrais. Une réponse compatible peut n'afficher aucune indication lorsque les deux booléens sont faux. Une ligne absente peut signifier que le réducteur a écarté une réponse avec supported faux ; une promesse rejetée suit une voie de journalisation et ne fournit aucune ligne à réduire. Aucun de ces états n'explique seul l'indisponibilité d'un format dans une autre application. Ces entrées sont des requêtes précises, pas toutes les combinaisons possibles de canaux, fréquences, résolutions, profils de codec ou fréquences d'images.

Il ne s'agit pas de demander quels formats sont pris en charge par la plateforme en général. La spécification Media Capabilities décrit les champs de prise en charge, de fluidité et d'efficacité énergétique ; le collecteur fixe choisit les six entrées interrogées et les valeurs conservées. La référence de decodingInfo() explique le contrat de la méthode, pas la politique d'affichage du collecteur. Si une application utilise 30 images par seconde tandis que le rapport en demande 60, ce sont deux requêtes distinctes. Le résultat de l'une ne se transpose pas automatiquement à l'autre. La même limite vaut pour la fréquence d'échantillonnage et les canaux audio : une requête à deux canaux avec la valeur fixée n'énumère pas toutes les configurations possibles.

Champs de candidat et résultats partiels

Le callback enregistre la première chaîne non vide et analyse son foundation, mais continue d'écouter jusqu'à ce que getIPAddress() puisse extraire une adresse du SDP de la description locale. Dans cette branche, knownInterface transforme 842163049 en public interface et 2268587630 en WireGuard ; le délai de trois secondes renvoie plutôt la valeur brute analysée. La valeur affichée dépend donc de la branche de sortie et ne constitue pas un inventaire d'interfaces. foundationProp et stunConnection viennent de l'événement qui satisfait la branche d'adresse et peuvent donc être postérieurs à celui qui a enregistré iceCandidate.

Deux conditions d'arrêt sont distinctes. Si window.RTCPeerConnection manque, le collecteur renvoie null avant de créer une connexion. Sinon, il crée une connexion avec une taille de groupe de un et deux URL STUN Google, crée un canal de données et demande une offre avec des options de réception audio et vidéo. Il appelle setLocalDescription() puis lit immédiatement le SDP de l'objet offre pour résumer les extensions et les codecs. Cette première analyse n'attend pas que setLocalDescription() soit terminée.

Le collecteur lance ensuite un délai de trois secondes tout en écoutant les événements icecandidate. À son échéance, si un SDP d'offre existe, le résultat peut contenir les champs de codec, d'extension, de foundation et de candidat sans les champs d'adresse obtenus plus tard ; sans SDP, il renvoie null. Le délai retire le listener et ferme la connexion. Cette fenêtre temporelle est définie par le code ; elle ne prouve ni la fin de la collecte ICE ni l'exhaustivité de la liste finale. Le code n'associe pas de motif universel à tous ces cas.

getIPAddress() essaie d'abord une ligne de connexion SDP puis une sous-chaîne ressemblant à un candidat. Il exclut le littéral 0.0.0.0, mais un résultat undefined établit seulement que ce code n'a pas renvoyé d'adresse. Il ne prouve pas que le navigateur n'avait pas d'interface, qu'aucun candidat n'existait ou qu'un service distant a accepté ou refusé la session. Cet analyseur n'est pas un inventaire réseau : il renvoie une correspondance selon sa priorité à la ligne de connexion. Le guide distinct sur la confidentialité des adresses mDNS explique ce que la forme d'une adresse peut révéler et ce qu'elle ne prouve pas.

L'association des champs renvoyés a une limite subtile. iceCandidate et foundation ne sont définis que tant que la chaîne enregistrée est vide ; ils conservent donc la première chaîne d'événement non vide. L'analyse d'adresse lit en revanche le texte actuel de connection.localDescription.sdp. Lorsqu'un événement atteint un SDP avec une adresse analysable, le callback renvoie foundationProp et stunConnection de cet événement courant. Regrouper toutes les propriétés renvoyées sous « le premier candidat » confondrait deux règles de sélection distinctes.

L'objet peut donc mêler plusieurs provenances : la chaîne et le foundation conservés depuis un événement précoce, une adresse trouvée dans la description locale courante et des champs issus de l'événement qui a satisfait la branche d'adresse. « Mêlées » décrit les branches qui ont fourni chaque propriété ; cela ne prouve pas une course, une incohérence ou un défaut réseau. Il faut conserver la distinction de source au lieu d'affirmer que toutes les propriétés décrivent un seul paquet ou une seule interface.

Le callback ignore aussi les événements sans objet de candidat et retourne tôt lorsque le texte courant de la description locale ne fournit pas d'adresse. Il ne termine pas la collecte à chaque événement. Le délai est l'autre voie de fin et son résultat partiel contient moins de propriétés que la voie où une adresse a été trouvée. Lors de la comparaison de deux rapports, vérifiez d'abord s'ils ont atteint la même branche ; sinon, la différence de forme de l'objet peut provenir du timing ou de la disponibilité, pas d'une valeur modifiée dans un champ commun.

Ce que représente le hash du rapport

Le code d'affichage construit l'entrée du hash avec codecsSdp, extensions, foundation, foundationProp, address et mediaDevices. Il n'inclut pas chaque valeur renvoyée : iceCandidate et stunConnection ne figurent pas dans cet objet. Une chaîne brute différente peut donc ne pas apparaître dans la comparaison du hash si les champs choisis restent identiques ; à l'inverse, un champ retenu peut modifier le résumé sans expliquer la cause du changement.

L'égalité du hash est un outil de comparaison propre à cette implémentation. Elle n'établit pas que deux navigateurs sont le même appareil, que leurs rapports complets concordent ou qu'un site externe leur attribue le même résultat. Si les digestes diffèrent, le code indique seulement qu'au moins une entrée choisie diffère selon l'implémentation du hash ; le digeste ne dit pas laquelle. S'ils concordent, des champs omis peuvent encore différer parce qu'ils ne faisaient pas partie de l'entrée. Le résumé est une invitation compacte à inspecter les champs choisis, pas leur substitut.

Le producteur calcule également mediaDevices indépendamment du résultat de la connexion pair à pair. Le rendu HTML transforme cette liste en libellés courts, et l'entrée du hash inclut la liste avec les valeurs issues du SDP. Une énumération filtrée par les permissions ou indisponible peut modifier cette partie du hash même si les champs d'offre restent identiques. À l'inverse, une différence d'offre peut modifier un champ SDP retenu alors que les types d'appareils restent les mêmes. Le digeste combine des catégories venant d'API et de chemins de collecte distincts.

Pour comparer avec rigueur, séparez trois niveaux : l'opération source, sa valeur renvoyée et la projection affichée. Par exemple, enumerateDevices() renvoie des enregistrements d'appareils ; ce helper ne conserve que les types ; l'interface transforme ensuite ces types en libellés. La liste initiale, la sortie du helper et le libellé visible ne sont pas interchangeables. De même, decodingInfo() renvoie un objet de prise en charge ; le réducteur en conserve un sous-ensemble, puis le panneau présente les champs restants. C'est le chemin du code, pas seulement le texte final, qui définit ce que le rapport permet d'affirmer.

La maintenance de cette carte suit les changements d'entrées fixes, de propriétés conservées, de délai ou de champs du hash dans les révisions ultérieures de CreepJS. Comparer seulement le libellé affiché masquerait l'étape modifiée. Fixez la révision, comparez les fonctions productrices et consommatrices, puis mettez à jour uniquement la ligne pertinente de la carte de provenance. Cette procédure décrit la maintenance d'une source publique et ne vaut pas test d'une compilation du navigateur. Pour les limites entre page, réseau et produit, consultez la couverture des suites de détection publiques.

Un relevé de lecture limité

Pour conserver une interprétation du code, notez la révision et uniquement les distinctions de champs nécessaires à la question. Ne conservez pas d'adresses brutes, de libellés d'appareils, de SDP complet ou de chaînes de candidat lorsqu'un état expurgé suffit. Un bon relevé indique si une valeur vient d'un appel API, d'une description d'offre, d'un callback d'événement ou d'une projection d'interface. Il précise aussi si la propriété était absente, filtrée ou produite par la voie d'expiration. Ces étiquettes permettent de comparer deux rapports sans en copier le contenu sensible.

{
  "sourceCommit": "10aa6724cd33a1015db1574211890518cd04f0cc",
  "field": "extensions",
  "sourceOperation": "getExtensions(sdp)",
  "steps": ["remove numeric extmap id", "deduplicate", "sort"],
  "state": "parsed",
  "interpretationLimit": "not original SDP order or extension IDs"
}

L'exemple consigne un chemin de code, pas une observation du navigateur. Si une enquête de support distincte nécessite des données d'exécution, recueillez-les selon un plan de test autorisé et expurgez les valeurs avant partage ; la source publique ne fournit pas de relevé d'une telle exécution. Évitez de stocker un SDP complet ou une adresse non expurgée uniquement pour prouver qu'un analyseur a renvoyé un champ. Un état booléen comme addressPresent, le nom d'une branche et la révision peuvent répondre à la question en conservant moins de données. Le relevé ne doit jamais être présenté comme preuve d'identité ou de décision distante.

FAQ

Un hash WebRTC de CreepJS identifie-t-il un navigateur ?

Non. Le code fixé hache des entrées sélectionnées du rapport. Il n'inclut pas toutes les valeurs renvoyées et ne prouve ni appareil physique, ni personne, ni décision d'un service externe.

Une adresse absente prouve-t-elle que WebRTC est désactivé ?

Non. L'analyseur peut ne renvoyer aucune adresse alors que le collecteur a d'autres données, et le délai peut produire un résultat partiel. Le code possède une branche null immédiate distincte lorsque RTCPeerConnection est indisponible.

La liste d'extensions est-elle le SDP d'origine ?

Non. Les ID numériques sont retirés, les doublons supprimés et les valeurs triées. La liste ne permet pas de reconstruire l'ordre ni les identifiants d'origine.

decodingInfo() affiche-t-il tous les formats multimédias pris en charge ?

Non. Ce collecteur interroge six configurations fixes et ne garde que les réponses prises en charge avec quelques indications. Une autre configuration, version du navigateur ou contexte d'appareil peut donner un résultat différent.

Sources

• Collecteur WebRTC CreepJS fixé
• WebRTC du W3C
• RFC 8866 : SDP
• Media Capabilities du W3C
• MDN : RTCPeerConnection
• MDN : MediaCapabilities.decodingInfo()
• Prévention des fuites WebRTC de BotBrowser

Conclusion pratique

Lisez le panneau WebRTC de CreepJS comme un ensemble de champs ayant des producteurs et traitements distincts. Conservez la révision source, distinguez l'API absente du délai et de la sortie filtrée, et ne transformez pas un rapport partiel ou un hash de champs choisis en affirmation d'appareil, d'identité ou de verdict.