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

Esta página foi traduzida pela API Cloud Translation.

Impressão digital

Impressão digital significa tentar identificar um usuário quando ele retorna ao seu site ou identificar o mesmo usuário em sites diferentes. Muitas características podem ser diferentes entre sua configuração e a de outra pessoa. Por exemplo, talvez você esteja usando um tipo diferente de dispositivo e navegador diferente, que tenham um tamanho de tela diferente e diferentes fontes instaladas. Com a fonte "Dejavu Sans", instalado e se não tiver, qualquer site poderá diferenciar você de mim ao verificar a fonte. É assim que técnicas de impressão digital funcionam; você cria uma coleção desses pontos de dados, e cada um fornece mais maneiras de distinguir os usuários.

Uma definição mais formal pode ser assim: impressão digital é a ação de usar recursos óbvios e não óbvios características da configuração de um usuário para tentar diferenciá-lo 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 o uso de técnicas de impressão digital do usuário é importante, como a detecção de fraudes. 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 estão nas extremidades. com os dedos.

Os fornecedores de navegadores sabem que os usuários não gostam de serem rastreados e estão sempre implementando recursos para limitar o uso de técnicas de impressão digital , que você já viu no módulo anterior. Aqui, pretendemos analisar como esses recursos podem afetar sua empresa. e como fazer o que quer fazer com proteção da 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. Caso seu app exija login dos usuários, os usuários estão se identificando para você, com o consentimento deles, e de forma que possam recusar unilateralmente 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 seus terceiros quanto ao uso de técnicas de 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. Pode ser possível para inspecionar essas solicitações e ver quais dados estão sendo transmitidos de volta ao criador, 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.

Consulte também 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 em uso. Ela também é chamada de "correspondência probabilística" ou como 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

Frequentemente, sua combinação pessoal de todos esses atributos é exclusiva para você ou, pelo menos a um pequeno grupo de pessoas semelhantes, isso pode ser usado para rastrear você furtivamente.

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

Há uma distinção útil aqui a ser feita entre técnicas de impressão digital passivas e ativas. Uma impressão digital passiva é aquela que usa informações fornecidas ao site por padrão; uma técnica ativa de técnicas de impressão digital que interroga explicitamente o navegador em busca de informações adicionais. Essa distinção é importante porque os navegadores podem tentar detectar, interceptar ou mitigar técnicas ativas. As APIs podem ser restritas ou protegidas por uma caixa de diálogo Pedir a permissão do usuário (e, portanto, alertar o usuário de que eles estão sendo usados ou permitir que o usuário negue a permissão) 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 é uma exemplo disso, e veremos 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 está fazendo diferentes ramificações de código, dependendo do user agent, então esse código pode ser corrompido à medida que os navegadores congelam ou interrompem essas informações. Testar é a melhor defesa aqui ( ver mais tarde).

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

A medida técnica de quanta informação 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 técnicas de impressão digital existentes automatizam esse processo de combinação das respostas de muitas APIs diferentes em um "hash", que pode identificar somente uma um pequeno grupo de usuários, talvez apenas um. Maud Nalpas aborda isso com alguns detalhes em este vídeo do YouTube, mas, resumindo, imagine que você viu uma lista de seus amigos com suas músicas favoritas, comidas favoritas e os idiomas que falam ... mas com seus nomes 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, identificar um usuário como a mesma pessoa em dois sites diferentes não conectados fica mais fácil, que é o objetivo de rastreamento: para contornar o desejo do usuário por privacidade.

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

É importante ressaltar que os fornecedores de navegadores estão bem cientes das diversas maneiras pelas quais um site (ou um terceiro incluído em um site) para calcular uma impressão digital distinta de um usuário ou para diferentes partes de informação que contribuam para a exclusividade da 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. O site 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).

Sem 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 dos principais navegadores para uma variedade de APIs de hardware e dispositivos (como acesso NFC e Bluetooth do aplicativos da Web do lado do cliente), com questões de impressão digital e privacidade citadas como motivos por que elas não foram 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 é geralmente adotada por motivos de segurança: um site não deve ser capaz de 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 é violação de privacidade em si, é claro, mas também contribui para a singularidade 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. A ideia central o uso de técnicas de impressão digital para distinguir clandestinamente os usuários. Se você estiver preparado para que o usuário saiba você estiver tentando identificá-los, então não serão necessárias técnicas de impressão digital: peça para o usuário criar uma conta e fazer login a ele.

Adicionando 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 de usuários, para evitar coletar acidentalmente dados que são de identificação. Fornecedores de navegadores também podemos adotar essa abordagem em relação aos dados de API disponibilizados para apps da Web e terceiros. Um exemplo disso é APIs de tempo muito precisas usadas para medir a performance 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 estimam as informações reveladas por cada plataforma de técnicas de impressão digital. Ele ainda não foi implementado em 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.

Use um ambiente de teste amplo

Tudo isso vai afetar a forma como você cria apps e serviços. Há uma ampla diversidade de respostas e abordagens em vários 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 se aplica ao uso de APIs precisamente porque os navegadores que compartilham uma mecanismo de renderização pode diferir drasticamente na proteção da superfície da API contra técnicas de impressão digital.

O que fazer

Verifique suas próprias análises e público-alvo para orientar o conjunto de navegadores que você deve priorizar ao realizar os testes.
Um bom conjunto de navegadores para testar são: Firefox, Chrome, Edge, Safari no computador, Chrome e Samsung Internet no Android, e Safari no iOS. Isso garante o 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 nas plataformas para dispositivos móveis e computadores.
Caso seu site também possa ser usado em dispositivos menos comuns, como tablets, smartwatches ou consoles de jogos, faça o teste lá 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. Incluir versões de pré-lançamento e teste futuras dos seus navegadores mais comuns onde você pode e se eles estão disponíveis para você: visualização de tecnologia do Safari, Canário do Chrome, canal Beta do Firefox. Isso aumenta suas chances de identificar falhas de API e alterações que afetam seus sites antes que elas sejam afetadas. seus usuários. Da mesma forma, tenha em mãos as ambientes em mente com referência a qualquer análise presente. Se as tem um grande número de smartphones Android mais antigos, então não se esqueça de incluí-los nos seus 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 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. Considere se o fuzzing deliberado dificulta a realização do que você precisa. Considere fazer as correções necessárias para obter 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

Testar seu código para fins de privacidade é difícil de automatizar, e o que procurar ao testar manualmente é descrito 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 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, após a auditoria do site, os testes de APIs para confirmar que nada foi corrompido nas versões mais recentes dos navegadores (ou nas a próxima "versão Beta" e "prévia" ) pode ser automatizada e, em grande parte, precisa fazer parte do pacote 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. (Veja, por exemplo, browser-launch plugin um o parâmetro launch.args do nd puppeteer para formas para adicionar sinalizações do navegador ao iniciar.

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

Tomando outro exemplo, os navegadores enviaram, desde o início da web, uma descrição de si mesmos a cada solicitação da Cabeçalho do user agent HTTP. Há quase tanto tempo, as pessoas têm incentivado os desenvolvedores Web a não usar o conteúdo do cabeçalho user agent exibir conteúdos diferentes em navegadores diferentes e, durante todo esse tempo, os desenvolvedores da web fizeram isso mesmo assim, com uma certa quantidade de em alguns casos (mas não em todos). 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 técnicas de impressão digital, e, para mitigar esse problema de impressão digital, 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 completamente a API. O envio de um cabeçalho user agent em branco corromperia inúmeros sites que presumem que ele está presente. Em geral, o que os navegadores fazem é remover alguns dos detalhes e, em seguida, mantê-lo praticamente inalterado daquele momento em diante. 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 esclarecer, 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, no Firefox, Safari e Chrome. o número da versão do macOS relatada para 10. Consulte Atualização sobre a redução da string do user agent. para mais detalhes. 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. Então, uma versão imaginária do Chrome 123.45.67.89 em execução em um "Windows 20" informaria o 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 informações principais de 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 "atual" User agent do Chrome 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 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 todo o resto fica congelado. Assim, uma versão imaginária do Safari 1234.5.67 em execução em um macOS 20 imaginário poderia fornecer ao user agent da seguinte forma:

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

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. É importante ressaltar que isso inclui o Safari número da versão, que não está necessariamente disponível.

As mudanças no user agent relatado foram debatedas acaloradamente. https://github.com/WICG/ua-client-hints#use-cases resumes (em inglês) resume alguns dos argumentos e motivos da mudança, e Rowan Merewood tem uma apresentação de slides com algumas estratégias para deixar de usar o user agent para diferenciação, no contexto da proposta de dicas de 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 por 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. Aqui, no entanto, isso está sendo feito preventivamente por navegadores (ao tornar o user agent deliberadamente incorreto) para incentivar os desenvolvedores a parar de confiar nesses 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.
A MDN descreve boas maneiras de evitar a dependência da string do user agent ("browser sniffing"), sendo que a principal é a detecção de atributos.
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 fazer testes com os próximos navegadores as próprias versões por meio de builds Beta ou de prévia 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 são as dicas de cliente HTTP do user agent, embora isso não seja suportado em 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, pois eles são Cabeçalhos estruturados em vez de strings simples, Isso é feito pelos navegadores que enviam informações valores, que serão tratados incorretamente se não forem devidamente analisados. 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 conforme navigator.userAgentData, que em um navegador compatível pode se parecer com este objeto:

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