WebRTC : cycle et temporalité du pool ICE

Le pool ICE change le moment possible de certaines opérations ; il ne confond pas collecte, événements de page, description locale et redémarrage ultérieur. Un journal silencieux ne prouve pas l’absence d’activité serveur antérieure. BotBrowser documente des politiques d’adresse WebRTC, mais ne garantit pas de réglage du pool ni l’annulation du trafic antérieur.

Résumé

• Une valeur non nulle de iceCandidatePoolSize demande la précollecte ; elle ne prouve pas que le pool soit prêt.
• setLocalDescription() marque une phase de remise, pas l’heure de la première activité réseau.
• Le pool initial sert au premier échange ; restartIce() demande une négociation ultérieure sans effacer l’activité passée.

Regarder la vidéo

Cette vidéo en anglais reprend la question de l’article : une trace WebRTC contient plusieurs horloges, donc une taille de pool configurée, un événement de candidat dans la page, une description locale et un journal serveur ne peuvent pas être remplacés par un seul instant appelé « ICE démarré ». Elle montre un fixture local contrôlé sous Ubuntu Chrome : une peer connection est créée avec une taille de pool non nulle, puis une modification tardive renvoie InvalidModificationError ; une seconde sonde compte les événements de candidat dans une fenêtre déclarée et lit l’état de collecte. Le compte reste une observation de la page, pas un journal côté serveur ; la vidéo ne prétend pas avoir mesuré un vrai site ni que BotBrowser contrôle la taille du pool. L’audio est en anglais.

Sommaire

• Regarder la vidéo
• Pourquoi le temps change la question de confidentialité
• Le pool a un cycle de vie limité
• Séparer les couches d’observation
• Trier une chronologie incomplète
• Limite de la politique BotBrowser
• Conclusion pratique

BotBrowser documente des politiques d’adresse WebRTC pour les sessions contrôlées, mais ne garantit pas de réglage du pool ni l’annulation du trafic passé. Le guide de prévention des fuites WebRTC couvre les types de candidats et les politiques de route ; le guide des candidats mDNS explique la représentation des candidats host. La question plus étroite porte ici sur le moment d’observation de chaque phase ICE.

Pourquoi le temps change la question de confidentialité

Une trace WebRTC peut contenir plusieurs horloges : création de la connexion, précollecte facultative, appel à une description locale, événements candidats remis à la page, échange offre/réponse et redémarrage ultérieur. Réduire tout cela à un instant unique appelé « démarrage ICE » masque des différences utiles pour lire un rapport de confidentialité. La recommandation WebRTC définit iceCandidatePoolSize comme la taille du pool précollecté, avec zéro par défaut. Une valeur non nulle demande un pool ; ce n’est pas un relevé horodaté de ce que la page a reçu.

Limite d’API	Consigner	Ne pas déduire
RTCPeerConnection(configuration)	Valeur demandée de iceCandidatePoolSize et début de capture	Que la précollecte est terminée
setLocalDescription()	Heure d’appel et événements remis	Que le réseau a commencé à cet appel
restartIce()	Demande et négociation suivante	Que le pool initial est restauré

Un événement de page décrit un point de remise visible par l’application. Il ne date pas chaque opération DNS, STUN ou TURN qui a pu le précéder. L’inverse compte aussi : l’absence d’événement candidat dans un journal applicatif ne prouve pas qu’il n’y a pas eu de collecte ou d’activité serveur préalable. La capture peut avoir commencé tard, l’application peut avoir filtré son journal ou l’observation peut venir d’une autre couche. Il faut borner la preuve, pas inventer l’événement manquant.

Dans un examen autorisé de compatibilité ou de confidentialité, séparez quatre observations :

• La taille du pool configurée et l’heure de capture de cette configuration.
• L’activité réseau vue par un relevé serveur indépendant et autorisé, s’il existe.
• Les événements candidats remis à l’application, avec la fenêtre de capture.
• La description locale et la phase offre/réponse consignées par l’application.

Ces relevés répondent à des questions distinctes. Un réglage indique ce que l’application a demandé. Un événement indique ce qui a été remis au script. Une description locale indique ce que l’application a fourni à l’API de négociation. Un journal serveur indique ce que ce serveur précis a observé. Aucun ne prouve seul qu’une politique d’adresse a précédé toute action réseau pertinente. Identifiez l’horloge et le point d’observation de chaque source avant de comparer des heures.

Le pool n’est pas non plus un décompte de candidats visible par la page. La taille demandée ne prouve pas que l’implémentation ait fini de collecter ce nombre de candidats utilisables avant l’appel suivant. Le RFC 9429 prévoit explicitement l’épuisement du pool si davantage de composants ICE sont requis ou si le temps de collecte a manqué ; les candidats restants sont alors collectés normalement. La valeur configurée, le nombre d’événements de page et le contenu d’une description locale ne sont donc pas des mesures interchangeables.

Cette séparation évite deux affirmations excessives. « Aucun événement candidat n’a été consigné avant la description locale » décrit un journal précis et sa couverture. « Aucune activité réseau n’a eu lieu avant la description locale » est plus large et exige une preuve provenant du point d’observation réseau pertinent. De même, une valeur non nulle autorise la précollecte ; elle ne prouve pas qu’un serveur précis ait été contacté à une heure donnée. Consignez ce que chaque source montre et laissez le reste comme inconnu.

Le pool a un cycle de vie limité

Le pool a un rôle défini dans la négociation ; ce n’est pas un cache réutilisé pour tous les échanges suivants. La section 3.5.4 du RFC 9429 décrit la séquence : lorsque setLocalDescription commence la collecte nécessaire au premier échange offre/réponse, l’implémentation devrait d’abord vérifier si des candidats sont disponibles dans le pool. Ceux-ci devraient être remis à l’application par des événements candidats. Si le pool est épuisé parce que davantage de composants sont nécessaires ou que la collecte a manqué de temps, les candidats restants sont collectés normalement. Le RFC précise que ce comportement concerne le premier échange offre/réponse ; ensuite, le pool est vidé et n’est plus utilisé.

Le RFC utilise « SHOULD » pour la remise des candidats disponibles. Gardez cette modalité : c’est une recommandation normative, pas la preuve qu’un pool donné ait été rempli avant une heure précise. La même section explique que conserver des candidats précollectés actifs peut consommer des ressources sur les serveurs STUN ou TURN configurés. C’est une conséquence décrite par le RFC, pas un volume mesuré ni une durée de conservation garantie pour une version particulière.

Le moment de configuration est également limité. L’algorithme WebRTC de configuration rejette une modification de iceCandidatePoolSize après l’appel à setLocalDescription. La méthode signale InvalidModificationError pour ce changement restreint, mais le nom de l’exception ne diagnostique pas la cause : d’autres modifications peuvent déclencher la même erreur. Un relevé utile contient les configurations précédente et demandée, l’ordre des appels et le contexte de l’exception. Sans cela, attribuer l’erreur à la taille du pool reste une hypothèse.

Phase	Interprétation du pool	Preuve visible par l’application	Ce que le relevé ne permet pas d’établir
Création avec taille 0	Ce réglage ne demande pas de précollecte	Instantané initial de configuration	Qu’aucune collecte ultérieure n’aura lieu
Création avec taille non nulle	La précollecte est autorisée pendant la préparation	Taille demandée ; observation serveur distincte si disponible	Que le pool soit rempli ou qu’un événement ait déjà eu lieu
Avant la description locale	La taille peut être choisie ou modifiée selon les règles API	Instantanés et ordre des appels	Que le pool demandé soit prêt
Première collecte de description locale	Les candidats disponibles devraient être remis ; le manque est collecté normalement	Événements candidats et cycle de description locale	La chronologie réseau complète antérieure à partir des seuls événements
Après le premier échange	Le pool initial est vide et n’est plus utilisé	Historique de négociation	Qu’un redémarrage recrée le pool
Redémarrage ICE ultérieur	Une nouvelle génération est demandée par négociation	Appel de redémarrage et signalisation suivante	Que l’activité antérieure ait été effacée

Cette matrice aide à lire les relevés d’une application maîtrisée ; elle ne donne pas une recette de détection. Consignez les phases et leur ordre approximatif plutôt que le contenu des candidats. Distinguez le réglage demandé de l’opération terminée. Sans observation réseau indépendante, dites-le ; ne transformez pas les événements de page en substitut d’une activité serveur.

Un redémarrage ICE est une action ultérieure de négociation, pas un retour en arrière. restartIce() demande un redémarrage pour une négociation suivante. Il ne supprime pas un événement antérieur, n’efface pas un journal serveur et ne restaure pas le pool initial après consommation lors du premier échange offre/réponse. Si un rapport couvre plusieurs générations, indiquez la phase de chaque relevé afin de ne pas rattacher un candidat postérieur au redémarrage à la preuve de l’échange initial.

Séparer les couches d’observation

Un dossier de preuve doit préciser la couche à l’origine de chaque observation et l’intervalle couvert. Un instantané indique les valeurs demandées par l’application. Un événement de page décrit la remise au script. Une description locale montre ce que l’application a fourni à cette frontière d’API. Un journal serveur, si son propriétaire est autorisé à le consulter, décrit ce que ce serveur a observé. Horloges, conservation et couverture peuvent différer. Une comparaison qui omet ces éléments paraît parfois plus concluante que les relevés ne le permettent.

Observation	Elle étaye	Elle n’étaye pas seule
iceCandidatePoolSize: 0 avant négociation	Ce réglage n’a pas demandé de précollecte	Qu’aucun candidat ne sera collecté ensuite
Pool configuré à une valeur non nulle	Une précollecte a été demandée	Que la collecte soit finie ou le pool encore disponible
Heure d’un événement candidat	La page a reçu cet événement à l’heure indiquée	Que la première activité réseau ait eu lieu à ce moment
Appel à setLocalDescription	L’application est entrée dans la phase de description locale	Que tous les candidats aient déjà été collectés
Appel restartIce()	L’application a demandé un redémarrage pour la suite	Le rétablissement du pool initial ou l’effacement de l’historique
Événement absent d’une trace partielle	La trace ne contient pas cet événement	L’absence d’activité hors de la fenêtre capturée

Un relevé pratique conserve le début de capture, les marqueurs API ordonnés, la version du navigateur et l’état complet ou non du journal. Le but est d’interpréter un diagnostic autorisé, pas de collecter plus que nécessaire. Les chaînes de candidats brutes, adresses, octets SDP, identifiants de serveurs et identifiants par utilisateur ne sont pas nécessaires aux distinctions de cycle de vie présentées ici. Si un autre incident autorisé exige des données sensibles, traitez-les selon sa politique d’accès et de conservation plutôt que de les copier dans un rapport général.

Évitez d’associer l’heure d’un événement de page à une heure supposée de requête STUN en l’absence d’observation réseau indépendante. Cela peut être une hypothèse à vérifier, mais pas un fait observé. Même prudence pour une exportation qui supprime des champs : un champ absent peut avoir été omis par l’exportateur, pas par le navigateur. Conservez la provenance : couche source, fenêtre de capture, transformations et point de rétention.

Pour comparer deux exécutions, définissez les observations de la même façon. Si l’une consigne les appels API dès la création de connexion et l’autre commence au premier callback candidat, leurs chronologies ne sont pas alignées. Avant la comparaison, notez la définition d’événement, l’horloge, le début de capture et la règle de traitement des absences. Cette méthode concerne des systèmes de test maîtrisés ; elle ne requiert pas de divulguer des candidats ni de sonder des services tiers.

Trier une chronologie incomplète

Si un rapport qualifie une adresse de « tardive », définissez ce terme d’abord. Il peut s’agir du premier événement côté page, du premier candidat de la description locale, du premier événement conservé par l’export ou de la première observation dans un journal serveur autorisé. Ces heures ne sont pas interchangeables. Vérifiez si la capture a commencé avant la création de connexion et si la configuration initiale a été enregistrée. Vérifiez ensuite si setLocalDescription avait déjà été appelé lors de la tentative de modifier la taille du pool.

Symptôme	Vérifier d’abord	Éviter de conclure
Aucun événement avant la description locale	Demande de collecte et couverture d’une activité antérieure	Absence de précollecte ou de contact serveur
Moins d’événements qu’attendu après la description	Capacité ou préparation du pool ; la collecte normale peut continuer	Échec causé uniquement par un petit pool
InvalidModificationError pendant la configuration	Champ modifié et appel préalable à setLocalDescription	Rejet nécessairement dû à la taille du pool
Événements après restartIce()	Appel, ordre de renégociation et couverture	Disparition de l’ancienne génération ou activité
Désaccord des journaux page/serveur	Horloge, limites, filtres et point d’observation	Qu’un relevé décrive l’autre couche

Cette séquence garde le diagnostic lié aux preuves. Commencez par l’ordre des appels et la couverture. Comparez la valeur demandée à celle consignée avant la description locale. Séparez les erreurs de configuration de la remise d’événements. Ne comparez les relevés de page et de serveur que si les deux ont été collectés avec autorisation. Si un élément manque, consignez la lacune au lieu de la compléter avec une valeur par défaut supposée ou une heure inventée.

Si la configuration initiale ou l’intervalle de capture manque, marquez la chronologie comme incomplète. Ne reconstruisez pas l’intention depuis la liste finale de candidats : c’est un résultat conservé, pas l’historique complet de sa production. Si l’export manque de provenance, indiquez que les transformations sont inconnues. Un rapport moins absolu est plus utile si un autre ingénieur peut identifier le fait manquant qui changerait l’interprétation.

Entre deux exécutions, un écart peut provenir de la couverture, du délai réseau, de l’ordre d’appels ou des limites des journaux serveur, pas seulement de la taille du pool. Notez ces conditions avec la comparaison. N’attribuez pas l’écart à la taille à moins que les preuves isolent ce changement et que la source applicable étaye le mécanisme. Les normes décrivent le comportement API et le cycle ; elles ne fournissent pas de mesures pour une configuration qui n’a pas été exécutée.

La même méthode s’applique à un changement rejeté. Conservez les configurations précédente et nouvelle sans secrets, précisez si la description locale avait déjà été appelée et notez le type d’exception et la phase. InvalidModificationError signifie que la modification a été refusée selon les règles API ; sans le contexte, l’exception seule n’identifie pas le champ responsable.

Limite de la politique BotBrowser

La documentation WebRTC de BotBrowser décrit les choix et réglages de politique d’adresse des sessions gérées. Elle est la source produit de ces contrôles. Le défaut du pool, son cycle lors du premier échange et le traitement de la description locale viennent de WebRTC et JSEP. La documentation publique ne promet ni commande dédiée pour régler la taille du pool, ni précollecte de chaque candidat, ni suppression d’une activité serveur antérieure après un changement de politique.

Dans une comparaison maîtrisée, consignez séparément la politique produit et les phases API, puis attribuez chaque affirmation à sa source. Une référence de configuration n’est pas une preuve réseau. L’absence d’un événement de page ne prouve pas qu’un hôte n’a jamais contacté un service configuré. Le guide de prévention des fuites WebRTC reste la référence opérationnelle des politiques d’adresse ; les matrices présentes ajoutent l’interprétation temporelle et le périmètre des preuves. Aucun résultat n’est revendiqué pour une version, un réseau ou un déploiement non exécuté.

Questions fréquentes

Un pool non nul garantit-il que les candidats sont prêts avant la négociation ?

Non. Il demande la précollecte, mais le RFC 9429 prévoit l’épuisement du pool ou un temps de collecte insuffisant. Les candidats disponibles devraient être remis au début de la collecte ; le réglage ne confirme pas l’achèvement.

Modifier la taille après la description locale corrige-t-il une capture antérieure ?

Non. L’algorithme set-configuration du W3C limite cette modification après l’appel à setLocalDescription(). Une configuration ultérieure ne réécrit ni le journal précédent ni l’observation serveur.

restartIce() restaure-t-il le pool initial ?

Non. Il demande un redémarrage pour une négociation suivante. Ce redémarrage a sa propre fenêtre de preuve et n’efface pas l’activité réseau passée.

Sources

• Recommandation WebRTC du W3C : RTCConfiguration et algorithme de configuration
• RFC 9429, section 3.5.4 : ICE Candidate Pool
• MDN : RTCPeerConnection.setConfiguration()
• MDN : RTCPeerConnection.restartIce()
• BotBrowser : prévention des fuites WebRTC

Conclusion pratique

Gardez configuration, événements de page et observations serveur comme preuves distinctes. Conservez la fenêtre de capture et l’ordre des appels ; s’il manque l’un des deux, signalez une chronologie incomplète au lieu d’inférer l’absence d’activité réseau antérieure.