Prepárate para el fin de las cookies de terceros en Chrome. Prueba tu sitio hoy mismo para detectar fallas.

Se usó la API de Cloud Translation para traducir esta página.

Creación de huellas digitales

La huella digital significa tratar de identificar a un usuario cuando regresa a tu sitio web, o bien identificar al mismo usuario en diferentes sitios web. Muchas características pueden diferir entre tu configuración y la de otra persona. Por ejemplo, es posible que estés usando un tipo de dispositivo diferente y un navegador diferente, un tamaño de pantalla diferente y fuentes instaladas diferentes. Si tengo la fuente "Dejavu Sans" instalada y tú no, cualquier sitio web puede marcar la diferencia entre tú y yo al buscar esa fuente. Así es como funciona la huella digital: creas una colección de estos datos y cada uno proporciona más formas de distinguir entre los usuarios.

Una definición más formal podría ser la siguiente: la creación de huellas digitales es la acción de usar características obvias y no evidentes de larga duración de la configuración de un usuario para intentar distinguirlo de tantos otros usuarios como sea posible.

Por qué la creación de huellas digitales obstaculiza la privacidad del usuario

Hay algunos casos extremos en los que la creación de huellas digitales de un usuario es importante, por ejemplo, la detección de fraudes. Sin embargo, la creación de huellas digitales también se puede usar para hacer un seguimiento de los usuarios en todos los sitios, y ese seguimiento suele realizarse sin su consentimiento o, en algunos casos, basándose en un consentimiento no válido que no informa adecuadamente al usuario. Una vez hecho esto, a esos usuarios les resultará algo inquietante y se sentirán traicionados.

La creación de huellas digitales significa encontrar formas de distinguir en forma oculta un usuario de otro. La huella digital se puede utilizar para reconocer que sigue siendo el mismo usuario en el mismo sitio web o para reconocer al mismo usuario en dos perfiles de navegador diferentes al mismo tiempo. Esto significa que la creación de huellas digitales se puede utilizar para hacer un seguimiento de los usuarios en todos los sitios. Los usuarios pueden observar y controlar, en cierta medida, los métodos de seguimiento deterministas y evidentes, como almacenar una cookie con un ID específico de usuario único (y, en el módulo anterior, se explicaron algunos de estos enfoques). Sin embargo, es más difícil evitar la creación de huellas digitales exactamente porque es encubierta: depende de características inmutables y, lo más probable, sucede de forma invisible. Por eso se llama "huella digital". Es difícil cambiar tu huella dactilar, ya sea la digital o las que están en los extremos de los dedos.

Los proveedores de navegadores saben que a los usuarios no les gusta que se les haga un seguimiento y que implementan continuamente funciones para limitar la creación de huellas digitales (algunas de las cuales ya vimos en el módulo anterior). Aquí analizamos cómo estas funciones pueden afectar a los requisitos de tu empresa y cómo seguir haciendo lo que deseas de una manera que proteja la privacidad. Se trata más de cómo la protección del navegador contra la creación de huellas digitales afectará a lo que haces y cómo lo harás, en lugar de cómo dejará de realizar la creación de huellas digitales.

En la práctica, la mayoría de los desarrolladores y de las empresas no necesitan usar sus huellas digitales. Si tu app requiere que los usuarios accedan, significa que se identifican ante ti, con su consentimiento y de manera que pueden inhabilitar la opción de forma unilateral en cualquier momento que deseen. Este es un método que protege la privacidad para comprender qué usuarios accedieron. Es posible que tu app no requiera que los usuarios accedan, lo que protege aún más su privacidad (y, por lo tanto, recopilas solo los datos que necesitas).

Sí

Evalúa los terceros para detectar la creación de huellas digitales. Como parte del módulo de terceros, es posible que ya tengas una lista de los servicios de terceros que incluyas y las solicitudes web que realicen. Es posible inspeccionar esas solicitudes para ver qué datos se devuelven al creador, si corresponde. Sin embargo, esto suele ser difícil, ya que la huella digital es, por naturaleza, un proceso encubierto que implica la solicitud de datos que no están sujetos a la aprobación del usuario.

También vale la pena leer las políticas de privacidad de los servicios y las dependencias de terceros para buscar indicaciones de creación de huellas digitales en uso. A veces, se lo denomina "coincidencia probabilística", o como parte de un conjunto de técnicas de coincidencia probabilística, en lugar de "coincidencia determinística".

Cómo funciona la creación de huellas digitales

Por lo general, tu combinación personal de todos estos atributos es exclusiva de ti o, al menos, de un pequeño grupo de personas similares; esto se puede usar para hacer un seguimiento encubierto de ti.

Apartado: Creación de huellas digitales pasiva y activa

Aquí se debe dibujar una distinción útil entre las técnicas de creación de huellas digitales pasivas y activas. Una técnica de creación de huellas digitales pasiva es aquella que usa información que se proporciona al sitio web de forma predeterminada. Una técnica activa de huella digital es una que interroga de forma explícita al navegador para obtener información adicional. Esta distinción es importante porque los navegadores pueden intentar detectar, interceptar o mitigar las técnicas activas. Las APIs se pueden restringir, o bien usar una puerta de enlace detrás de un diálogo en el que se solicita el permiso del usuario (y, por lo tanto, se le puede alertar que se están usando o se le permite denegar la operación de forma predeterminada). Una técnica pasiva es aquella que usa datos que ya se proporcionaron al sitio web, a menudo porque, históricamente, en los días incipientes de la supercarretera de la información, esa información se proporcionaba a todos los sitios. La cadena de usuario-agente es un ejemplo de esto, y lo veremos en detalle más adelante. Se consideró útil para proporcionar una gran cantidad de información sobre el navegador, la versión y el sistema operativo del usuario a fin de que un sitio web pudiera elegir presentar diferentes elementos en función de ello. Sin embargo, esto también aumenta la cantidad de información distintiva disponible, que ayuda a identificar a un usuario de otro. Por lo tanto, esa información ya no está disponible cada vez más o, al menos, queda bloqueada, de modo que ya no se distingue. Si lo que haces se basa en esta información (por ejemplo, si tomas diferentes ramas de código según el usuario-agente), es posible que este código falle, ya que los navegadores congelan o detienen esa información cada vez más. En este caso, las pruebas son la mejor defensa ( ver más tarde).

Información adicional: medición de la huella digital

La medida técnica que determina la cantidad de información que proporciona cada uno de estos datos se denomina entropía y se mide en bits. Una función en la que existen muchos valores posibles diferentes (como la lista de fuentes instaladas) puede contribuir con muchos bits al total, por lo que algo sin mucha potencia distintiva (como el sistema operativo que usas) solo puede agregar unos pocos. En el archivo HTTP, se describe cómo las bibliotecas de creación de huellas digitales existentes automatizan este proceso de combinar las respuestas de muchas APIs diferentes en un “hash”, que puede identificar solo un pequeño grupo de usuarios, tal vez solo uno. Maud Nalpas cubre esto con cierto detalle en este video de YouTube, pero, en resumen, imagina que verías una lista de tus amigos con su música favorita, su comida favorita y los idiomas que hablan... pero sin el nombre. Es muy probable que una lista de una persona los identifique de manera inequívoca entre tus amigos o, al menos, reduzca la lista a solo unas pocas personas. Así es como funciona la creación de huellas digitales: la lista de cosas que te gustan se convierte en el "hash". Con ese hash, es más fácil identificar a un usuario como la misma persona en dos sitios desconectados diferentes, que es el objetivo del seguimiento: eludir el deseo del usuario de privacidad.

¿Qué hacen los navegadores contra la creación de huellas digitales?

Es importante destacar que los proveedores de navegadores conocen muchas maneras en las que un sitio web (o un tercero incluido en un sitio web) puede calcular la huella digital distintiva de un usuario, o bien utilizar bits de información diferentes para contribuir a que esa huella digital sea única. Algunas de estas formas son explícitas e intencionadas, como la string usuario-agente del navegador, que a menudo identifica el navegador, el sistema operativo y la versión en uso (y ayuda a distinguirte de mí si tú y yo usamos navegadores diferentes). Algunas de las formas no se crean de forma deliberada para que se puedan crear huellas digitales, pero sí lo son, como la lista de fuentes o los dispositivos de audio y video disponibles para el navegador. No es necesario que el navegador use estos dispositivos. Solo debes obtener una lista por su nombre. y algunos se establecieron para contribuir a una huella digital mucho después del lanzamiento, como la renderización exacta de píxeles del suavizado de contorno de fuentes en un elemento de lienzo. Hay muchas más, y cada una de las diferencias entre tu navegador y el mío agrega entropía y, por lo tanto, contribuye a una forma de diferenciar entre tú y yo e identificar a una persona de la manera más única posible en los sitios web. https://amiunique.org tiene una lista larga (pero definitivamente no exhaustiva) de funciones que pueden generar huellas digitales, y la lista aumenta el interés de los usuarios (si no hay mucho interés monetario).

La falta de compatibilidad con ciertas APIs potentes

La respuesta de los proveedores de navegadores a todos estos enfoques para calcular la huella digital de un usuario es encontrar formas de reducir la cantidad de entropía disponible de estas APIs. La opción más restrictiva es no implementarlas. Esto lo hicieron algunos de los principales navegadores para una variedad de APIs de hardware y dispositivos (como el acceso NFC y Bluetooth desde las apps web del cliente). Los motivos por los que no se implementaron las inquietudes sobre la privacidad y la creación de huellas digitales se han citado. Obviamente, esto puede afectar a tus apps y servicios: no puedes usar una API en un navegador que no la implemente y puede restringir o impedir por completo algunos enfoques de hardware.

La puerta de enlace de permisos del usuario

Un segundo enfoque que adoptan los proveedores de navegadores es impedir el acceso a la API o a los datos sin algún tipo de permiso explícito del usuario. Este enfoque también se suele adoptar por motivos de seguridad: los sitios web no deberían poder tomar fotos con tu cámara web sin tu permiso. Pero aquí, la privacidad y la seguridad pueden tener intereses similares. Identificar la ubicación de una persona es un incumplimiento de la privacidad, por supuesto, pero también contribuye a la unicidad de una huella dactilar. Requerir permiso para ver la ubicación geográfica no disminuye la entropía adicional que una ubicación agrega a la exclusividad de esa huella digital, pero básicamente elimina el uso de la ubicación geográfica para la creación de huellas digitales porque ya no se hace de forma invisible. El objetivo de la creación de huellas digitales es distinguir surrepticiamente a los usuarios entre sí. Si estás preparado para que el usuario sepa que intentas identificarlo, no necesitas técnicas de creación de huellas digitales: haz que el usuario cree una cuenta y acceda con ella.

Agregar imprevisibilidad

Un tercer enfoque adoptado en algunos casos es que los proveedores de navegadores “fuzzan” las respuestas de las APIs para hacerlas menos detalladas y, por lo tanto, menos identificativas. Esto se describió como parte del mecanismo de respuesta aleatoria en el módulo de datos como una acción que puedes realizar cuando recopilas datos de los usuarios, para evitar la recopilación involuntaria de datos que identifican la información. Los proveedores de navegadores también pueden adoptar este enfoque para los datos de API disponibles para apps web y terceros. Un ejemplo de esto son las APIs de tiempo muy precisas que se usan para medir el rendimiento de la página desde window.performance.now(). El navegador conoce estos valores con una precisión de microsegundos, pero la precisión de los valores que se muestran se reduce deliberadamente en precisión cuando se redondea al límite de 20 microsegundos más cercano para evitar su uso en la creación de huellas digitales (y también para evitar ataques de sincronización). En este caso, el objetivo es garantizar que las APIs sigan siendo útiles, pero que las respuestas sean menos identificativas: en esencia, proporcionar "inmunidad de rebaño" haciendo que tu dispositivo se parezca más al dispositivo de todos en lugar de ser algo peculiar de ti. Por este motivo, Safari presenta una versión simplificada de la configuración del sistema.

Aplicar un presupuesto de privacidad

El presupuesto de privacidad es una propuesta que sugiere que los navegadores estimen la información revelada por cada superficie de creación de huellas digitales. Todavía no se implementó en navegadores. El objetivo es permitir APIs potentes y, al mismo tiempo, preservar la privacidad del usuario. Obtén más información sobre la propuesta de presupuesto para la privacidad.

Usa un entorno de pruebas amplio

Todos estos afectarán la forma en que compiles apps y servicios. En particular, hay una amplia diversidad de respuestas y enfoques para navegadores y plataformas en esta área. Esto significa que probar tu trabajo en varios entornos diferentes es fundamental. Por supuesto, esto siempre es importante, pero puede ser razonable suponer que la renderización de HTML o CSS será constante para un motor de renderización determinado, independientemente del navegador o la plataforma en el que se encuentre ese motor (y por lo tanto, puede ser tentador probarlo en solo un navegador basado en Blink, por ejemplo). Este no es enfáticamente el caso del uso de la API precisamente porque los navegadores que comparten un motor de renderización pueden diferir drásticamente en la forma en que endurecen la superficie de la API contra la creación de huellas digitales.

Sí

Revisa tus propias estadísticas y tu público para guiar el conjunto de navegadores que debes priorizar cuando realices pruebas.
Un buen conjunto de navegadores para probar son Firefox, Chrome, Edge, Safari en computadoras de escritorio, Chrome y Samsung Internet en Android, y Safari en iOS. Esto garantiza que realices pruebas en los tres motores de renderización principales (Gecko en Firefox, varias bifurcaciones de Blink en Chrome, Edge y Samsung Internet, y Webkit en Safari), y en las plataformas móviles y de escritorio.
Si es posible que tu sitio también se use en dispositivos menos comunes, como tablets, relojes inteligentes o consolas de juegos, haz la prueba allí. Algunas plataformas de hardware pueden retrasarse en dispositivos móviles y computadoras de escritorio en lo que respecta a las actualizaciones del navegador, lo que significa que algunas APIs pueden no estar implementadas o no estar disponibles en los navegadores de esas plataformas.
Realiza pruebas con uno o más navegadores que afirmen la privacidad del usuario como una motivación. Incluye las próximas versiones previas al lanzamiento y de prueba de los navegadores más comunes donde puedas y si están disponibles: la vista previa de la tecnología de Safari, Canary de Chrome y el canal beta de Firefox. Estas te brindan la mejor oportunidad de identificar fallas y cambios de la API que afecten a tus sitios antes de que afecten a los usuarios. Del mismo modo, ten en cuenta los entornos de los usuarios en relación con los análisis que tengas presentes. Si tu base de usuarios tiene una gran cantidad de teléfonos Android más antiguos, asegúrate de incluirlos en las pruebas. La mayoría de las personas no tienen el hardware rápido ni las versiones más recientes que los equipos de desarrollo.
Realiza pruebas con un perfil limpio y en modo incógnito o de navegación privada. Es probable que ya hayas otorgado los permisos necesarios en tu perfil personal. Prueba qué sucede si deniegas el permiso al sitio para cualquier pregunta.
Prueba de forma explícita tus páginas en el modo de protección de huellas digitales de Firefox. Si lo haces, se mostrarán diálogos de permisos si tu página intenta crear huellas digitales, o bien se mostrarán datos fuzzed para algunas APIs. Esto te ayudará a confirmar si los terceros incluidos en tu servicio usan datos que admiten huellas digitales o si tu propio servicio depende de ello. Luego, puedes considerar si el fuzzing intencional hace que sea más difícil hacer lo que necesitas. Considera hacer las correcciones correspondientes para obtener esos datos de otra fuente, hacerlo sin ellos o usar datos menos detallados.
Como se describió anteriormente en el módulo de terceros, también es importante auditar tus dependencias de terceros para ver si usan técnicas de creación de huellas digitales. La creación de huellas digitales pasiva es difícil de detectar (y imposible si un tercero lo hace en su servidor), pero el modo de creación de huellas digitales puede marcar algunas técnicas de este tipo, y buscar usos de navigator.userAgent o la creación inesperada de objetos <canvas> también puede revelar algunos enfoques que merecen una mayor atención. También vale la pena buscar los usos del término "coincidencia probabilística" en marketing o material técnico que describa a un tercero; a veces, esto puede indicar el uso de técnicas de creación de huellas digitales.

Herramientas de prueba entre navegadores

Probar tu código con fines de privacidad es difícil de automatizar, y los aspectos que debes tener en cuenta cuando se realiza una prueba manual se describen más arriba. Por ejemplo, ¿qué sucede cuando deniegas el permiso de acceso al sitio para las APIs a las que intenta acceder y cómo se presenta eso al usuario? Una prueba automatizada no puede juzgar si el sitio actúa para ayudar al usuario a confiar en él o, por el contrario, para alentar al usuario a desconfiar de él o a pensar que algo se está ocultando.

Sin embargo, una vez que se haya auditado el sitio, se podrán automatizar las pruebas de las APIs para confirmar que nada haya fallado en las versiones más recientes del navegador (o en las próximas versiones "beta" y "de vista previa") y deberían formar parte de tu paquete de pruebas existente. Algo que debes tener en cuenta con tus herramientas de prueba automatizadas cuando trabajas con la cobertura de superficie de API es que la mayoría de los navegadores permiten cierto nivel de control sobre las APIs y las funciones disponibles. Chrome lo hace mediante interruptores de línea de comandos, al igual que Firefox, y tener acceso a estos en la configuración de la herramienta de prueba te permitirá ejecutar ciertas pruebas con las APIs activadas o desactivadas. (Consulta, por ejemplo, el complemento de lanzamiento del navegador de Cypress y el parámetro launch.args de Cypress para conocer las formas de agregar marcas del navegador durante el inicio).

Solo confiar en la cadena usuario-agente para obtener información general

Tomando otro ejemplo, los navegadores han enviado desde el comienzo de la Web una descripción de sí mismos con cada solicitud en el encabezado de usuario-agente HTTP. Desde hace ya mucho tiempo, las personas piden a los desarrolladores web que no usen el contenido del encabezado del usuario-agente para entregar contenido diferente a distintos navegadores. Durante todo ese tiempo, los desarrolladores web lo han hecho de todas formas, con cierta justificación en algunos casos (pero no en todos). Dado que los navegadores no quieren que los sitios web los seleccionen para una experiencia poco satisfactoria, todos los navegadores simulan ser los demás navegadores y la cadena de usuario-agente se ve de la siguiente manera:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

Entre otras cosas, se afirma que es Mozilla/5.0, un navegador que se lanzó al mismo tiempo que los primeros astronautas embarcaron en la Estación Espacial Internacional hace más de dos décadas. Por supuesto, la cadena usuario-agente es una rica fuente de entropía para la creación de huellas digitales y, para mitigarla, los fabricantes de navegadores ya congelaron el encabezado del usuario-agente o están trabajando para hacerlo. Este es otro ejemplo de cómo cambiar los datos que proporciona una API sin quitarla por completo. Si se envía un encabezado de usuario-agente en blanco, se dañaría un sinfín de sitios web que suponen que está presente. Por lo general, lo que hacen los navegadores es quitar algunos de los detalles y mantenerlos casi sin cambios a partir de ese momento. (Puedes ver esto en Safari, Chrome y Firefox). Esta protección contra la huella digital detallada básicamente significa que ya no puedes confiar en que el encabezado del usuario-agente sea preciso y, si lo haces, es importante encontrar fuentes de datos alternativas.

Para ser claros, los datos del usuario-agente no desaparecerán por completo, pero están disponibles en un nivel de detalle menor o, a veces, son inexactos porque es posible que se informe un número antiguo, pero inmutable. Por ejemplo, Firefox, Safari y Chrome limitan el número de versión de macOS informado a diez (consulta Actualización sobre la reducción de cadenas de usuario-agente para obtener más información aquí). Los detalles exactos acerca de cómo Chrome planea reducir los datos en la cadena de usuario-agente están disponibles en Reducción de usuario-agente, pero, en resumen, puedes esperar que el número de versión del navegador informado solo contenga una versión principal (por lo que el número de versión será como 123.0.0.0, incluso si el navegador es la versión 123.10.45.108), y la versión del SO no se modificará y quedará sin cambios. Por lo tanto, una versión imaginaria de Chrome 123.45.67.89 que se ejecuta en un "Windows 20" imaginario informaría su número de versión de la siguiente manera:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

La información principal que necesitas (la versión del navegador) sigue disponible: es Chrome 123 en Windows. Sin embargo, la información de la subsidiaria (la arquitectura del chip, la versión de Windows, la versión de Safari que está imitando y la versión secundaria del navegador) ya no estará disponible después del congelamiento.

Compara esto con un usuario-agente de Chrome "actual" en una plataforma diferente:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

y lo único que difiere es el número de versión de Chrome (104) y el identificador de la plataforma.

Del mismo modo, la cadena usuario-agente de Safari muestra una plataforma y un número de versión de Safari, y también proporciona una versión del SO en iOS, pero el resto está bloqueado. Por lo tanto, una versión de Safari imaginaria 1234.5.67 que se ejecuta en un macOS 20 imaginario podría darle a su usuario-agente del siguiente modo:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

y en un iOS 20 imaginario podría ser:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

Una vez más, la información principal (que es Safari, que está en iOS o macOS) está disponible, y Safari para iOS aún proporciona un número de versión de iOS. Sin embargo, gran parte de la información complementaria que estaba disponible en el pasado se congela. Es importante destacar que esto incluye el número de versión de Safari, que no está disponible necesariamente.

Los cambios en el usuario-agente informado se analizaron con mucha atención. https://github.com/WICG/ua-client-hints#use-cases summarises resume algunos de los argumentos y las razones del cambio, y Rowan Merewood tiene una presentación de diapositivas con algunas estrategias para migrar del uso del usuario-agente para la diferenciación, en el contexto de la propuesta de UA Client Hints.

Fuzzing

Fuzzing es un término de la práctica de seguridad, en el que se llama a las APIs con valores inesperados con la esperanza de que manejen esos valores inesperados y expongan un problema de seguridad. Los desarrolladores web deben estar familiarizados con la secuencia de comandos entre sitios (XSS), que implica agregar secuencias de comandos maliciosas a una página, a menudo porque la página no escapa correctamente el código HTML insertado (por lo que puedes realizar una búsqueda con el texto <script>). Los desarrolladores back-end estarán al tanto de la inyección de SQL, en la que las consultas de la base de datos que no validan de forma correcta las entradas del usuario exponen problemas de seguridad (como lo ilustra xkcd con Little Bobby Tables). Las fuzzing, o pruebas de fuzz, se usan de manera más adecuada para intentos automatizados de proporcionar muchas entradas no válidas o inesperadas a una API y verificar los resultados en busca de filtraciones de seguridad, fallas o cualquier otro tipo de manejo. Todos estos son ejemplos de proporcionar información imprecisa de forma deliberada. Sin embargo, en este caso los navegadores lo hacen de manera preventiva (mediante una acción del usuario-agente deliberadamente incorrecto) para alentar a los desarrolladores a que dejen de basarse en esos datos.

Sí

Verifica si tu base de código depende de la cadena usuario-agente (es probable que una búsqueda de navigator.userAgent encuentre la mayoría de los casos en el código del cliente, y el código de backend buscará User-Agent como encabezado), incluidas tus dependencias.
Si encuentras usos en tu propio código, averigua qué busca el código y busca otra manera de hacer esa diferenciación (o encuentra una dependencia de reemplazo, o bien trabaja con la dependencia de manera ascendente presentando problemas o consultando para conocer las actualizaciones). En ocasiones, la diferenciación del navegador es necesaria para solucionar los errores, pero el usuario-agente no será la mejor opción una vez que se detenga.
Es posible que estés a salvo. Si solo usas los valores centrales de la marca, la versión principal y la plataforma, es muy probable que estos sigan estando disponibles y sean correctos en la cadena de usuario-agente.
MDN describe buenas maneras de evitar la dependencia de la cadena usuario-agente ("browser sniffing"), la principal de las cuales es la detección de funciones.
Si dependes de la cadena usuario-agente de alguna manera (incluso cuando usas los pocos valores principales que siguen siendo útiles), es una buena idea probar con los próximos usuarios-agentes que estarán en las nuevas versiones del navegador. Es posible realizar pruebas con esas próximas versiones del navegador por medio de compilaciones de versión preliminar de tecnología o beta, pero también es posible configurar una cadena de usuario-agente personalizada para la prueba. Cuando realizas desarrollos locales, puedes anular la cadena usuario-agente en Chrome, Edge, Firefox y Safari para verificar cómo funciona tu código con los diferentes valores de usuario-agente que podrías recibir de los usuarios.

Client Hints

Una propuesta importante para proporcionar esta información es User-Agent Client Hints, aunque no es compatible con todos los navegadores. Los navegadores compatibles pasarán tres encabezados: Sec-CH-UA, que proporciona la marca y el número de versión del navegador; Sec-CH-UA-Mobile, que indica si la solicitud proviene de un dispositivo móvil, y Sec-CH-UA-Platform, que nombra el sistema operativo. (Analizar estos encabezados es menos fácil de lo que parece porque son encabezados estructurados en lugar de cadenas simples). Esto se aplica a los navegadores que envían valores "complicados", que no se procesarán correctamente si no se analizan correctamente. Al igual que antes, este es un ejemplo de “pruebas de fuzz” que el navegador realiza de forma preventiva. Un desarrollador que usa estos datos debe manejarlos de forma adecuada, ya que están diseñados para que los análisis inadecuados o lentos probablemente arrojen malos resultados, como mostrar marcas que no existen o cadenas que no se cierran correctamente). Afortunadamente, el navegador también pone estos datos a disposición de JavaScript directamente como navigator.userAgentData, que en un navegador compatible podría verse de la siguiente manera:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}