Blog de Analytics House
Notas de arquitectura sobre cómo construir sobre Cloudflare Workers y D1 la plataforma de analítica web respetuosa con la privacidad más verificable del mundo.
Cómo la destrucción de la sal diaria efímera impide revertir por fuerza bruta los hashes históricos de visitantes
Como IPv4 solo tiene unos 4300 millones de direcciones, un hash estático de (IP + User-Agent) puede revertirse en minutos con una tabla arcoíris en GPU. Así es como Analytics House rota cada día UTC una sal CSPRNG de 256 bits en Cloudflare D1 y destruye de forma permanente la sal del día anterior en cuanto se sellan los resúmenes agregados.
La mayoría de las plataformas de analítica "sin cookies" calculan un hash diario de (daily_salt + site_id + IP + User-Agent) para poder contar los visitantes únicos diarios sin instalar cookies en el navegador. Sin embargo, si la sal se deriva de un secreto estático o se conserva indefinidamente en disco, cualquiera que comprometa la base de datos —u obtenga acceso mediante un requerimiento judicial— puede recorrer por fuerza bruta el espacio IPv4 de 32 bits para un User-Agent conocido.
En Analytics House, cada día UTC genera una sal aleatoria independiente de 256 bits mediante crypto.getRandomValues(), que se guarda en la tabla meta de Cloudflare D1 con la clave salt:YYYY-MM-DD. Durante el día, las solicitudes entrantes a /collect calculan en la memoria del Worker un identificador de visitante y de sesión SHA-256 con sal, truncado a 64 bits, y descartan de inmediato la IP del cliente y el User-Agent en bruto.
Cada 15 minutos, el Cron Trigger programado sella los días UTC completados en tablas de resumen preagregadas (rollup_day y rollup_dim). En cuanto la marca de agua supera un día UTC, shredExpiredSalts() elimina todas las sales anteriores a la marca de agua sellada. Una vez borrada esa clave de 256 bits, no hay ninguna forma práctica de vincular un identificador de visitante pasado con una dirección IP, ni de vincular las visitas de un día con las de otro. Los identificadores siguen siendo datos seudonimizados, así que el resto de las protecciones siguen aplicándose.
Modo sin historial en bruto y depuración automática de datos personales en el perímetro con Cloudflare Workers
Las URL de las aplicaciones y las cargas útiles de los eventos personalizados filtran a menudo, por accidente, tokens de restablecimiento, UUID, direcciones de correo electrónico o números de tarjeta de crédito. Descubre cómo nuestro cortafuegos síncrono de datos personales en el perímetro depura la telemetría antes de escribir en D1 y cómo el modo sin historial en bruto purga las filas de eventos en bruto al sellar los resúmenes agregados.
Los desarrolladores rara vez pretenden enviar datos personales a su servicio de analítica; sin embargo, las URL de restablecimiento de contraseña (/reset-password/eyJhbGci...), las rutas de perfiles de usuario (/users/alice@example.com) y las propiedades del proceso de pago filtran habitualmente cadenas sensibles a las bases de datos de analítica.
Analytics House ejecuta un depurador determinista de datos personales dentro del Cloudflare Worker antes de que cualquier evento llegue a D1. Se eliminan las cadenas de consulta y los fragmentos de las URL; los segmentos de ruta que coinciden con correos electrónicos ([email]), UUID ([uuid]), JWT ([jwt]), direcciones IPv4 ([ip]) o tokens hexadecimales/base64 de alta entropía ([token]) se enmascaran durante el tránsito. Las propiedades de los eventos personalizados se analizan de forma recursiva en busca de claves sensibles (email, password, token, secret, ssn, phone, credit_card, api_key) y de números de tarjeta de crédito validados con el algoritmo de Luhn.
Para los equipos con requisitos de cumplimiento estrictos, activar el modo sin historial en bruto (ephemeral_raw) va un paso más allá: cuando un día UTC se sella en resúmenes agregados, las filas en bruto de ese día en la tabla events se eliminan de inmediato y solo quedan los contadores diarios agregados.
Confianza sin IP desde la arquitectura: retransmisión con un Cloudflare Worker propio
Aunque un proveedor de analítica prometa no registrar las direcciones IP, las solicitudes HTTPS estándar siguen exponiendo la IP del visitante al servidor perimetral del proveedor. Con nuestro proxy de Cloudflare Worker propio, que se configura en 1 clic, tu propio dominio elimina la IP del visitante antes de reenviar un token de retransmisión anonimizado.
En una configuración de analítica tradicional, el navegador del visitante se conecta directamente al dominio del proveedor de analítica. Eso significa que debes confiar en que la política del proveedor sea no registrar CF-Connecting-IP.
Como Analytics House es 100 % nativo de Cloudflare, cada proyecto del panel genera un script de Cloudflare Worker propio e independiente que puedes desplegar en una ruta de tu propio dominio (por ejemplo, yoursite.com/_ea/*).
Cuando un visitante carga tu sitio web, tu propio Worker recibe la solicitud, calcula un resumen SHA-256 con clave de (UTC_date + CF-Connecting-IP + User-Agent) usando un secreto que nunca sale de tu cuenta de Cloudflare, elimina la dirección IP del visitante y reenvía a Analytics House solo el encabezado opaco X-EA-Visitor-Relay y un código de país aproximado.
¿Quieres revisar las garantías criptográficas en tiempo real?
Lee nuestra Especificación de privacidad o explora la Referencia de la API.