Cómo funciona el seguimiento de la huella digital por dentro

Todo dispositivo que se conecta a internet deja un rastro de artefactos técnicos: una huella digital. En tracio.ai, reconstruimos esta huella a partir de más de 300 señales pasivas recopiladas durante una única carga de página, sin que la identificación dependa de cookies ni de ninguna otra forma de almacenamiento persistente del lado del cliente. Este artículo explica exactamente cómo funciona ese proceso.

La capa de recopilación de señales

Cuando nuestro agente JavaScript se carga en el navegador de un visitante, empieza a recopilar señales de múltiples categorías simultáneamente. El renderizado de canvas, las consultas de parámetros de WebGL, el procesamiento de AudioContext, la enumeración de fuentes y las lecturas de propiedades del navigator se ejecutan todas en paralelo, cada una acotada por su propio timeout para que una sonda lenta no retenga a las demás. Cuánto tarda la pasada completa depende del dispositivo del visitante, y las cifras que siguen son las que medimos en los nuestros.

La idea clave es que cada señal captura un aspecto diferente del stack de hardware y software del dispositivo. El renderizado de canvas refleja la GPU, el driver y el motor de renderizado de fuentes. Los parámetros de WebGL exponen el modelo de tarjeta gráfica y sus capacidades. AudioContext revela diferencias en cómo el DSP de audio procesa las operaciones en coma flotante. Las propiedades del navigator informan los núcleos de CPU, la memoria, la plataforma y la configuración de idioma.

Nuestro equipo lo midió sobre 2.000 millones de eventos el mes pasado: el tiempo de recopilación medio fue de 38ms y el percentil 99 fue de 52ms. En realidad, primero probamos el enfoque ingenuo —recopilar las señales de forma secuencial—. Era 40 veces más lento. La recopilación en paralelo con una barrera de timeout fue una de las primeras decisiones arquitectónicas que acertamos.

Fingerprinting de TLS: la primera capa

Antes incluso de que nuestro JavaScript se ejecute, el navegador ya ha revelado información significativa a través del handshake TLS. El mensaje Client Hello contiene las suites de cifrado que el navegador soporta, las extensiones TLS que usa, las curvas elípticas que prefiere y los algoritmos de firma que acepta. Esta información está determinada por la librería TLS del navegador y varía significativamente entre familias de navegadores, versiones y sistemas operativos.

Capturamos esta huella de TLS usando el hashing JA4, un reemplazo moderno de JA3 que ofrece mejor granularidad y estabilidad entre versiones. El hash JA4 por sí solo puede distinguir Chrome de Firefox de Safari, y a menudo acota la identificación a un rango de versión específico del navegador. Combinado con nuestras señales del lado del cliente, proporciona una capa de validación cruzada extremadamente difícil de falsificar.

Fingerprinting de canvas y GPU

El fingerprinting de canvas explota el hecho de que diferentes GPU renderizan las mismas instrucciones de dibujo con sutiles diferencias a nivel de píxel. La Canvas API nos permite dibujar una escena cuidadosamente diseñada —cadenas de texto específicas en múltiples fuentes, formas geométricas con coordenadas concretas y gradientes con paradas de color precisas— y luego calcular un hash de los datos de píxeles resultantes.

Las diferencias de renderizado provienen de variaciones en los algoritmos de antialiasing, el renderizado de subpíxeles, la mezcla de colores y el hinting de fuentes entre modelos de GPU y versiones de driver. Incluso dos dispositivos con el mismo modelo de GPU pueden producir salidas de canvas diferentes si ejecutan versiones de driver o sistemas operativos distintos. Esto convierte al hash de canvas en una de nuestras señales más distintivas.

Perfilado de hardware con WebGL

La WebGL API expone información detallada sobre el subsistema gráfico que va mucho más allá de las cadenas de renderizador y fabricante. Consultamos los tamaños máximos de textura, los formatos de precisión de shader, las extensiones soportadas, las dimensiones del viewport y docenas de otros parámetros que varían entre modelos de GPU y configuraciones de driver.

La combinación de estos parámetros crea un perfil de hardware detallado. Un dispositivo con una NVIDIA RTX 4070, por ejemplo, informará tamaños máximos de textura diferentes, una precisión de shader diferente y un soporte de extensiones diferente al de un dispositivo con una AMD RX 7800 XT. Este perfil de hardware es inherentemente estable: no cambia con las actualizaciones del navegador, solo con cambios de hardware o de driver.

Fingerprinting del procesamiento de audio

La Web Audio API proporciona otra fuente de señal dependiente del hardware. Creamos un nodo oscilador, lo conectamos a un compresor de dinámica y medimos el búfer de salida. Las diferencias en la precisión en coma flotante, la implementación del DSP y los algoritmos de remuestreo entre el hardware de audio y los sistemas operativos producen variaciones medibles en la salida.

Las huellas de audio tienen una unicidad moderada pero una estabilidad excepcional. El pipeline de procesamiento de audio rara vez cambia a menos que el usuario cambie de hardware de audio o reinstale el sistema operativo. Esto convierte a las señales de audio en anclas valiosas dentro de nuestro sistema de identificación multinivel.

Fusión de señales y resolución de identidad

Las señales sin procesar se cifran y se transmiten a nuestro servidor, donde el motor de identificación de dispositivos las procesa a través de un sistema de hashing de tres niveles. Las señales a nivel de hardware (canvas, WebGL, audio) forman el Nivel 1: la identidad central estable. Las señales a nivel de navegador (detección de características, propiedades CSS, capacidades de medios) forman el Nivel 2, procesado mediante coincidencia entre sesiones para manejar la deriva esperada de las actualizaciones del navegador. Las señales volátiles (user agent, zona horaria, idioma) forman el Nivel 3, que contribuye a la puntuación de confianza sin dirigir las decisiones de identidad.

El algoritmo de fusión pondera cada señal según su unicidad y estabilidad. Una coincidencia en un hash de canvas poco común tiene mucho más peso que una coincidencia en una resolución de pantalla común. Este enfoque ponderado garantiza que la identificación siga siendo precisa incluso cuando cambia un subconjunto de señales.

Qué almacenamos y por qué la identificación no depende de ello

Un principio de diseño crítico de nuestro sistema es que la identificación no depende del almacenamiento del lado del cliente. El ID de visitante se deriva de las características inherentes del dispositivo —el hardware, el stack de software, la configuración de red—, y por eso la identificación sobrevive al borrado de cookies, el modo incógnito e incluso la reinstalación del navegador.

Es una afirmación sobre dependencia, no sobre abstinencia, y conviene decir la diferencia con claridad. Sí fijamos una cookie propia, _vid_t, que contiene un identificador opaco con una caducidad de 365 días, y replicamos ese mismo valor en localStorage. Lo que no hacemos es fijar cookies de terceros, escribir nada que funcione entre sitios ni leer el historial de navegación, los datos de formularios o IndexedDB. La cookie existe porque es la respuesta más barata posible a «¿hemos visto antes este navegador?»: cuando sobrevive, la coincidencia es inmediata y certera. Cuando no sobrevive, no se rompe nada: las señales del dispositivo reconstruyen el identificador por sí solas, con algo menos de confianza. A un visitante que lo borra todo se le sigue reconociendo; un sistema basado solo en el almacenamiento lo habría perdido.

Privacidad por arquitectura

Como recopilamos únicamente atributos técnicos del navegador —sin historial de navegación, sin datos de formularios, sin contenido personal—, el impacto en la privacidad es mínimo. La guía de fingerprinting del W3C describe las mejores prácticas para el uso responsable de las señales del navegador, y nuestra arquitectura se alinea con estos principios. El procesamiento ocurre en nuestra nube gestionada, con residencia de datos en la UE o en EE. UU. según la región que elija. Esta arquitectura simplifica el cumplimiento del GDPR, la CCPA y otras regulaciones de privacidad.