Retour au Centre de connaissances
Empreinte

Résultats EFF Cover Your Tracks : guide de lecture

Séparez la simulation des traqueurs de la comparaison d’empreintes et lisez les limites de Canvas, WebGL, des polices et du fuseau horaire.

BotBrowser Team

Documentation

Vous voulez la documentation structurée pour Empreinte ?

Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.

Un rapport EFF Cover Your Tracks répond à deux questions différentes : que sont devenues les requêtes d’une simulation de traqueurs, et à quel point la configuration du navigateur paraissait-elle singulière dans les données comparées ? Le blocage d’une requête ne rend pas l’empreinte anonyme ; une configuration rare ne prouve pas non plus qu’un traqueur a identifié une personne. BotBrowser permet de valider des réglages déclarés des surfaces du navigateur, mais ne reproduit pas la population de comparaison d’EFF et ne prédit pas la décision d’un tiers.

TL;DR

  • Lisez séparément la simulation des traqueurs et la comparaison de singularité ; le modèle affiche des lignes distinctes.
  • Distinguez une requête non chargée d’un cookie limité après le chargement de la requête.
  • Situez toute estimation dans les données et la période observées par EFF, jamais comme une identité personnelle.
  • Canvas, WebGL, polices et fuseau horaire sont des catégories documentées ; un modèle de source ne prouve pas leur collecte à chaque exécution actuelle.
  • Conservez la date, la révision de l’outil et les seules catégories utiles. Évitez les identifiants bruts sans objectif défini.

Sommaire

Deux parcours indépendants : observations de requêtes et cookies, puis comparaison d’empreintes bornée par les données, sans identifier une personne.

Deux volets, deux questions

Cover Your Tracks réunit une simulation de blocage des traqueurs et une étude des empreintes de navigateur. Leur proximité visuelle ne les transforme pas en une mesure unique. Le volet traqueurs concerne des requêtes de page simulées et les cookies associés. Le volet empreinte compare des caractéristiques observables à des configurations présentes dans le jeu de données du service. Aucun des deux ne constitue un verdict général sur tous les sites visités.

Le modèle de résultats EFF affiche des lignes distinctes pour les publicités de suivi, les traqueurs invisibles, l’empreinte, les publicités acceptables et Do Not Track. Une autre zone compare des requêtes simulées chargées et des nombres de cookies. Face à une étiquette marquante, identifiez d’abord la ligne et l’observation qui l’ont produite. Ne transférez pas une conclusion d’une ligne à l’autre sans relation explicitée par le rapport.

Le modèle précise aussi que l’outil ne mesure pas toutes les formes de suivi et de protection. Un résultat favorable décrit le parcours testé ; il ne certifie pas tous les traqueurs, stockages ou mécanismes de protection. Un résultat défavorable signale une condition à examiner, pas la preuve qu’une entreprise a relié un navigateur à une personne.

Les rapports peuvent changer selon la configuration, l’implémentation du test ou le jeu de comparaison. Les lignes traqueurs et singularité peuvent donc évoluer indépendamment. Un résumé à un seul nombre ne suffit pas pour expliquer le changement. Le guide général sur les empreintes de navigateur décrit la notion large ; les lignes EFF ad_status, tracker_status et fp_status gardent les deux observations distinctes.

La même prudence vaut entre applications distinctes : la corrélation multi-navigateur exige une paire et un protocole de comparaison définis, pas seulement un rapport distinctif.

Requêtes et cookies de la simulation

Lorsqu’une explication détaillée est disponible, conservez son texte exact ou un lien vers l’explication officielle ; ne la remplacez pas par une paraphrase plus catégorique. Une comparaison ultérieure reste ainsi vérifiable sans conserver d’empreinte brute.

Lisez la simulation comme un petit tableau d’observations, pas comme l’inventaire de toutes les requêtes du navigateur. Le modèle distingue le chargement simulé des requêtes tierces du nombre de cookies. Une protection partielle n’équivaut pas au blocage d’une requête avant son arrivée au traqueur simulé. Une requête peut avoir lieu alors qu’un cookie est limité ; l’absence d’un cookie ne prouve pas l’absence de requête.

Élément observéCe qu’il permet d’affirmerCe qu’il ne permet pas d’affirmer
Requête simulée affichée comme bloquéeCette requête de test n’a pas suivi le parcours montréTous les domaines ou mécanismes de suivi sont bloqués
Requête chargée et nombre de cookies affichéLa requête et le résultat de cookie ont été observés dans cette simulationLe cookie identifie une personne ou sert sur des sites sans lien
Requête chargée, cookie limitéLe traitement de la requête et du cookie diffère iciToute forme d’état ou de corrélation est empêchée
Résumé de protection partielleUne condition testée diffère du blocage completQuelle fonction non testée changerait le résultat

Le modèle étaye les catégories et la comparaison visible requête/cookie. Ce n’est pas une trace de chaque événement réseau de la navigation ordinaire. Une affirmation sur un en-tête précis, une API de stockage ou un script exige une trace de cette page et de cette exécution, pas une déduction tirée d’une ligne de résumé.

Pour une revue, conservez une ligne par catégorie : nom affiché, état de la requête, résultat de cookie s’il existe. Lors d’une comparaison entre deux dates, séparez les résultats des traqueurs de ceux de l’empreinte. Si seul le résultat du cookie change, examinez son contexte avant d’invoquer l’empreinte. Si seule la singularité change, n’invoquez pas les traqueurs sans lien explicite dans le rapport.

Une comparaison limitée par ses données

L’horodatage indique quand le rapport a été consulté ou produit ; il ne garantit pas la durée de conservation des données. Le 45-day epoch décrit dans README.md concerne des totaux agrégés, pas une promesse de conservation individuelle.

Le volet empreinte compare les caractéristiques observables aux configurations représentées dans les données EFF. Une estimation de singularité décrit cet ensemble et cette méthode, pas un recensement de tous les navigateurs. Elle ne révèle pas non plus l’identité d’un visiteur correspondant. « Rare dans ces données » et « identifie une personne » sont deux affirmations aux exigences de preuve différentes.

Le README du dépôt EFF décrit une période de 45 jours pour la mise à jour des totaux de caractéristiques observées. C’est une propriété du processus d’agrégation. Cela ne signifie pas qu’une empreinte individuelle reste inchangée pendant 45 jours, qu’elle apparaît à chaque mise à jour ou qu’une personne peut être suivie entre sites durant cette période. Le 45-day epoch concerne les totaux agrégés, pas la persistance d’un identifiant individuel.

La comparaison dépend des champs observés, de l’implémentation qui les regroupe et de la population du jeu de données. Un résultat peut changer lorsque l’un de ces éléments change. Sans détail de champ et preuve correspondante, n’attribuez pas une estimation à une caractéristique unique. Ne comparez pas non plus un nombre EFF à la note d’un autre service comme s’ils partageaient population, normalisation, méthode et calendrier.

Pour un suivi longitudinal, gardez la date, la révision publique si elle est connue, la catégorie et le libellé exact. Ajoutez famille et version majeure du navigateur seulement si elles sont nécessaires à la comparaison déclarée. N’enregistrez pas une valeur Canvas brute, une liste complète de polices ou une autre valeur à forte entropie sans objectif documenté. Si le rapport qualifie une configuration de rare, limitez la conclusion à cette catégorie et cette date. N’en déduisez ni identification, ni automatisation, ni suivi garanti.

Portée de la liste des champs

L’analyse des empreintes Canvas explique la surface de rendu derrière ce résultat ; ce mécanisme ne suffit pas à établir la rareté d’une configuration dans les données EFF.

Le modèle EFF fixé énumère notamment Accept HTTP, écran, fuseau horaire, polices, valeurs Canvas et WebGL, Do Not Track, plateforme, langue et prise en charge tactile. Il conserve aussi des termes de l’époque des extensions. La liste documente le vocabulaire d’une révision source ; elle ne prouve pas que chaque champ est collecté dans chaque exécution actuelle. Pour décrire une collecte présente, vérifiez le rapport, l’avis de confidentialité et l’implémentation actuels.

Les explications publiques sont plus précises. Le texte Canvas décrit un condensat d’image et indique que le contexte compte. Celui de WebGL décrit un résultat apparenté et rapproche les sorties Canvas et WebGL. Le texte sur les polices parle de mesure via du texte rendu et de leur pouvoir distinctif possible. Le fuseau horaire est présenté comme un indice général, pas une localisation exacte. Rien de cela ne prouve identité, lieu physique ou intention.

FamilleInterprétation étayéeQuestion de comparaison sûre
CanvasUne image rendue peut être résumée ; le contexte compteRévision de l’outil et configuration identiques ?
WebGLUn résultat graphique apparenté à Canvas est rapportéDes sorties corrélées sont-elles comptées comme preuves indépendantes ?
PolicesLe texte rendu peut refléter les polices disponiblesLa liste répond-elle à un besoin ou crée-t-elle une exposition ?
Fuseau horaireUne valeur visible par le navigateur peut donner un indice largeS’agit-il d’un réglage, et non d’une preuve de lieu ?
Langue et écranCes catégories figurent dans le vocabulaire documentéSont-elles nécessaires à la question ?

Les références MDN de Canvas et WebGL décrivent les interfaces du navigateur, pas toute la collecte d’EFF. L’existence d’une API ne prouve pas qu’un site l’a appelée pendant une session précise. Les catégories héritées des extensions demandent une prudence supplémentaire : une mention historique ne prouve pas leur disponibilité ou collecte dans le rapport actuel.

Fiche d’interprétation reproductible

Si la révision est inconnue, notez-la comme inconnue : ne supposez pas que le dernier commit du dépôt est déployé sur le service public.

ÉtapeÀ conserverRègle de décision
1. Identifier le rapportOutil, URL, date et révision si disponibleMarquez la révision inconnue si nécessaire
2. Séparer les voletsLignes de simulation et de comparaison d’empreinteNe les fusionnez pas en note unique non définie par l’outil
3. Noter les traqueursRésultat de requête et cookie séparémentDécrivez seulement la simulation affichée
4. Noter l’empreinteLibellé de singularité et détails visiblesRestez dans l’ensemble et la méthode du rapport
5. Vérifier la provenanceModèle fixé, rapport actuel ou avis de confidentialitéUne liste de termes ne prouve pas une collecte actuelle
6. Comparer les datesParcours, révision et contexte communs s’ils sont connusSi un élément est inconnu, la comparaison est incomplète
7. Limiter la conservationDate, catégorie, version nécessaire et explicationPas d’identifiant brut sans objectif documenté

Cette fiche explique les différences affichées ; elle ne reproduit pas le backend EFF et ne reconstitue pas son jeu depuis une capture. Si le rapport n’expose pas la cause au niveau du champ, ne l’attribuez pas. Un inconnu explicite vaut mieux qu’une cause inventée pour Canvas, WebGL ou les cookies.

CasChangement observéÉtape suivante justifiée
ALigne traqueurs inchangée ; singularité différenteVérifiez date, révision et contexte comparé avant d’examiner les traqueurs
BRequête inchangée ; résultat cookie différentExaminez le résultat des cookies sans affirmer que l’empreinte a changé
CUne étiquette de champ manque dans un rapportVérifiez le rapport ou l’implémentation actuelle ; l’absence ne prouve pas l’absence de capacité

La référence de cohérence de l’automatisation présente les réglages déclarés comme une configuration cohérente, plutôt que des champs isolés. Cette documentation concerne la validation de configuration ; elle ne prétend pas calculer la singularité EFF ni prédire sa simulation de traqueurs.

Confidentialité et limites produit

Cette précaution concerne aussi les appareils professionnels. Ne supposez pas qu’un test public reçoit uniquement le résumé affiché par le navigateur ; vérifiez la collecte et la conservation dans l’avis actuel avant de soumettre le profil.

Pour comparer des produits, déclarez le périmètre du test et utilisez des preuves directes de chaque outil. La sortie de l’un ne détermine pas le résultat de l’autre.

BotBrowser permet de valider des réglages déclarés du navigateur, mais ne peut pas reproduire la population comparée par EFF ni prédire la décision d’un tiers.

L’avis de confidentialité EFF décrit les informations recueillies et leur usage. Consultez-le avant de soumettre un navigateur à un test en ligne, surtout sur un profil contenant des comptes personnels. Pour la conservation, l’avis actuel est la source pertinente ; une explication de métrique ne remplace pas une politique de confidentialité.

Définissez la question avant toute évaluation interne. Si vous cherchez seulement un changement entre deux exécutions autorisées, ne gardez que les champs nécessaires. Évitez de les associer à des comptes, journaux réseau ou historiques sans rapport. Limitez l’accès, fixez une date de suppression et précisez si la comparaison concerne un profil, une version logicielle ou un environnement contrôlé.

La documentation publique de BotBrowser traite de la configuration des surfaces et de la cohérence de l’automatisation. Elle aide à valider des réglages déclarés, mais n’établit pas la couverture des données EFF, ne reproduit pas son résultat à partir d’une configuration et ne prédit pas la décision d’un service tiers. BotBrowser valide des réglages déclarés ; il ne calcule pas l’estimation de singularité d’EFF.

Aucune catégorie du rapport ne doit servir à déduire le comportement d’une personne ou à prendre une décision lourde de conséquences sans processus adapté et validé. Une configuration de navigateur n’est pas une personne : le rapport représente la sortie d’un outil, un parcours et un instant, même si son étiquette visuelle paraît catégorique.

Questions fréquentes

Le blocage d’un traqueur prouve-t-il que le navigateur ne peut pas être suivi ?

Non. EFF précise que l’outil ne mesure pas toutes les formes de suivi ou de protection. Le résultat concerne seulement le parcours simulé.

Une empreinte rare identifie-t-elle le visiteur ?

Non. Elle décrit une comparaison dans les données et la méthode observées ; elle ne nomme personne et ne prouve pas une identité durable.

Pourquoi deux rapports du même navigateur diffèrent-ils ?

Les champs, l’implémentation, les données comparées et le contexte peuvent changer indépendamment. Sans preuve par champ, la différence n’a pas de cause unique démontrée.

Faut-il stocker les valeurs brutes Canvas ou les polices ?

Seulement avec un objectif documenté et des contrôles d’accès et de suppression. La catégorie, la date et les versions utiles suffisent souvent.

Sources

Conclusion pratique

Traitez la page EFF comme deux rapports liés mais distincts : une simulation définie des traqueurs et une comparaison de configurations de navigateur. Gardez catégorie et date, consultez l’avis de confidentialité avant de soumettre un profil et ne conservez que le nécessaire. Le résultat peut orienter une vérification ciblée ; il n’identifie personne, ne certifie pas toutes les protections et ne prédit pas la décision d’un autre service.

#fingerprinting#confidentialité#Trackers

Cet article fait partie du guide : Qu'est-ce qu'une empreinte de navigateur ?

Faites passer BotBrowser de la recherche à la production

Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.