Comment un test de vie privée ne conserve aucune donnée
Un test de vie privée est un outil qui vous montre ce que les sites web peuvent apprendre de votre navigateur — signaux canvas et GPU, polices, écran, fuseau horaire, langue, indices réseau et les identifiants silencieux qui permettent à un site de vous reconnaître à votre retour — et cela crée un problème de crédibilité : un outil qui démontre des techniques de surveillance est jugé aussi sur ses propres pratiques de données, qui ne peuvent pas être une page de politique ajoutée après coup. La règle de conception derrière notre test d’empreinte de navigateur se dit en une phrase : si le navigateur peut le lire, le serveur ne le voit jamais. Cet article explique ce que cette règle coûte, où elle plie et où elle s’arrête. Si vous voulez d’abord l’inventaire des signaux, commencez par ce que les sites web savent de vous ; ce texte parle de la plomberie sous le test, pas des signaux eux-mêmes.
Côté client d’abord
Chaque signal que le navigateur lui-même offre est lu et affiché localement, sur votre machine, par le code de la page dans votre onglet. Rendu canvas, chaînes du moteur de rendu WebGL, propriétés du contexte audio, sondes de polices installées, géométrie d’écran et de fenêtre, profondeur de couleur, prise en charge tactile, estimations de stockage, requêtes média sur le contraste et le mouvement : tout est calculé là où c’est découvert et dessiné dans la page que vous voyez. Le code de la page est la seule chose qui détient jamais le tableau complet. Aucun script ne rassemble le panneau dans une charge, aucune balise ne le ramène à la maison et aucun événement d’analyse ne le résume, car au moment où une empreinte complète quitte le navigateur, le test est devenu ce contre quoi il mettait en garde.
Cet ordre — local d’abord, serveur en dernier, et serveur uniquement pour les quelques tâches qu’un navigateur ne peut vraiment pas faire seul — n’est pas une caractéristique de l’architecture ; c’est l’architecture. La plupart des outils de vie privée sont construits à l’envers : tout collecter au centre, puis promettre de le supprimer, de l’anonymiser ou de le garder peu de temps. Ces promesses peuvent être tenues, mais ce sont des promesses, et un lecteur ne peut pas auditer une suppression. Une conception qui ne transmet jamais les données remplace une promesse par un fait sur le chemin du code, et les faits sur les chemins de code se vérifient dans un onglet réseau, ce qui est exactement la norme qu’un outil de vie privée devrait inviter.
Le coût est réel et accepté par la conception. Il n’y a rien entre appareils : aucun compte qui vous suit, aucun historique qui se synchronise, aucune comparaison avec votre empreinte sur votre autre ordinateur portable, parce que tout cela exige que le serveur conserve quelque chose par personne. Les comparaisons se limitent à ce que votre propre navigateur retient localement et aux compteurs quotidiens anonymes décrits ci-dessous. Quand une fonctionnalité exigerait l’empreinte complète sur le serveur, la réponse n’est pas une politique de conservation plus prudente : c’est non. La contrainte est le produit.
Trois petits endpoints, trois tâches différentes
Trois tâches ne peuvent vraiment pas se faire dans la page, et chacune reçoit son propre petit endpoint avec sa tâche étroite. Le premier, /api/check/whoami, renvoie uniquement ce que tout serveur voit déjà dans la requête qui a chargé la page : votre adresse réseau telle qu’elle est arrivée, les en-têtes que votre navigateur a envoyés avec elle et la géographie approximative attachée à cette adresse. Vous montrer ces valeurs n’ajoute aucune exposition nouvelle, car chaque serveur que vous visitez les reçoit, qu’il les affiche ou non ; l’endpoint transforme simplement une divulgation à sens unique en une divulgation visible, et ne conserve rien au-delà de la réponse.
Le deuxième, /api/check/etag, existe uniquement pour démontrer la reconnaissance fondée sur le cache, expliquée dans la section suivante : il distribue un identifiant de cache aléatoire et ne conserve rien du tout — ni table des valeurs émises, ni journal de qui a demandé. Le troisième est l’endpoint de compteurs : il accepte une poignée de valeurs approximatives d’une exécution terminée et renvoie des totaux courants, pour que la page puisse dire à quel point votre configuration est courante sans que personne ne conserve votre visite. Chaque endpoint est limité en débit comme les autres vérificateurs du site, car petit et honnête n’est pas la même chose qu’illimité, et un endpoint de démonstration que l’on peut marteler est une surface d’abus à bonne intention.
La page est aussi explicite sur les services extérieurs qu’elle contacte directement depuis votre navigateur, car ces services voient aussi votre adresse et l’honnêteté à leur sujet fait partie de la conception. Le test lit des endpoints de trace Cloudflare, interroge un service d’écho DNS pour révéler quel résolveur répond pour vous et ouvre des connexions vers deux serveurs STUN publics pour montrer ce qu’une recherche de type WebRTC peut apprendre. Chacun est nommé sur la page elle-même, à côté du résultat qu’il produit — la même discipline de divulgation que nous appliquons aux contrôles de fuites dans fuites VPN et contrôles de déguisement. Un test de vie privée qui appellerait silencieusement des tiers échouerait à sa propre leçon.
L’astuce ETag, expliquée honnêtement
Un ETag est une pièce ordinaire de la mise en cache HTTP : un serveur attache un validateur à une réponse, le navigateur le stocke avec la copie en cache et, à la visite suivante, le navigateur renvoie le validateur pour que le serveur puisse répondre « non modifié » et économiser le transfert. L’astuce est que le validateur n’a pas à décrire le contenu. Un serveur peut émettre un validateur unique pour chaque visiteur, et le navigateur renverra fidèlement cette valeur unique à chaque revalidation — moment où le serveur reconnaît le navigateur avec exactement la même fiabilité qu’un cookie, sans jamais en avoir posé un. La validation de cache sert d’identifiant parce que le navigateur fait correctement son travail.
C’est pourquoi effacer les cookies ne l’efface pas : cookies et cache sont des stockages séparés, vidés par des contrôles séparés, selon des calendriers séparés. Et c’est pourquoi une fenêtre privée ou de navigation privée casse l’astuce — une fenêtre privée fonctionne avec son propre cache séparé, jeté à la fermeture de la fenêtre, donc le validateur meurt avec la session. Notre endpoint démontre l’aller-retour et ne stocke rien : la reconnaissance est prouvée par la réponse 304 elle-même, par le serveur voyant revenir sa propre valeur aléatoire, et non par un quelconque enregistrement conservé entre les visites. La démonstration se termine au moment où la page se ferme, ce qui est exactement la propriété que les traqueurs réels qui utilisent cette technique n’offrent pas.
Il y a un pli honnête qui mérite d’être nommé : le cache de périphérie. Si les réponses passaient par un cache CDN partagé, l’identifiant du premier visiteur pourrait être servi à tout le monde, et la démonstration montrerait une foule partageant un seul ID au lieu que chaque navigateur ait le sien. Cet endpoint renonce donc entièrement à la mise en cache de périphérie — chaque requête atteint l’origine, chaque visiteur reçoit une valeur aléatoire fraîche et aucun cache partagé n’en conserve jamais une. C’est une petite ligne de configuration, mais c’est la différence entre une démonstration qui prouve le mécanisme et une qui prouve accidentellement le contraire.
Des compteurs au lieu de journaux
Une question a vraiment besoin du serveur : « à quel point suis-je inhabituel ? » Une page qui peut dire votre GPU est apparu dans N exécutions sur M aujourd’hui enseigne bien davantage qu’une page qui ne peut que lister des signaux, car la rareté est ce qui rend une empreinte identifiante. Mais y répondre de la manière évidente — journaliser chaque visite, puis compter — construit exactement la base de données contre laquelle l’outil met en garde. Le test conserve donc des compteurs au lieu de journaux : un nombre par valeur et par jour. Le système d’exploitation, la famille du navigateur, la chaîne GPU, le fuseau horaire, la première langue, la classe de taille d’écran, les huit premiers caractères des identifiants d’empreinte, le résultat de chaque contrôle individuel et une tranche de durée d’exécution : chacun apporte une coche à un total quotidien, et rien d’autre n’est conservé.
Les limites comptent plus que le mécanisme. L’empreinte complète n’est jamais envoyée, et encore moins stockée ; votre adresse n’est jamais envoyée au compteur. Un compteur ne peut pas être interrogé à rebours jusqu’à une personne, car il n’y a aucune ligne par visiteur à trouver — l’agrégation a lieu au moment du comptage, et non plus tard comme une étape de rapport sur des enregistrements stockés. C’est la même raison pour laquelle les totaux se réinitialisent par jour : un compteur qui s’accumulerait pour toujours, découpé assez finement, deviendrait silencieusement une base de données d’empreintes par accumulation, et la conception refuse cette dérive à l’avance plutôt que de s’en excuser ensuite.
Deux autres choix protègent les personnes qui ne liront jamais cet article. Les navigateurs envoyant le signal Global Privacy Control ne sont jamais comptés du tout — le signal signifie « ne me suivez pas », et sa lecture la plus respectueuse est d’exclure entièrement ces exécutions plutôt que de les compter avec soin. Tous les autres disposent d’une option de refus visible sur la page, honorée avant tout comptage. Et une exécution qui ne se termine pas en 45 secondes compte une fois, comme « bloquée », dans sa propre tranche : la lenteur et les pannes restent visibles pour nous en tant qu’opérateurs, sous la forme d’un seul nombre agrégé, sans suivre aucun visiteur individuel à travers une exécution en échec.
Ce que nous avons choisi de ne pas construire
La partie la plus instructive de la conception est la liste des choses laissées de côté. Il n’y a pas de sonde au niveau de la connexion : ni empreinte TLS, ni lecture de type JA3 de votre poignée de main. La raison honnête est architecturale — le TLS de ce site se termine au CDN placé devant lui, donc une lecture de poignée de main prise à notre origine décrirait la négociation et les réglages du CDN bien plus que ceux de votre navigateur. La publier comme « votre empreinte TLS » serait du théâtre : une valeur plausible portant le nom de quelqu’un d’autre. Un outil de vie privée qui imprime une lecture confiante mais fausse apprend à ses utilisateurs à faire confiance aux lectures confiantes mais fausses partout ailleurs, ce qui est pire qu’un panneau vide.
La même discipline a façonné le reste des omissions. Les compteurs sont approximatifs parce que des compteurs fins deviennent une base de données d’empreintes par accumulation, une dimension innocente à la fois. La mémoire de la dernière visite — « depuis votre dernière exécution, ces valeurs ont changé » — vit uniquement dans le stockage de votre propre navigateur, sur votre machine, et n’est jamais transmise ; au moment où elle se synchroniserait, elle deviendrait un historique, et un historique est un enregistrement. Des fonctionnalités qui auraient été vraiment utiles ont été coupées pour la même raison que les endpoints sont restés petits : l’utilité n’est pas une défense quand le coût en données est tout l’objet de l’outil.
Enfin, la note d’honnêteté résiduelle, car aucun article de conception ne devrait se terminer sur ses propres compliments. Cette conception minimise les données ; elle ne peut pas rendre les lectures elles-mêmes moins identifiantes. Votre GPU, vos polices, votre écran et votre fuseau horaire se combinent en quelque chose de presque unique, qu’on les stocke ou non — c’est la conclusion que l’outil existe pour vous montrer. Ne conserver aucune donnée vous protège de nous. Cela ne vous protège pas de la technique, et prétendre le contraire serait la seule fonctionnalité vraiment malhonnête que nous pourrions livrer.