Blog d’Analytics House
Notes d’architecture sur la construction, avec Cloudflare Workers et D1, de la plateforme d’analyse web respectueuse de la vie privée la plus vérifiable au monde.
Comment la destruction du sel quotidien éphémère met les anciennes empreintes de visiteurs à l’abri de la force brute
Comme l’IPv4 ne compte qu’environ 4,3 milliards d’adresses, un hachage statique de (IP + User-Agent) peut être inversé en quelques minutes avec une table arc-en-ciel sur GPU. Voici comment Analytics House renouvelle chaque jour UTC un sel CSPRNG de 256 bits dans Cloudflare D1 et détruit définitivement le sel de la veille une fois les agrégats clôturés.
La plupart des plateformes d’analyse « sans cookies » calculent un hachage quotidien de (daily_salt + site_id + IP + User-Agent) pour compter les visiteurs uniques quotidiens sans déposer de cookies dans le navigateur. Cependant, si le sel est dérivé d’un secret statique ou conservé indéfiniment sur disque, quiconque compromet la base de données (ou en obtient l’accès sur injonction judiciaire) peut parcourir par force brute l’espace IPv4 de 32 bits pour un User-Agent connu.
Dans Analytics House, chaque jour UTC génère un sel aléatoire indépendant de 256 bits via crypto.getRandomValues(), stocké dans la table meta de Cloudflare D1 sous salt:YYYY-MM-DD. Au cours de la journée, les requêtes /collect entrantes calculent, dans la mémoire du Worker, un identifiant de visiteur et de session SHA-256 salé, tronqué à 64 bits, puis suppriment immédiatement l’adresse IP du client et le User-Agent brut.
Toutes les 15 minutes, le Cron Trigger planifié clôture les journées UTC terminées dans des tables d’agrégats pré-calculés (rollup_day et rollup_dim). Dès que le repère d’avancement (watermark) dépasse une journée UTC, shredExpiredSalts() supprime tous les sels antérieurs à ce repère. Une fois cette clé de 256 bits effacée, il n’existe aucun moyen pratique de relier un ancien identifiant de visiteur à une adresse IP, ni de relier les visites d’une journée à celles d’une autre. Les identifiants restent des données pseudonymes : les autres protections continuent donc de s’appliquer.
Mode sans historique brut et nettoyage automatique des données personnelles en périphérie sur Cloudflare Workers
Les URL des applications et les données des événements personnalisés laissent souvent fuiter par accident des jetons de réinitialisation, des UUID, des adresses e-mail ou des numéros de carte bancaire. Découvrez comment notre pare-feu synchrone de données personnelles en périphérie assainit la télémétrie avant toute écriture dans D1, et comment le mode sans historique brut purge les lignes d’événements bruts à la clôture des agrégats.
Les développeurs ont rarement l’intention d’envoyer des données personnelles à leur service d’analyse, et pourtant les URL de réinitialisation de mot de passe (/reset-password/eyJhbGci...), les routes de profil utilisateur (/users/alice@example.com) et les propriétés liées au paiement laissent régulièrement fuiter des chaînes sensibles dans les bases de données d’analyse.
Analytics House exécute un filtre déterministe de données personnelles dans le Cloudflare Worker avant que le moindre événement n’atteigne D1. Les chaînes de requête et les fragments d’URL sont supprimés ; les segments de chemin correspondant à des adresses e-mail ([email]), des UUID ([uuid]), des JWT ([jwt]), des adresses IPv4 ([ip]) ou des jetons hexadécimaux/base64 à forte entropie ([token]) sont masqués à la volée. Les propriétés des événements personnalisés sont analysées de manière récursive à la recherche de clés sensibles (email, password, token, secret, ssn, phone, credit_card, api_key) et de numéros de carte bancaire validés par l’algorithme de Luhn.
Pour les équipes soumises à des exigences de conformité strictes, l’activation du mode sans historique brut (ephemeral_raw) va encore plus loin : lorsqu’une journée UTC est clôturée dans les agrégats, les lignes brutes de la table events pour cette journée sont immédiatement supprimées, et il ne reste que des compteurs quotidiens agrégés.
Zéro IP par conception : le relais Cloudflare Worker sur votre propre domaine
Même lorsqu’un fournisseur d’analyse promet de ne pas journaliser les adresses IP, les requêtes HTTPS classiques exposent toujours l’adresse IP du visiteur au serveur périphérique du fournisseur. Avec notre proxy Cloudflare Worker sur votre propre domaine, déployable en un clic, votre domaine supprime l’adresse IP du visiteur avant de transmettre un jeton de relais anonymisé.
Dans une configuration d’analyse traditionnelle, le navigateur du visiteur se connecte directement au domaine du fournisseur d’analyse. Vous devez donc vous fier à la politique du fournisseur pour qu’il ne journalise pas CF-Connecting-IP.
Comme Analytics House est 100 % natif Cloudflare, chaque projet du tableau de bord génère un script Cloudflare Worker autonome que vous pouvez déployer sur une route de votre propre domaine (par exemple, yoursite.com/_ea/*).
Lorsqu’un visiteur charge votre site, votre propre Worker reçoit la requête, calcule une empreinte SHA-256 de (UTC_date + CF-Connecting-IP + User-Agent) avec une clé secrète qui ne quitte jamais votre compte Cloudflare, supprime l’adresse IP du visiteur et ne transmet à Analytics House que l’en-tête opaque X-EA-Visitor-Relay et un code pays approximatif.
Envie d’inspecter les garanties cryptographiques en direct ?
Lisez notre spécification de confidentialité ou explorez la référence de l’API.