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
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 volets, deux questions
- Requêtes et cookies de la simulation
- Une comparaison limitée par ses données
- Portée de la liste des champs
- Fiche d’interprétation reproductible
- Confidentialité et limites produit
- Conclusion pratique
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’affirmer | Ce qu’il ne permet pas d’affirmer |
|---|---|---|
| Requête simulée affichée comme bloquée | Cette 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 simulation | Le 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 ici | Toute forme d’état ou de corrélation est empêchée |
| Résumé de protection partielle | Une condition testée diffère du blocage complet | Quelle 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.
| Famille | Interprétation étayée | Question de comparaison sûre |
|---|---|---|
| Canvas | Une image rendue peut être résumée ; le contexte compte | Révision de l’outil et configuration identiques ? |
| WebGL | Un résultat graphique apparenté à Canvas est rapporté | Des sorties corrélées sont-elles comptées comme preuves indépendantes ? |
| Polices | Le texte rendu peut refléter les polices disponibles | La liste répond-elle à un besoin ou crée-t-elle une exposition ? |
| Fuseau horaire | Une valeur visible par le navigateur peut donner un indice large | S’agit-il d’un réglage, et non d’une preuve de lieu ? |
| Langue et écran | Ces 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 | À conserver | Règle de décision |
|---|---|---|
| 1. Identifier le rapport | Outil, URL, date et révision si disponible | Marquez la révision inconnue si nécessaire |
| 2. Séparer les volets | Lignes de simulation et de comparaison d’empreinte | Ne les fusionnez pas en note unique non définie par l’outil |
| 3. Noter les traqueurs | Résultat de requête et cookie séparément | Décrivez seulement la simulation affichée |
| 4. Noter l’empreinte | Libellé de singularité et détails visibles | Restez dans l’ensemble et la méthode du rapport |
| 5. Vérifier la provenance | Modèle fixé, rapport actuel ou avis de confidentialité | Une liste de termes ne prouve pas une collecte actuelle |
| 6. Comparer les dates | Parcours, révision et contexte communs s’ils sont connus | Si un élément est inconnu, la comparaison est incomplète |
| 7. Limiter la conservation | Date, catégorie, version nécessaire et explication | Pas 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.
| Cas | Changement observé | Étape suivante justifiée |
|---|---|---|
| A | Ligne traqueurs inchangée ; singularité différente | Vérifiez date, révision et contexte comparé avant d’examiner les traqueurs |
| B | Requête inchangée ; résultat cookie différent | Examinez le résultat des cookies sans affirmer que l’empreinte a changé |
| C | Une étiquette de champ manque dans un rapport | Vé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
- EFF Cover Your Tracks : About : méthode de simulation et étude de singularité.
- EFF Cover Your Tracks : Learn : identifiants de stockage et caractéristiques observables.
- EFF Cover Your Tracks : Privacy : collecte et usage des informations.
- Modèle de résultats EFF fixé : lignes distinctes, comparaison requêtes/cookies et limite de mesure.
- Modèle de champs EFF fixé : vocabulaire documenté et termes hérités.
- Explication Canvas, WebGL, polices et fuseau horaire : interprétations par mesure.
- README EFF fixé : période de 45 jours pour les totaux de caractéristiques.
- API Canvas MDN et API WebGL MDN : contexte des interfaces, sans preuve d’une collecte particulière.
- Cohérence d’automatisation BotBrowser et aperçu des empreintes : périmètre produit.
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.
Cet article fait partie du guide : Qu'est-ce qu'une empreinte de navigateur ?
Articles Connexes
Empreinte multi-navigateur : portée de la corrélation
EmpreinteRapport Canvas de BrowserLeaks : signaux et limites
EmpreinteQu'est-ce qu'une empreinte de navigateur ?
EmpreinteComprendre les réglages de protection contre le pistage du navigateur
EmpreinteLire les signaux d’empreinte du navigateur
EmpreinteRapport WebGL BrowserLeaks : collecte et champs absents
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.