Las cookies no desaparecen por primera vez, y la sensación de déjà vu es como tras la tercera «última gira» de una banda de rock. Aun así, el mercado se está reeducando colectivamente hacia la huella del dispositivo: en lugar de almacenar un identificador en el navegador, se calcula al vuelo a partir de cientos de señales de hardware, sistema operativo, red y comportamiento. En este artículo analizamos qué señales funcionan realmente en 2025, por qué los ataques de temporización vuelven a estar de moda, cómo no dejarse engañar por navegadores anti‑detección y dónde se traza la línea roja legal. Vamos.
Qué es la huella del dispositivo 2.0 y por qué sobrevivió sin cookies
La huella moderna no es un «hash mágico», sino un modelo probabilístico: muchos indicadores débiles se combinan en una «rugosidad» digital persistente de un dispositivo concreto. Los navegadores llevan tiempo recortando fuentes de entropía; los organismos que estandarizan publican recomendaciones para mitigar fugas, por ejemplo la guía W3C, y Google impulsa ideas como Privacy Sandbox, Client Hints y el «presupuesto de privacidad». Pero el mercado publicitario, la lucha contra el fraude y la seguridad siguen necesitando identificación estable, por eso evoluciona la «versión 2.0» de las huellas: más señales de red y de temporización, coherencia entre capas y aprendizaje automático para coser sesiones.
De qué se compone la huella: superficies de entropía
En la práctica los indicadores útiles se dividen en tres capas. Cuanto más baja es la capa, más caro y complejo es sufalseamiento, y por tanto mayor su valor para la detección antifraude.
- Capa del navegador. Renderizado Canvas/WebGL y métricas de fuentes, patrones reconocibles de
AudioContext, conjunto y comportamiento de APIs, idioma y formato de fechas, tamaño de la ventana, zoom, densidad de píxeles, comportamiento de controladores gráficos. Orígenes y clásicos: desde «Pixel Perfect» hasta investigaciones como «La web nunca olvida». Véanse materiales de referencia: huellas Canvas, mediciones a gran escala. - Capa de red. Características del apretón de manos TLS (JA3/JA4), comportamiento de HTTP/2/HTTP/3, conjunto de extensiones, orden de tramas, QUIC y prioridades. Esas cosas son más difíciles de «simular» con un script en el proceso de renderizado: la mimetización correcta reside en la biblioteca TLS y la pila de protocolos. Véanse JA3 y el más reciente JA4/JA4+, así como la ponencia sobre huellas HTTP/2.
- Capa de comportamiento. Ritmo del cursor/tacto, scroll, micro‑latencias entre eventos, inestabilidad de fotogramas. No es una panacea, pero «añade peso» al modelo de scoring, especialmente contra granjas de cuentas.
Canvas/WebGL y fuentes: por qué «los píxeles no mienten»
Las huellas Canvas y WebGL se apoyan en diferencias microscópicas de renderizado: desde la versión del controlador hasta las tablas de consejos de fuentes y el suavizado subpíxel. A veces basta dibujar una cadena con un conjunto de glifos no estándar, medir su ancho real y obtener un vector estable y distintivo. Trabajos clásicos sobre el tema son Mowery & Shacham y métricas de fuentes como Fifield & Egelman. Para la práctica es útil comparar con las pruebas de Cubre tus huellas de EFF.
Los navegadores anti‑detección intentan «apenar» o sustituir Canvas. Por eso conviene verificar la integridad del canal: comparar el GPU/renderizador de WebGL con el comportamiento del controlador en una tarea de sombreado, buscar señales de sustitución mediante estadísticas de errores y backends no estándar, y usar comprobaciones activas de manipulación (idea descrita, por ejemplo, aquí: detección de manipulación de Canvas).
Ataques de temporización como herramientas útiles del antifraude
La reducción de la precisión de performance.now() y la introducción de jitter no mataron los ataques por temporización, solo los obligaron a evolucionar. En 2022, investigadores propusieron la técnica DrawnApart: mediante una serie de sombreadores WebGL se mide el «carácter» de ejecución de varios bloques de GPU. Eso produce un patrón de ruido estable que perdura más que los indicadores del navegador y ayuda a enlazar sesiones incluso tras limpiar el perfil. Las firmas de temporización pueden obtenerse por otros medios: micro‑benchmarks WASM, canal de audio ( huellas AudioContext), renderizado de fuentes bajo carga — lo importante no es qué medimos exactamente, sino con qué frecuencia la señal es reproducible.
La red te delata primero: JA3/JA4, HTTP/2/3 y los detalles
Mientras el front end cambia huellas como guantes, la capa de red sigue siendo conservadora. El cliente TLS dice más de lo que parece: orden de extensiones, curvas, suites de cifrado, grupos de firmas soportados — todo eso forma una firma como JA3 o el más moderno JA4+. Historia similar con HTTP/2: diferencias en SETTINGS, priorización y ventanas de flujo permiten distinguir un navegador «nativo» de un motor headless y ciertos antideteciones (ver investigación de Akamai y la explicación práctica sobre huellas HTTP/2).
La conclusión es simple: si la huella «superficial» dice «soy Safari en iOS», pero TLS/HTTP2 se comportan como «Chromium desde Node + proxy», es una bandera roja para el scoring.
Navegadores anti‑detección: qué cambian y cómo cazarlos
Los antideteción sustituyen todo lo que ve JS: de navigator a la geometría Canvas, suelen añadir ruido en WebGL y audio, simulan fuentes, manipulan zonas horarias. Algunos intentan imitar Client Hints ( UA‑CH), pero fallan en la coherencia entre capas. La respuesta es comprobaciones de consistencia y cosido de indicadores:
- Validación cruzada del renderizado. Contraste el vendor/renderizador de WebGL, el conjunto exacto de extensiones y el comportamiento en una serie de sombreadores. Las incoherencias son señal de sustitución.
- Fuentes vs. texto. Verifique métricas de glifos y algoritmos de fallback: una lista «perfecta» de fuentes instaladas rara vez coincide con el renderizado real del texto.
- Microscopio de temporización. Repita un par de tareas pesadas (WASM+WebGL+Audio) en distinto orden. Un patrón estable de latencias frente a un «aleatorizador» suma confianza.
- Interrogatorio de red. Observe JA3/JA4, HTTP/2/3 y patrones QUIC. Suplantar todo a la vez es más difícil, sobre todo al cambiar entre proxies.
- Comportamiento. Patrones de ratón/tacto, colisiones entre zona horaria y
Accept-Languagey formatos de fecha, falta de coincidencia entre geolocalización por IP y ajustes del sistema — todo ello es una buena añadidura a la huella del dispositivo. - Pruebas de manipulación. Integre tests pasivos y activos de integridad para Canvas/WebGL (ver ideas de detección de manipulación).
Finalmente, no olvide el «mundo fuera del navegador»: tarjetas de pago iguales, direcciones, grafos de comportamiento y mapas de actividad temporal — todo eso cosecha granjas incluso con una mimetización cliente perfecta.
Derecho y cumplimiento: dónde «se puede» y dónde «hace falta el botón de consentimiento»
En la UE los reguladores consideran las huellas de dispositivo como un mecanismo de seguimiento al mismo nivel que las cookies. La CNIL francesa afirma claramente: si se usa información del terminal con fines publicitarios se requiere consentimiento informado. Véase la aclaración de la CNIL sobre alternativas a las cookies y el repaso de actuaciones en acciones posteriores. En los estándares están las recomendaciones de la W3C. Para antifraude y seguridad (KYC, prevención de fraude, protección de cuentas) la lógica legal es más flexible, pero igualmente importante: minimización de datos, finalidad y plazos de conservación, evaluación de impacto sobre la protección de datos (DPIA), transparencia en la política y posibilidad de exclusión.
Cómo probar las defensas sin volverse loco
Empiece por las herramientas. Para tener una visión general — Cubre tus huellas. Para la capa de red — examine la implementación y los registros JA3/JA4 (existen utilidades y módulos abiertos para nginx), y revise publicaciones sobre HTTP/2. En el navegador conviene tener presentes los límites y los modos «anti‑fingerprint»: Tor y Brave ofrecen descripciones claras: Manual de Tor, Protecciones de Brave.
Esquema práctico de scoring: cómo coser sesiones sin cookies
- Recoja indicadores por capas. De navegador (Canvas/WebGL/fuentes/audio), de red (JA4, HTTP/2/3), y de comportamiento.
- Construya dos vectores. Largo plazo (temporizaciones, pila de red) y Corto plazo (idioma, tamaño de ventana, zoom). El primero da anclaje; el segundo, dinamismo.
- Consistencia. Introduzca invariantes entre niveles: si se violan, penalice la puntuación.
- Cosido por grafo. Enlace identificadores mediante indicadores comunes/patrones de pago/tiempo/red. Cuantos más arcos tenga un nodo, mayor probabilidad de tratarse de una granja.
- Valore riesgo y respuesta. «Sombra» → verificación adicional; «alto riesgo» → limitación de bonos/retiros; «crítico» → bloqueo y verificación manual.
Tabla: qué señales valen la pena
| Señal | Permanencia | Dificultad de suplantación | Comentario |
|---|---|---|---|
| Renderizado Canvas/WebGL | Media | Media | Bueno contra bots «vanilla»; los antideteción añaden ruido — detectamos manipulación e incoherencias |
| Métricas de fuentes | Media | Media | Combínelas con comprobaciones de fallback y ligaduras |
| AudioContext | Media | Media | Sensible a controladores y sistema operativo; útil en conjunto |
| Microbenchmarks de temporización | Alta | Alta | El estilo DrawnApart ofrece un patrón estable del dispositivo |
| TLS JA4 / HTTP/2 | Alta | Muy alta | Mejor ancla; lo más difícil de falsificar «al vuelo» |
| Comportamiento del usuario | Baja | Media | Enriquece el modelo, pero no basta como único indicador |
SEO y navegadores: Client Hints y el «presupuesto de privacidad»
La clásica cadena User‑Agent se reduce y la información se traslada a cabeceras/JS controladas por Client Hints. Paralelamente se ha debatido el «presupuesto de privacidad»: un límite a la «fuga» total de entropía vía APIs (véase la página de la iniciativa). La idea es atractiva; implementarla es complejo: las discusiones sobre practicidad y seguridad están bien resumidas por la comunidad Mozilla. En la práctica queda menos fuga pasiva y más retos activos y comprobaciones cruzadas.
Lista de comprobación para la resistencia del antifraude frente a antideteciones
- Añada la capa de red (JA4/HTTP2/3) a todos los casos de antifraude.
- Implemente desafíos activos de Canvas/WebGL/Audio y pruebas contra manipulación.
- Construya dos vectores (largo/corto) y un «pegamento» de reglas de consistencia.
- Use análisis por grafos y scoring de riesgo en lugar de decisiones binarias «ban/no ban».
- Documente las bases legales: finalidad, plazos, política y el botón de consentimiento donde proceda para publicidad.
- Reentrene modelos regularmente con datos recientes y pruebe A/B off‑line.
Conclusiones
La «huella 2.0» no es un truco con Canvas, sino una disciplina en la intersección del front end, redes y analítica. Es eficaz cuando las señales están coherentes entre capas, la pila de red se considera un fundamento y las señales de temporización sirven de ancla a la que se sujetan los detalles más frágiles del navegador. Los navegadores anti‑detección nos obligan a pensar de forma sistémica — y sí, a veces con ironía, cuando un perfil «perfectamente verosímil» se delata en el primer SETTINGS de HTTP/2. En resumen: menos magia, más ingeniería — y algo de humor.
