Prepare-se para o fim dos cookies de terceiros no Chrome. Teste seu site hoje mesmo e veja se há falhas.

Esta página foi traduzida pela API Cloud Translation.

Impressão digital

Impressão digital significa tentar identificar um usuário quando ele voltar ao seu site ou identificar o mesmo usuário em sites diferentes. Muitas características podem diferir entre sua configuração e a de outra pessoa. Por exemplo, você pode estar usando um tipo diferente de dispositivo e um navegador diferente, ter um tamanho de tela diferente e fontes instaladas diferentes. Se eu tiver a fonte "Dejavu Sans" instalada e você não tiver, qualquer site poderá identificar a diferença entre você e eu verificando essa fonte. É assim que a impressão digital funciona: você cria uma coleção desses pontos de dados e cada um fornece mais maneiras de distinguir entre os usuários.

Uma definição mais formal pode ser assim: a impressão digital é a ação de usar características óbvias e não óbvias de longa duração da configuração de um usuário para tentar distingui-las do maior número possível de usuários.

Por que as técnicas de impressão digital prejudicam a privacidade do usuário

Há alguns casos extremos em que a impressão digital de um usuário é importante, como a detecção de fraudes. No entanto, as técnicas de impressão digital também podem ser usadas para rastrear usuários em sites, e esse rastreamento geralmente é feito sem o consentimento dos usuários ou, em alguns casos, com base em um consentimento inválido que não informa o usuário corretamente. Quando isso é feito, esses usuários geralmente acham isso um pouco inquietante e se sentem enganados.

Impressão digital significa encontrar maneiras de distinguir secretamente um usuário de outro. A impressão digital pode ser usada para reconhecer que ele ainda é o mesmo usuário no mesmo site ou para reconhecer o mesmo usuário em dois perfis diferentes de navegador ao mesmo tempo. Isso significa que as técnicas de impressão digital podem ser usadas para rastrear usuários em sites. Os métodos determinísticos e explícitos, como o armazenamento de um cookie com um ID exclusivo específico do usuário, podem ser até certo ponto observados e controlados pelos usuários (e o módulo anterior explicou algumas dessas abordagens). No entanto, o processo de impressão digital é mais difícil de evitar exatamente por ser oculto. Ele depende de características imutáveis e, muito provavelmente, acontece de forma invisível. É por isso que ela é chamada de "impressão digital". Na melhor das hipóteses, é difícil mudar sua impressão digital, seja a digital ou as que estão nas pontas dos seus dedos.

Os fornecedores de navegadores sabem que os usuários não gostam de ser acompanhados e implementam recursos continuamente para limitar o uso de técnicas de impressão digital, como no módulo anterior. Aqui, estamos analisando como esses recursos podem afetar seus requisitos de negócios e como você ainda pode fazer o que quer fazer com proteção da privacidade. Ela está mais relacionada a como a proteção do navegador contra impressões digitais vai afetar o que você faz e como, em vez de como ela vai impedir que você faça impressões digitais.

Na prática, a maioria dos desenvolvedores e a maioria das empresas não precisa usar a impressão digital dos usuários. Se o app exigir que os usuários façam login, eles se identificarão para você, com o consentimento deles, e poderão desativar unilateralmente a qualquer momento. Esse é um método de proteção da privacidade para entender quais usuários estão conectados. Seu app pode não exigir que os usuários façam login, o que protege ainda mais a privacidade deles. Assim, você coleta apenas os dados necessários.

O que fazer

Avalie a impressão digital de terceiros. Como parte do módulo de terceiros, talvez você já tenha uma lista de qualquer serviço de terceiros que esteja incluindo e as solicitações da Web que eles fazem. É possível inspecionar essas solicitações para ver quais dados estão sendo transmitidos de volta ao criador, se houver. No entanto, isso costuma ser difícil. A impressão digital é, por natureza, um processo oculto que envolve a solicitação de dados que não estão sujeitos à aprovação do usuário.

Também vale a pena ler as Políticas de Privacidade dos serviços e dependências de terceiros para procurar indícios de uso de técnicas de impressão digital. Às vezes, ela é chamada de "correspondência probabilística" ou como parte de um conjunto de técnicas de correspondência probabilística, em oposição à "correspondência determinística".

Como a impressão digital funciona

Muitas vezes, sua combinação pessoal de todos esses atributos é exclusiva para você ou, pelo menos, para um pequeno grupo de pessoas semelhantes. Isso pode ser usado para rastrear você secretamente.

À parte: técnicas de impressão digital passivas e ativas

Há uma distinção útil aqui entre técnicas de impressão digital passivas e ativas. Uma técnica de impressão digital passiva é aquela que usa informações fornecidas ao site por padrão. Uma técnica de impressão digital ativa é aquela que consulta explicitamente o navegador em busca de informações adicionais. Essa distinção é importante porque os navegadores podem tentar detectar e interceptar ou mitigar técnicas ativas. As APIs podem ser restritas ou por gateway em uma caixa de diálogo que solicita a permissão do usuário (e, portanto, alertando-o de que estão sendo usadas ou permitindo que o usuário as negue por padrão). Uma técnica passiva é aquela que usa dados que já foram fornecidos ao site, muitas vezes porque, historicamente, nos primeiros dias da superviatura de informações, essas informações eram fornecidas a todos os sites. A string do user agent é um exemplo disso, e vamos analisar isso em mais detalhes. Ele foi considerado útil para fornecer muitas informações sobre o navegador, a versão e o sistema operacional do usuário, para que um site pudesse escolher apresentar itens diferentes com base nisso. No entanto, isso também aumenta a quantidade de informações distintivas disponíveis, ou seja, informações que ajudam a identificar um usuário do outro. Assim, essas informações não ficam mais disponíveis ou são, pelo menos, congeladas para que não possam mais distinguir. Se o que você faz depende dessas informações, por exemplo, se você usa ramificações de código diferentes dependendo do user agent, esse código pode ser corrompido à medida que os navegadores congelam ou interrompem cada vez mais essas informações. O teste é a melhor defesa nesse caso ( veja mais tarde).

À parte: medição da impressão digital

A medida técnica para a quantidade de informações que cada um desses pontos de dados fornece é chamada de entropia e é medida em bits. Um recurso com muitos valores possíveis diferentes (como a lista de fontes instaladas) pode contribuir com muitos bits para o total, em que algo sem muita distinção (como o sistema operacional que você está usando) só pode adicionar alguns. O HTTP Almanac descreve como as bibliotecas de impressão digital atuais automatizam esse processo de combinação das respostas de várias APIs diferentes em um "hash", que pode identificar apenas um pequeno grupo de usuários ou até mesmo um. Maud Nalpas aborda isso com mais detalhes neste vídeo do YouTube, mas, em resumo, imagine que você veria uma lista dos seus amigos com as músicas e a comida preferidas e os idiomas que eles falam, mas com o nome removido. É bem provável que a lista de uma pessoa só a identifique entre seus amigos ou, pelo menos, reduza a lista a apenas algumas pessoas. É assim que o processo de impressão digital funciona: a lista de coisas de que você gosta se torna o "hash". Com esse hash, fica mais fácil identificar um usuário como a mesma pessoa em dois sites desconectados diferentes, que é o objetivo de rastreamento: burlar o desejo de privacidade do usuário.

O que os navegadores fazem contra as técnicas de impressão digital?

É importante ressaltar que os fornecedores de navegador estão cientes de muitas maneiras diferentes para um site (ou um terceiro incluído em um site) calcular uma impressão digital que distingue um usuário ou para diferentes partes de informações que contribuem para a exclusividade dessa impressão digital. Algumas dessas formas são explícitas e deliberadas, como a string do user agent do navegador, que geralmente identifica o navegador, o sistema operacional e a versão em uso. Assim, isso contribui para diferenciar você de mim, caso você e eu estejam usando navegadores diferentes. Algumas delas não são deliberadamente criadas para serem digitais, mas acabam sendo assim, como a lista de fontes ou os dispositivos de vídeo e áudio disponíveis para o navegador. O navegador não precisa usar esses dispositivos, basta conseguir uma lista deles por nome. Alguns deles foram estabelecidos para contribuir para uma impressão digital logo após o lançamento, como a renderização exata de pixel do antialiasing de fontes em um elemento de tela. Há muitos outros, e cada maneira em que seu navegador difere do meu adiciona entropia e, portanto, possivelmente contribui para uma maneira de dizer a diferença entre você e eu, e identificar uma pessoa da forma mais única possível entre os sites. O site https://amiunique.org tem uma lista longa (mas definitivamente não abrangente) de recursos potenciais que contribuem com impressões digitais, e a lista cresce o tempo todo em que os usuários podem ter muitas impressões,

Sem suporte a determinadas APIs avançadas

A resposta dos fornecedores de navegador a todas essas abordagens para calcular a impressão digital de um usuário é encontrar maneiras de reduzir a quantidade de entropia disponível dessas APIs. A opção mais restritiva é primeiro não implementá-las. Isso foi feito por alguns dos principais navegadores para diversas APIs de hardware e dispositivo (como acesso NFC e Bluetooth de apps da Web do lado do cliente), com questões de impressão digital e privacidade citadas como motivos pelos quais elas não foram implementadas. Obviamente, isso pode afetar seus apps e serviços: não é possível usar uma API em um navegador que não a implemente, e isso pode restringir ou impedir totalmente a consideração de algumas abordagens de hardware.

O gateway de permissões do usuário

Uma segunda abordagem adotada pelos fornecedores de navegadores é impedir acessos à API ou aos dados sem algum tipo de permissão explícita do usuário. Essa abordagem também é adotada com frequência por motivos de segurança. Um site não pode tirar fotos com a webcam sem sua permissão. Mas aqui, privacidade e segurança podem ter interesses semelhantes. Identificar a localização de alguém é, por si só, uma violação de privacidade, mas também contribui para a exclusividade de uma impressão digital. Exigir permissão para ver a geolocalização não diminui a entropia extra que um local adiciona à exclusividade dessa impressão digital, mas basicamente elimina o uso da geolocalização para esse tipo de impressão, já que isso não está mais sendo feito de maneira invisível. O objetivo da impressão digital é distinguir os usuários de maneira clandestina. Se estiver tudo pronto para o usuário saber que você está tentando identificá-lo, não será necessário usar técnicas de impressão digital: peça para o usuário criar uma conta e fazer login com ela.

Adicionar imprevisibilidade

Uma terceira abordagem adotada em alguns casos é para que os fornecedores de navegadores "confundam" as respostas das APIs para torná-las menos granulares e, portanto, menos identificáveis. Isso foi descrito como parte do mecanismo de resposta aleatória no módulo de dados como algo que você pode fazer ao coletar dados de usuários para evitar a coleta acidental de dados de identificação. Os fornecedores de navegadores também podem adotar essa abordagem aos dados da API disponibilizados para apps da Web e terceiros. Um exemplo disso são as APIs de tempo muito precisas usadas para medir o desempenho da página de window.performance.now(). O navegador reconhece esses valores com precisão de microssegundos, mas os valores retornados são deliberadamente reduzidos na precisão, arredondando para o limite de 20 microssegundos mais próximo para evitar o uso em técnicas de impressão digital (e também para a segurança de evitar ataques de tempo, é bem). O objetivo é garantir que as APIs continuem úteis, mas com menos identificação. Em essência, oferecer "imunidade de rebanho" fazendo com que seu dispositivo se pareça com o de outras pessoas, em vez de ser peculiar para você. Por esse motivo, o Safari apresenta uma versão simplificada da configuração do sistema.

Como definir um orçamento de privacidade

O Orçamento de privacidade é uma proposta que sugere que os navegadores estimem as informações reveladas por cada plataforma de impressão digital. Ela ainda não foi implementada nos navegadores. O objetivo é permitir APIs avançadas sem prejudicar a privacidade do usuário. Saiba mais sobre a proposta de orçamento de privacidade.

Use um ambiente de teste amplo

Tudo isso afeta a forma como você cria apps e serviços. Em particular, há uma ampla diversidade de respostas e abordagens em navegadores e plataformas nessa área. Isso significa que é essencial para testar seu trabalho em ambientes diferentes. Isso é sempre importante, mas pode ser razoável presumir que a renderização de HTML ou o CSS serão constantes para um determinado mecanismo de renderização, independentemente do navegador ou da plataforma em que ele esteja. Por isso, pode ser tentador fazer testes em apenas um navegador baseado no Blink, por exemplo. Esse não é o caso do uso da API, precisamente, porque os navegadores que compartilham um mecanismo de renderização podem apresentar diferenças drásticas no modo como eles protegem a superfície da API contra técnicas de impressão digital.

O que fazer

Verifique sua própria análise e público-alvo para orientar o conjunto de navegadores que você deve priorizar ao realizar os testes.
Alguns navegadores para testar são Firefox, Chrome, Edge, Safari no computador, Chrome e Samsung Internet no Android e Safari no iOS. Isso garante que você teste nos três principais mecanismos de renderização (Gecko no Firefox, várias bifurcações do Blink no Chrome, Edge e Samsung Internet e Webkit no Safari) e em plataformas para dispositivos móveis e computadores.
Se o site também puder ser usado em dispositivos menos comuns, como tablets, smartwatches ou consoles de jogos, faça o teste nele também. Algumas plataformas de hardware podem ter um atraso nas atualizações do navegador para dispositivos móveis e computadores, o que significa que algumas APIs podem não estar implementadas ou disponíveis nos navegadores dessas plataformas.
Teste com um ou mais navegadores que tenham a privacidade do usuário como motivador. Inclua as próximas versões de pré-lançamento e teste dos seus navegadores mais comuns sempre que possível e se elas estiverem disponíveis: a prévia de tecnologia do Safari, o Canary do Chrome e o canal Beta do Firefox. Elas oferecem mais chances de identificar falhas na API e mudanças que afetam seus sites antes que elas afetem os usuários. Da mesma forma, não se esqueça dos ambientes dos usuários com referência a quaisquer análises presentes. Se sua base de usuários tiver um grande número de smartphones Android mais antigos, inclua-os nos seus testes. A maioria das pessoas não tem o hardware rápido e os lançamentos mais recentes que uma equipe de desenvolvimento tem.
Faça testes usando um perfil limpo e o modo de navegação anônima/privada. É provável que você já tenha concedido as permissões necessárias no perfil pessoal. Teste o que acontece se você negar a permissão ao site por qualquer pergunta.
Teste explicitamente suas páginas no modo de proteção contra impressão digital do Firefox. Isso vai mostrar caixas de diálogo de permissão se a página estiver tentando usar o técnicas de impressão digital ou vai retornar dados imprecisos para algumas APIs. Isso ajuda a confirmar se os terceiros incluídos no seu serviço estão usando dados com impressão digital ou se seu próprio serviço depende disso. Depois, considere se o fuzzing deliberado dificulta a realização do que você precisa. Faça as correções necessárias para extrair esses dados de outra fonte, fazer sem eles ou usar dados menos granulares.
Como discutido anteriormente no módulo de terceiros, também é importante auditar suas dependências de terceiros para ver se eles estão usando técnicas de impressão digital. A impressão digital passiva é difícil de detectar (e impossível se um terceiro faz isso no servidor dele), mas o modo de impressão digital pode sinalizar algumas técnicas e procurar usos de navigator.userAgent ou a criação inesperada de objetos <canvas> também pode revelar algumas abordagens que merecem uma análise mais detalhada. Também vale a pena procurar usos do termo "correspondência probabilística" no marketing ou em materiais técnicos que descrevam um terceiro. Isso às vezes pode indicar o uso de técnicas de impressão digital.

Ferramentas de teste em vários navegadores

Testar o código para fins de privacidade é difícil de automatizar, e as coisas que procurar ao testar manualmente estão descritas anteriormente. O que acontece quando você nega permissão ao site para qualquer API que ele tenta acessar, por exemplo, e como isso é apresentado ao usuário? Um teste automatizado não pode julgar se o site atua de forma a ajudar o usuário a confiar nele ou, por outro lado, a incentivar o usuário a desconfiar ou acreditar que algo está sendo ocultado.

No entanto, depois que o site for auditado, o teste de APIs para confirmar se nada foi corrompido nas versões mais recentes do navegador (ou nas próximas versões "Beta" e "pré-lançamento") pode ser automatizado e precisa fazer parte do seu pacote de testes atual. Ao trabalhar com a cobertura de superfície da API, considere que a maioria dos navegadores permite algum nível de controle sobre quais APIs e recursos estão disponíveis. O Chrome faz isso por meio de chaves de linha de comando, assim como o Firefox, e ter acesso a elas na configuração da ferramenta de teste permite que você execute determinados testes com APIs desativadas ou ativadas. Consulte, por exemplo, o plug-in de inicialização do navegador e o parâmetro launch.args do Cypress para conhecer maneiras de adicionar sinalizações do navegador ao iniciar.

Confie apenas na string do user agent para ter informações aproximadas

Além disso, os navegadores enviaram, desde o início da Web, uma descrição de si mesmos a cada solicitação no cabeçalho do user agent HTTP. Por quase esse tempo, as pessoas têm exortado os desenvolvedores da Web a não usar o conteúdo do cabeçalho do user agent para exibir conteúdo diferente em diferentes navegadores. Durante todo esse tempo, os desenvolvedores da Web fizeram isso mesmo assim, com uma certa quantidade de justificativa em alguns (mas não todos). Como os navegadores não querem ser escolhidos por sites com uma experiência abaixo do ideal, isso faz com que todos os navegadores finjam ser todos os outros. Além disso, a string do user agent é parecida com esta:

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.

Isso alega, entre outras coisas, ser o Mozilla/5.0, um navegador lançado na mesma época em que os primeiros astronautas embarcaram na Estação Espacial Internacional há mais de duas décadas. A string do user agent é uma rica fonte de entropia para técnicas de impressão digital. Para reduzir essa possibilidade, os fabricantes de navegadores já congelaram o cabeçalho do user agent ou estão trabalhando para fazer isso. Esse é outro exemplo de alteração dos dados fornecidos por uma API sem necessariamente remover a API completamente. Enviar um cabeçalho de user agent em branco quebraria inúmeros sites que assumem que ele está presente. Em geral, o que os navegadores fazem é remover alguns detalhes e mantê-los praticamente inalterados a partir de então. Isso acontece no Safari, no Chrome e no Firefox. Essa proteção contra impressões digitais detalhadas significa essencialmente que não é mais possível confiar na precisão do cabeçalho do user agent e, se estiver fazendo isso, é importante encontrar fontes de dados alternativas.

Para deixar claro, os dados no user agent não desaparecem totalmente, mas estão disponíveis em uma granularidade menor ou às vezes são imprecisos porque um número mais antigo, mas imutável, pode ser informado. Por exemplo, Firefox, Safari e Chrome limitam o número de versão do macOS informado como dez. Consulte Atualização na redução da string do user agent para mais detalhes. Os detalhes exatos sobre como o Chrome planeja reduzir dados na string do user agent estão disponíveis em Redução do user agent. Em resumo, o número informado da versão do navegador terá apenas a versão principal. Por exemplo, 123.0.0.0, mesmo que o navegador seja da versão 123.10.45.108, e um número pequeno de opções do SO seja congelado. Assim, uma versão imaginária do Chrome 123.45.67.89 executada em um "Windows 20" imaginário informaria seu número de versão como:

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

As principais informações de que você precisa (a versão do navegador) ainda estão disponíveis: é o Chrome 123, no Windows. No entanto, as informações subsidiárias (a arquitetura do chip, qual versão do Windows, qual versão do Safari está imitando, a versão secundária do navegador) não estarão mais disponíveis após o congelamento.

Compare isso com um user agent "atual" do Chrome em outra plataforma:

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

e pode ser visto que a única diferença é o número da versão do Chrome (104) e o identificador da plataforma.

Da mesma forma, a string do user agent do Safari mostra uma plataforma e um número de versão do Safari, além de informar uma versão do SO no iOS. No entanto, todo o restante é congelado. Assim, um Safari versão 1234.5.67 imaginário em execução em um macOS 20 imaginário poderia dar ao seu user agent como:

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,

e em um iOS 20 imaginário poderia 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**.

Novamente, as informações principais (é o Safari, no iOS ou no macOS) estão disponíveis, e o iOS Safari ainda fornece um número de versão para iOS. No entanto, grande parte das informações complementares disponíveis no passado foi congelada. Isso inclui o número da versão do Safari, que não está necessariamente disponível.

Houve um debate acalorado sobre as alterações no user agent informado. O artigo https://github.com/WICG/ua-client-hints#use-cases resume resume alguns dos argumentos e motivos da mudança. Rowan Merewood tem uma apresentação de slides com algumas estratégias para migrar do user agent para diferenciação do UA, no contexto das dicas do cliente.

Fuzzing

Fuzzing é um termo da prática de segurança, em que as APIs são chamadas com valores inesperados na esperança de que elas processem esses valores inesperados incorretamente e exponham um problema de segurança. Os desenvolvedores da Web precisam estar familiarizados com o scripting em vários sites (XSS), que envolve adicionar script malicioso a uma página, geralmente porque a página não escapa corretamente do HTML injetado. Portanto, você faz uma consulta de pesquisa com o texto <script>. Os desenvolvedores back-end estarão cientes da injeção de SQL, em que as consultas do banco de dados que não validam corretamente a entrada do usuário expõem problemas de segurança (como ilustrado pelo xkcd com Little Bobby Tables). Fuzzing, ou teste de fuzz, é mais usado para tentativas automatizadas de fornecer muitas entradas inválidas ou inesperadas em uma API e verificar os resultados em busca de vazamentos de segurança, falhas ou outros tipos de tratamento inadequados. Todos esses são exemplos de fornecimento de informações imprecisas deliberadamente. No entanto, isso está sendo feito preventivamente pelos navegadores (tornando o user agent deliberadamente incorreto) para incentivar os desenvolvedores a parar de depender desses dados.

O que fazer

Verifique sua base de código para ver se há dependência da string do user agent (uma pesquisa por navigator.userAgent provavelmente encontrará mais ocorrências no código do lado do cliente, e o código de back-end provavelmente procurará por User-Agent como cabeçalho), incluindo suas dependências.
Se você encontrar usos no seu código, descubra o que ele está verificando e encontre outra maneira de fazer essa diferenciação. Também é possível encontrar uma dependência substituta ou trabalhar com a dependência upstream registrando problemas ou verificando se há atualizações. Às vezes, a diferenciação do navegador é necessária para solucionar bugs, mas o user agent não será mais a maneira de fazer isso depois de congelado.
Talvez você esteja bem. Se você estiver usando apenas os valores principais de marca, versão principal e plataforma, eles provavelmente ainda estarão disponíveis e corretos na string do user agent.
A MDN descreve boas maneiras de evitar a dependência da string do user agent ("sniffing de navegador"). A principal é a detecção de recursos.
Se você depender da string do user agent de alguma forma (mesmo ao usar os poucos valores principais que permanecem úteis), é recomendável testar com os futuros user agents que estarão nas novas versões do navegador. É possível testar essas próximas versões do navegador por meio de builds Beta ou de visualização de tecnologia, mas também é possível definir uma string de user agent personalizada para teste. É possível modificar a string do user agent no Chrome, Edge, Firefox e Safari durante o desenvolvimento local para verificar como seu código lida com diferentes valores de user agents recebidos dos usuários.

Dicas de cliente

Uma das principais propostas para disponibilizar essas informações são as Dicas de cliente do user agent, embora elas não sejam aceitas em todos os navegadores. Os navegadores compatíveis transmitirão três cabeçalhos: Sec-CH-UA, que informa a marca do navegador e o número da versão; Sec-CH-UA-Mobile, que indica se a solicitação vem de um dispositivo móvel; e Sec-CH-UA-Platform, que nomeia o sistema operacional. A análise desses cabeçalhos é menos fácil do que parece, porque eles são cabeçalhos estruturados em vez de strings simples. Isso é aplicado pelos navegadores que enviam valores "complicados", que serão tratados incorretamente se não forem analisados adequadamente. Esse é, como antes, um exemplo de "teste de fuzz" sendo feito preventivamente pelo navegador. Um desenvolvedor que usa esses dados precisa lidar com eles corretamente porque eles foram projetados para que uma análise inadequada ou lenta tenha resultados ruins, como mostrar marcas inexistentes ou strings que não fecham corretamente.) Felizmente, esses dados também são disponibilizados pelo navegador para o JavaScript diretamente como navigator.userAgentData, que em um navegador compatível pode ter esta aparência:

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