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

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

Os desenvolvedores da Web precisam revisar o código do site para usar a string do user agent. Se o site depende da análise da string do user agent para ler o modelo do dispositivo, a versão da plataforma ou a versão completa do navegador, você precisará implementar a API User-Agent Client Hints.

Dicas de cliente do user agent (UA-CH)

As dicas do cliente do user agent permitem acessar o conjunto completo de dados do user agent, mas somente quando os servidores declaram ativamente uma necessidade explícita de dados específicos.

Ao remover dados de usuários expostos de forma passiva, conseguimos medir e reduzir melhor a quantidade de informações expostas intencionalmente por cabeçalhos de solicitação, APIs JavaScript e outros mecanismos.

Por que precisamos de redução do UA e UA-CH?

Antes, a string do user agent transmitia uma grande string de dados sobre o navegador, o sistema operacional e a versão de um usuário a cada solicitação HTTP. Isso foi 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 veio a solicitação (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 existente que analisa a string do UA não deve ser corrompido (embora retorne menos dados). Você precisará migrar para o UA-CH se o site precisar de informações específicas do cliente.

Como o UA e o UA-CH reduzidos funcionam?

Veja um breve exemplo de como a string user agent reduzida e o UA-CH funcionam. Para ver um exemplo mais detalhado, consulte Como melhorar a privacidade do usuário e a experiência do desenvolvedor com as dicas do 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 do 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 essas mesmas informações nos cabeçalhos de dica de cliente do 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 do 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 configurações do usuário para determinar quais dados podem retornar ao servidor nos cabeçalhos das solicitações subsequentes. Exemplo:

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

Dicas importantes do cliente

Se você precisar de um conjunto específico de dicas de 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 de Device-Memory e Viewport-Width, em que Device-Memory é considerado essencial.

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 das dicas de cliente para mais informações.

Detectar tablets com a API UA-CH

Como a linha entre dispositivos móveis, tablets e computadores continua a se tornar menos distinta, e os formatos dinâmicos são mais comuns (telas dobráveis, alternando entre modo laptop e tablet), é aconselhá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 do user agent e as dicas do cliente do user agent vêm da mesma origem. Portanto, as mesmas formas de lógica precisam funcionar.

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

  • Padrão do smartphone: '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 do smartphone: 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 do smartphone: 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 usando a dica Sec-CH-UA-Model de alta entropia.

Como usar e testar o UA reduzido?

Para começar, revise o código do seu site em busca de instâncias e usos da string do user agent. Se o site depende da análise da string do user agent para ler o modelo do dispositivo, a versão da plataforma ou a versão completa do navegador, você precisará implementar a API UA-CH.

Depois de atualizar para a API UA-CH, faça um teste para garantir que você recebeu os dados esperados do user agent. Há três maneiras de testar, cada uma com complexidade cada vez maior.

A disponibilidade escalonada para redução do user agent significa a string do UA totalmente reduzida enviada a todos os dispositivos Chrome. A redução começou com um lançamento secundário do Chrome no segundo trimestre de 2022.

Testar strings personalizadas localmente

Se você quiser testar seu site usando strings de user agent personalizadas para simular dispositivos diferentes, inicie o Chrome com a sinalização de linha de comando --user-agent="Custom string here". Saiba mais sobre sinalizações de linha de comando aqui.

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

Transformar a string no código do seu site

Se você processar a string user-agent do Chrome no código do lado do cliente ou do servidor, poderá transformar essa string no novo formato para testar a compatibilidade. É possível testar substituindo e substituindo a string ou gerando a nova versão e o teste lado a lado.

Suporte para dicas de clientes e dicas importantes

Há três dicas 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. Eles são enviados 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 críticas para que o site seja renderizado.

Otimizar dicas importantes

Um handshake de 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 instruir o navegador a repetir imediatamente a solicitação se a primeira for enviada sem uma dica crítica.

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

Para otimizar dicas críticas (cabeçalho Critical-CH), você precisa interceptar esse handshake e fornecer um modelo para as dicas do cliente. Essas etapas podem ser complexas e exigir conhecimento avançado.

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

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

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

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, independentemente de como essa origem é definida no DNS. A delegação precisa ser processada com Permissions-Policy para qualquer sub-recurso de origem cruzada ou recebida por JavaScript executado no contexto de origem cruzada.

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

A mudança do Chrome na string user agent não afeta diretamente a string que um bot escolhe enviar.

Os bots podem atualizar as próprias strings para refletir a quantidade reduzida de informações enviadas pelo Chrome, mas essa é a 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 de user agent podem fazer isso.

Se você tiver dúvidas sobre bots específicos, entre em contato diretamente com os proprietários para perguntar se eles têm algum plano para alterar a string do user agent.

Interaja e compartilhe feedback

Saiba mais