La migración a User-Agent Client Hints: medir dispositivos sin la cadena UA completa
Chrome está reduciendo la cadena User-Agent a un caparazón congelado. Así lee una analítica centrada en la privacidad las señales de dispositivo mediante Client Hints, sin fingerprinting.
La lenta muerte de la cadena User-Agent
Durante décadas, la cabecera de petición User-Agent fue el caballo de batalla de la analítica para responder preguntas básicas: ¿qué navegador, qué sistema operativo, móvil o escritorio? También era un pasivo en materia de fingerprinting. Una cadena UA completa como Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xxx.0.0.0 Safari/537.36 filtra números de versión precisos y detalles de plataforma que, combinados con otras señales, ayudan a identificar a visitantes concretos.
La iniciativa de Reducción del User-Agent de Google lleva años recortando esta cadena. Chrome envía ahora una UA reducida, en la que la versión de plataforma queda congelada y los segmentos de versión menor se ponen a cero. La intención, según la documentación de Chrome, es eliminar entropía disponible de forma pasiva y preservar a la vez un sustituto estructurado y opt-in: los User-Agent Client Hints (UA-CH).
Para quien construye analítica en 2026, la consecuencia práctica es clara. Parsear la cadena UA heredada para obtener algo más que la familia aproximada del navegador es cada vez menos fiable — y cada vez más el enfoque equivocado.
Cómo funcionan realmente los Client Hints
UA-CH divide la información del dispositivo en hints discretos y solicitables, en lugar de una única cadena densa. Los hints de baja entropía se envían por defecto en cada petición:
Sec-CH-UA— lista de marca y versión significativaSec-CH-UA-Mobile— un booleano?0/?1Sec-CH-UA-Platform— por ejemplo,"macOS"
Los hints de alta entropía — versión completa de plataforma, arquitectura, modelo, bitness — no se envían a menos que el servidor los pida explícitamente. El servidor los solicita con una cabecera de respuesta Accept-CH, y el navegador puede incluirlos entonces en peticiones posteriores. El prefijo Sec- significa que estas cabeceras las controla el navegador y no pueden establecerse desde scripts, lo que es una propiedad de integridad relevante.
Esta inversión importa para la privacidad. La postura por defecto es la divulgación mínima. La entropía adicional es un acto deliberado, registrado en tus propias cabeceras de respuesta, en lugar de algo recolectado en silencio de cada visitante.
La lectura centrada en la privacidad de este cambio
Monoid se mantiene deliberadamente en el lado de baja entropía de esta frontera. Nunca enviamos Accept-CH para obtener arquitectura, modelo o versión completa de plataforma, y nunca combinamos los hints que sí vemos en una firma estable del dispositivo. Eso sería fingerprinting — reconstruir un identificador a partir de características del dispositivo —, que es justamente lo que la reducción de la UA se diseñó para evitar, y lo que el artículo 5(3) de la Directiva ePrivacy y las políticas antifingerprinting de los navegadores tratan como acceso a información del equipo terminal.
Los hints de baja entropía por defecto bastan para las preguntas que la analítica debería plantearse:
- Familia y versión mayor del navegador a partir de
Sec-CH-UA, para planificar compatibilidad y soporte. - Móvil frente a no móvil a partir de
Sec-CH-UA-Mobile, para segmentar maquetación y Core Web Vitals. - Plataforma a partir de
Sec-CH-UA-Platform, para desgloses por sistema operativo.
Es crucial entender que estas son dimensiones agregadas, no claves por visitante. Un booleano y un nombre de plataforma compartidos por millones de visitantes no tienen, por sí solos, ningún poder identificador significativo.
Leer los hints en el edge
Como los Client Hints son cabeceras de petición corrientes, un worker de edge puede leerlos sin ningún script del lado del cliente. En Cloudflare, los hints de baja entropía llegan en el objeto Request entrante:
export default {
async fetch(request) {
const brands = request.headers.get('Sec-CH-UA') || '';
const isMobile = request.headers.get('Sec-CH-UA-Mobile') === '?1';
const platform = request.headers.get('Sec-CH-UA-Platform') || '';
// Deriva solo dimensiones gruesas; nunca persistas una clave compuesta.
return new Response('ok');
}
};
Fíjate en lo que falta: ningún eco de Accept-CH, ninguna petición de hints de alta entropía, ningún hash de los valores combinados. El valor de Sec-CH-UA es una lista estructurada, así que parséalo con cuidado — contiene entradas de marca "GREASE" intencionadas, diseñadas para frenar el parseo frágil por coincidencia exacta, una técnica que la especificación toma prestada de TLS.
Qué cambiar en tu pipeline
Si tu analítica sigue aplicando expresiones regulares a la cadena UA completa, tres cosas se romperán con el tiempo. Los números de versión derivan a .0.0.0, las versiones de plataforma se congelan y la detección de móvil basada en coincidencia de subcadenas pierde fiabilidad. La ruta de migración es sencilla:
- Prioriza los hints estructurados de baja entropía sobre el parseo de la cadena UA.
- Trata la cadena UA reducida como un respaldo solo para clientes antiguos.
- Resiste la tentación de pedir hints de alta entropía "por si acaso": cada hint adicional amplía tu superficie de fingerprinting y tu exposición en cumplimiento normativo.
La lección de fondo es coherente con todo lo que construimos. Los fabricantes de navegadores están eliminando de forma sostenida la entropía pasiva de la plataforma web. La respuesta correcta no es perseguirla a través de nuevas APIs, sino diseñar una medición que nunca la necesitó.
Comments
Loading comments…