Gracias por seguir Google I/O. Mira contenido a pedido.

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

Creación de huellas digitales

La creación de huellas digitales implica intentar identificar a un usuario cuando regresa a tu sitio web o al mismo usuario en diferentes sitios web. Muchas características pueden diferir entre tu configuración y la de otra persona. Por ejemplo, podrías usar otro tipo de dispositivo y un navegador diferente, tienen un tamaño de pantalla diferente y tienen distintas fuentes instaladas. Si tengo la fuente "Dejavu Sans" instalado y no lo tienes, cualquier sitio web puede diferenciar entre tú y yo buscando esa fuente. Así es como la creación de huellas digitales; creas una colección de estos datos y cada uno ofrece más formas de distinguir entre los usuarios.

Una definición más formal podría ser así: la creación de huellas digitales es la acción de usar datos de larga duración obvios y no evidentes características de la configuración de un usuario para intentar distinguirlo de la mayor cantidad posible de usuarios.

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

Existen algunos casos extremos en los que la creación de huellas digitales de un usuario es importante, como la detección de fraudes. Pero la creación de huellas digitales también usarse para hacer un seguimiento de los usuarios en distintos sitios y, a menudo, se realiza sin que los usuarios otorguen su consentimiento o, en algunos casos, de un consentimiento no válido que no informa adecuadamente al usuario. Cuando esté listo, es probable que los usuarios encuentren esto inquietantes y bastante traicionados.

La creación de huellas digitales significa encontrar formas de distinguir secretamente a un usuario de otro. Las huellas digitales se pueden usar para reconocer lo siguiente: sigue siendo el mismo usuario en el mismo sitio web o reconocerlo en dos perfiles de navegador diferentes al mismo tiempo. Esto significa que la creación de huellas digitales se puede usar para hacer un seguimiento de los usuarios en los sitios. Los métodos de seguimiento determinísticos y evidentes, como almacenar una cookie con un ID único específico del usuario, pueden ser observados por los usuarios y controlados (y en el módulo anterior se explicaron algunos de estos enfoques). Pero la creación de huellas digitales es más difícil evitar exactamente porque es encubierto; depende de características que no cambian y, lo más probable, es que suceda de forma invisible. Por eso se llama "huellas digitales". Es difícil cambiar tu huella dactilar, ya sea la digital o las de los extremos de tus dedos.

Los proveedores de navegadores saben que a los usuarios no les gusta que se haga un seguimiento y que implementan constantemente funciones para limitar la creación de huellas digitales. (algunas vimos en el módulo anterior). A continuación, analizamos cómo estas funciones podrían afectar a su empresa y cómo hacer lo que quieres de una manera que proteja la privacidad. Esto tiene más que ver sobre cómo la protección del navegador contra la creación de huellas digitales afectará lo que haga y cómo, en lugar de cómo evitará que la tome.

En la práctica, la mayoría de los desarrolladores y la mayoría de las empresas no necesitan identificar a los usuarios con sus huellas digitales. Si tu app requiere que los usuarios accedan, tus usuarios se identifican ante ti, con su consentimiento y de una manera en la que pueden rechazar unilateralmente los en el momento que lo deseen. Este es un método que protege la privacidad para comprender qué usuarios accedieron. Es posible que tu app no los usuarios deben acceder, lo que protege aún más la seguridad la privacidad (y, luego, recopilas solo los datos que necesitas).

Qué debes hacer

Evalúa tus terceros para la creación de huellas digitales. Como parte del módulo de terceros, posiblemente ya tenga una lista de los servicios de terceros que incluye y las solicitudes web que realizan. Es posible que sea posible para inspeccionar esas solicitudes y ver qué datos se devuelven al originador, si corresponde. Sin embargo, esto suele ser difícil. la creación de huellas digitales es, por naturaleza, un proceso encubierto que implica solicitar datos que no están sujetos a la aprobación del usuario.

También te recomendamos leer las políticas de privacidad de tus dependencias y servicios de terceros para buscar indicios de la creación de huellas digitales. en uso. A veces se lo denomina "coincidencia probabilística", o bien como parte de un conjunto de técnicas de coincidencia probabilística. a diferencia de la “coincidencia determinista”.

Cómo funciona la creación de huellas digitales

Frecuentemente, tu combinación personal de todos estos atributos es única para ti, o en al menos a un grupo pequeño de personas similares; esto se puede usar para rastrearte en secreto.

Apartado: creación de huellas digitales pasiva y activa

Es útil hacer una distinción útil entre las técnicas de creación de huellas digitales pasiva y activa. Una creación de huellas digitales pasiva una técnica que utiliza información que se proporciona al sitio web de forma predeterminada una técnica activa de creación de huellas digitales es que interroga explícitamente al navegador para obtener información adicional. Esta distinción es importante porque los navegadores puede intentar detectar e interceptar o mitigar las técnicas activas. Las APIs se pueden restringir o pasar a una puerta de enlace detrás de un diálogo solicitar el permiso del usuario (y, por lo tanto, alertarlo al usuario sobre su uso o permitir que se deniegue de forma predeterminada). Una técnica pasiva es aquella que usa datos que ya se han proporcionado al sitio web, a menudo porque, históricamente, en los primeros días de la supercarretera de información, esa información se proporcionaba a todos los sitios. La cadena usuario-agente es una de esto y lo analizaremos con más detalle. Se consideró útil para proporcionar bastante información sobre el navegador, la versión y el sistema operativo del usuario, para que un sitio web pueda presentar cosas en función de eso. 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 o, al menos, se bloquea para que ya no los distinga. Si lo que usted hace se basa en esta información, por ejemplo, si está tomando diferentes ramas de código en función del usuario-agente; entonces, este código puede fallar a medida que los navegadores inmovilizan o detienen esa información cada vez más. Las pruebas son la mejor defensa aquí ( ver más adelante).

Información adicional: Cómo medir la huella digital

La medida técnica de la cantidad de información que proporciona cada uno de estos datos se llama entropía y se mide en bits. Una función en la que hay muchos valores posibles diferentes (como la lista de fuentes instaladas) puede aportar muchos bits al total, por lo que algo sin mucha potencia distintiva (como el sistema operativo que usas) solo puede sumar algunos. En el almanac HTTP, se describe cómo la creación de huellas digitales existente las bibliotecas automatizan este proceso de combinar las respuestas de muchas APIs diferentes en un “hash”, que puede identificar solo un un pequeño grupo de usuarios, quizás solo uno. Maud Nalpas lo cubre con más detalle en este video de YouTube, pero, en resumen, imaginen que una lista de tus amigos con su música favorita, comida favorita y los idiomas que hablan, pero con sus nombres o quitarse. Es muy probable que la lista de una persona la identifique de manera inequívoca entre tus amigos o, al menos, limite en la lista y solo unas pocas personas. Así es como funciona la creación de huellas digitales. la lista de cosas que te gustan se convierte en "hash". Con ese hash, que identifica a un usuario como la misma persona en dos sitios diferentes desconectados, se vuelve más fácil, que es el objetivo de Seguimiento: para eludir el deseo de privacidad del usuario.

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

Es importante señalar que los proveedores de navegadores conocen muy bien las diversas opciones que existen para crear un sitio web (o un tercero incluido en un sitio web) para calcular una huella digital distintiva de un usuario o para diferentes bits de información que contribuyan a la unicidad. de esa huella dactilar. Algunas de estas formas son explícitas y deliberadas, como la cadena usuario-agente del navegador, que a menudo identifica el navegador, el sistema operativo y la versión en uso (lo que contribuye a distinguirte de mí, si tú y Utilizo distintos navegadores). Algunas de las formas no se crean deliberadamente para que se puedan usar las huellas digitales, pero terminan siendo tan de todos modos, como la lista de fuentes o los dispositivos de audio y video disponibles para el navegador. (El navegador no tiene que usar estos dispositivos, solo tienes que obtener una lista por nombre). Y otros se establecieron para ser colaboradores después del lanzamiento, como la renderización de píxeles exactos del suavizado de fuentes en un elemento de lienzo. Hay muchas más, y cada forma en que tu navegador se diferencia del mío agrega entropía y así, potencialmente, contribuye a un de diferenciar a una persona de la forma más única posible en los distintos sitios web. https://amiunique.org tiene una lista larga (pero definitivamente no exhaustiva) de posibles contribuciones de huellas digitales y la lista crece todo el tiempo (ya que existe un gran interés monetario en la posibilidad de identificar a los usuarios, incluso si estos no quieren o no lo esperan).

No es compatible 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 en primer lugar. Esto lo han hecho algunos navegadores importantes para una variedad de API de hardware y dispositivos (como el acceso a NFC y Bluetooth desde aplicaciones web del cliente), y se citaron inquietudes sobre la privacidad y la creación de huellas digitales como motivos por los que no se implementaron. Esto, puede afectar a tus apps y servicios: no puedes usar una API en un navegador que no la implemente, y esto puede restringir o excluir por completo algunos enfoques de hardware.

La puerta de enlace de permisos de usuario

El 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 suele usarse también por motivos de seguridad: un sitio web no debería poder tomar fotos con tu cámara web sin tu permiso. Pero, en este caso, la privacidad y la seguridad pueden tener intereses similares. Identificar la ubicación de alguien es una una infracción de la privacidad en sí, por supuesto, pero también contribuye a la singularidad de una huella digital. Solicitar permiso para ver la ubicación geográfica no disminuye la entropía adicional que una ubicación suma a la singularidad de esa huella digital, sino que 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 ocultamente a los usuarios entre sí. Si estás preparado para que el usuario sepa que intentas identificarlos, entonces no necesitas técnicas de creación de huellas digitales: haz que el usuario cree una cuenta y acceda con él.

Agregar imprevisibilidad

El tercer enfoque que se adopta en algunos casos consiste en hacer que los proveedores de navegadores realicen una "fuzzing" las respuestas de las APIs para que sean menos detalladas y, por lo tanto, menos identificativa. Esto se describió como parte del mecanismo de respuesta aleatoria en el módulo de datos como algo que puedes hacer cuando recopilas datos de los usuarios, para evitar recopilar datos de forma involuntaria. Proveedores de navegadores también pueden adoptar este enfoque con respecto a los datos de APIs que se ponen a disposición de apps web y de terceros. Un ejemplo de esto es el APIs de tiempo muy precisas que se usan para medir el rendimiento de las páginas desde window.performance.now(). El navegador reconoce estos valores con una exactitud de microsegundos, pero los valores mostrados se reducen deliberadamente en precisión al redondear a la cifra de 20 microsegundos más cercana límite para evitar su uso en la creación de huellas digitales (y también por seguridad, para evitar la sincronización de ataques, cierto que hay). El objetivo aquí es para garantizar que las APIs sigan siendo útiles, pero para que las respuestas sean menos identificativas; en esencia, para proporcionar "inmunidad de rebaño" haciendo tu dispositivo se parece más al dispositivo de los demás, en lugar de ser uno particular de ti. Safari presenta una versión simplificada de la configuración del sistema por este motivo.

Aplicar un presupuesto de privacidad

Privacy Budget es una propuesta que sugiere que los navegadores estiman 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

Todo esto afectará la forma en que compilas apps y servicios. En particular, hay una gran diversidad de respuestas y enfoques en navegadores y plataformas en esta área. Esto significa que probar tu trabajo en varios entornos diferentes es fundamental. Esto es, por supuesto, siempre importante, pero puede ser razonable suponer que la representación HTML o CSS será constante para un de un motor de renderización determinado, sin importar en qué navegador o plataforma se encuentre (por lo que puede ser tentador probarlo desde un navegador Blink). Este no es el caso para el uso de API precisamente porque los navegadores que comparten un el motor de renderización puede diferir drásticamente en la forma en que endurecen la superficie de la API contra la creación de huellas digitales.

Qué debes hacer

Revisa tus propias estadísticas y tu público para guiar el conjunto de navegadores que debes priorizar cuando realices pruebas.
Algunos navegadores adecuados 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, Samsung Internet y Webkit en Safari), y en 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, realiza la prueba allí también. Algunas plataformas de hardware pueden retrasarse con respecto a los dispositivos móviles y las computadoras de escritorio para las actualizaciones de los navegadores, lo que significa que algunas APIs pueden no estar implementadas o no disponible en los navegadores de esas plataformas.
Realiza pruebas con uno o más navegadores que reclaman la privacidad del usuario como motivador. Incluye las próximas versiones previas al lanzamiento y de prueba de los navegadores más comunes donde puede y si están disponibles: la vista previa tecnológica de Safari, Canary de Chrome y canal beta de Firefox Estos ofrecen la mejor oportunidad de identificar las fallas de la API y los cambios que afectan a tus sitios antes de que esos cambios afecten tus usuarios. Del mismo modo, ten en cuenta la y entornos de prueba en función de cualquier análisis que presente. Si el de usuarios tiene un gran número de teléfonos Android más antiguos, así que asegúrate de incluirlos en tus pruebas. La mayoría de las personas no tienen hardware rápido y las versiones más recientes que hace un equipo de desarrollo.
Realiza pruebas con un perfil limpio y en el modo incógnito o de navegación privada. lo más probable es que ya hayas otorgado los permisos requeridos en tu perfil personal. Prueba lo que sucede si deniegas el permiso al sitio por alguna pregunta.
Prueba explícitamente tus páginas con la protección de huellas digitales de Firefox. . Al hacerlo, se mostrarán diálogos de permisos si tu página intenta la creación de huellas digitales o se mostrarán datos confusos para algunas APIs. Esto te ayuda a confirmar si los terceros incluidos en tu servicio usan datos de huellas digitales o si tu propio servicio depende sobre eso. Luego, puedes considerar si el fuzzing deliberado dificulta hacer lo que necesitas. Considera hacer las correcciones necesarias para obtener esos datos de otra fuente, prescindir de ellos o utilizar datos menos detallados.
Como se analizó anteriormente en el módulo sobre terceros, también es importante que las dependencias 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 es imposible si un tercero lo hace en su servidor), pero el modo de huella digital puede marcar algunas técnicas. Buscar el uso de navigator.userAgent o crear de forma inesperada objetos <canvas> también puede revelar algunos enfoques. que merecen un análisis más profundo. También vale la pena buscar usos del término “coincidencia probabilística” en marketing o material técnico que describa a un tercero; esto a veces puede indicar el uso de técnicas de creación de huellas digitales.

Herramientas de prueba en varios navegadores

Probar tu código con fines de privacidad es difícil de automatizar, y los aspectos que debes tener en cuenta cuando realizas pruebas manuales se describen más arriba. Por ejemplo, ¿qué sucede cuando deniegas el permiso al sitio para cualquier API a la que intenta acceder, y cómo se presenta eso al usuario? Una prueba automatizada no puede determinar si el sitio actúa para ayudar al usuario a confiar en él o, en cambio, para alentar al usuario a desconfiar de él. o piensas que algo se está escondiendo.

Sin embargo, una vez auditado el sitio, se probaron las APIs para confirmar que no se produjo ningún error en las versiones más recientes del navegador (o en próxima "versión beta" y "vista previa" versiones) se pueden automatizar y, en gran medida, debería formar parte de tu paquete de pruebas existente. Algo con las herramientas de prueba automatizadas, cuando se trabaja con la cobertura de la superficie de las APIs, la mayoría de los navegadores permiten controlar qué APIs y funciones están disponibles. Chrome lo hace mediante interruptores de líneas de comandos al igual que Firefox, y tener acceso a ellos en la herramienta de prueba te permitirá ejecutar ciertas pruebas con las APIs activadas o desactivadas. (Consulta, por ejemplo, la filosofía de Cypress complemento del inicio del navegador a el parámetro launch.args de nd puppeteer para conocer las para agregar marcas del navegador cuando se inicie).

Usa la cadena usuario-agente solo para obtener información general

Tomemos otro ejemplo. Desde el comienzo de la Web, los navegadores han enviado una descripción de ellos mismos con cada solicitud en la Encabezado de usuario-agente HTTP. Durante casi el mismo tiempo, las personas han exhortado a los desarrolladores web a no utilizar el contenido del encabezado de usuario-agente. publicar contenido diferente en distintos navegadores y durante todo ese tiempo los desarrolladores web lo hicieron de todas formas, con una cierta cantidad de justificación en algunos casos (pero no en todos). Como los navegadores no quieren que los sitios web tengan una experiencia poco óptima, Como resultado, todos los navegadores simulan ser todos los demás, y la cadena usuario-agente tendrá un aspecto como el siguiente:

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.

Esto afirma, entre otras cosas, ser Mozilla/5.0, un navegador que se lanzó al mismo tiempo que los primeros astronautas abordaron la Estación Espacial Internacional hace más de dos décadas. La cadena usuario-agente es una rica fuente de entropía para la creación de huellas digitales, Por supuesto, y para mitigar la capacidad de las huellas digitales, los fabricantes de navegadores ya inmovilizaron el encabezado del usuario-agente o están trabajando para hacerlo. Este es otro ejemplo de cambio de datos que proporciona una API sin quitar necesariamente la API por completo. Si se envía un encabezado user-agent en blanco, se dañarían innumerables sitios web que suponen que está presente. En general, ¿qué están haciendo los navegadores es quitar algunos detalles y mantenerlos casi sin cambios a partir de ese momento. (Puedes ver que esto ocurre en Safari, Chrome, y Firefox). Esta protección contra la creación de huellas digitales detallada significa que no puedes confiar en que el encabezado del usuario-agente ya sea preciso, y si eres es importante buscar fuentes alternativas de datos.

Para ser claros, los datos del usuario-agente no desaparecerán por completo, pero están disponibles con un nivel de detalle más bajo, o A veces es inexacta porque es posible que se informe un número anterior que no cambia. Por ejemplo, Firefox, Safari y Chrome (todo en mayúsculas). 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 de cómo Chrome planea reducir los datos en la cadena usuario-agente están disponibles en Reducción de usuario-agente pero, en resumen, puede esperar que el número de versión del navegador informado solo contenga una versión principal (por lo tanto, el número de versión se verá como 123.0.0.0, incluso si el navegador es la versión 123.10.45.108), y la versión del SO no tendrá detalles y se congelan en una de una pequeña cantidad de opciones que no cambian. Entonces, una versión imaginaria de Chrome, 123.45.67.89, que se ejecuta en un imaginario "Windows 20" 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) aún está disponible: Chrome 123 para Windows. Sin embargo, la subsidiaria información (la arquitectura del chip, la versión de Windows, la versión de Safari que imita, la versión secundaria del navegador) dejará de estar disponible tras el bloqueo.

Compara esto con una “actual” El usuario-agente de Chrome está 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 podemos ver que 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 de usuario-agente de Safari sí muestra una plataforma y un número de versión de Safari, y también proporciona la versión del SO en iOS. pero el resto está congelado. Por lo tanto, una versión imaginaria de Safari 1234.5.67 que se ejecuta en un macOS 20 imaginario podría mostrar su usuario-agente de la siguiente manera:

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,

En 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**.

Nuevamente, la información principal (es decir, Safari, está disponible en iOS o macOS) está disponible, y Safari para iOS sigue proporcionando un número de versión de iOS. pero gran parte de la información que estaba disponible en el pasado se congela. Cabe destacar que esto incluye Safari de la versión, que no está disponible necesariamente.

Los cambios en el usuario-agente denunciado se debatieron mucho. Resúmenes https://github.com/WICG/ua-client-hints#use-cases summarises algunos de los argumentos y las razones del cambio, y Rowan Merewood tiene una presentación de diapositivas. con algunas estrategias para migrar sin usar el usuario-agente con fines de diferenciación, en el contexto de la propuesta de UA Client Hints que se explica con más detalle.

Fuzzing

Fuzzing es un término que proviene de la práctica de seguridad, en el que se llama a las APIs con valores inesperados con la esperanza de que resuelvan esos problemas valores inesperados de forma incorrecta y exponen un problema de seguridad. Los desarrolladores web deben estar familiarizados con la secuencia de comandos entre sitios (XSS). que implica agregar una secuencia de comandos maliciosa a una página, a menudo porque la página no escapa correctamente al HTML insertado (por lo que se hace una búsqueda) con el texto <script>). Los desarrolladores back-end estarán al tanto de la inyección de SQL, en las que las consultas de la base de datos que no validan correctamente las entradas del usuario exponen los problemas de seguridad (como se ilustra en xkcd con Pequeñas Mesas Bobby). El fuzzing, o prueba de fuzzing, funciona usarse en 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 y otro tipo de manejo inadecuado. Todos estos son ejemplos de proporcionar información imprecisa de forma deliberada. Aquí, sin embargo, esto se está haciendo de forma preventiva por los navegadores (al hacer que el usuario-agente deliberadamente incorrecto), para alentar a los desarrolladores a dejar de confiar en esos datos.

Qué debes hacer

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 tu código del cliente, y es probable que el código de backend busque User-Agent como encabezado), incluida tu dependencias.
Si encuentras usos en tu propio código, averigua qué es lo que el código está verificando y encuentra otra manera de hacer esa diferenciación. (o busca una dependencia de reemplazo o trabaja con la dependencia en sentido ascendente presentando problemas o consultando con ellos si hay actualizaciones). A veces es necesaria la diferenciación del navegador para evitar errores, pero el usuario-agente dejará de ser la forma de hacerlo cada vez más una vez que se bloquee.
Es posible que estés a salvo. Si solo se usan los valores centrales de la marca, la versión principal y la plataforma, es casi seguro que se seguirán usando estén disponibles y sean correctos en la cadena de usuario-agente.
MDN describe buenas maneras de evitar la dependencia de la string usuario-agente ("browser sniffing"), La principal es la detección de rasgos.
Si dependes de la cadena usuario-agente de alguna manera (incluso cuando usas los pocos valores fundamentales que siguen siendo útiles), es una buena idea probar con los próximos usuarios-agentes que estarán en las nuevas versiones de los navegadores. Es posible realizar pruebas con los navegadores a través de compilaciones de versiones preliminares de tecnología o beta, pero también es posible configurar una cadena de usuario-agente personalizada para y pruebas. Puedes anular la cadena usuario-agente en Chrome, Edge Firefox y Safari o cuando realices desarrollos locales, para comprobar cómo tu código trabaja con los diferentes valores de usuario-agente que podrías recibir de los usuarios.

Client Hints

Una propuesta importante para brindar esta información es User-Agent Client Hints, aunque esto no es compatible con todos los navegadores. La compatibilidad con navegadores pasará tres encabezados: Sec-CH-UA, que brinda 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, y esto lo hacen los navegadores que envían "engañoso" de salida, que se manejarán de forma incorrecta si no se analizan correctamente. Es decir, como antes, un ejemplo de una "prueba de fuzz" que el navegador realiza de manera preventiva. Se requiere un desarrollador que use estos datos para correctamente, ya que los datos están diseñados para que un análisis inadecuado o diferido probablemente dé malos resultados, como mostrar las marcas que no los muestran. existen o cadenas que no se cierran correctamente). Afortunadamente, estos datos también están disponibles a través del navegador para JavaScript directamente como navigator.userAgentData, que en un navegador compatible podría verse como este objeto:

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