Tras la congelación del User-Agent, ¿por qué Client Hints es la nueva señal de huella digital? Evolución de UA a CH

Durante los últimos años, los principales navegadores han endurecido sus políticas de privacidad: Safari lanzó ITP, Firefox introdujo Total Cookie Protection y Chrome avanzó oficialmente con la congelación del User-Agent (UA Reduction). Aun hoy, muchas personas creen que basta con “cambiar el UA” para hacer pasar un dispositivo por otro, sin darse cuenta de que el UA ya se ha simplificado considerablemente y está perdiendo información detallada. La señal que está tomando su relevo en la identificación de dispositivos es Client Hints (CH).

Este artículo no enseña ninguna técnica para “eludir la detección”. Solo explica los principios técnicos detrás de tres preguntas: ¿por qué se congela el UA?, ¿qué es exactamente Client Hints y por qué se considera una señal de huella de alta entropía?, ¿por qué la llamada “coherencia de la huella” es lo realmente importante? Entender estos puntos ayuda a comprender por qué la gestión moderna de entornos de navegador, especialmente al aislar varias cuentas, debe tratar todos los parámetros como un conjunto coherente y no como campos independientes.

1. ¿Por qué la cadena UA ya no es suficiente?

Durante mucho tiempo, User-Agent fue el principal dato que los sitios web utilizaban para identificar navegadores y dispositivos. Revelaba información como la marca y versión del navegador, el sistema operativo y la arquitectura del dispositivo. Sin embargo, las cadenas UA eran demasiado largas y estables, lo que las hacía útiles para crear huellas de usuarios. Por eso Chrome anunció de forma explícita la reducción gradual del UA: conservar solo la información básica, como la versión principal, y trasladar más detalles a un nuevo mecanismo, Client Hints.

La consecuencia directa de congelar el UA es que falsificar únicamente el UA ya no resulta convincente. Los sistemas no confían solo en ese valor; también comprueban si otros campos son coherentes con él. Las señales de incoherencia más evidentes son parámetros contradictorios, por ejemplo:

• El UA indica macOS 14, pero el campo de versión de plataforma muestra macOS 13;
• El UA declara un dispositivo móvil, pero el indicador móvil sigue siendo ?0;
• La arquitectura de hardware aparece como arm64, mientras que valores como navigator.hardwareConcurrency parecen propios de x86.

En los sistemas de identificación de dispositivos, contradicciones como estas pueden indicar rápidamente que el perfil no corresponde a un dispositivo real. Por eso “cambiar solo el UA” ha dejado de ser suficiente en la era de la congelación del User-Agent.

2. ¿Qué es Client Hints y por qué se considera una huella de alta entropía?

Client Hints (CH) es un conjunto de datos sobre las capacidades del dispositivo que el navegador puede revelar al servidor bajo demanda mediante solicitudes HTTP o el entorno JavaScript. Se diferencia del UA principalmente en dos aspectos:

1. Incluye campos de alta entropía (High Entropy Values). “Alta entropía” significa que la combinación de esos datos puede ser muy distintiva y difícil de adivinar, por ejemplo una versión exacta de la plataforma, una lista completa de marcas y versiones o la arquitectura del dispositivo. Los navegadores reales devuelven estos valores cuando se solicitan, en lugar de exponerlos todos de una sola vez.

2. CH no se evalúa por separado, sino junto con otras huellas. Los sistemas reales de identificación suelen comprobar si CH coincide con el UA, si CH y las huellas de la capa de transporte —como TLS JA3/JA4— corresponden al mismo tipo de navegador, si CH es coherente con propiedades JavaScript como navigator.platform, la concurrencia y la relación de píxeles del dispositivo (DPR), y si coincide con las características de la plataforma del sistema operativo.

Esto lleva a una idea fundamental: lo difícil no es modificar un campo aislado, sino conseguir que todos parezcan proceder del mismo dispositivo real. Casi cualquier campo puede alterarse individualmente. El reto es lograr que marca, versión de plataforma, UA, DPR, memoria, arquitectura, huella TLS y otras señales formen un perfil de dispositivo coherente. Por eso muchas configuraciones que aparentemente “rellenan todos los campos” siguen resultando fáciles de detectar por sus contradicciones.

3. ¿Cuáles son los errores de coherencia más habituales?

Una vez que se entiende que la coherencia es la clave, resulta fácil ver por qué fallan muchas configuraciones de parámetros. Entre los errores más comunes están:

• CH no coincide con el UA (el más habitual): el UA indica macOS 14.1, pero CH devuelve una versión de plataforma que no existe realmente;
• UA móvil con indicador móvil ?0: en un dispositivo móvil real normalmente debería ser ?1;
• Derivación incorrecta de la lista de versiones completas: por ejemplo, la versión principal del navegador es 120, pero las características de versión completa parecen corresponder a una antigua 115;
• DPR, memoria u otros valores contradicen el tipo de dispositivo real: por ejemplo, un dispositivo Apple muestra una relación de píxeles anormalmente baja o un equipo Windows común informa de solo 1 GB de memoria;
• Se ignoran las diferencias entre navegadores: por ejemplo, se fuerza un campo en un navegador que no lo admite o se devuelve un dato que un determinado motor nunca expondría.

Estas incoherencias destacan claramente en los sistemas de identificación de dispositivos. En esencia, todas proceden de no tratar el entorno como un conjunto coherente.

4. Entonces, ¿qué significa una “configuración correcta”?

Más que “rellenar campos”, se trata de mantener un perfil de entorno coherente. Por lo general, esto implica:

• Vincular CH con el UA: derivar el conjunto correspondiente de CH —marca, plataforma y versión— siguiendo las reglas reales del motor y la versión del navegador, en vez de combinar valores arbitrarios;
• Respetar la estrategia de devolución de campos de alta entropía: ofrecer información de baja entropía por defecto, devolver valores de alta entropía bajo demanda tal como lo haría un navegador real y no devolver campos que el navegador actual no soporta;
• Mantener coherentes las propiedades JS, los encabezados HTTP y las características del sistema: que el DPR tenga sentido con la resolución de pantalla, la memoria con el tipo de plataforma, el indicador móvil con el UA y la arquitectura con el resto del perfil del sistema;
• Coordinar también la huella de la capa de transporte: características como TLS/JA3/JA4 deben ser compatibles con la versión de navegador declarada.

En una frase: la verdadera dificultad está en hacer que CH, UA, el entorno JavaScript y las características del sistema formen un perfil coherente de comportamiento del navegador, no en acumular el mayor número posible de campos.

5. ¿Qué relación tiene esto con la gestión de entornos multicuenta?

Quienes trabajan en comercio electrónico internacional, publicidad en redes sociales o tiendas independientes pueden preguntarse qué tiene que ver todo esto con “crear entornos de navegador separados para distintas cuentas comerciales”. La relación es directa: la gestión de entornos solo funciona bien si cada entorno es coherente consigo mismo.

• Cuando hay muchas cuentas y regiones, en vez de configurar manualmente UA, sistema operativo, resolución y otros parámetros en cada entorno, es más práctico dejar que la herramienta genere automáticamente un conjunto de parámetros alineados según el sistema y la versión del motor seleccionados, reduciendo contradicciones y retrabajo.
• Las cuentas comerciales de distintas regiones y plataformas deberían tener entornos independientes y coherentes internamente, en lugar de compartir todos los mismos “parámetros de plantilla” y acabar pareciéndose de forma poco natural a nivel de dispositivo.
• Al cambiar el proxy a otra región, mantener la versión del sistema, el modelo de dispositivo y otros rasgos como una configuración interna coherente del entorno se parece más al comportamiento de un dispositivo real que “cambiar solo la IP y dejar todo lo demás exactamente igual”.

Estos son precisamente los problemas de coherencia que buscan resolver las herramientas de gestión de entornos de navegador para varias cuentas. Al crear un entorno, PurpleMark ofrece una entrada de configuración unificada para sistema operativo, versión del motor Chromium, User-Agent, resolución, zona horaria, idioma, CPU/memoria, Canvas, WebGL, TLS y otros parámetros de dispositivo y huella. Tras elegir una región y el propósito de la cuenta, se puede generar el entorno siguiendo un esquema coherente, en lugar de improvisar parámetros en cada inicio de sesión. Lo que realmente se gestiona es la coherencia global y la reutilización de la cuenta, el entorno del navegador y la configuración de red dentro de un mismo espacio de trabajo, no cómo engañar a un mecanismo de detección concreto.

6. Resumen

La congelación del UA marca una nueva etapa en las huellas de navegador: ya no importa solo qué campos existen, sino si esos campos son coherentes entre sí. A medida que Client Hints toma el relevo del UA como señal de alta entropía, comprender la relación entre CH, UA, características del sistema y huellas de transporte es más importante que memorizar una larga lista de nombres de campos.

Si solo gestionas unas pocas cuentas comerciales reales y conformes con las normas, no es necesario dedicar esfuerzos a combatir sistemas de detección. Una opción más práctica es usar una herramienta de gestión de entornos como PurpleMark para mantener claros, coherentes y reutilizables la región, el sistema y los parámetros del navegador de cada cuenta, reduciendo desde el origen los problemas causados por configuraciones contradictorias.

(Nota: Este artículo se ofrece únicamente como divulgación técnica sobre las huellas de navegador. Opera siempre respetando los términos de servicio de cada plataforma y utilizando cuentas legítimas.)