Lembra do WEI? O Google Também Lembra

Em 2023, o Google tentou algo que a comunidade open source chamou de “DRM para a web”. A proposta se chamava Web Environment Integrity (WEI) e, na prática, obrigaria navegadores a provar para sites que não tinham sido modificados — leia-se: que não usavam ad blockers, extensões de privacidade ou sistemas operacionais alternativos.

A reação foi brutal. Mozilla, Brave, Vivaldi, a Electronic Frontier Foundation e até o W3C disseram não. O Google recuou em novembro de 2023, removeu o protótipo do Chromium e jurou que estava tudo bem.

Três anos depois, a mesma ideia voltou. Só que dessa vez, ninguém pediu permissão.

Google Cloud Fraud Defence: o Rebranding que Ninguém Pediu

No início de maio de 2026, durante o Google Cloud Next, o Google anunciou o Google Cloud Fraud Defence como “a próxima evolução do reCAPTCHA”. A proposta parece inofensiva na superfície: substituir aqueles testes irritantes de “selecione os semáforos” por um QR code que você escaneia com o celular.

Funciona assim: um site exibe um QR code. Você abre a câmera do celular, escaneia, e pronto — está autenticado como humano. Sem clicar em fotos borradas, sem resolver puzzles. Parece uma melhoria, certo?

O problema está no que acontece nos bastidores.

Por Dentro da Máquina: Como Funciona de Verdade

Quando você escaneia aquele QR code, seu celular não está apenas provando que você é humano. Ele está fazendo uma attestation — uma verificação criptográfica de que seu dispositivo é “legítimo” segundo os critérios do Google.

No Android, isso passa pelo Google Play Integrity API. Esse serviço verifica:

• Se o bootloader do dispositivo está trancado
• Se o sistema operacional não foi modificado
• Se o Google Play Services está instalado e atualizado
• Se o dispositivo é “certificado” pelo Google

No iOS, algo similar acontece via Device Check da Apple.

O resultado é um token criptografado que volta para o site dizendo: “este dispositivo é confiável”. Não diz quem você é — mas diz o que você está usando.

Fluxo simplificado:

Site → exibe QR code
  ↓
Celular escaneia → Google Play Integrity API verifica o hardware
  ↓
API retorna token assinado → "dispositivo certificado"
  ↓
Token volta pro site → "usuário verificado como humano"

E aqui está o déjà vu: isso é exatamente o que o WEI propunha em 2023. A diferença? O WEI era uma proposta aberta, submetida ao escrutínio público. O Fraud Defence é um produto comercial, disponível para qualquer empresa com uma conta no Google Cloud.

O Que Morreu como Proposta Aberta Renasceu como Produto Pago

Eu preciso ser honesto: a jogada é brilhante do ponto de vista de negócios. E completamente preocupante do ponto de vista da web aberta.

Em 2023, o WEI passou por escrutínio público. Desenvolvedores, organizações de privacidade e fabricantes de navegadores puderam analisar, criticar e, no fim, rejeitar a proposta. O processo funcionou como deveria.

Mas o Fraud Defence não é uma proposta de padrão web. É um produto. Não precisa de aprovação do W3C. Não precisa de consenso entre fabricantes de navegadores. É só um serviço do Google Cloud que qualquer site pode implementar.

A tabela acima não mente. Os mesmos problemas fundamentais do WEI existem no Fraud Defence. A única diferença é o caminho que o Google escolheu para implementá-los.

Quem Fica de Fora (E Por Que Isso Importa)

Se você usa um celular Android comum comprado numa loja, provavelmente não vai sentir diferença. Escaneia o QR code, passa na verificação, vida que segue.

Mas a web não é feita só de usuários mainstream. E é aqui que o bicho pega.

Dispositivos que falham na attestation:

• GrapheneOS — o sistema operacional recomendado pela EFF para jornalistas, ativistas e qualquer pessoa sob risco de vigilância. Sem Google Play Services, sem attestation.
• LineageOS com microG — alternativa open source ao Android que milhões de pessoas usam para escapar do ecossistema Google. Não passa.
• Celulares com root — qualquer dispositivo com bootloader destrancado é automaticamente “não confiável”.
• Firefox no Android — dependendo da implementação, navegadores que não são o Chrome podem ter problemas.

Pensa no absurdo: a EFF recomenda GrapheneOS para pessoas em situações de risco. O Google cria um sistema que exclui exatamente essas pessoas de acessar sites protegidos pelo Fraud Defence.

“Nenhuma empresa deveria ter o poder de decidir unilateralmente qual hardware é legítimo o suficiente para acessar a web.” — Private Captcha Blog

O Problema do Rastreamento Persistente

Cada vez que seu dispositivo passa por uma attestation, um sinal é enviado ao Google: este dispositivo certificado acessou este site neste horário.

Isso cria um identificador de hardware que persiste entre sessões. Trocou de navegador? Tanto faz — o identificador está no hardware. Usando aba anônima? Irrelevante — a attestation acontece no nível do dispositivo. VPN? Não protege contra identificação de hardware. Lembra do identificador secreto do Firefox que ligava identidades no Tor? O Fraud Defence vai além.

Para entender a gravidade, compare com cookies:

A attestation de dispositivo é, na prática, um super-cookie de hardware que o usuário não pode apagar — similar em conceito aos tokens secretos que rastreiam cliques no ChatGPT, mas no nível do hardware. E diferente de cookies tradicionais, não existe uma configuração no navegador para desativá-la.

“Mas Vai Funcionar Contra Bots?”

Essa é a justificativa oficial: combater fraude e bots. E eu entendo a motivação. Bots são um problema real. Fraude online custa bilhões por ano. Os CAPTCHAs atuais são uma experiência horrível que todo mundo odeia.

Mas a eficácia do Fraud Defence contra bots é, no mínimo, questionável.

O ataque do QR code de $30: Um dispositivo Android certificado custa aproximadamente US$ 30 em lotes grandes. Atacantes podem montar farms de dispositivos baratos, cada um com Google Play Services legítimo, e automatizar a captura de QR codes com câmeras. O custo para escalar é baixo.

O vetor de phishing: O sistema treina bilhões de pessoas a escanear QR codes sem pensar. “Escaneia aqui para provar que é humano” é exatamente o tipo de ação automática que phishers adoram explorar. QR codes maliciosos já são um problema; criar uma cultura de “escaneia para acessar” só piora a situação.

A corrida armamentista: Toda solução de verificação eventualmente é quebrada. CAPTCHAs de texto duraram anos até serem resolvidos por OCR. CAPTCHAs de imagem estão sendo resolvidos por IA. Attestation de hardware vai seguir o mesmo caminho — a única questão é quanto tempo vai levar.

# Custo estimado de uma farm de bypass
# 100 dispositivos Android certificados: ~$3,000
# Câmeras USB para leitura de QR: ~$500
# Servidor de automação: ~$50/mês
# Total para bypass massivo: ~$3,550

# vs. custo do reCAPTCHA v3 atual para resolver via API:
# $2-3 por 1000 soluções via serviços de solving
# Muito mais barato que a farm, mas Fraud Defence deveria eliminar isso

Alternativas que Respeitam a Privacidade

A boa notícia é que existem formas de combater bots sem transformar cada celular em um cartão de identidade digital.

Proof-of-Work (PoW): Em vez de verificar quem você é ou o que você está usando, desafios de proof-of-work pedem que seu dispositivo resolva um problema computacional. Quanto mais requisições vêm de uma fonte, mais difícil fica o problema. Humanos passam sem perceber; bots precisam gastar recursos reais.

Rate limiting inteligente: Combinando análise de comportamento (velocidade de digitação, padrões de mouse, tempo entre cliques) com limitação de requisições, é possível identificar bots sem saber nada sobre o hardware do usuário.

Tokens de acesso anônimos: Projetos como Privacy Pass (desenvolvido pela Cloudflare e Apple) permitem provar que você é humano sem revelar qual dispositivo está usando. O token é criptograficamente separado da identidade do dispositivo.

Nenhuma dessas soluções é perfeita. Mas todas compartilham um princípio fundamental: verificam o comportamento, não o hardware.

A Estratégia do Google: Embrace, Extend, Extinguish?

Quem acompanha a história da tecnologia reconhece o padrão. A Microsoft fez isso com padrões web nos anos 90. O Google está fazendo com a web agora, só que de um jeito mais sutil.

Embrace: O Google criou o Chrome, que hoje domina ~65% do mercado de navegadores (e já instalou 4 GB de IA no seu PC sem pedir). Contribuiu para a web aberta com projetos como V8, Angular e inúmeros padrões.

Extend: O reCAPTCHA já é usado em milhões de sites. O Fraud Defence é a extensão natural — mesmo sites que não usam Chrome vão precisar lidar com ele se quiserem proteção contra fraude.

Extinguish: Se o Fraud Defence se tornar ubíquo, dispositivos que não passam na attestation do Google ficam de fora. Não por uma proibição explícita, mas por incompatibilidade prática. O resultado é o mesmo: a web se torna um jardim murado onde o Google decide quem entra.

Eu posso estar sendo paranóico. Talvez o Google genuinamente queira apenas combater fraude e não tenha intenção de usar isso como alavanca de controle. Mas quando a mesma empresa que controla o navegador dominante, o sistema operacional mobile dominante e agora o sistema de verificação de humanidade é a mesma… a preocupação é legítima.

Vale lembrar que o Google já fez movimentos similares antes. O AMP (Accelerated Mobile Pages) foi vendido como uma melhoria de performance para a web mobile, mas na prática forçou publishers a hospedar conteúdo nos servidores do Google e seguir suas regras de formatação. O FLoC (Federated Learning of Cohorts) foi apresentado como uma alternativa “privada” aos cookies de terceiros, mas agrupava usuários em coortes de comportamento que podiam ser exploradas para fingerprinting. Ambos foram eventualmente abandonados ou reformulados após pressão da comunidade. O padrão se repete: proposta controversa, rebranding, nova tentativa.

O Que Você Pode Fazer

Se você é desenvolvedor, tem opções:

1. Não implemente o Fraud Defence cegamente. Avalie se o reCAPTCHA v3 ou soluções como hCaptcha, Turnstile da Cloudflare ou Privacy Pass não atendem suas necessidades.
2. Teste com dispositivos alternativos. Se seu site usa Fraud Defence, verifique se usuários de GrapheneOS, LineageOS e Firefox conseguem acessar.
3. Ofereça fallbacks. Se a attestation falhar, tenha um método alternativo de verificação que não dependa de hardware certificado.

Se você é usuário:

1. Fique atento a sites que pedem para escanear QR codes como forma de verificação.
2. Reclame quando um site bloquear seu acesso por causa do dispositivo que você usa.
3. Apoie organizações como a EFF e a Mozilla que lutam pela web aberta.

A Reação da Comunidade: Déjà Vu Coletivo

O post no Hacker News que expôs a conexão entre Fraud Defence e WEI acumulou mais de 500 pontos em poucas horas — um sinal claro de que a comunidade de desenvolvedores não esqueceu 2023.

Nos fóruns do Privacy Guides, a discussão seguiu a mesma linha: frustração com o fato de que o processo democrático de revisão de padrões web foi simplesmente contornado. Não importa se o W3C disse não — o Google tem market share suficiente para implementar a mesma coisa por outra via.

O mais preocupante é o efeito cascata. Se o Fraud Defence ganhar tração, outros provedores de cloud vão criar soluções similares. A Amazon já tem o AWS WAF Bot Control. A Microsoft tem o Azure Bot Protection. Nenhum deles, até agora, exige attestation de hardware — mas se o Google normalizar essa prática, a pressão competitiva pode mudar isso rapidamente.

E existe um cenário ainda mais sombrio: governos usando attestation de dispositivo para controlar acesso a serviços públicos. Se a tecnologia já existe e está normalizada no setor privado, a barreira para adoção governamental cai drasticamente. Imagine precisar de um dispositivo “certificado” para acessar o portal do governo ou fazer sua declaração de imposto.

O Fantasma do WEI Está Vivo

O que o Google não conseguiu via consenso em 2023, está implementando via mercado em 2026. Não precisou convencer a Mozilla, o W3C ou a comunidade de desenvolvedores. Precisou apenas empacotar a mesma tecnologia como um produto do Google Cloud e esperar que a adoção acontecesse naturalmente.

A pergunta que fica não é se o Fraud Defence funciona contra bots — provavelmente funciona, pelo menos por um tempo. A pergunta é: qual o preço que estamos dispostos a pagar pela conveniência? Um mundo onde uma única empresa decide qual hardware é “legítimo” o suficiente para navegar na internet é um mundo onde a web aberta já morreu. Só ninguém avisou ainda.

Fonte de inspiração: Google Cloud Fraud Defence is just WEI repackaged — Private Captcha