cside copreside a segurança antifraude do navegador no W3C
A fraude acontece cada vez mais dentro da sessão do navegador. Credential stuffing, account takeover, tráfego publicitário inválido, carding feito por bots, scraping, engagement falso e abuso automatizado dependem do que a plataforma web permite a um cliente fazer.
A parte difícil não é dar nome aos ataques. A parte difícil é pará-los sem transformar o navegador numa camada de vigilância ou forçar cada utilizador legítimo a passar por CAPTCHAs repetidos.
A IA está a mudar rapidamente o panorama da fraude. Os atacantes conseguem gerar comportamento de conta convincente, automatizar fluxos de navegador, coordenar abuso lento e distribuído, e adaptar-se mais depressa do que regras estáticas. Os defensores precisam de sinais de navegador que acompanhem esse ritmo sem transformar cada utilizador num perfil rastreável.
É por isso que Simon Wijckmans é agora copresidente do W3C Anti-Fraud Community Group (AFCG), representando a cside ao lado de Sam Schlesinger da Google e da comunidade mais ampla que trabalha publicamente neste problema.
O que faz o W3C Anti-Fraud Community Group
O AFCG existe para identificar lacunas na plataforma web que permitem fraude e tráfego indesejado. O seu trabalho foca-se em funcionalidades e APIs de navegador que possam responder a esses cenários enquanto melhoram a segurança, a privacidade e a acessibilidade dos utilizadores.
O grupo é aberto. Fornecedores de navegadores, fornecedores antifraude, defensores da privacidade, programadores web, fornecedores cloud e operadores de serviços que recebem tráfego indesejado podem participar. O trabalho técnico acontece em público, principalmente nos repositórios de propostas e casos de uso do AFCG.
Esse modelo público importa. O trabalho antifraude falha quando se torna uma corrida privada entre trackers e atacantes. As normas do navegador precisam de um patamar mais alto: capacidades precisas, limites de privacidade, limites de acessibilidade e revisão por pessoas que nem sempre concordam umas com as outras.
Porque é que a segurança do navegador precisa de primitivas antifraude
O repositório de casos de uso do AFCG descreve claramente a superfície de ameaça. Inclui fraude na criação de contas, account takeover, credential cracking, credential stuffing, phishing, roubo de tokens, tráfego inválido em publicidade, fraude ecommerce, carding, card cracking, cashing out, abuso de promoções, scraping, spam, engagement falso, negação de serviço e acesso não autorizado.
Isto não está separado da segurança do navegador. Isto é segurança do navegador.
A maioria das defesas antifraude atuais depende de uma mistura de sinais frágeis:
- Reputação IP que falha com proxies, VPNs e CGNAT
- Fingerprints de dispositivo que criam problemas de tracking e consentimento
- CAPTCHAs que transferem custo para utilizadores reais e equipas de acessibilidade
- Limites de taxa do lado do servidor que não veem o que aconteceu no navegador
- Desafios antibot que bloqueiam automação legítima e navegação assistida
A plataforma web precisa de melhores primitivas. Uma boa primitiva deve responder a uma pergunta estreita sem revelar mais do que o necessário. Deve ajudar um site a defender um fluxo sensível sem permitir que esse site siga o utilizador pela web.
Esse equilíbrio importa. Os sinais antifraude têm de ser fortes o suficiente para travar abuso, mas limitados o suficiente para não se tornarem novos sistemas de tracking. Provas de conhecimento zero e inferência no dispositivo tornam possíveis novos desenhos: o navegador pode provar um facto limitado ou classificar comportamento de risco localmente sem expor identificadores brutos, histórico de navegação ou fingerprints de dispositivo a cada site.
Propostas ativas a acompanhar
Várias propostas e discussões mostram para onde o trabalho está a avançar.
Private Access Control Tokens
Private Access Control Tokens (PACT) é um dos itens de trabalho recentes mais importantes. O issue foi aberto em 2025-12-02 como uma declaração conjunta do problema por Dennis Jackson, Sam Schlesinger e Eric Trouton.
PACT explora um mecanismo web que pode reduzir a fricção dos CAPTCHAs e permitir que websites apliquem limites de taxa contra tráfego indesejado de alto volume. O objetivo de desenho é explícito: preservar a privacidade, evitar tracking entre sessões e não excluir utilizadores com base em hardware, plataforma ou user agent.
A proposta também importa para controlo de acesso. Um utilizador pode precisar de provar que tem uma conta válida e em bom estado sem revelar que recursos está a aceder. Isto torna-se mais importante à medida que agentes locais de IA no navegador atuam em nome dos utilizadores e acionam sinais de automação que muitos sites bloqueiam hoje.
Private State Tokens
Private State Tokens surgiu do trabalho da Trust Token API. O conceito permite que um emissor forneça tokens criptográficos ao navegador quando um utilizador é considerado confiável, e que esses tokens sejam resgatados mais tarde noutro contexto sem expor um identificador estável entre sites.
Esse tipo de mecanismo é fundamental para sinais de confiança que preservam a privacidade. Não resolve todos os cenários de abuso, mas aponta na direção certa: transmitir um sinal limitado, manter tokens brutos fora de JavaScript e evitar dar aos sites um novo identificador de tracking.
Device Integrity Attestation
A discussão sobre Device Integrity Attestation reúne casos de uso e requisitos para sinais de alta fidelidade e baixa entropia sobre a integridade do dispositivo. O objetivo é ajudar a distinguir ambientes legítimos de ambientes emulados, com root ou falsificados usados em abuso.
Este é um trabalho sensível. Sinais de integridade podem melhorar a defesa, mas também podem excluir utilizadores em dispositivos antigos, sistemas operativos alternativos ou configurações que preservam a privacidade. É exatamente por isso que este trabalho pertence a um fórum aberto de normalização, e não a uma funcionalidade privada de fornecedor.
Porque é que isto importa para o trabalho da cside
A cside trabalha na camada do navegador. Monitorizamos que scripts executam, o que carregam, como mudam e como o comportamento do lado do navegador afeta segurança, privacidade, fraude e conformidade.
Essa visão operacional alinha-se com a missão do AFCG. Equipas antifraude precisam de sinais suficientemente precisos para agir. Equipas de privacidade precisam que esses sinais não se tornem novos identificadores. Equipas de segurança precisam de visibilidade ao nível do navegador porque os logs do servidor não veem o código que executa na máquina do utilizador.
O trabalho de normalização não vai substituir a segurança do navegador em runtime. Pode tornar a plataforma subjacente mais segura e dar aos defensores ferramentas melhores do que fingerprinting, tracking e desafios bruscos.
Obrigado a Sam Schlesinger e à Google
Este trabalho depende de pessoas que aparecem, escrevem propostas, aceitam revisão e mantêm tradeoffs difíceis visíveis. Quero agradecer a Sam Schlesinger e à equipa da Google pela oportunidade de ajudar a liderar este trabalho em conjunto.
O trabalho de Sam em protocolos que preservam a privacidade, PACT e Private State Tokens moldou a direção técnica do AFCG. Essa profundidade importa porque normas antifraude precisam de resistir tanto à pressão de atacantes como à revisão de privacidade.
Este papel é uma extensão natural do trabalho anterior da cside no W3C. Desde que nos juntámos ao W3C Web Application Security Working Group em 2024, temos defendido um modelo mais forte de segurança do navegador. O AFCG dá-nos outro lugar para levar evidência prática de runtime para o processo de normalização.
Como participar
O AFCG está aberto à participação. Se a sua equipa trabalha em fraude, segurança do navegador, sinais que preservam a privacidade, infraestrutura cloud, agentes de IA, pagamentos, integridade publicitária ou prevenção de abuso, o grupo precisa de profissionais que entendam a realidade operacional.
Comece pela página do grupo W3C e pelos repositórios públicos do GitHub de casos de uso e propostas. Leia os issues abertos. Acrescente casos de uso concretos. Questione pressupostos fracos. Traga cedo as restrições de implementação.
O navegador está a evoluir depressa. As normas que governam a segurança do navegador e os sinais antifraude precisam de acompanhar esse ritmo.
Em 2026-05-12, as propostas do AFCG continuam a ser discussões públicas ativas. O estado de implementação, o suporte dos navegadores e os destinos de normalização podem mudar.
