Comment fonctionne l'identification des visiteurs par hachage (et pourquoi elle respecte la vie privée) -- Web-Tracking.eu

Le problème : compter les visiteurs uniques sans les suivre

Compter les visiteurs uniques est l'un des plus vieux problèmes de l'analyse web. Vous voulez savoir combien de personnes différentes sont venues sur votre site hier, combien sont revenues aujourd'hui, combien sont arrivées pour la première fois depuis une campagne spécifique. Ce sont des questions raisonnables pour quiconque gère un site web. Y répondre nécessite un moyen de dire « ces deux pages vues viennent de la même personne, et ces deux-là non ».

Pendant des décennies, la réponse standard consistait à attribuer à chaque visiteur un identifiant permanent — généralement stocké dans un cookie — et à rechercher cet identifiant à chaque requête. Un nouveau visiteur reçoit un nouvel ID. Un visiteur récurrent réutilise le sien. Compter les uniques revient alors simplement à compter les ID distincts.

Cette approche fonctionne à merveille pour l'ingénieur et terriblement pour le visiteur. Un identifiant permanent, stocké sur l'appareil, lié à chaque requête, est exactement le genre de chose que la directive ePrivacy a été écrite pour contrôler. Cela nécessite un consentement dans l'UE, et cela crée un véritable problème de vie privée même quand ce n'est pas le cas : toute partie ayant accès à cet identifiant peut en construire un profil comportemental.

L'analytique sans cookies moderne résout le même problème de comptage sans rien stocker sur l'appareil. Le mécanisme est l'identification par hachage, et il fonctionne en calculant un identifiant éphémère côté serveur à partir de données que le serveur possède déjà.

Pourquoi les cookies et localStorage l'ont résolu (et ont créé des problèmes juridiques)

L'attrait des cookies et de localStorage pour l'analytique était évident : ils vous donnent un identifiant stable qui survit à travers les requêtes, à travers les onglets et souvent à travers les sessions, sans aucun état côté serveur. Le navigateur fait tout le travail. Vous définissez un cookie lors de la première visite, vous le lisez à chaque requête suivante, vous n'avez plus jamais besoin de penser à l'identité.

Le problème est que ce mécanisme est juridiquement encadré. L'article 5(3) de la directive ePrivacy considère le « stockage d'informations » et « l'obtention de l'accès à des informations déjà stockées » sur l'appareil de l'utilisateur comme déclencheur de l'obligation de consentement. Les cookies en sont l'exemple canonique. localStorage aussi. sessionStorage aussi. IndexedDB aussi. Toute forme de fingerprinting qui lit des propriétés stables du matériel ou du logiciel aussi.

Cela signifie que tout outil d'analytique qui dépend du stockage sur l'appareil pour compter les uniques doit soit afficher une bannière de consentement, soit remplir l'une des exemptions étroites — ce qui pour l'analytique nécessite généralement un usage strictement first-party, pas de suivi intersites, une conservation limitée et une autorité de contrôle prête à accepter la configuration. L'enveloppe de conformité est étroite, et les conséquences d'une erreur ont été sévères. Les autorités française, allemande et autrichienne ont toutes émis des ordres contre des sites web exécutant Google Analytics dans sa configuration par défaut.

L'approche par hachage contourne entièrement cela en déplaçant l'identifiant loin de l'appareil.

L'alternative par hachage

L'idée centrale est simple : au lieu de stocker un identifiant sur l'appareil et de le renvoyer au serveur à chaque requête, le serveur calcule un identifiant à partir de zéro à chaque requête en utilisant des attributs que le protocole HTTP porte déjà. Le navigateur n'est jamais impliqué. Rien n'est stocké. Rien n'est lu.

Pour que cela fonctionne comme compteur de visiteurs, l'identifiant calculé doit être :

Stable sur la période de comptage (typiquement une journée)
Imprévisible pour quiconque n'a pas accès au secret côté serveur
Non liable à travers les périodes ou les sites, afin qu'il ne puisse pas être utilisé pour construire un profil à long terme
Irréversible, de sorte que le serveur ne puisse pas (et les attaquants non plus) récupérer les entrées d'origine à partir du hachage stocké

Une fonction de hachage cryptographique vous donne toutes ces propriétés quand vous lui fournissez les bonnes entrées et que vous faites tourner les bons composants.

Comment cela fonctionne

Voici la forme générale de l'algorithme utilisé par Web-Tracking.eu et les outils d'analytique sans cookies similaires. Les détails exacts varient entre fournisseurs, mais les briques sont les mêmes.

function visitorId(request, siteId) {
    const ip     = request.remoteAddr;
    const ua     = request.headers['user-agent'];
    const date   = today('UTC');        // YYYY-MM-DD
    const salt   = dailySalt();         // random bytes, rotated every day

    const input  = ip + '|' + ua + '|' + siteId + '|' + date + '|' + salt;
    const hash   = sha256(input);

    // raw inputs are discarded here, only the hash leaves this function
    return hash;
}

C'est tout le mécanisme. À chaque requête entrante sur notre endpoint tracker, le serveur :

Prend l'adresse IP et l'en-tête User-Agent de la requête
Y ajoute la date UTC courante, l'ID du site et le sel secret du jour
Passe le tout dans SHA-256
Utilise le hachage résultant comme ID visiteur pour cette requête
Rejette l'IP d'origine, le User-Agent et le sel — seul le hachage est stocké

Le navigateur ne voit jamais ce hachage. Il n'est pas écrit dans un cookie, pas renvoyé dans un en-tête Set-Cookie, pas stocké dans localStorage, pas renvoyé dans aucune réponse. Il vit entièrement dans notre base de données sous forme d'une courte chaîne hexadécimale qui identifie « le visiteur qui a envoyé ces requêtes ce jour-là ».

Pourquoi la rotation quotidienne compte

La composante date de l'entrée est l'élément d'ingénierie de confidentialité le plus important de ce schéma. Sans elle, chaque requête provenant du même triplet (IP, User-Agent, site) produirait le même hachage pour toujours. Le hachage serait effectivement un identifiant persistant et global — exactement ce que nous essayons d'éviter.

Avec une rotation quotidienne, le hachage pour un visiteur donné change à minuit UTC chaque jour. Un visiteur qui revient demain produit un hachage complètement différent, indiscernable d'un tout nouveau visiteur. Nous ne pouvons pas lier ses visites du lundi à ses visites du mardi, car nous n'avons aucun mécanisme pour faire le pont entre les deux hachages.

Cela sacrifie une partie de la puissance analytique. Nous ne pouvons pas calculer un compte de visiteurs uniques sur 7 jours en comptant les hachages distincts ; nous devons l'estimer à partir des comptes quotidiens et d'une hypothèse sur le taux de retour, ou présenter les uniques quotidiens et laisser l'opérateur les interpréter. Le compromis est délibéré : nous pouvons mesurer l'audience sans construire une infrastructure de suivi.

Certains fournisseurs font tourner selon un autre calendrier (hebdomadaire, mensuel). Notre avis est que le quotidien est la bonne valeur par défaut. La rotation hebdomadaire et mensuelle donne des analyses légèrement meilleures mais des garanties de confidentialité plus faibles, et toute autorité contestant une approche sans cookies est plus susceptible d'accepter une fenêtre de rotation courte.

Pourquoi le sel compte

Le sel secret quotidien fait deux choses. Premièrement, il empêche les attaques par table arc-en-ciel : sans le sel, un attaquant ayant mis la main sur une liste de nos hachages pourrait précalculer les hachages pour les combinaisons (IP, User-Agent) courantes et retrouver les entrées. Avec un sel secret que nous ne divulguons jamais, l'espace de hachage est effectivement rendu aléatoire et le précalcul est inutile.

Deuxièmement, le sel signifie que même si l'algorithme exact et la structure complète de l'entrée étaient publiés (comme ils le sont dans cet article), personne hors de nos serveurs ne peut calculer l'ID visiteur pour une combinaison (IP, User-Agent) connue. Il faudrait le sel, et le sel est renouvelé quotidiennement et ne quitte jamais le serveur.

Le sel est long (32 octets de données cryptographiquement aléatoires), stocké dans un gestionnaire de secrets séparé de la base de données d'analytique, et renouvelé toutes les 24 heures. Les anciens sels sont supprimés après la rotation, de sorte que même un dump complet de la base de données ne vous permettrait pas de reconstruire les sels d'hier pour calculer les hachages d'hier.

Quelles données sont hachées

Les ingrédients de notre hachage sont délibérément minimaux :

Adresse IP — identifie l'origine réseau de la requête. À l'intérieur du hachage, jamais stockée brute.
User-Agent — identifie le navigateur et l'OS en termes larges. À l'intérieur du hachage, jamais stocké brut en tant qu'identifiant.
ID du site — limite le hachage à un seul site. Un visiteur apparaissant sur deux sites suivis par Web-Tracking.eu produit deux hachages sans rapport.
Date UTC courante — fait tourner l'identifiant quotidiennement.
Sel secret — fait tourner l'identifiant quotidiennement et empêche la rétro-ingénierie.

Nous ne hachons aucune propriété de l'appareil qui nécessiterait une lecture depuis le navigateur (taille d'écran, langue, plugins, polices, rendu canvas, etc.). Ce que le navigateur envoie volontairement dans les en-têtes HTTP est acceptable ; ce qui nécessiterait une lecture JavaScript depuis l'appareil ne l'est pas.

C'est une ligne importante. Cela signifie que notre « empreinte » n'est aussi stable que l'adresse IP et le User-Agent. Un visiteur qui change de réseau en milieu de journée obtient un nouveau hachage. Un visiteur qui met à jour son navigateur obtient un nouveau hachage après la mise à jour. Un visiteur qui utilise un VPN faisant tourner les IP de sortie obtient un nouveau hachage à chaque rotation. Nous acceptons cette imprécision comme le coût de ne pas construire une véritable empreinte.

Pourquoi cela n'identifie pas les utilisateurs

La sortie du hachage est une chaîne hexadécimale de 64 caractères qui ressemble à ceci :

a3f2c9b4e8d1f7a5c6b9e2d4f8a1c3b5e7d9f2a4c6b8e1d3f5a7c9b2e4d6f8a0

En elle-même, cette chaîne ne peut être liée à aucun individu. Elle ne peut pas être inversée pour retrouver l'IP ou le User-Agent. Elle ne peut pas être corrélée à travers les jours car la date et le sel changent. Elle ne peut pas être corrélée à travers les sites car l'ID du site change.

Les entrées brutes (IP et User-Agent) existent en mémoire pendant les millisecondes nécessaires au calcul du hachage. Elles ne sont jamais écrites sur disque, jamais copiées dans des logs, jamais envoyées à un tiers, jamais conservées sous quelque forme que ce soit. La seule chose qui persiste est le hachage, et le hachage n'a aucune des propriétés qui en feraient des données personnelles au sens de l'article 4(1) du RGPD : il n'identifie pas, il ne peut pas distinguer, et il ne peut pas être lié à une personne identifiable sans accès à des données que nous n'avons pas.

L'avis 05/2014 du Groupe de travail Article 29 sur les techniques d'anonymisation pose trois tests : individualisation, corrélation et inférence. Notre hachage quotidien rotatif, limité au site et salé échoue aux trois tests en tant qu'identifiant d'individus, ce qui est précisément le but.

Limites : utilisateurs du même foyer, IP partagées, VPN

L'identification par hachage n'est pas un compteur parfait. Elle troque la précision contre la vie privée, et les façons dont elle est imparfaite méritent d'être comprises.

Les utilisateurs d'un même foyer partageant une adresse IP et utilisant la même version de navigateur produiront le même hachage. Deux personnes sur le même Wi-Fi domestique, toutes deux utilisant Chrome sur Windows, toutes deux sur le même site le même jour, seront comptées comme un seul visiteur. L'analytique basée sur les cookies les distinguerait (chacun reçoit son propre cookie) ; l'analytique par hachage non.

Les réseaux d'entreprise derrière un NAT peuvent réduire de nombreux visiteurs réels à un seul hachage. Un bureau de 200 personnes accédant à votre site depuis la même IP publique, tous utilisant la même version de navigateur poussée par l'informatique, ressemblera à un seul visiteur. L'analytique basée sur les cookies les distinguerait ; l'analytique par hachage non.

Les utilisateurs de VPN et Tor ont le problème inverse : une seule personne dont l'IP de sortie tourne produira plusieurs hachages et sera comptée plusieurs fois. L'analytique basée sur les cookies la verrait comme un seul visiteur ; l'analytique par hachage surcomptera.

Les utilisateurs sur plusieurs appareils seront toujours comptés séparément, car la combinaison IP + User-Agent est différente. C'est la même limite que l'analytique basée sur les cookies sans liaison d'identité entre appareils.

L'effet net est que l'analytique sans cookies tend à sous-compter les uniques dans les environnements partagés denses et à surcompter les uniques pour les utilisateurs soucieux de la vie privée avec des IP rotatives. Les deux effets s'annulent dans l'agrégat pour la plupart des sites, mais si votre audience est concentrée dans des réseaux d'entreprise ou fortement orientée vers les utilisateurs de VPN, les chiffres peuvent dériver par rapport aux comptages basés sur les cookies de plusieurs pour cent dans les deux sens.

Nous pensons que c'est un compromis acceptable, et la plupart de nos clients aussi. L'analytique n'est pas du recensement. Ce qui compte, c'est la forme de la courbe, la comparaison entre les jours, l'impact d'une campagne, le classement des pages. Tout cela est parfaitement préservé par le comptage par hachage.

Comparaison avec d'autres approches sans cookies

Plusieurs fournisseurs d'analytique ont convergé vers des variantes de la même architecture de base.

Plausible utilisait historiquement un hachage par site, à rotation quotidienne, de IP + User-Agent + site + sel. Leur implémentation actuelle est très proche de ce qui est décrit ci-dessus.
Fathom utilise une approche par hachage similaire avec calcul côté serveur et aucun stockage côté client.
Pirsch utilise une empreinte rotative quotidienne basée sur IP + User-Agent salés.
Simple Analytics calcule un hachage de IP + User-Agent + hostname + sel rotatif, également quotidiennement.

Les différences portent principalement sur :

La fréquence de rotation (quotidienne est typique, mais pas universelle)
Que le sel soit partagé entre clients ou par site
Quels champs d'en-tête exacts sont inclus dans l'entrée du hachage
Que les adresses IP soient tronquées (v4 : dernier octet, v6 : derniers 80 bits) avant le hachage, pour plus de confidentialité
Combien de temps le hachage résultant est conservé sous forme agrégée

Ce qui est remarquable, c'est la convergence. Il y a cinq ans, l'analytique axée sur la vie privée était un espace désordonné avec de nombreuses architectures concurrentes. Aujourd'hui, tous les acteurs sérieux utilisent le hachage côté serveur avec une forme de rotation, car c'est la seule architecture qui évite proprement le déclencheur ePrivacy sans compromettre la tâche analytique centrale.

En résumé

L'identification des visiteurs par hachage n'est ni un hack ni un contournement. C'est une solution de principe à un problème réel : compter les visiteurs uniques sans rien stocker sur leurs appareils et sans conserver d'identifiants bruts sur le serveur. Bien fait, avec une rotation quotidienne, un sel secret rotatif et des entrées brutes rejetées, cela vous donne une analytique utilisable avec de solides propriétés de confidentialité et sans exigence de consentement ePrivacy.

Mal fait — avec des fenêtres de rotation longues, des sels partagés, des IP conservées ou du fingerprinting d'appareil supplémentaire — cela dégénère en un simple autre schéma de suivi. Le diable est dans les détails d'ingénierie, c'est pourquoi cela vaut la peine de comprendre ce que votre fournisseur d'analytique fait réellement sous le capot.

Web-Tracking.eu est une plateforme d'analytique sans cookies. Pour en savoir plus sur notre approche, consultez l'explication juridique aucune bannière cookies.