O que é a redução de user agent?

A redução de user agent (UA) minimiza as informações de identificação compartilhadas na string do user agent, que pode ser usada para impressão digital passiva. Agora que essas mudanças foram lançadas para disponibilidade geral, todas as solicitações de recurso têm um cabeçalho User-Agent reduzido. Como resultado, os valores de retorno de certas interfaces Navigator são reduzidos, incluindo: navigator.userAgent, navigator.appVersion e navigator.platform.

Os desenvolvedores Web precisam analisar o código do site para verificar o uso da string User-Agent. Se o site depender da análise da string User-Agent para ler o modelo do dispositivo, a versão da plataforma ou a versão completa do navegador, será necessário implementar a API User-Agent Client Hints.

Dicas de cliente HTTP do user agent (UA-CH)

As dicas do cliente do User-Agent permitem o acesso ao conjunto completo de dados do User-Agent, mas somente quando os servidores declaram ativamente uma necessidade explícita de partes específicas de dados.

Ao remover dados do usuário expostos de forma passiva, medimos e reduzimos melhor a quantidade de informações que são intencionalmente expostas por cabeçalhos de solicitação, APIs JavaScript e outros mecanismos.

Por que precisamos de UA e UA-CH reduzidos?

Historicamente, a string User-Agent transmitia uma grande string de dados sobre o navegador, o sistema operacional e a versão do usuário com cada solicitação HTTP. Isso era problemático por dois motivos:

  • A granularidade e a abundância de detalhes podem levar à identificação do usuário.
  • A disponibilidade padrão dessas informações pode levar ao rastreamento oculto.

A redução do UA e do UA-CH melhora a privacidade do usuário, compartilhando apenas informações básicas por padrão.

O User-Agent reduzido inclui a marca do navegador e uma versão significativa, de onde a solicitação veio (computador ou dispositivo móvel) e a plataforma. Para acessar mais dados, as dicas do cliente do User-Agent permitem que você solicite informações específicas sobre o dispositivo ou as condições do usuário.

Além disso, com o tempo, a string User-Agent ficou mais longa e complexa, o que levou a uma análise de string propensa a erros. O UA-CH fornece dados estruturados e confiáveis que são mais fáceis de interpretar. O código atual que analisa a string do UA não vai ser interrompido (embora retorne menos dados), e você vai precisar migrar para o UA-CH se o site precisar de informações específicas do cliente.

Como funcionam o UA e o UA-CH reduzidos?

Confira um exemplo breve de como a string User-Agent reduzida e o UA-CH funcionam. Para um exemplo mais detalhado, consulte Como melhorar a privacidade do usuário e a experiência do desenvolvedor com as dicas de cliente do user agent.

Um usuário abre o navegador e digita example.com na barra de endereço:

  1. O navegador envia uma solicitação para carregar a página da Web.

    1. O navegador inclui o cabeçalho User-Agent com a string User-Agent reduzida. Por exemplo: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36

    2. O navegador inclui as mesmas informações nos cabeçalhos de sugestão de cliente User-Agent padrão. Exemplo:

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. O servidor pode pedir ao navegador para enviar outras dicas de cliente, como o modelo do dispositivo, com o cabeçalho de resposta Accept-CH. Por exemplo: Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model

  3. O navegador aplica políticas e a configuração do usuário para determinar quais dados podem ser retornados ao servidor em cabeçalhos de solicitação subsequentes. Por exemplo:

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

Dicas de cliente HTTP críticas

Se você precisar de um conjunto específico de dicas do cliente na solicitação inicial, use o cabeçalho de resposta Critical-CH. Os valores Critical-CH precisam ser um subconjunto dos valores solicitados por Accept-CH.

Por exemplo, a solicitação inicial pode incluir uma solicitação para Device-Memory e Viewport-Width, em que Device-Memory é considerado crítico.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

Se o navegador exigir uma dica crítica (Critical-CH) para renderizar corretamente a página da Web, o servidor poderá solicitar essas informações adicionais com o cabeçalho Accept-CH. Em seguida, o navegador pode enviar uma nova solicitação para a página, incluindo a dica crítica.

Em resumo, Accept-CH solicita todos os valores que você quer para a página, enquanto Critical-CH solicita apenas o subconjunto de valores que você precisa ter no carregamento para carregar a página corretamente. Consulte a especificação de confiabilidade de dicas do cliente para mais informações.

Detectar dispositivos tablet com a API UA-CH

À medida que a linha entre dispositivos móveis, tablets e computadores continua se tornando menos distinta e os formatos dinâmicos são mais comuns (telas dobráveis, mudança entre o modo laptop e tablet), é recomendável usar o design responsivo e a detecção de recursos para apresentar uma interface do usuário adequada.

No entanto, as informações fornecidas pelo navegador para a string User-Agent e as dicas do cliente User-Agent vêm da mesma fonte. Portanto, os mesmos formulários de lógica devem funcionar.

Por exemplo, se este padrão for verificado na string do UA:

  • Padrão do telefone: 'Android' + 'Chrome/[.0-9]* Mobile'
  • Padrão do tablet: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

A interface de cabeçalhos UA-CH padrão correspondente pode ser verificada:

  • Padrão de telefone: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • Padrão do tablet: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

Ou a interface JavaScript equivalente:

  • Padrão de telefone: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • Padrão do tablet: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

Para casos de uso específicos de hardware, o nome do modelo do dispositivo pode ser solicitado pela dica Sec-CH-UA-Model de alta entropia.

Como usar e testar a UA reduzida?

Para começar, analise o código do seu site para encontrar instâncias e usos da string User-Agent. Se o site depender da análise da string User-Agent para ler o modelo do dispositivo, a versão da plataforma ou a versão completa do navegador, será necessário implementar a API UA-CH.

Depois de atualizar para a API UA-CH, faça testes para garantir que você receba os dados esperados do User-Agent. Há três maneiras de testar, cada uma com um nível de complexidade maior.

A disponibilidade escalonada para redução do user agent significa que a string do UA totalmente reduzida é enviada em todos os dispositivos Chrome. A redução começou com uma versão menor do Chrome no segundo trimestre de 2022.

Testar strings personalizadas localmente

Se você quiser testar seu site usando strings User-Agent personalizadas para simular diferentes dispositivos, inicie o Chrome com a flag de linha de comando --user-agent="Custom string here". Saiba mais sobre as flags de linha de comando.

Como alternativa, use o emulador de dispositivos no Chrome DevTools.

Transformar a string no código do seu site

Se você processar a string user-agent atual do Chrome no código do lado do cliente ou do servidor, poderá transformá-la no novo formato para testar a compatibilidade. Você pode testar substituindo e substituindo a string ou gerando a nova versão e testando lado a lado.

Suporte a dicas do cliente e dicas críticas

Há três Sugestões de cliente padrão retornadas ao servidor, incluindo o nome do navegador e a versão principal, um booleano que indica se o navegador está em um dispositivo móvel e o nome do sistema operacional. Elas são enviadas após o handshake do protocolo Transport Layer Security (TLS). Elas já estão disponíveis e são compatíveis com seu navegador.

No entanto, pode haver momentos em que você precisa recuperar informações importantes para renderizar o site.

Otimizar dicas importantes

Um handshake TLS é a primeira etapa para criar uma conexão segura entre o navegador e o servidor da Web. Sem uma intervenção, o cabeçalho de resposta Critical-CH foi projetado para informar ao navegador que ele deve tentar a solicitação novamente imediatamente se a primeira foi enviada sem uma dica crítica.

Diagrama de sequência para dicas de cliente com dicas essenciais.
Quando uma dica crítica é solicitada pelo servidor, o cliente tenta novamente enviar a primeira solicitação para a página da Web com a dica crítica. Neste exemplo, a dica para Sec-CH-UA-Model é solicitada duas vezes: uma como uma dica do cliente com Accept-CH e outra como uma dica crítica com Critical-CH.

Para otimizar dicas importantes (cabeçalho Critical-CH), é necessário interceptar essa troca de informações e fornecer um modelo para as dicas do cliente. Essas etapas podem ser complexas e exigem conhecimento avançado.

Os ACCEPT_CH frames HTTP/2 e HTTP/3, combinados com a extensão ALPS do TLS, são uma otimização no nível da conexão para entregar as preferências de sugestão de cliente do servidor a tempo para a primeira solicitação HTTP. Eles exigem uma configuração complexa e recomendamos o uso apenas para informações realmente importantes.

O BoringSSL (uma ramificação do OpenSSL) ajuda você a trabalhar com os recursos experimentais do Google no Chromium. No momento, o ALPS só está implementado no BoringSSL.

Se você precisar usar dicas importantes, consulte nosso guia sobre confiabilidade e otimização de dicas importantes.

Perguntas frequentes

Por quanto tempo as dicas especificadas pelo cabeçalho Accept-CH serão enviadas?

As dicas especificadas pelo cabeçalho Accept-CH serão enviadas durante a sessão do navegador ou até que um conjunto diferente de dicas seja especificado.

O UA-CH funciona com HTTP/2 e HTTP/3?

O UA-CH funciona com conexões HTTP/2 e HTTP/3.

Os subdomínios (e CNAMEs) exigem uma página de nível superior Permissions-Policy para acessar o UA-CH de alta entropia?

O UA-CH de alta entropia em cabeçalhos de solicitação é restrito em solicitações de origem cruzada, independente de como essa origem é definida no lado do DNS. A delegação precisa ser gerenciada por Permissions-Policy para qualquer subrecurso entre origens ou obtida por JavaScript que seja executado no contexto entre origens.

Como a redução do user agent afeta a detecção de bots?

A mudança do Chrome na string User-Agent não afeta diretamente a string User-Agent que um bot escolhe enviar.

Os bots podem atualizar as próprias strings para refletir as informações reduzidas enviadas pelo Chrome, mas isso é uma escolha de implementação deles. O Chrome ainda está enviando o mesmo formato de User-Agent, e os bots que anexam o próprio identificador ao final de uma string User-Agent do Chrome podem continuar fazendo isso.

Se você tiver dúvidas sobre bots específicos, entre em contato diretamente com os proprietários para perguntar se eles têm planos de mudar a string User-Agent.

Engajamento e compartilhamento de feedback

Saiba mais