Por que o Google bloqueia contas e o que seu antidetect tem a ver com isso

Introdução

A Google complicou mais uma vez os mecanismos de identificação digital, implementando um novo e mais complexo nível de proteção baseado em cabeçalhos HTTP proprietários. Esta mudança silenciosa apanhou a maior parte do mercado de surpresa, provocando uma onda de atualizações apressadas. Enquanto os outros se apressavam a lançar "correções" superficiais, nós percebemos que não estávamos a lidar com um problema menor, mas sim com uma mudança fundamental que exigia uma análise profunda e abrangente.

Neste artigo, explicaremos como funciona este novo mecanismo de rastreamento. Primeiro, analisaremos detalhadamente o conteúdo e o propósito dos cabeçalhos-chave — desde a família X-Browser-* até os críticos X-Client-Data e X-Chrome-Id-Consistency-Request, explicando exatamente como eles permitem que a Google distinga um utilizador real de um antidetect. Em seguida, apresentaremos os resultados da nossa extensa investigação, na qual mostraremos sem rodeios como os principais navegadores antidetect lidam (ou, mais frequentemente, não lidam) com esta nova ameaça. Se já está familiarizado com a teoria, pode ir diretamente para os resultados da nossa investigação.

No entanto, para compreender verdadeiramente por que algumas soluções constroem uma impressão digital coesa e credível, enquanto outras apenas criam um mosaico de artefactos facilmente detetáveis, recomendamos vivamente a leitura da análise completa. É na implementação correta destas subtilezas que reside a linha que separa um funcionamento estável de um bloqueio inevitável.

De que cabeçalhos estamos a falar?

Ao interagir com os seus serviços, o Google Chrome utiliza um grupo de cabeçalhos HTTP proprietários que desempenham um duplo papel. Oficialmente, destinam-se a tarefas internas: testes A/B, recolha de telemetria e confirmação da autenticidade do navegador. No entanto, a sua aplicação real é muito mais ampla — é um poderoso mecanismo para identificar utilizadores e detetar atividades anómalas, o que torna a sua análise e emulação uma tarefa fundamental para os desenvolvedores de navegadores antidetect. Vamos analisá-los em mais detalhe.

Família X-Browser-*

// Cabeçalhos X-Browser-* //
X-Browser-Channel: stable
X-Browser-Year: 2025
X-Browser-Validation: XPdmRdCCj2OkELQ2uovjJFk6aKA=
X-Browser-Copyright: Copyright 2025 Google LLC. All rights reserved.

Inclui 4 cabeçalhos que servem para a identificação básica da compilação do navegador e para a verificação da sua autenticidade. Desta forma, a Google determina que o pedido foi feito a partir de um Google Chrome real, e não de outro navegador que tenta mascarar-se como tal.

• X-Browser-Channel — informa o servidor sobre o canal de lançamento do navegador (stable, beta, dev, canary). Isto permite à Google adaptar o conteúdo ou a funcionalidade dependendo da estabilidade da compilação. Para a maioria dos utilizadores, o valor é stable.

• X-Browser-Year — o ano de lançamento da versão do navegador utilizada.

• X-Browser-Copyright — uma linha padrão com informações sobre direitos de autor.

• X-Browser-Validation — o cabeçalho mais importante deste grupo, destinado a proteger contra bots e clientes modificados. O seu valor é gerado com base em dois componentes: uma chave de API incorporada no ficheiro binário do Chrome (única para cada sistema operativo) e a string User-Agent do pedido atual.

Cabeçalho X-Client-Data

// Cabeçalho X-Client-Data //
x-client-data: CJa2yQEIpLbJAQipncoBCMvrygEIk6HLAQj0o8sBCIWgzQEI/aXOAQiTgc8BCP+EzwEIkIfPAQiFis8BCKqLzwEIpIzPARiYiM8BGIyJzwE=

Descodificado:
message ClientVariations {
  // IDs de variação ativos visíveis para a Google neste cliente. São reportados para análise, mas não afetam diretamente qualquer comportamento do lado do servidor.
  repeated int32 variation_id = [3300118, 3300132, 3313321, 3323339, 3330195, 3330548, 3362821, 3379965, 3391635, 3392127, 3392400, 3392773, 3392938, 3393060];
  // IDs de variação ativos visíveis para a Google neste cliente que acionam comportamento do lado do servidor. São reportados para análise *e* afetam diretamente o comportamento do lado do servidor.
  repeated int32 trigger_variation_id = [3392536, 3392652];
}

O cabeçalho X-Client-Data é uma ferramenta fundamental do sistema de "testes de campo" (Field Trials) da Google, representando um objeto protobuf codificado em Base64 seguro para a web. Ele informa os servidores da Google sobre quais funcionalidades experimentais estão ativas nesta instância do navegador, permitindo a realização de testes A/B em grande escala, a introdução gradual de novas funcionalidades para um círculo limitado de utilizadores e a alteração dinâmica do comportamento dos serviços web (como a Pesquisa Google ou o YouTube) para um cliente específico.

A mensagem contém duas listas principais de identificadores numéricos:

1. variation_id: IDs dos grupos de experiências ativos no navegador.
2. trigger_variation_id: uma lista separada de IDs marcados como "trigger" para as propriedades web da Google. Logicamente separada dos variation_id normais.

A característica principal deste mecanismo reside no seu ciclo de vida: os valores das variações são definidos no primeiro arranque do perfil do Chrome e podem mudar ligeiramente entre arranques subsequentes. A remoção completa da pasta do perfil inicia a sua regeneração. Assim, este cabeçalho não é uma "fotografia" estática, mas sim um identificador dinâmico, único para cada perfil.

Cabeçalho X-Chrome-Id-Consistency-Request

// Cabeçalho X-Chrome-Id-Consistency-Request //

x-chrome-id-consistency-request: version=1,client_id=77185425430.apps.googleusercontent.com,device_id=78e64ade-1b2a-4ea6-9068-9765aa13e80a,signin_mode=all_accounts,signout_mode=show_confirmation

X-Chrome-ID-Consistency-Request é um cabeçalho de serviço, um elemento-chave do mecanismo DICE (Desktop Identity Consistency). A sua principal tarefa é garantir que a lista de contas Google nas quais iniciou sessão no próprio navegador (no perfil do Chrome) coincida sempre com a lista de contas ativas nas páginas web da Google, como o Gmail, Drive ou YouTube. Simplificando, é uma espécie de garantia de consistência de contas que o Chrome apresenta aos sites da Google.

Este cabeçalho é enviado em cada pedido aos domínios da Google relacionados com a gestão de contas (como accounts.google.com) e contém informações sobre todas as sessões ativas no navegador. Em resposta, o servidor envia o cabeçalho X-Chrome-ID-Consistency-Response, que indica ao navegador quais contas devem ser adicionadas ou removidas na página web para alcançar a correspondência total. É graças a este mecanismo que, quando adiciona uma nova conta no navegador Chrome, ela aparece instantaneamente na lista de contas disponíveis no YouTube sem necessidade de iniciar sessão novamente.

Como o cabeçalho X-Chrome-Id-Consistency-Request está intrinsecamente ligado à função de autorização no próprio perfil do navegador, a sua ausência ou formação incorreta torna-se um marcador claro de emulação para a Google. A sua ausência ao aceder aos serviços de autenticação da Google é um sinal explícito e facilmente verificável de que não se trata de um utilizador padrão do Chrome. Esta é uma falha arquitetónica que a maioria dos navegadores antidetect do mercado comete, revelando instantaneamente a sua falta de autenticidade.

A maioria das soluções antidetect no mercado não consegue reproduzir corretamente este mecanismo. No entanto, mesmo a sua presença formal não garante a autenticidade da impressão digital. Num dos produtos que analisámos, a função de sincronização de contas é declarada e o cabeçalho é de facto enviado, mas com que qualidade imita o comportamento do Chrome real? É nos detalhes desta implementação que se escondem novos riscos de deteção, como demonstraremos na nossa investigação.

Investigação: como os antidetects populares emulam o Chrome

A teoria é a base, mas a verdadeira imagem do mercado só pode ser vista na prática. Para avaliar objetivamente como as principais soluções antidetect lidam com a emulação dos mecanismos-chave do Chrome, realizámos a nossa própria investigação aprofundada. A nossa análise foca-se em dois aspetos críticos: a correção dos cabeçalhos enviados e a qualidade da implementação da função de autorização na conta Google — um elemento indispensável de um navegador moderno.

E, seguindo o nosso princípio de transparência, descreveremos detalhadamente toda a metodologia. Isto permitir-lhe-á não apenas confiar nos nossos resultados, mas também verificar de forma independente qualquer navegador antidetect e certificar-se da sua fiabilidade.

Como verificar o seu navegador antidetect?

Verificação dos cabeçalhos:

1. Crie uma sessão/perfil no seu navegador antidetect
2. Inicie a sessão, aguarde 20-30 segundos (isto é necessário para a atribuição dos grupos de experiências), pare a sessão
3. Inicie a sessão novamente
4. Abra as DevTools premindo a tecla F12 > mude para o separador "Network"
5. Aceda a accounts.google.com
6. Verifique os cabeçalhos num par de pedidos a este domínio
7. Repita o procedimento com 5 sessões/perfis diferentes para reduzir a margem de erro

Deverá obter uma lista de 6 cabeçalhos, por exemplo:

// Novos Cabeçalhos do Chrome //

x-browser-channel: stable
x-browser-copyright: Copyright 2025 Google LLC. All rights reserved.
x-browser-validation: qSH0RgPhYS+tEktJTy2ahvLDO9s=
x-browser-year: 2025

x-chrome-id-consistency-request: version=1,client_id=77185425430.apps.googleusercontent.com,device_id=1efe3440-1559-4a46-b9f4-ea61f9a587b9,signin_mode=all_accounts,signout_mode=show_confirmation

x-client-data: CKy1yQEIkbbJAQiktskBCKmdygEI3vjKAQiSocsBCJGkywEIhqDNAQj9pc4BCPaEzwEI04jPAQiFis8BCJaMzwEIo4zPARiYiM8B

Descodificado:
message ClientVariations {
  // IDs de variação ativos visíveis para a Google neste cliente. São reportados para análise, mas não afetam diretamente qualquer comportamento do lado do servidor.
  repeated int32 variation_id = [3300012, 3300113, 3300132, 3313321, 3325022, 3330194, 3330577, 3362822, 3379965, 3392118, 3392595, 3392773, 3393046, 3393059];
  // IDs de variação ativos visíveis para a Google neste cliente que acionam comportamento do lado do servidor. São reportados para análise *e* afetam diretamente o comportamento do lado do servidor.
  repeated int32 trigger_variation_id = [3392536];
}

Verificação da autorização na conta Google:

1. Crie uma sessão/perfil no seu navegador antidetect
2. Inicie a sessão
3. No canto superior direito, clique no ícone do perfil
4. Verifique a presença do botão "Sign in to..." — se este botão estiver presente, o início de sessão na conta Google é tecnicamente possível
5. Clique nele e inicie sessão na sua conta Google
6. Clique no ícone da conta autenticada no canto superior direito > "Manage your Google Account"
7. Vá para "Security" > "Your devices" > "Manage all devices"
8. Clique no dispositivo atual e, se necessário, confirme a palavra-passe da conta
9. Preste atenção ao nome do dispositivo que está disponível para a Google (exibido sob o nome do SO)

Então, recolheu todos os dados necessários. Agora é hora de dar um veredito. Para sistematizar a análise e dar uma avaliação objetiva ao seu navegador antidetect, compare os resultados obtidos com esta lista de verificação. Quanto mais respostas positivas obtiver, melhor será a qualidade da emulação e mais difícil será para os sistemas da Google distingui-lo de um utilizador real.

• [ ] O navegador envia todos os cabeçalhos da família X-Browser-*?
• [ ] O navegador envia o cabeçalho X-Client-Data e este contém mais do que um variation_id?
• [ ] O navegador envia o cabeçalho X-Chrome-Id-Consistency-Request e suporta o início de sessão na conta Google?
• [ ] O nome do dispositivo ao iniciar sessão na Google parece realista?

Resultados da nossa investigação

Os resultados da nossa investigação, resumidos na tabela final, pintam um quadro inequívoco e bastante alarmante. Por trás das promessas de marketing brilhantes, escondem-se falhas conceptuais na implementação. Para compreender a profundidade destes problemas, vamos analisar cada coluna, cada linha de defesa — em detalhe.

Primeira linha de defesa: a assinatura básica do navegador

Os quatro cabeçalhos da família X-Browser-* não são apenas informações de serviço, mas a "assinatura" básica do Chrome moderno. A sua ausência é um sinal instantâneo e óbvio para os sistemas da Google de que não se trata de um navegador autêntico. Como se pode ver na tabela, a esmagadora maioria das soluções (Dolphin Anty, Adspower, Multilogin, GoLogin, MoreLogin) simplesmente não gera estes cabeçalhos. Este é um erro grosseiro que imediatamente destaca o perfil em relação ao tráfego real, tornando as verificações posteriores praticamente desnecessárias.

É de notar separadamente o Undetectable: apesar da implementação formal destes cabeçalhos, nos perfis Android o X-Browser-Validation permanece vazio. Esta inconsistência crítica com o comportamento de um navegador real anula todo o valor da sua emulação formal.

Anomalia comportamental: X-Client-Data estático e limitado

Aqui reside uma vulnerabilidade fundamental na qual quase todos tropeçam. O problema é duplo: não reside apenas na estaticidade do cabeçalho, mas também na sua estrutura primitiva.

A maioria das soluções gera um x-client-data que contém apenas um variation_id e ignora completamente o trigger_variation_id. Enquanto isso, o Chrome real, participando em dezenas de "testes de campo" simultaneamente, forma um cabeçalho com um rico conjunto de múltiplos variation_id e, regra geral, vários trigger_variation_id.

Esta impressão digital, inicialmente defeituosa e facilmente distinguível, é agravada pelo facto de permanecer inalterada. Tal comportamento (um ID, sem atualizações) é característico de um navegador real apenas nos primeiros 10-30 segundos após o arranque. Depois disso, o Chrome real começa a receber informações da Google sobre as experiências ativas, e o conteúdo do cabeçalho enriquece e muda.

Como resultado, ao longo de toda a sessão, tal perfil envia um sinal anómalo que pode ser descrito da seguinte forma: "Eu sou um emulador que não só não participa nas experiências da Google, como também não consegue atualizar o seu estado".

X-Chrome-Id-Consistency-Request como marcador de vulnerabilidades no mecanismo de sincronização

A capacidade de iniciar sessão numa conta Google diretamente através da interface do navegador não é apenas uma conveniência, mas um elemento crucial de confiança, intrinsecamente ligado ao cabeçalho X-Chrome-Id-Consistency-Request. Como estabelecemos anteriormente, este cabeçalho é o garante da integridade das contas. Consequentemente, se o navegador não suportar esta função, ele fisicamente não pode enviar este cabeçalho, o que é para a Google uma prova direta de emulação.

Os nossos testes mostraram que quase nenhum dos participantes do mercado conseguiu implementar corretamente este mecanismo.

A única exceção, além do Linken Sphere, é o Dolphin Anty. No entanto, a sua implementação apenas agrava o problema. Por defeito, na configuração padrão do perfil, a função de envio do nome do dispositivo está desativada. Como resultado, ao autorizar numa conta Google, o Dolphin não transmite este parâmetro criticamente importante — uma diferença fundamental em relação ao comportamento do Chrome real, que sempre transmite este valor.

Se a função de substituição do DeviceName for ativada manualmente, o sistema propõe gerar um nome, e aqui reside a segunda, não menos grave, fraqueza. A esmagadora maioria dos utilizadores nunca altera o nome do seu dispositivo, utilizando os identificadores padrão definidos pelo fabricante. Em vez de imitar estes nomes de fábrica reais (MacBookPro16,1, ProBook 400, VivoBook E14 E402), o algoritmo do Dolphin cria construções linguisticamente não naturais segundo um modelo de máquina único. Durante os testes, obtivemos exemplos como: BernieFast, JewellSuperTablet, KorbinUltraLaptop, MazieServer e LiaTablet (é de notar que todos foram obtidos em testes em configurações de PC).

Este é um padrão morto e facilmente detetável. As pessoas não nomeiam os seus dispositivos juntando um nome próprio com um adjetivo ou o tipo de gadget. Em vez de mascarar, isto cria uma impressão digital única e facilmente rastreável que não só denuncia um perfil específico, mas também permite agrupar todas as contas criadas com esta ferramenta.

Os resultados da análise levam-nos a um veredito inequívoco. Não vemos erros isolados, mas uma vulnerabilidade sistémica na própria abordagem: a maioria das soluções funciona segundo o princípio de uma lista de verificação, reproduzindo formalmente elementos individuais, mas ignorando completamente a sua lógica interna e interconexão. Para os sistemas de análise modernos da Google, uma omissão tão crucial serve como prova direta de emulação.

Novos vetores de deteção: riscos e oportunidades estratégicas

Apesar das declarações oficiais da Google sobre a baixa entropia do cabeçalho X-Client-Data, as nossas investigações, que incluem várias centenas de arranques de teste do Chrome, demonstram o contrário: não registámos uma única repetição do conjunto de variações gerado. Isto força-nos a reavaliar o seu papel nos mecanismos de rastreamento.

Para o utilizador comum, este cabeçalho torna-se mais um vetor para a criação de uma impressão digital única. Em conjunto com o endereço IP e outros parâmetros do dispositivo, permite identificar com alta precisão um navegador específico dentro de uma mesma rede. No entanto, no contexto dos navegadores antidetect, a principal ameaça não vem da singularidade em si, mas da imperfeição da sua imitação. Como mostrámos anteriormente, a estrutura primitiva e o comportamento estático deste cabeçalho na maioria das soluções são uma anomalia facilmente detetável.

É importante compreender a escala e os objetivos desta recolha de dados: - Os cabeçalhos da família X-Browser-* e X-Client-Data são enviados para todos os domínios afiliados à Google. - O cabeçalho X-Chrome-Id-Consistency-Request tem um objetivo mais restrito e é transmitido apenas para serviços diretamente relacionados com os processos de autenticação.

Embora estes cabeçalhos possam ainda não ser o principal gatilho para os sistemas anti-bot da Google, a situação atual não deve ser enganadora. Estamos a observar uma fase de recolha de dados em grande escala e de calibração de algoritmos. A implementação completa de sistemas de proteção baseados neles é o próximo passo lógico. Os dados são enviados apenas para os domínios da Google, mas isso não impede a corporação de partilhar informações com parceiros, criando riscos adicionais.

Neste novo cenário, a capacidade de autorização correta numa conta Google dentro do perfil transforma-se de uma função conveniente num elemento estratégico fundamental. A sua implementação correta permite que a sessão se integre organicamente no modelo comportamental da esmagadora maioria dos utilizadores reais, que estão autenticados nos seus navegadores. Desta forma, o perfil abandona a categoria de sessões anómalas e não autorizadas (modos de convidado, computadores públicos) com um nível de risco inicialmente diferente, o que se torna um dos fatores decisivos para o sucesso.

Linken Sphere: A solução do problema a um nível fundamental

A análise do mercado revela um padrão comum: a maioria das soluções reage às mudanças post-factum, adicionando a emulação de elementos individuais à medida que são descobertos. A nossa abordagem é fundamentalmente diferente. Desde o início, considerámos estes mecanismos não como um conjunto de cabeçalhos isolados, mas como um sistema único e interligado que reflete a lógica interna de funcionamento do navegador. Foi isto que nos permitiu não apenas imitar, mas recriar o seu comportamento com precisão nativa.

Recriação da assinatura digital: emulação abrangente de cabeçalhos

No Linken Sphere, está implementada uma emulação completa e multinível de todos os cabeçalhos criticamente importantes.

• Família X-Browser-*: Este é o nível básico de autenticidade, e está implementado de forma impecável. Os cabeçalhos são formados corretamente e correspondem totalmente ao comportamento do Google Chrome real em todos os sistemas operativos, incluindo Android, onde outros produtos cometem erros óbvios.

• X-Client-Data: Em vez de um substituto estático e estruturalmente primitivo, o Linken Sphere gera um cabeçalho dinâmico e dependente do contexto. Graças às substituições ao nível do núcleo, os IDs de experiências atribuídos dependem diretamente da configuração da sessão. O sistema tem em conta as características do dispositivo exatamente da mesma forma que o Chrome real o faz antes de atribuir "testes de campo". Isto cria não apenas uma impressão digital única, mas logicamente fundamentada.

O elemento final de confiança: sincronização de contas integrada

Consideramos o cabeçalho X-Chrome-Id-Consistency-Request e a autorização a ele associada não como uma função adicional, mas como uma parte integrante de uma impressão digital credível.

1. Integração por defeito. A substituição do nome do dispositivo não é uma opção que se possa esquecer de ativar. Está ativa por defeito e é um componente básico da impressão digital. Isto garante que a sessão, desde o primeiro pedido, se comporta como um dispositivo real, excluindo anomalias.

2. Realismo contextual. O sistema gera não apenas um nome de dispositivo aleatório, mas um que é totalmente correspondente à configuração. Se a sua sessão emula um HP ProBook 400, então o DeviceName utilizado será um que existe na realidade e é característico desse modelo específico. O mesmo princípio aplica-se às nossas configurações móveis: um perfil Android receberá um nome realista, correspondente ao modelo de smartphone selecionado.

As abordagens diferem radicalmente. Muitas soluções oferecem um conjunto de artefactos díspares e facilmente detetáveis. O Linken Sphere cria um retrato digital orgânico e credível, onde cada detalhe, incluindo o nome do dispositivo, está logicamente ligado aos restantes e no seu devido lugar.

Conclusão

A introdução pela Google de cabeçalhos HTTP proprietários marca uma nova era na arquitetura da identificação digital. Como a nossa investigação demonstrou, o mercado não estava preparado para isso. A maioria das soluções antidetect exibe apenas uma emulação superficial e fragmentada, que se desfaz à primeira análise séria. Cada cabeçalho formado incorretamente e cada anomalia comportamental levam diretamente a perdas operacionais, acionando o temporizador até à deteção e comprometimento de toda a rede de contas.

Em vez de tapar buracos, o Linken Sphere resolve o problema a um nível fundamental, recriando um ecossistema de navegador coeso e logicamente interligado. Desde a geração correta do X-Client-Data até à integração nativa da autorização Google — cada aspeto funciona em sinergia, criando um retrato digital verdadeiramente credível e vivo.

Nesta nova realidade, a escolha da ferramenta torna-se criticamente importante para a estabilidade das suas operações. Deixe de confiar o seu trabalho a soluções que estão atrasadas em relação à indústria. Escolha uma ferramenta capaz de antecipar ameaças e proporcionar uma vantagem estratégica.