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

Hay algunos casos extremos en los que es importante crear una huella digital de un usuario, 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 se puede usar la creación de huellas digitales para hacer un seguimiento de los usuarios en varios 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 “huella digital”. En el mejor de los casos, 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 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 empresas no necesitan crear huellas digitales de los usuarios. Si tu app requiere que los usuarios accedan, estos se identifican ante ti, con su consentimiento, y de una manera que pueden inhabilitar unilateralmente en cualquier momento. 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 a sus cuentas, lo que protege aún más su privacidad (y, luego, recopilas solo los datos que necesitas).

Qué debes hacer

Evalúa a tus terceros para detectar 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, ya que 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 vale la pena leer las políticas de privacidad de tus servicios y dependencias de terceros para buscar indicios 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 por una puerta de enlace detrás de un diálogo que le solicite permiso al usuario (y, por lo tanto, alertarlo de que se están usando o permitir que las rechace 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 inicios de la superautopista de la 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 haces depende de esta información (por ejemplo, si tomas diferentes ramas de código según el usuario-agente), es posible que este código falle a medida que los navegadores bloquean o detienen cada vez más esa información. Las pruebas son la mejor defensa (consulta más adelante).

Nota al margen: Cómo medir la capacidad de generar huellas dactilares

La medida técnica de 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 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 Almanaque de HTTP, se describe cómo las bibliotecas 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, o incluso uno solo. 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 cualquier persona la identifique de forma única entre tus amistades o, al menos, reduzca la lista a solo unas pocas personas. Así es como funciona la creación de huellas digitales: la lista de lo que te gusta se convierte en el "hash". Con ese hash, identificar a un usuario como la misma persona en dos sitios diferentes no conectados es más fácil, que es el objetivo del seguimiento: 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 de usuario-agente del navegador, que a menudo identifica el navegador, el sistema operativo y la versión en uso (y, por lo tanto, contribuye a distinguirte de mí, si ambos usamos navegadores diferentes). Algunas de las formas no se crean de forma deliberada para que se puedan crear huellas digitales, pero terminan siendo así 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 se estableció que algunos contribuyen a una huella digital mucho después del lanzamiento, como la renderización de píxeles exacta del suavizado de fuentes en un elemento de lienzo. Hay muchas más, y cada forma en que tu navegador difiere del mío agrega entropía y, por lo tanto, puede contribuir a una forma de distinguir entre tú y yo, y de identificar a una persona individual de la forma más única posible en todos los sitios web. https://amiunique.org tiene una lista larga (pero definitivamente no exhaustiva) de posibles funciones que contribuyen a la creación de huellas digitales, y la lista crece todo el tiempo (ya que hay un gran interés monetario en poder crear huellas digitales de los usuarios, incluso si los usuarios no lo desean o tal vez no lo esperan).

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

La puerta de enlace de permisos del 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. A menudo, este enfoque también se adopta por motivos de seguridad: un sitio web no debería poder tomar fotos con tu cámara web sin tu permiso. Sin embargo, aquí, 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. Exigir permiso para ver la geolocalización no disminuye la entropía adicional que una ubicación agrega a la singularidad de esa huella digital, pero básicamente elimina el uso de la geolocalización para la creación de huellas digitales, ya que ya no se realiza 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 estás tratando de identificarlo, no necesitas técnicas de creación de huellas digitales: pídele que cree una cuenta y que acceda con ella.

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. Los proveedores de navegadores también pueden adoptar este enfoque para los datos de la API que se ponen a disposición de las 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 garantizar que las APIs sigan siendo útiles, pero que las respuestas sean menos identificables: en esencia, proporcionar "inmunidad colectiva" haciendo que tu dispositivo se vea más como el de todos los demás en lugar de ser peculiar para ti. Safari presenta una versión simplificada de la configuración del sistema precisamente 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, por supuesto, 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, sin importar en qué navegador o plataforma se encuentre (por lo que puede ser tentador probar en un solo navegador basado en Blink, por ejemplo). 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 durante las 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 en las actualizaciones de navegadores para dispositivos móviles y computadoras, lo que significa que es posible que algunas APIs no se hayan implementado o que no estén disponibles 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 te brindan la mejor oportunidad de identificar las interrupciones de la API y los cambios que afectan a tus sitios antes de que esos cambios afecten a tus usuarios. Del mismo modo, ten en cuenta la y entornos de prueba en función de cualquier análisis que presente. Si tu base de usuarios tiene una gran cantidad de teléfonos Android más antiguos, 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.
Prueba 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 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 que se pueden identificar o si tu propio servicio depende de eso. Luego, puedes considerar si la generación de fuzz deliberada dificulta lo que necesitas hacer. 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 pasivas es difícil de detectar (y es imposible si un tercero lo hace en su servidor), pero el modo de creación de huellas digitales puede marcar algunas técnicas de creación de huellas digitales, y buscar usos de navigator.userAgent o la creación inesperada de objetos <canvas> también puede revelar algunos enfoques que merecen un mayor escrutinio. También vale la pena buscar usos del término "coincidencia probabilística" en el material de marketing o técnico que describa a un tercero. Esto puede indicar el uso de técnicas de creación de huellas digitales.

Herramientas de prueba multinavegador

Probar tu código con fines de privacidad es difícil de automatizar, y ya se describieron los aspectos que debes tener en cuenta cuando realizas pruebas manuales. 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 que se haya auditado el sitio, las pruebas de las APIs para confirmar que no se haya producido ningún error en las versiones más recientes del navegador (o en las próximas versiones "beta" y "preview") se pueden automatizar y, en gran medida, deben formar parte de tu suite 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, el complemento browser-launch de Cypress y el parámetro launch.args de Puppeteer para ver cómo agregar marcas de navegador durante el inicio).

Solo usa la cadena de usuario-agente para obtener información aproximada

Tomemos otro ejemplo: desde el principio de la Web, los navegadores envían una descripción de sí mismos con cada solicitud en el encabezado HTTP User-Agent. Durante casi el mismo tiempo, las personas han estado exhortando a los desarrolladores web a no usar el contenido del encabezado del usuario-agente para entregar contenido diferente a diferentes navegadores, y durante todo ese tiempo los desarrolladores web lo hicieron de todos modos, con cierta justificación en algunos (pero no todos) los casos. 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.

Entre otras cosas, se indica que es 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 esto en Safari, Chrome y Firefox). Esta protección contra las huellas digitales detalladas significa, en esencia, que ya no puedes confiar en que el encabezado del usuario-agente sea preciso. Si lo haces, es importante que encuentres fuentes de datos alternativas.

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) sigue disponible: es Chrome 123, en 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 se puede ver que lo único que difiere es el número de versión de Chrome (104) y el identificador de 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 proporcionar 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**.

Una vez más, la información principal (es Safari, está en iOS o macOS) está disponible, y Safari para iOS aún proporciona un número de versión de iOS, pero gran parte de la información complementaria que estaba disponible en el pasado se congeló. 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

El 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 de forma incorrecta y expongan un problema de seguridad. Los desarrolladores web deben estar familiarizados con las secuencias de comandos entre sitios (XSS), que implican agregar una secuencia de comandos maliciosa a una página, a menudo porque la página no escapa correctamente el HTML insertado (por lo que realizas una búsqueda con el texto <script> en ella). 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 tu base de código en busca de cualquier dependencia de la cadena de usuario-agente (es probable que una búsqueda de navigator.userAgent encuentre la mayoría de las ocurrencias en tu código del cliente, y es probable que tu código de backend busque User-Agent como encabezado), incluidas tus 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, la diferenciación del navegador es necesaria para solucionar errores, pero el usuario-agente dejará de ser la forma de hacerlo una vez que se congele.
Es posible que estés a salvo. Si solo usas los valores principales de la marca, la versión principal y la plataforma, es casi seguro que estos aún estarán disponibles y serán correctos en la cadena del usuario-agente.
En MDN, se describen buenas formas de evitar depender de la cadena de usuario-agente ("detección de navegador"), 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 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 de usuario-agente en Chrome, Edge, Firefox y Safari cuando realices el desarrollo local para verificar cómo tu código controla los diferentes valores de usuario-agente que podrías recibir de los usuarios.

Sugerencias de cliente

Una propuesta importante para brindar esta información es User-Agent Client Hints, aunque esto no es compatible con todos los navegadores. Los navegadores compatibles pasarán tres encabezados: Sec-CH-UA, que proporciona una marca y un 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. (El análisis de estos encabezados es menos fácil de lo que parece, ya que son encabezados estructurados en lugar de cadenas simples, y los navegadores lo aplican enviando valores "complicados", que se manejarán de forma incorrecta si no se analizan correctamente. Como se mencionó antes, este es un ejemplo de “pruebas de fuzz” que realiza el navegador de forma preventiva. Se requiere un desarrollador que use estos datos para correctamente, ya que los datos están diseñados de manera que un análisis inadecuado o diferido probablemente generará 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
}