Agradecemos por acompanhar o Google I/O. Assista ao conteúdo sob demanda.

Esta página foi traduzida pela API Cloud Translation.

Técnicas de impressão digital

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

Uma definição mais formal pode ser esta: 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 diferenciá-lo de outros usuários.

Por que a impressão digital dificulta a privacidade do usuário

Há alguns casos extremos em que a impressão digital de um usuário é importante: detecção de fraude, por exemplo. Mas a impressão digital também pode ser usado para rastrear usuários em sites e que o acompanhamento geralmente é feito sem o consentimento dos usuários ou, em alguns casos, com base de um consentimento inválido que não informa o usuário adequadamente. Quando isso for feito, esses usuários geralmente terão uma ideia desagradável e se sentir um pouco traída.

O processo de impressão digital se refere a encontrar maneiras de distinguir ocultamente um usuário do outro. A impressão digital pode ser usada para reconhecer ainda é o mesmo usuário no mesmo site ou reconhecer o mesmo usuário em dois perfis de navegador diferentes ao mesmo tempo. Isso significa que a impressão digital pode ser usada para rastrear usuários em vários sites. Os métodos determinísticos e explícitos de rastreamento, como o armazenamento de um cookie com um ID único e específico do usuário, podem, até certo ponto, serem observados pelos usuários e controlados (e o módulo anterior explicou algumas dessas abordagens). Mas é mais difícil evitar a impressão digital porque é oculto; depende de características que não mudam e provavelmente acontece de forma invisível. É por isso que ele é chamado "impressão digital". Na melhor das hipóteses, é difícil alterar sua impressão digital, seja ela digital ou as que ficam nas extremidades. com os dedos.

Os fornecedores de navegador sabem que os usuários não gostam de ser rastreados e estão continuamente implementando recursos para limitar a impressão digital (alguns dos quais falamos no módulo anterior). Aqui, vamos analisar como esses recursos podem afetar os requisitos de negócios e como fazer o que você quer sem comprometer a privacidade. Vamos entender melhor como a proteção do navegador contra técnicas de impressão digital afetam o que você faz e como, e não como elas vão impedir que você faça esse processo.

Na prática, a maioria dos desenvolvedores e 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 vão se identificar para você com consentimento e de uma forma que possam desativar o uso a qualquer momento. Esse é um método de proteção de privacidade para entender quais usuários estão conectados. Seu app pode não exigem que os usuários façam login, o que protege ainda mais privacidade (e, depois, você coleta apenas os dados de que você precisa).

O que fazer

Avalie os terceiros para verificar se há impressão digital. Como parte do módulo de terceiros, você pode já ter uma lista dos serviços de terceiros incluídos e das solicitações da Web feitas por eles. Talvez seja possível inspecionar essas solicitações para saber quais dados estão sendo transmitidos de volta ao autor, se houver. No entanto, isso é muitas vezes 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 indicações de impressão digital em uso. Às vezes, é chamada de "correspondência probabilística" ou parte de um conjunto de técnicas de correspondência probabilística, em vez de "correspondência determinística".

Como as técnicas de impressão digital funcionam

Muitas vezes, a combinação pessoal de todos esses atributos é exclusiva para você ou 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 entre as técnicas de impressão digital passiva e ativa. Uma técnica de impressão digital passiva usa informações fornecidas ao site por padrão. Uma técnica de impressão digital ativa é aquela que interroga explicitamente o navegador para obter informações adicionais. A razão pela qual essa distinção é importante é que os navegadores podem tentar detectar e interceptar ou reduzir técnicas ativas. As APIs podem ser restritas ou encapsuladas por uma caixa de diálogo que solicita a permissão do usuário (e, portanto, alerta o usuário de que elas estão sendo usadas ou permite que ele as recuse por padrão). Uma técnica passiva é aquela que usa dados que já foram fornecidos ao site, geralmente porque, historicamente, nos primeiros dias da "superhighway" de informações, elas eram fornecidas a todos os sites. A string do user-agent é um exemplo disso, e vamos analisar isso com mais detalhes mais adiante. Ela foi considerada útil por fornecer várias informações sobre o navegador, a versão e o sistema operacional do usuário, para que um site possa optar por apresentar diferentes com base nisso. No entanto, isso também aumenta a quantidade de informações distintas disponibilizadas, que ajuda a identificar um usuário de outro; Portanto, cada vez mais essas informações não estão mais disponíveis ou pelo menos ficam congeladas para que não haja mais distinção. Se o que você faz depende dessas informações, por exemplo, se você está usando diferentes ramificações de código dependendo do user-agent, esse código pode falhar à medida que os navegadores congelam ou param essas informações. O teste é a melhor defesa aqui (mais adiante).

Observação: como medir a capacidade de impressão digital

A medida técnica de quantas informações 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 ao total, de modo que algo sem muito poder distintivo (como qual sistema operacional você está usando) só pode adicionar alguns. O HTTP Almanac descreve como as bibliotecas de impressão digital atuais automatizam esse processo de combinar as respostas de muitas APIs diferentes em um "hash", que pode identificar apenas um pequeno grupo de usuários, talvez até apenas um. Maud Nalpas aborda isso com alguns detalhes em este vídeo do YouTube, mas, em resumo, imagine que você veria uma lista dos seus amigos com suas músicas e comidas favoritas e os idiomas que eles falam ... mas com os nomes deles removida. É bem provável que a lista de qualquer pessoa a identifique exclusivamente entre seus amigos, ou pelo menos restrinja da lista a algumas pessoas. É assim que a impressão digital funciona: a lista de coisas 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 diferentes não conectados, que é o objetivo do rastreamento: contornar o desejo do usuário de privacidade.

O que os navegadores fazem contra a coleta de impressão digital?

É importante ressaltar que os fornecedores de navegadores sabem de muitas maneiras diferentes de um site (ou de um terceiro incluído em um site) calcular uma impressão digital distinta para um usuário ou de diferentes bits de informações contribuírem 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 muitas vezes identifica o navegador, o sistema operacional e a versão em uso (e isso contribui para distinguir você de mim, se você e estou usando navegadores diferentes). Algumas delas não são deliberadamente criadas para impressão digital, mas acabam sendo tão como a lista de fontes ou os dispositivos de vídeo e áudio disponíveis para o navegador. O navegador não precisa usar dispositivos, basta receber uma lista deles pelo nome. E alguns foram estabelecidos como contribuintes para um poço de impressão digital após o lançamento, como a renderização exata de pixels de anti-aliasing de fontes em um elemento de tela. Há muito mais, e cada maneira em que o seu navegador difere do meu acrescenta entropia e pode contribuir para uma maneira de distinguir entre você e eu, além de identificar uma pessoa da forma mais única possível em todos os sites. https://amiunique.org (em inglês) tem uma lista longa (mas não abrangente) de possíveis contribuições de impressão digital recursos e a lista cresce o tempo todo, já que há um grande interesse monetário em poder usar a impressão digital, mesmo que os usuários não quero ou talvez não espere por isso).

Não oferece suporte a determinadas APIs poderosas

A resposta dos fornecedores de navegadores a todas essas abordagens para calcular a impressão digital de um usuário é encontrar maneiras de reduzir a quantidade de entropia disponível por essas APIs. A opção mais restritiva é não implementá-las. Isso foi feito por alguns navegadores importantes para várias APIs de hardware e dispositivo (como acesso NFC e Bluetooth de apps da Web do lado do cliente), com preocupações de impressão digital e privacidade citadas como motivos para não serem implementadas. Isso, obviamente, pode afetar seus aplicativos e serviços: você não pode usar uma API em um navegador que não a implemente e isso pode que restringem ou eliminam completamente algumas abordagens de hardware.

O gateway de permissões do usuário

Uma segunda abordagem adotada pelos fornecedores de navegador é impedir acessos à API ou aos dados sem algum tipo de permissão explícita do usuário. Essa abordagem também é usada por motivos de segurança. Um site não pode tirar fotos com sua webcam sem sua permissão. No entanto, aqui, privacidade e segurança podem ter interesses semelhantes. Identificar o local de alguém é uma violação de privacidade, mas também contribui para a exclusividade de uma impressão digital. Requer permissão ver a geolocalização não diminui a entropia extra que um local adiciona à exclusividade dessa impressão digital, mas basicamente elimina o uso de geolocalização para técnicas de impressão digital, porque isso não está mais sendo feito de forma invisível. O objetivo da impressão digital é distinguir os usuários uns dos outros de forma secreta. Se você estiver preparado para que o usuário saiba que você está tentando identificá-lo, não precisará de técnicas de impressão digital: peça que o usuário crie uma conta e faça login com ela.

Como adicionar imprevisibilidade

Uma terceira abordagem adotada em alguns casos é os fornecedores de navegadores "confundir" as respostas das APIs para torná-las menos granulares e, portanto, menos identificável. 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 dos usuários para evitar a coleta acidental de dados de identificação. Os fornecedores de navegadores também podem usar essa abordagem para dados de 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 conhece esses valores para a precisão de microssegundos, mas os valores retornados são deliberadamente reduzidos com precisão, sendo arredondado para os 20 microssegundos mais próximos. para evitar seu uso em técnicas de impressão digital (e também para a segurança para evitar ataques de tempo, admitidamente). O objetivo aqui é para garantir que as APIs continuem úteis, mas tornar as respostas menos identificáveis: em essência, oferecer a "imunidade de rebanho" ao tornar seu dispositivo se parece mais com o de todas as outras pessoas, em vez de ser peculiar para você. O Safari apresenta uma versão simplificada da configuração do sistema por esse mesmo motivo.

Como aplicar um orçamento de privacidade

O Orçamento de privacidade é uma proposta que sugere que os navegadores estimem as informações reveladas por cada superfície de impressão digital. Ele ainda não foi implementado nos navegadores. O objetivo é permitir APIs potentes e, ao mesmo tempo, preservar a privacidade do usuário. Saiba mais sobre a proposta de orçamento para a privacidade.

Usar um ambiente de teste amplo

Tudo isso afeta a maneira como você cria apps e serviços. Em particular, há uma grande diversidade de respostas e abordagens em navegadores e plataformas nessa área. Isso significa que testar seu trabalho em vários ambientes diferentes é fundamental. Obviamente, isso é sempre importante, mas pode ser razoável presumir que a renderização HTML ou o CSS será constante para uma qualquer mecanismo de renderização, independentemente do navegador ou da plataforma do mecanismo. Por isso, pode ser tentador testar em apenas um navegador baseado em Blink, por exemplo). Isso não é o caso do uso de APIs, precisamente porque os navegadores que compartilham um motor de renderização podem diferir drasticamente na forma como protegem a superfície da API contra impressão digital.

O que fazer

Verifique seus próprios dados analíticos e público-alvo para orientar o conjunto de navegadores que você deve priorizar nos testes.
Um bom conjunto de navegadores para testar é Firefox, Chrome, Edge, Safari no computador, Chrome e Samsung Internet no Android e Safari no iOS. Isso garante que você teste os três principais mecanismos de renderização (Gecko no Firefox, vários forks 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 for usado em dispositivos menos comuns, como tablets, smartwatches ou consoles de jogos, faça testes neles também. Algumas plataformas de hardware podem ficar em defasagem com relação às atualizações de navegadores para dispositivos móveis e computadores, o que significa que algumas APIs podem não estar implementadas ou não disponíveis nos navegadores dessas plataformas.
Faça o teste com um ou mais navegadores que tenham a privacidade do usuário como motivação. Inclua as próximas versões de pré-lançamento e de teste dos navegadores mais comuns, quando possível e se estiverem disponíveis: Technology Preview do Safari, Canary do Chrome e canal Beta do Firefox. Isso aumenta a chance de identificar a quebra da API e as mudanças que afetam seus sites antes que elas afetem os usuários. Da mesma forma, tenha em mãos as ambientes em mente com referência a qualquer análise presente. Se a sua base de usuários tiver um número alto de smartphones Android mais antigos, inclua esses dispositivos nos testes. A maioria das pessoas não tem hardware rápido e os últimos lançamentos que uma equipe de desenvolvimento realiza.
Teste um perfil limpo e no modo de navegação anônima/privada. é provável que você já tenha concedido as permissões necessárias em seu perfil pessoal. Teste o que acontece se você negar a permissão ao site para qualquer pergunta.
Testar explicitamente suas páginas na proteção contra impressão digital do Firefox modo Isso vai mostrar caixas de diálogo de permissão se a página estiver tentando usar a 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 de impressão digital ou se o seu próprio serviço depende nisso. Em seguida, considere se o fuzzing deliberado dificulta mais o que você precisa fazer. Considere fazer correções para receber esses dados de outra fonte, fazer sem eles ou usar dados menos granulares.
Conforme conversado no módulo "Terceiros", também é importante fazer a auditoria dos dados dependências para verificar se elas estão usando técnicas de impressão digital. A impressão digital passiva é difícil de detectar (e impossível se um terceiro fizer isso no próprio servidor), mas o modo de impressão digital pode sinalizar algumas técnicas, e a busca por usos de Navigator.userAgent ou da criação inesperada de objetos <canvas> também pode revelar algumas abordagens que merecem uma análise mais detalhada. Também convém procurar usos do termo "correspondência probabilística" no marketing ou material técnico que descreva um terceiro; isso pode indicar o uso de técnicas de impressão digital.

Ferramentas de teste para vários navegadores

É difícil automatizar o teste do código para fins de privacidade, e as coisas a serem observadas durante o teste manual foram descritas anteriormente. O que acontece quando você nega a permissão ao site para as APIs que ele tenta acessar, por exemplo, e como isso é apresentado ao usuário? Um teste automatizado não pode julgar se o site age de modo a ajudar o usuário a confiar nele ou, por outro lado, para incentivar o usuário a não confiar nele. ou pensam que algo está sendo escondido.

No entanto, depois que o site for auditado, o teste de APIs para confirmar que nada foi quebrado em versões mais recentes do navegador (ou nas versões "Beta" e "Pré-lançamento") pode ser automatizado e, em grande parte, deve fazer parte do seu conjunto de testes atual. Algo a considerar com suas ferramentas de teste automatizadas, ao trabalhar com a cobertura de superfície da API, é que a maioria dos navegadores permite algum nível de controle sobre quais APIs e recursos vão estar disponíveis. O Chrome faz isso com chaves de linha de comando, assim como o Firefox, e ter acesso a eles na ferramenta de teste permite que você execute certos testes com APIs ativadas ou desativadas. Consulte, por exemplo, o plug-in de inicialização do navegador do Cypress e o parâmetro launch.args do Puppeteer para saber como adicionar flags do navegador na inicialização.

Só confiar na string do user-agent para informações aproximadas

Tomando outro exemplo, os navegadores enviam uma descrição de si mesmos com cada solicitação no cabeçalho HTTP User-Agent desde o início da Web. Por quase o mesmo tempo, as pessoas têm instruído os desenvolvedores da Web a não usar o conteúdo do cabeçalho user-agent para fornecer conteúdo diferente a navegadores diferentes. Durante todo esse tempo, os desenvolvedores da Web fizeram isso de qualquer maneira, com uma certa justificativa em alguns (mas não em todos) casos. Como os navegadores não querem ser escolhidos pelos sites para uma experiência inferior, o resultado é que todos os navegadores fingem ser todos os outros e a string do user agent é semelhante a:

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.

Ele afirma, entre outras coisas, ser o Mozilla/5.0, um navegador lançado na mesma época que os primeiros astronautas embarcaram na Estação Espacial Internacional há mais de duas décadas. A string "user-agent" é uma fonte rica de entropia para impressão digital. Para reduzir essa capacidade de impressão digital, os fabricantes de navegadores já congelaram o cabeçalho "user-agent" ou estão trabalhando para fazer isso. Esse é outro exemplo de mudança dos dados fornecidos por uma API sem necessariamente remover a API por completo. Enviar um cabeçalho de user-agent em branco quebraria incontáveis sites que presumem que ele está presente. Em geral, os navegadores estão removendo alguns detalhes e mantendo-o praticamente inalterado. Você pode ver isso acontecendo Safari, Chrome e e Firefox). Essa proteção contra o processo de impressão digital detalhado significa essencialmente que você não pode mais confiar que o cabeçalho do user agent seja preciso e, se estiver para fazer isso, é importante encontrar fontes de dados alternativas.

Para ser claro, os dados no user agent não estão sendo totalmente descontinuados, mas estão disponíveis em uma granularidade mais baixa, ou às vezes imprecisos, pois um número mais antigo, mas inalterado, pode ser informado. Por exemplo, o Firefox, o Safari e o Chrome limitam o número de versão do macOS informado a dez. Consulte a Atualização sobre a redução da string do user agent para mais informações. Os detalhes exatos sobre como o Chrome planeja reduzir os dados na string do user agent estão disponíveis em Redução do user agent mas, em resumo, o número da versão do navegador informado terá apenas a versão principal (por isso o número da versão será semelhante a 123.0.0.0, mesmo que a versão do navegador seja 123.10.45.108), e a versão do SO será sem detalhes e congelam a um de um pequeno número de escolhas imutáveis. Assim, uma versão imaginária do Chrome 123.45.67.89 em execução em um "Windows 20" imaginário informaria o número da 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 informações principais que você precisa (a versão do navegador) ainda estão disponíveis: é o Chrome 123, no Windows. Mas a subsidiária informações (a arquitetura do chip, a versão do Windows, a versão do Safari, a versão secundária do navegador) não estará mais disponível após a congelamento.

Compare isso com um user-agent do Chrome "atual" em uma plataforma diferente:

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

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

Da mesma forma, a string de user-agent do Safari mostra uma plataforma e um número de versão do Safari, além de fornecer uma versão do SO no iOS, mas tudo o mais está congelado. Portanto, uma versão imaginária do Safari 1234.5.67 em execução em um macOS 20 imaginário pode fornecer o 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, pode 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**.

Mais uma vez, as informações principais (o Safari, no iOS ou no macOS) estão disponíveis, e o iOS ainda fornece um número de versão do iOS. mas muitas das informações complementares que estavam disponíveis no passado foram congeladas. Isso inclui o número da versão do Safari, que não está necessariamente disponível.

As mudanças no user-agent informado foram bastante debatidas. https://github.com/WICG/ua-client-hints#use-cases summarises resume alguns dos argumentos e motivos da mudança, e Rowan Merewood tem uma apresentação de slides com algumas estratégias para migrar do uso do user-agent para diferenciação, no contexto da proposta de dicas do cliente do UA explicada mais adiante.

Fuzzing

Fuzzing é um termo da prática de segurança, em que as APIs são chamadas com valores inesperados na esperança de lidar com esses valores inesperados e expor um problema de segurança. Os desenvolvedores Web precisam estar familiarizados com scripting em vários locais (XSS), que envolve a adição de um script malicioso a uma página, muitas vezes porque a página não escapa corretamente do HTML injetado (por isso você faz uma consulta de pesquisa) com o texto <script>). Os desenvolvedores back-end estão cientes da injeção de SQL, quando 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 Mesas pequenas do Bobby). O fuzzing, ou teste de fuzz, é mais adequado usada em tentativas automatizadas de fornecer muitas entradas inválidas ou inesperadas para uma API e verificar se há vazamentos de segurança nos resultados; falhas ou outros problemas de tratamento. Todos esses são exemplos de fornecimento de informações imprecisas deliberadamente. No entanto, aqui, isso é feito de forma preventiva pelos navegadores (fazendo com que o user-agent esteja deliberadamente incorreto) para incentivar os desenvolvedores a deixar de depender desses dados.

O que fazer

Verifique se a base de código pode depender da string do user agent (uma pesquisa por navigator.userAgent provavelmente encontrará mais ocorrências no código do lado do cliente, e seu código de back-end provavelmente vai procurar User-Agent como cabeçalho, incluindo seu dependências.
Se você encontrar usos em seu próprio 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 de substituição 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 contornar bugs, mas o user agent se tornará cada vez mais inadequado para fazer isso quando estiver congelado.
Talvez você esteja bem. Se você usar apenas os valores fundamentais da marca, da versão principal e da plataforma, esses valores provavelmente ainda serão disponíveis e estejam corretas na string do user agent.
O MDN descreve boas maneiras de evitar a dependência da string do user agent ("farejamento do navegador"), sendo a principal delas a detecção de recursos.
Se você depender da string do user agent de alguma forma (mesmo ao usar os poucos valores essenciais que continuam úteis), essa é uma boa ideia para testar com os user agents que serão lançados em novas versões dos navegadores. É possível testar com essas versões de navegador futuras usando builds Beta ou de visualização de tecnologia, mas também é possível definir uma string de user-agent personalizada para testes. É possível substituir a string do user agent no Chrome, no Edge, Firefox e Safari, durante o desenvolvimento local, para verificar como o código lida com diferentes valores de user agent que você pode receber dos usuários.

Dicas de cliente

Uma proposta importante para fornecer essas informações é as dicas do cliente do User-Agent, embora não haja suporte para todos os navegadores. Os navegadores compatíveis transmitirão três cabeçalhos: Sec-CH-UA, que fornece a marca e o número da versão do navegador; Sec-CH-UA-Mobile, que indica se a solicitação vem de um dispositivo móvel. e Sec-CH-UA-Platform, que dá nome ao sistema operacional. Analisar esses cabeçalhos é menos fácil do que parece, porque eles são cabeçalhos estruturados, e não strings simples. Isso é aplicado pelos navegadores que enviam valores "difíceis", que serão processados incorretamente se não forem analisados corretamente. Ou seja, como antes, um exemplo de "teste de fuzz" feito preventivamente pelo navegador. Um desenvolvedor que usa esses dados precisa lidar com corretamente, porque os dados são projetados de modo que uma análise inadequada ou preguiçosa provavelmente gere resultados ruins, como mostrar às marcas existem 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 com suporte pode ter uma aparência semelhante a este objeto:

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