Fingerprinting de la Network Information API : revue de politique

La Network Information API donne à une page quelques estimations de la connexion via navigator.connection. Elle a été conçue pour qu'un site puisse choisir des ressources plus légères sur un lien lent, mais n'importe quel script de la page peut lire ces mêmes valeurs, de sorte qu'elles peuvent aussi s'ajouter à l'empreinte du navigateur. Les sections ci-dessous expliquent ce que rapporte chaque propriété, pourquoi la sortie d'un proxy peut contredire les valeurs mesurées par le navigateur, comment choisir entre une politique native, une politique issue du profil et une politique par champ, et comment vérifier le résultat sans deviner. BotBrowser peut garder cohérentes les valeurs d'information réseau d'un profil dans un contexte contrôlé ; il ne peut pas modifier la connexion réelle ni l'usage qu'un site fait de ces valeurs.

Résumé

• navigator.connection expose effectiveType, rtt en millisecondes, downlink en mégabits par seconde, type et saveData sans demande d'autorisation, donc tout script de la page lit les mêmes cinq champs.
• --bot-network-info-override=false conserve les valeurs mesurées de la machine, l'option seule ou profile applique toutes les valeurs définies par le profil chargé, et une politique JSON ne fixe que les champs qu'elle nomme.
• Un JSON mal formé, un champ inconnu, une valeur invalide ou un sélecteur profile sur un champ absent du profil écartent la politique entière, et les valeurs natives mesurées restent en place.
• La politique résolue appartient à un contexte de navigation et alimente aussi les en-têtes RTT, Downlink, ECT et Save-Data, donc comparez la page aux en-têtes reçus par un serveur que vous exploitez.
• Enchaînez l'exécution native et l'exécution avec remplacement sur la même machine et la même route, car un proxy déplace le chemin et non les valeurs lues par la page.

Sommaire

• Ce qu'expose navigator.connection
• Comment les valeurs de connexion s'ajoutent à une empreinte
• Choisir une politique d'informations réseau
• Incohérences qu'une revue peut repérer
• Comparer une exécution native à une exécution avec remplacement
• Où BotBrowser s'intègre
• Conclusion pratique

Ce qu'expose navigator.connection

L'objet NetworkInformation rapporte des indications approximatives sur la connexion utilisée par le navigateur à un instant donné. Les pages s'en servent pour décider de différer une vidéo facultative, de choisir une image plus petite ou de reporter un préchargement. Il ne demande aucune autorisation, donc tout script exécuté dans la page peut le lire, et un événement change est émis quand l'estimation du navigateur évolue.

• effectiveType classe les conditions observées en slow-2g, 2g, 3g ou 4g. Il décrit la qualité que le navigateur a constatée, pas la technologie radio.
• rtt est une estimation du temps d'aller-retour en millisecondes. Le navigateur l'arrondit, il évolue donc par paliers.
• downlink est une estimation de la bande passante descendante en mégabits par seconde, également arrondie.
• type nomme la technologie de connexion, comme wifi, cellular, ethernet ou unknown, lorsque le navigateur l'implémente.
• saveData est un booléen qui indique si l'utilisateur a demandé une consommation de données réduite.

Ces valeurs sont des estimations produites par le navigateur, pas des mesures auxquelles une page peut se fier au dernier chiffre. La spécification autorise le navigateur à les arrondir et à les regrouper par paliers, et deux lectures espacées de quelques secondes peuvent différer. La prise en charge varie aussi selon la famille de navigateurs. Les navigateurs basés sur Chromium exposent l'objet, Firefox n'en offre qu'une surface limitée et Safari ne le fournit pas, donc une revue doit partir de la marque de navigateur visée par le déploiement. L'absence de l'objet sur une marque qui l'expose normalement est une observation inhabituelle en soi. Pour le côté application de cette même API, y compris la gestion des indications absentes ou changeantes, consultez Network Information API pour du contenu adaptatif. La spécification décrit aussi downlinkMax, une borne supérieure de la technologie de connexion sous-jacente que seuls certains navigateurs implémentent ; ne supposez donc pas qu'une propriété que vous pouvez définir dans une politique existe sur chaque cible.

Comment les valeurs de connexion s'ajoutent à une empreinte

Aucune propriété n'identifie une personne à elle seule. effectiveType n'a que très peu de valeurs possibles, type vaut souvent unknown ou est absent, et saveData est désactivé chez la plupart des visiteurs. La contribution est statistique. Un effectiveType donné, un rtt arrondi, un downlink arrondi et un réglage de saveData réduisent ensemble l'ensemble des navigateurs qui auraient pu produire une visite, et cette réduction s'ajoute aux autres signaux que la page collecte. Affirmer que ces valeurs identifient à elles seules un utilisateur, ou qu'elles atteignent un taux d'identification fixe, dépasse ce que soutiennent la spécification publique et la documentation.

Les valeurs apportent aussi du contexte sur la situation du navigateur. Un poste de bureau en fibre, un téléphone en données mobiles et un lien partagé de bureau tendent à rapporter des combinaisons différentes. saveData est une préférence de l'utilisateur, donc un visiteur qui l'active se distingue davantage que celui qui la laisse désactivée. Comme l'objet se lit sans autorisation, un script peut enregistrer les valeurs au chargement et les comparer à des lectures ultérieures de la même visite.

L'arrondi est la mesure de confidentialité propre au navigateur et limite ce que révèle une lecture isolée. Le signal qui reste concerne surtout la stabilité et la vraisemblance. Un contexte qui rapporte une seule classe de connexion pendant toute la session, avec une adresse IP, un fuseau horaire et une langue qui lui correspondent, ressemble à une visite ordinaire. Un contexte dont les valeurs réseau changent d'une manière que le reste de la visite n'explique pas, ou contredisent ses autres signaux, donne à un script quelque chose à comparer. C'est pourquoi la personne qui fait la revue examine l'ensemble des valeurs ensemble plutôt que de régler un seul nombre isolément.

Le problème le plus concret apparaît avec un proxy. Un navigateur qui envoie son trafic par une sortie située dans une autre région continue de mesurer le chemin qu'il emprunte réellement, donc rtt et downlink décrivent ce chemin réel et non une connexion typique de la région de sortie. Quand l'adresse IP, le fuseau horaire et la langue désignent un même lieu alors que les estimations de connexion décrivent un autre type de lien, la combinaison est inhabituelle. Ni le proxy ni un profil ne le corrigent seuls, car un proxy change la route et non les valeurs lues par la page. Le guide de configuration du proxy couvre le routage, et une politique d'informations réseau couvre les valeurs que la page peut voir.

Les valeurs peuvent aussi diverger dans la requête elle-même. Les mêmes estimations peuvent parvenir aux serveurs qui les demandent via les Client Hints, avec les en-têtes de requête RTT, Downlink, ECT et Save-Data. Si JavaScript rapporte une classe de connexion et que les en-têtes en rapportent une autre, l'incohérence se remarque plus facilement que chaque valeur prise seule. Une politique saine traite l'API JavaScript et les Client Hints réseau comme une seule décision. Le guide du fingerprinting par Client Hints présente la famille d'indications plus large.

Choisir une politique d'informations réseau

L'option --bot-network-info-override accepte une seule politique, et il existe trois choix utiles. Prenez le plus petit qui répond à la question que vous avez devant vous.

• Aucun remplacement, écrit false : la page voit les estimations natives du navigateur avec leur arrondi habituel. C'est la bonne base pour toute comparaison.
• Base du profil, écrite comme l'option sans valeur, true ou profile : toutes les valeurs réseau définies par le profil chargé sont utilisées. Cela convient à un déploiement où le profil décrit déjà la classe de connexion voulue.
• JSON par champ : seuls les champs nommés sont définis, les champs omis restent natifs. Une politique qui nomme uniquement rtt laisse tous les autres champs à leur valeur mesurée.

Utilisez la politique native quand vous voulez mesurer ce que rapporte la connexion de l'hôte, par exemple pour déboguer ou quand un déploiement n'a aucune raison de présenter autre chose. Utilisez la base du profil quand le profil a été choisi pour décrire l'appareil et la connexion que vous voulez montrer à une page, car une seule option apporte alors toutes les valeurs réseau disponibles et les garde cohérentes entre elles. Utilisez le JSON par champ quand un scénario a besoin d'une ou deux valeurs précises, comme un rtt différent pour une sortie lointaine, et que le reste des champs doit rester tel quel.

# Valeurs natives
--bot-network-info-override=false

# Toutes les valeurs disponibles du profil chargé
--bot-network-info-override=profile

# Champs choisis uniquement ; les champs omis restent natifs
--bot-network-info-override='{"effectiveType":"3g","rtt":180,"downlink":1.8,"saveData":false}'

# Mélanger les sources champ par champ
--bot-network-info-override='{"type":"profile","rtt":"host","downlink":2.5,"saveData":"profile"}'

Une politique JSON accepte type, effectiveType, rtt, downlink, downlinkMax et saveData. Chaque champ prend une valeur prise en charge ou un sélecteur de source, profile ou host. Le sélecteur profile prend le champ dans le profil chargé, et host conserve volontairement la valeur mesurée. Les valeurs prises en charge suivent la plateforme : type vaut wifi, cellular, ethernet, bluetooth, wimax, other, none ou unknown ; effectiveType vaut slow-2g, 2g, 3g ou 4g ; rtt est un entier non négatif dans la plage prise en charge ; downlink et downlinkMax sont des nombres non négatifs dans la plage prise en charge ; saveData vaut true ou false. Une politique personnalisée ou host peut fonctionner sans profil, alors qu'un sélecteur profile exige que le profil définisse ce champ.

Traitez chaque valeur comme une base, pas comme une constante. Le navigateur applique toujours ses limites, son arrondi et sa variation par hôte, de sorte que deux origines peuvent recevoir des nombres légèrement différents à partir de la même base, et deux lancements du navigateur ne renvoient pas forcément exactement le même rtt. Aucune politique ne promet un nombre fixe sur toutes les origines, et une valeur constante non arrondie sur chaque site serait elle-même inhabituelle.

Une entrée invalide n'est ni fatale ni partielle. Un JSON mal formé, un champ inconnu, une valeur invalide ou un sélecteur profile qui pointe vers un champ absent du profil font ignorer toute la politique, et les valeurs natives mesurées restent. Les autres réglages du profil continuent de fonctionner. La conséquence pour la revue est simple : des nombres d'apparence native ne prouvent pas l'existence d'un remplacement personnalisé. Vérifiez d'abord le texte de la politique, puis relisez les valeurs.

La politique résolue appartient à un contexte de navigation. Les pages, les workers, les navigations et les requêtes Client Hints prises en charge dans ce contexte utilisent le même résultat, et un autre contexte peut utiliser une politique différente. Définissez la politique avant la création de la première page du contexte. Une politique passée en ligne de commande a priorité sur le réglage networkInfoOverride du profil, donc vérifiez les deux quand le résultat ne correspond pas à ce que suggère le profil.

Incohérences qu'une revue peut repérer

La plupart des problèmes de valeurs réseau sont des incohérences entre champs, ou entre un champ et le reste du scénario, et non un seul nombre erroné. Ces cas valent la peine d'être vérifiés avant une mise en production.

Une classe d'appareil qui ne correspond pas au type de connexion. Un profil qui décrit un navigateur de bureau rapporte normalement ethernet, wifi ou unknown, alors qu'un profil de téléphone rapportera plus probablement cellular. Si vous définissez type à la main, assurez-vous qu'il correspond toujours à l'appareil que décrit le profil.

Des champs qui ne vont pas ensemble. La spécification définit effectiveType en fonction du temps d'aller-retour et du débit descendant, donc un 4g écrit à la main à côté d'une estimation d'aller-retour de plusieurs secondes décrit un lien qui existe rarement. Quand vous nommez plusieurs champs, choisissez des valeurs qui décrivent une connexion plausible, ou laissez le profil fournir l'ensemble complet.

Un indicateur d'économie de données que personne n'avait voulu. La plupart des visiteurs laissent saveData désactivé, donc le mettre à true rend le navigateur plus rare. Ne l'activez que si le scénario représente réellement un utilisateur ayant demandé une consommation réduite, et laissez sinon le profil ou la valeur native décider.

Un sélecteur host dans un scénario avec proxy. Le sélecteur host conserve la valeur mesurée, ce qui signifie que la lecture reflète de nouveau le chemin réel, y compris le saut vers le proxy. C'est le bon choix quand vous voulez un comportement mesuré, et le mauvais quand vous attendiez que la page ressemble à une connexion typique de la région de sortie.

Un worker qui rapporte autre chose. La politique résolue est censée s'appliquer de la même façon aux pages et aux workers du contexte. Si un worker dédié ou partagé utilisé par l'application rapporte des valeurs différentes de celles de la page, traitez-le comme un constat et notez quelle politique et quel contexte l'ont produit.

Une base native prise sur une autre connexion. Les valeurs natives dépendent de la connexion de l'hôte au moment de l'exécution, donc deux exécutions natives sur des réseaux différents, ou à quelques heures d'écart, ne sont pas directement comparables. Faites les exécutions native et avec remplacement l'une après l'autre, sur le même hôte et la même route.

Un contexte modifié trop tard. Comme la politique résolue est fixée pour le contexte, une valeur lue depuis une page qui existait avant l'application de la politique peut différer d'une valeur lue dans un contexte neuf. Quand deux lectures divergent, comparez-les dans des contextes séparés créés chacun avec la même politique.

Comparer une exécution native à une exécution avec remplacement

Une revue est une comparaison, pas une lecture isolée. Exécutez la page une fois avec la politique native et une fois avec la politique à tester. Gardez identiques la version du navigateur, le profil, la route du proxy, la fenêtre d'affichage et l'état de l'application, et ne changez que la valeur de la politique. Utilisez un contexte neuf pour chaque exécution afin que la nouvelle politique ne se mélange pas à une page déjà établie.

1. Notez le texte exact de la politique de chaque exécution, noms de champs compris.
2. Ouvrez une petite page de diagnostic qui affiche effectiveType, rtt, downlink, type et saveData, et rien d'autre.
3. Lisez les valeurs depuis la console comme ci-dessous, dans la page et dans un worker si l'application en utilise un.
4. Comparez les Client Hints réseau qui arrivent sur un serveur que vous exploitez, si ce serveur les demande.
5. Répétez la lecture après une navigation pour confirmer que le contexte conserve un seul résultat.

const c = navigator.connection;
console.log(c.effectiveType, c.rtt, c.downlink, c.type, c.saveData);

Imaginez un déploiement qui utilise une sortie proxy dans une autre région avec un profil de poste de bureau à haut débit. L'exécution native montre les valeurs mesurées de l'hôte. L'exécution avec le profil doit montrer à la place la classe de connexion du profil, avec des valeurs arrondies stables dans le contexte. Une exécution par champ qui nomme uniquement rtt doit modifier cette seule valeur et laisser effectiveType, downlink et les autres champs tels que les a rapportés l'exécution native. Si l'exécution par champ modifie plus de champs que ceux qu'elle nomme, ou ne change rien, la première chose à relire est le texte de la politique.

Un bon résultat ressemble à ceci. Les champs nommés dans la politique changent ensemble, dans la page et dans les en-têtes de requête, tandis que les champs omis gardent leurs valeurs natives. Les valeurs peuvent être arrondies ou varier légèrement d'une origine à l'autre, ce qui est attendu et n'est pas un échec. Ce qui ne change pas compte tout autant. Le débit du proxy, le routage et toute latence qu'un serveur mesure sur ses propres requêtes restent ce qu'ils étaient, donc une comparaison qui attend du serveur qu'il observe une autre vitesse teste la mauvaise chose.

Quand une valeur semble fausse, vérifiez dans cet ordre : le profil chargé, la syntaxe JSON, les noms de champs, si la politique a été définie avant la première page du contexte, lequel des réglages de ligne de commande et de profil l'a emporté, et la route du proxy. Une politique ignorée parce qu'elle est invalide renvoie les valeurs mesurées, donc une page qui semble inchangée ne signifie pas que le navigateur a cessé de fonctionner. Un contexte séparé est le moyen le plus propre de tester une politique corrigée.

Limitez le compte rendu de la revue à la configuration et aux résultats visibles : la version, le nom du profil, le texte de la politique, une étiquette de la route et les valeurs lues. Laissez de côté le contenu des pages, les identifiants et les données privées des requêtes. Cela suffit à une autre personne pour répéter la comparaison et garde le compte rendu partageable avec l'équipe.

Répétez la comparaison chaque fois que la version du navigateur, le profil ou le fournisseur de proxy change, car les règles d'arrondi, les propriétés prises en charge et la route elle-même peuvent évoluer. Une comparaison enregistrée de la version précédente est une bonne référence. Si les champs nommés changent toujours ensemble et que les champs omis restent natifs, la politique fait encore ce que le déploiement attend. Si les nombres diffèrent mais que les relations tiennent, la cause est généralement l'arrondi ordinaire et la variation par hôte, pas une politique défaillante.

Où BotBrowser s'intègre

BotBrowser prend en charge une seule politique --bot-network-info-override, soit la base du profil, soit les valeurs natives, soit un JSON par champ, qui définit les propriétés de navigator.connection et les Client Hints correspondants pour chaque contexte de navigation, de sorte que vous pouvez garder les valeurs réseau vues par une page alignées avec le profil et le scénario de proxy que vous avez choisis. Il ne peut pas modifier la vitesse ni la latence réelles d'un proxy, les mesures côté serveur ou ce qu'un site déduit d'autres signaux réseau, et une politique invalide est ignorée, ce qui laisse en place les valeurs natives mesurées.

Les valeurs réseau ne sont qu'une entrée parmi d'autres, donc gardez-les cohérentes avec le fuseau horaire, les paramètres régionaux et la langue choisis pour la même route, comme décrit dans configuration du fuseau horaire et des paramètres régionaux. La prise en charge des navigateurs et les détails de la spécification évoluent, donc consultez les sources ci-dessous quand une propriété ou une indication se comporte différemment sur une nouvelle version du navigateur.

Sources publiques

• WICG Network Information API
• MDN : NetworkInformation
• Documentation BotBrowser sur les propriétés de navigator

Conclusion pratique

Une revue d'informations réseau laisse trois éléments : le texte exact de --bot-network-info-override, les cinq valeurs lues dans la page et dans un worker, et les en-têtes RTT, Downlink, ECT et Save-Data reçus par un serveur que vous exploitez. Quand une exécution ressemble à du natif, lisez le texte de la politique avant les nombres, car un objet JSON rejeté revient silencieusement aux valeurs mesurées. Refaites la paire d'exécutions après chaque nouvelle version du navigateur, changement de profil ou changement de fournisseur de proxy, puis comparez les deux relevés champ par champ au lieu d'un seul nombre.