Abre el panel de Red en las herramientas de desarrollo de tu navegador y casi siempre encontrarás una cabecera User-Agent. Parece una breve introducción: qué navegador está haciendo la petición, en qué sistema operativo se ejecuta y en qué versión afirma ser.
Eso hace tentador tratar el encabezado como un ID de dispositivo—o asumir que cambiar una línea puede convertir un navegador en otro dispositivo. Ambas ideas son solo parcialmente correctas.
Una cadena de User-Agent, o UA, es la información de compatibilidad declarada por el cliente. No es una credencial de identidad confiable, y un cliente puede modificarla. Sin embargo, no existe de forma aislada. Un sitio puede comparar el UA con Client Hints, APIs JavaScript, propiedades de pantalla, fuentes, Canvas, WebGL, contexto de red y comportamiento. La cuestión útil no es simplemente si un UA puede cambiarse, sino qué papel desempeña en la superficie observable completa del navegador.
Este artículo utiliza estándares de HTTP y la investigación sobre huellas dactilares en el navegador para responder a cuatro preguntas:
- ¿Por qué una cadena de UA parece una pieza de arqueología de navegador?
- ¿Cuánta información identificativa puede aportar UA y cómo deberíamos interpretar la investigación?
- ¿Por qué cambiar solo la UA puede crear una inconsistencia más evidente?
- ¿Qué cambiaron realmente UA Reduction y User-Agent Client Hints?
En este artículo, UA se refiere principalmente al encabezado de la HTTP
User-Agentsolicitud. También hablamos denavigator.userAgentynavigator.userAgentDataen JavaScript. Estas interfaces están relacionadas pero no son idénticas de forma permanente en todos los navegadores y contextos.
1. ¿Qué es un User-Agent?
Sección 10.1.5 de RFC 9110 define User-Agent como un campo que contiene información sobre el agente de usuario que originó la solicitud. Su gramática simplificada es:
User-Agent = product *( RWS ( product / comment ) )
product = token [ "/" product-version ]
En lenguaje sencillo, la cadena comienza con un nombre de producto y puede incluir una versión. Pueden seguir más productos o comentarios. El estándar reconoce usos como soluciones alternativas de interoperabilidad, diagnósticos y análisis, pero también aconseja a las implementaciones no revelar detalles innecesarios: una UA más larga y específica aumenta tanto el tamaño de la solicitud como el riesgo de huellas dactilares.
Un UA moderno de escritorio Chromium podría verse así:
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36
Dividir la cadena por espacios revela varios nombres que parecen no estar relacionados con Chrome:
| Token | Lo que generalmente significa hoy en día | Una mala interpretación común |
|---|---|---|
Mozilla/5.0 | Un token de compatibilidad histórica | El navegador debe ser Firefox o un producto Mozilla |
Windows NT 10.0 | Una categoría Windows de plataforma; un UA reducido no puede distinguir de forma fiable Windows 10 de 11 | El ordenador debe funcionar Windows 10 |
Win64; x64 | Una pista de que esto es Windows de 64 bits en una arquitectura x86-64 | Demuestra el modelo físico exacto de la CPU |
AppleWebKit/537.36 | Un linaje de motor y token de compatibilidad | Chrome sigue usando la implementación completa de Safari |
KHTML, like Gecko | Lenguaje de compatibilidad histórica | Tanto KHTML como Gecko están funcionando |
Chrome/145.0.0.0 | La familia Chrome/Chromium y la versión principal; Los componentes de versiones inferiores pueden reducirse | Revela la versión precisa del parche |
Safari/537.36 | Un token retenido para compatibilidad con sitios antiguos | El navegador debe ser Safari |
El UA se volvió extenso porque los primeros sitios web a menudo se ramificaban en nombres de navegadores. Los navegadores nuevos tenían que declarar compatibilidad con productos antiguos para recibir la página correcta. Estas declaraciones se acumularon con el tiempo, creando un registro histórico que no puede leerse literalmente.
Por tanto, la primera regla del análisis sintáctico UA es sencilla: es un protocolo de compatibilidad, no una descripción estricta del dispositivo.
2. ¿Por qué siguen usando UA sitios web?
UA no se usa solo para rastrear. Los usos legítimos incluyen:
- sirviendo como recurso a un navegador antiguo con un problema de compatibilidad conocido;
- seleccionar un formato de instalación o descarga adecuado;
- encontrar fallos específicos de la versión en los registros de diagnóstico;
- medir distribuciones amplias de familias de navegadores, plataformas y versiones mayores;
- identificar combinaciones imposibles en tráfico automatizado o malicioso.
El problema comienza cuando UA olfateo pasa de una opción de compatibilidad limitada a adivinar por nombre de producto. El código puede ver Chrome y asumir que existe una API concreta. Esa suposición puede fallar en un WebView embebido, un navegador derivado de Chromium, un navegador con una política empresarial, un UA congelado o un cliente que haya cambiado su cabecera.
Un orden de operaciones más robusto es:
- Prueba directamente la API o el comportamiento requerido siempre que sea posible detectar capacidades.
- Cuando la identificación del navegador es inevitable, utiliza un analizador mantenido en lugar de una expresión regular ad hoc.
- Guarda solo las categorías groseras que el producto realmente necesita.
- Proporciona un respaldo para marcas desconocidas, versiones desconocidas y campos perdidos.
3. ¿Es UA una huella dactilar del navegador?
Más concretamente, UA es una sola entrada a una huella digital del navegador, no suele ser la huella dactilar completa.
La identificación digital del navegador no requiere un número de serie secreto. Mide una colección de atributos relativamente estables y distintivos expuestos por el navegador. UA aporta pistas sobre la familia, versión y plataforma de navegadores. Las dimensiones de pantalla, fuentes, zona horaria, Canvas, WebGL, AudioContext y otras interfaces aportan más información.
La encuesta realizada por Laperdrix y sus colegas, Browser Fingerprinting: A Survey, analiza estas técnicas como una forma de reconocimiento sin estado. Un sitio no tiene por qué escribir un Cookie primero; Puede intentar asociar visitas a los atributos que expone un navegador. "Sin estado" no significa que el servidor no almacene nada. Significa que el material de reconocimiento no depende de un identificador persistente en el lado del cliente.
1. ¿Qué significa el resultado de 10 bits del artículo?
En el estudio de Panopticlick de 2010 How Unique Is Your Web Browser?, Peter Eckersley analizó aproximadamente 470.000 huellas dactilares de navegadores. El periódico informó que:
- la huella dactilar completa contenía una media de unos 18,1 bits de información identificativa en esa muestra;
- Dicho de forma intuitiva, una huella digital promedio ocurrió aproximadamente una vez en 286.777 navegadores;
- La tabla informaba de unos 10,0 bits de información media solo para la cadena de UA;
- entre los navegadores con Flash o Java habilitado, el 94,2% de las huellas dactilares completas eran únicas.
La autoinformación se escribe comúnmente como:
I(x) = -log₂ P(x)
Si un UA particular ocurre con probabilidad 1/1024 en una población, observarlo proporciona 10 bits de información. Esto no significa que UA tenga exactamente 1.024 valores posibles ni que identifique de forma única a una persona. Describe cuánta incertidumbre elimina esa observación de media.
2. ¿Por qué el resultado de 2010 no es constante en la web actual?
El resultado sigue siendo importante, pero necesita al menos tres matices:
- Los visitantes de una página de pruebas de privacidad no eran una muestra aleatoria de todos los usuarios de Internet;
- La diversidad de navegadores, plugins y versiones UA en 2010 difería mucho del ecosistema actual;
- UA Reduction, la reducción de superficies de plugins y las protecciones anti-huellas han cambiado la distribución de atributos observables.
El estudio respalda la afirmación de que UA y otros atributos pueden aportar información distintiva medible. No apoya que un UA siempre tenga exactamente 10 bits de entropía hoy en día. La potencia de huella dactilar depende de la población, la ventana temporal, las políticas del navegador y la combinación de señales.
4. ¿Por qué cambiar solo UA puede salir mal?
UA es una declaración del cliente sin prueba criptográfica. Un servidor no puede leer la verdad de fábrica de un dispositivo desde esta cabecera. Sin embargo, puede comprobar si diferentes observaciones son razonablemente compatibles.
Supongamos que un UA afirma ser un navegador móvil, pero la página no observa puntos de contacto, una ventana que se asemeja constantemente a una pantalla de escritorio y Client Hints que informan de una plataforma de escritorio. Cualquier observación puede tener una excepción legítima. Varias contradicciones estables juntas aún pueden formar un patrón clasificable.
El artículo Panopticlick ya documentaba casos comparables: algunos navegadores afirmaban ser un iPhone mientras soportaban Flash, y algunos Firefox UA aparecían junto con funciones de almacenamiento disponibles solo en Internet Explorer. El estudio de la FP-Scanner de 2018 examinó este problema de forma sistemática. Algunas extensiones anti-huellas digitales y herramientas de suplantación introdujeron inconsistencias entre interfaces, permitiendo a un detector identificar atributos modificados y, en algunos casos, inferir el navegador original o la familia de sistemas operativos.
No todas las inconsistencias son maliciosas. Los escritorios remotos, las herramientas de accesibilidad, las políticas empresariales, las capas de compatibilidad y el hardware poco común pueden crear combinaciones inusuales. Un sistema de riesgos cuidadoso debería tratar una inconsistencia como evidencia probabilística, no como una razón automática para bloquear a un usuario.
Para la gestión de perfiles de navegador, tres propiedades importan:
- Consistencia interna: UA, Client Hints, plataforma, arquitectura, táctiles y señales de pantalla no deben contradecirse directamente.
- Estabilidad a lo largo del tiempo: un perfil de larga duración no debería cambiar drásticamente en cada lanzamiento sin una razón.
- Diversidad plausible: los perfiles pueden variar, pero las combinaciones raras generadas mecánicamente no son necesariamente más seguras.
El estudio FP-STALKER también mostró que cambiar atributos no previene automáticamente el enlace. Un modelo puede usar atributos estables y cambios plausibles de versión para conectar huellas dactilares anteriores y posteriores.
5. ¿Qué problema aborda UA Reduction?
Un UA tradicional se envía con casi todas las solicitudes. Cualquier endpoint de primera o tercera parte que reciba la solicitud puede leerla de forma pasiva. Cuanto más precisa es la cadena, más información distintiva obtiene cada destinatario por defecto.
El plan User-Agent Reduction de Chromium reduce esta granularidad por defecto:
- A partir de Chrome 101, las versiones menores, de compilación y de parche para escritorio se redujeron a
0.0.0; - fases posteriores versiones unificadas del sistema operativo de escritorio, detalles de la CPU y Android información de dispositivos;
- Un Android UA reducido utiliza valores fijos de plataforma y modelo como
Android 10; K; - Los sitios que realmente requieran más detalles pueden solicitar User-Agent Client Hints.
El formato reducido puede resumirse como:
Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36
La reducción disminuye la superficie pasiva de huella dactilar del UA heredado. No elimina la huella digital del navegador. La versión principal, la plataforma general y el estado móvil pueden seguir siendo visibles, mientras que otras APIs, propiedades de red y comportamientos aún pueden proporcionar información.
6. ¿Cómo funcionan User-Agent Client Hints
El mecanismo general se define en RFC 8942, mientras que el WICG User-Agent Client Hints borrador describe campos específicos de UA. El enfoque divide la información que antes existía en una cadena no estructurada en campos estructurados, distinguiendo las pistas de baja entropía que pueden enviarse por defecto de las pistas de alta entropía que un sitio normalmente solicita explícitamente.
Una solicitud inicial simplificada puede ser así:
GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Si el servidor realmente necesita arquitectura y bitness para seleccionar un instalador, puede responder con:
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Cuando el navegador soporta el mecanismo y se cumplen los requisitos de seguridad y políticas, una solicitud posterior puede incluir:
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"
Las UA Client Hints más comunes incluyen:
| Campo | Propósito típico | Nivel de información |
|---|---|---|
Sec-CH-UA | Lista de marcas y versiones principales | Normalmente baja entropía |
Sec-CH-UA-Mobile | Si el cliente prefiere una experiencia móvil | Normalmente baja entropía |
Sec-CH-UA-Platform | Categoría amplia de plataformas | Normalmente baja entropía |
Sec-CH-UA-Arch | Arquitectura de CPU | Alta entropía; solicitud cuando sea necesario |
Sec-CH-UA-Bitness | Bitness de arquitectura | Alta entropía; solicitud cuando sea necesario |
Sec-CH-UA-Platform-Version | Versión de la plataforma | Alta entropía; solicitud cuando sea necesario |
Sec-CH-UA-Full-Version-List | Versiones completas para las marcas reportadas | Alta entropía; solicitud cuando sea necesario |
Sec-CH-UA-Model | Modelo del dispositivo | Alta entropía; solicitud cuando sea necesario |
Tres detalles de ingeniería son fáciles de pasar por alto.
1. Client Hints no se envían todas automáticamente
Las pistas de baja entropía pueden aparecer por defecto. Las pistas de alta entropía suelen requerir una respuesta Accept-CH. La navegación inicial, los subrecursos, la política de permisos, el transporte seguro y el soporte del navegador pueden afectar a lo que llega. Un servidor debe permitir que todos los campos opcionales estén ausentes.
2. La lista de marcas prueba deliberadamente la robustez del analizador
Sec-CH-UA puede contener varias marcas y una marca sintética utilizada para probar la compatibilidad. El código no debe asumir que la primera entrada es siempre el nombre del producto, ni debe fallar cuando aparece una marca desconocida. Analiza el campo estructurado, ignora las entradas que no reconozcas y deja espacio para futuras marcas.
3. Las respuestas que varían en las pistas requieren un manejo correcto de la caché
Si la arquitectura, plataforma u otra pista cambia la respuesta, configura correctamente Vary o una estrategia de clave de caché equivalente. De lo contrario, una caché compartida puede servir contenido generado para una clase de dispositivo a otra.
7. ¿Son Client Hints más privadas que las UA tradicionales?
Mejoran la forma en que se expone la información, pero no proporcionan inmunidad frente a la toma de huellas dactilares.
La UA tradicional revela un gran paquete no estructurado de forma pasiva y por defecto. Client Hints divide ese conjunto en campos, hacen que las solicitudes de información con mayor entropía sean más explícitas y dan al navegador la oportunidad de aplicar controles de políticas, permisos o presupuesto de privacidad.
Sin embargo, la arquitectura, las versiones completas, las versiones de plataforma y los modelos de dispositivos aún pueden aumentar la diferenciabilidad. RFC 8942 trata explícitamente la privacidad y el rendimiento como restricciones de diseño. Los desarrolladores deberían preguntarse:
- ¿Esta función realmente requiere el campo?
- ¿Puede la detección de capacidades o una elección del usuario reemplazarla?
- ¿Puede la aplicación almacenar solo una categoría gruesa?
- ¿Cuánto tiempo se conservan los valores brutos y quién puede acceder a ellos?
- ¿Recibirán los recursos externos las mismas pistas?
8. Guía de ingeniería para el manejo de UA en el lado del servidor
1. Nunca usar UA como prueba de identidad o autoridad
UA puede soportar opciones de presentación y soluciones de compatibilidad. No debe determinar identidad, autorización, fideicomiso de pago ni un límite de seguridad. Un valor controlado por el cliente no puede servir como credencial de control de acceso.
2. Prefiere la detección de capacidades a las listas de navegador
Cuando una interfaz necesita una API, prueba esa capacidad directamente:
if ('share' in navigator) {
// Offer the system share feature.
} else {
// Fall back to copying a link.
}
La detección de capacidades gestiona mejor los navegadores derivados, las funciones experimentales, las políticas empresariales y futuras versiones que una regla como "habilitar esto para Chrome 145".
3. Aceptar UA, Client Hints y estados desconocidos heredados
Durante la migración, un servidor puede recibir solo el UA heredado, tanto UA como Client Hints, o formas altamente reducidas de ambos. El modelo de datos debería permitir unknown en lugar de adivinar un sistema operativo o modelo de dispositivo exacto para llenar cada campo.
4. Reducir la granularitud logarítmica
Si la analítica solo necesita escritorio frente a móvil, familia de navegadores y versión principal, no conserves las cadenas de UA brutas ni todas las pistas de alta entropía indefinidamente. La minimización de datos reduce el riesgo de privacidad y evita que una cadena de análisis trate la variación menor como una dimensión significativa.
5. Tratar las anomalías como prueba, no como veredictos
Una UA que afirma Windows mientras una API se comporta de forma diferente es, como mucho, una sola señal de riesgo. Los entornos empresariales, la virtualización, las sesiones remotas, las capas de compatibilidad y las tecnologías de asistencia pueden generar anomalías legítimas. Convertir una desajustada en una decisión automática de fraude genera falsos positivos.
9. ¿Cómo deberían configurarse UA en entornos de múltiples perfiles?
Para pruebas interregionales, avances publicitarios, operaciones de cuentas y aislamiento de privacidad, el objetivo no debería ser crear la UA más inusual. Un perfil debe ser explicable, estable y compatible con su entorno.
Revisa lo siguiente en orden:
- Versión del navegador: la versión UA principal debería ser plausible para el motor real y sus capacidades.
- Sistema operativo: La plataforma UA, la plataforma Client Hints y la categoría de plataforma JavaScript-visible deberían ser compatibles.
- Arquitectura y bitness: UA, Client Hints y el entorno ejecutable no deben hacer afirmaciones directamente contradictorias.
- Factor de forma del dispositivo: una declaración móvil debería tener sentido junto con soporte táctil, viewport, proporción de píxeles y patrones de interacción.
- Contexto regional: idioma, zona horaria, geolocalización y salida del proxy no tienen que coincidir mecánicamente, pero deberían tener sentido para el flujo de trabajo real.
- Estabilidad del perfil: Cuando una cuenta o identidad de prueba reutiliza un perfil de larga duración, evita cambiar de plataforma y versión principal sin una razón.
La conversión actual de perfil de PurpleMark mapea el sistema operativo seleccionado a una plataforma UA y primero intenta extraer la versión del navegador de un token de Chrome/ o CriOS/ configurado. Cuando no existe una versión utilizable, obtiene un respaldo razonable respecto a la versión principal del motor actual. El propósito no es falsificar una cadena aislada, sino colocar UA configuración dentro de un modelo de perfil de navegador consistente.
El aislamiento de perfiles y la consistencia de parámetros pueden reducir la correlación técnica y el sesgo de prueba. No pueden garantizar que las cuentas nunca se vinculen, y no sustituyen las normas de la plataforma, los datos de cuenta, la información de pagos ni las prácticas operativas responsables. Utiliza estas capacidades únicamente para la protección legal de la privacidad, pruebas autorizadas y actividad empresarial conforme a la normativa.
10. Preguntas frecuentes
P1: ¿Cambiar UA convierte el navegador en otro usuario?
No. Cambia parte de lo que declara el cliente. No reemplaza el motor de JavaScript, la tubería de renderizado, la pila de red ni las APIs web compatibles.
P2: ¿Puede una web leer el "UA real"?
No existe una "UA real" universal a nivel de hardware que cualquier sitio web pueda saltarse el navegador para leer. Sin embargo, un sitio puede comparar Client Hints, pruebas de capacidad y otras señales de huellas, encontrar afirmaciones incompatibles y hacer una inferencia probabilística.
P3: ¿Puede un UA reducido distinguir Windows 10 de Windows 11?
La reducción de UA heredada normalmente no puede hacerlo de forma fiable porque ambos pueden informar Windows NT 10.0. Un navegador que soporte UA Client Hints puede proporcionar información más detallada sobre la versión de la plataforma después de que un sitio la solicite. Los servidores deben seguir gestionando campos ausentes y diferencias de mapeo.
P4: ¿Desactivar JavaScript detiene UA exposición?
No del todo. El HTTP User-Agent es un encabezado de solicitud y puede enviarse junto con la solicitud de página antes de que se ejecute la página JavaScript. Desactivar JavaScript elimina algunas superficies de recogida, pero también rompe partes sustanciales de la web moderna.
P5: ¿Client Hints reemplazará completamente User-Agent?
No lo asumas a corto plazo. Muchos clientes y servidores siguen dependiendo del UA heredado, aunque UA Client Hints soporte varía. Trata Client Hints como mejora progresiva: prefiere información estructurada cuando esté disponible, pero conserva alternativas para UA heredados y estados desconocidos.
P6: ¿Mejora el anonimato un UA generado aleatoriamente?
No necesariamente. Aleatorizar un campo puede crear contradicciones con la versión, la plataforma, el tacto y las señales de renderizado. Para un perfil de larga duración, una configuración común, estable y compatible internamente suele ser más defendible que los cambios aleatorios frecuentes.
11. Conclusión
User-Agent no es ni una credencial de identidad fiable ni una cadena irrelevante. Se sitúa en la intersección de la compatibilidad web, la privacidad y el análisis de riesgos. Para los desarrolladores, es una entrada de compatibilidad cargada por la historia. Para los investigadores en huellas dactilares, es un atributo con información estadística medible. Para los fabricantes de navegadores, es una superficie de exposición predeterminada que debe reducirse.
Las ideas clave encajan en tres afirmaciones:
- No leas un UA literalmente; Contiene muchos tokens históricos de compatibilidad.
- No evalúes UA de forma aislada; El reconocimiento práctico proviene de combinaciones de señales y su evolución a lo largo del tiempo.
- No pienses en Client Hints simplemente como "campos más UA"; su valor reside en una divulgación estructurada, basada en peticiones y gobernable.
Cuando un sistema pasa de identificar el nombre de un navegador a probar la capacidad que necesita—y de recopilar todos los detalles disponibles a solicitar solo lo necesario—UA vuelve a su papel adecuado: una pista de compatibilidad, no una verdad de identidad.
Referencias y estándares
- Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
- Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
- IETF. RFC 9110: HTTP Semantics, 2022.
- IETF. RFC 8942: HTTP Client Hints, 2021.
- WICG. User-Agent Client Hints, Draft Community Group Report.
- Chromium. User-Agent Reduction.
- Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.