How We Built a System That Scans 100,000 Websites for Cookie Consent Violations

Quando nos propusemos a analisar 97.304 websites da UE quanto à conformidade com o GDPR, rapidamente encontrámos um problema que define todo este domínio: não se pode avaliar a conformidade do consentimento lendo HTML. É preciso executar o website, interagir com ele e observar o que o navegador realmente faz.

Esta publicação descreve a arquitetura técnica por detrás do scanner do GDPR Monitor, os desafios de engenharia que encontrámos e as limitações sobre as quais somos honestos.

Visão geral da arquitetura

O scanner é uma aplicação Go construída em torno do Chromium headless via Chrome DevTools Protocol (CDP). Não é um crawler no sentido tradicional -- é mais próximo de um teste de navegador automatizado que produz evidências de conformidade estruturadas.

Os componentes principais:

• Orquestrador de pipeline -- coordena as fases da análise em sequência: lançamento do navegador, navegação, snapshot pré-consentimento, deteção de banner, interação de consentimento, snapshot pós-consentimento, análise e geração de relatório.
• Gestor de navegador -- gere o ciclo de vida do processo Chromium, interceção de pedidos e comunicação CDP. Usamos chromedp como cliente CDP do lado Go.
• Biblioteca de deteção de CMP -- identifica plataformas de gestão de consentimento usando uma combinação de assinaturas de scripts, seletores DOM e heurísticas comportamentais. A biblioteca cobre dezenas de CMPs conhecidos.
• Classificadores de cookies e rastreadores -- comparam cookies observados com uma base de dados de classificação e pedidos de rede com padrões de rastreadores conhecidos.
• Pipeline de evidências -- captura e armazena capturas de ecrã, ficheiros HAR (HTTP Archive), snapshots de cookies e logs de rede como artefactos com marca temporal.
• Módulos de análise -- verificações de nível superior incluindo auditoria de acessibilidade, validação do Google Consent Mode, mapeamento de fluxos de dados, deteção de sinais de impressão digital e análise de política de privacidade.

O scanner funciona como um worker de fila em produção. Uma fila suportada por Redis distribui URLs a instâncias de workers, cada uma gerindo o seu próprio pool de processos Chromium.

O pipeline de análise em detalhe

Uma única análise passa por estas fases:

Fase 1: Lançamento de navegador limpo

Cada análise começa com uma instância de Chromium fresca. Sem cookies, sem armazenamento local, sem recursos em cache, sem histórico de navegação anterior. Isto é crítico -- precisamos de observar a experiência de um visitante pela primeira vez sem estado de consentimento prévio.

Configuramos o navegador com um viewport padrão, um user agent realista e cabeçalhos de idioma correspondentes ao país alvo. As considerações de GeoIP são tratadas ao nível da rede.

Fase 2: Snapshot pré-consentimento

Antes de qualquer interação, o scanner captura:

• Todos os cookies definidos pela página (first-party e third-party)
• Todos os pedidos de rede efetuados, com URL completo, temporização e metadados de resposta
• O número e identidade dos domínios de terceiros contactados
• Uma captura de ecrã de página inteira

Este snapshot responde à pergunta: o que aconteceu antes de o visitante ter tido a possibilidade de consentir?

O website médio no nosso estudo contactou 10,4 domínios de terceiros nesta fase. Esse número por si só indica quanto está a acontecer antes de o utilizador ver um banner, muito menos clicar em alguma coisa.

Fase 3: Deteção de banner e CMP

Este é um dos problemas de engenharia mais difíceis no sistema. Os banners de consentimento não são padronizados. Variam desde widgets CMP polidos com estruturas DOM bem conhecidas até diálogos modais personalizados, barras deslizantes e sobreposições de página inteira.

A nossa deteção usa uma abordagem em camadas:

1. Deteção de scripts CMP conhecidos. Verificamos URLs de scripts e objetos JavaScript globais associados a CMPs principais (Cookiebot, OneTrust, Usercentrics, Didomi, Complianz e muitos outros).

2. Correspondência de seletores verificados. Para cada CMP conhecido, mantemos um conjunto de seletores CSS que identificam de forma fiável o contentor do banner, o botão de aceitar e o botão de rejeitar.

3. Correspondência de seletores compatíveis. Um conjunto mais amplo de seletores que funcionam para muitas versões de um CMP mas podem ser menos precisos.

4. Heurísticas genéricas. Para sites que usam soluções de consentimento personalizadas ou não identificadas (34,7% dos banners no nosso estudo), recorremos à deteção heurística: procura de elementos com posição fixa com texto relacionado com consentimento, botões com rótulos comuns ("Aceitar tudo", "Rejeitar", "Gerir preferências") e padrões estruturais típicos de diálogos de consentimento.

5. Sondagem de API CMP. Alguns CMPs expõem uma API JavaScript (a API IAB TCF, por exemplo). Sondamos estas APIs e usamo-las para verificar o estado de consentimento detetado.

Esta abordagem em camadas é necessária porque nenhuma estratégia única funciona em toda a diversidade da web. Mesmo os nossos detetores CMP mais específicos encontram variações de versão, estilos personalizados, testes A/B e modificações específicas de clientes.

Fase 4: Interação de consentimento

Uma vez detetado o banner, o scanner interage com ele. Para a análise principal, clica no botão de aceitar para observar o comportamento pós-consentimento completo. Para o teste do fluxo de rejeição, clica no botão de rejeitar e depois recarrega para verificar consent respawn.

A temporização da interação é importante. Esperamos que a página estabilize após o clique, tendo em conta animações, reavaliação de scripts e acionamento tardio de tags. Errar significa perder rastreamento que é acionado após um breve atraso ou produzir falsos positivos em pedidos que já estavam em trânsito.

Fase 5: Snapshot pós-consentimento e comparação

Após a interação de consentimento, tiramos outro snapshot completo: cookies, pedidos de rede, domínios de terceiros. A comparação entre o estado pré-consentimento e pós-consentimento revela o que mudou:

• Que novos cookies apareceram
• Que novos pedidos de rastreamento foram acionados
• Se o estado de consentimento na API CMP corresponde ao comportamento observado

Fase 6: Análise e classificação

A comparação bruta alimenta múltiplos módulos de análise:

• Classificação de cookies. Cada cookie é comparado com a nossa base de dados para o categorizar como essencial, análise, marketing ou desconhecido.
• Correspondência de rastreadores. Os pedidos de rede são verificados contra bases de dados de padrões de rastreadores.
• Verificação do tempo de vida dos cookies. Sinalizamos cookies que excedem o máximo de 13 meses recomendado pela CNIL e outras autoridades nacionais. A nossa análise encontrou 58.127 desses cookies em 26.250 websites.
• Auditoria de acessibilidade. Avaliamos o banner detetado quanto ao tamanho dos alvos de toque, contraste de cor e navegabilidade por teclado.
• Validação do Consent Mode. Para sites que usam Google Consent Mode, comparamos o estado de consentimento declarado com o comportamento observado.
• Pontuação de risco. As conclusões são agregadas numa pontuação de risco que tem em conta a gravidade, contagem e categoria das violações.

A descoberta do Consent Respawn

O consent respawn não era uma categoria que nos propusemos encontrar. Emergiu dos dados.

Durante os testes do fluxo de rejeição, notámos um padrão: alguns sites mostravam um estado de cookies limpo imediatamente após clicar em rejeitar, mas os cookies voltavam após um recarregamento da página. A nossa suposição inicial foi um problema de temporização no scanner. Após investigação, confirmámos que era comportamento real: scripts de terceiros restabeleciam cookies em cada carregamento de página, independentemente do estado de consentimento armazenado pela CMP.

Adicionámos deteção explícita de respawn ao pipeline: após completar o fluxo de rejeição, o scanner recarrega a página, espera que estabilize e compara o estado dos cookies com o snapshot pós-rejeição. Se cookies que foram removidos pela ação de rejeição reaparecem, isso é sinalizado como consent respawn.

Encontrámos 1.642 sites que exibem este comportamento, com 4.932 cookies individuais a reaparecer. O padrão é particularmente comum em sites que usam gestores de tags com integração de consentimento incompleta -- o gestor de tags respeita o sinal CMP, mas um script diretamente incorporado não.

Deteção de evasão de bots

Durante o estudo, identificámos 137 websites que parecem esconder deliberadamente o seu banner de consentimento de scanners automatizados.

O padrão: estes sites servem um banner de consentimento totalmente funcional a navegadores normais mas suprimem-no quando detetam características de navegação automatizada. O banner simplesmente não aparece na nossa sessão de Chromium headless, mas aparece numa visita manual com navegador ao mesmo URL.

As heurísticas de deteção incluem sinais detetáveis por CDP (navigator.webdriver), deteção baseada em temporização e impressão digital comportamental. Usamos contramedidas para os padrões de deteção de bots mais comuns, mas alguns sites empregam deteção suficientemente sofisticada para que o banner fique efetivamente escondido da verificação de conformidade automatizada.

Esta é uma conclusão preocupante. Se um website esconde deliberadamente o seu mecanismo de consentimento de scanners de conformidade, levanta questões sobre a finalidade desse mecanismo. Sinalizamos estes sites separadamente nos nossos resultados.

Limitações

Nenhum sistema automatizado pode replicar perfeitamente cada experiência de navegação humana. Estas são as limitações conhecidas:

Sensibilidade a GeoIP. Alguns websites servem conteúdo diferente ou fluxos de consentimento diferentes com base na geolocalização IP do visitante. As nossas análises foram realizadas a partir de localizações de rede específicas, o que significa que podemos não ver exatamente a mesma experiência que um visitante em cada país da UE. Shadow DOM e complexidade de frameworks. Frameworks JavaScript modernos e encapsulamento Shadow DOM podem esconder elementos de interface de consentimento de consultas DOM padrão. A nossa deteção trata muitos destes casos, mas algumas implementações personalizadas podem ser perdidas. Carregamento assíncrono e atrasado. Alguns banners de consentimento ou scripts de rastreamento carregam de forma assíncrona com atrasos significativos. Usamos timeouts generosos, mas um script que dispara 30 segundos após o carregamento da página pode ser perdido por uma análise que espera 15 segundos. Aplicações de página única. SPAs que gerem o estado de consentimento inteiramente em JavaScript do lado do cliente sem produzir alterações DOM detetáveis são mais difíceis de avaliar de forma fiável. A nossa taxa de 14,9% de resultados inconclusivos reflete parcialmente este desafio. Idioma do banner de consentimento. Detetamos botões por uma combinação de seletores e correspondência de texto. Um banner num idioma não coberto pelos nossos dados de localização pode não ser corretamente identificado.

Estas limitações contribuem para a nossa taxa de 14,9% de resultados inconclusivos.

Infraestrutura para escala

Analisar 97.304 websites não é um trabalho para uma única máquina. A infraestrutura de produção usa:

• Uma fila de trabalho suportada por Redis que distribui URLs a workers do scanner
• Instâncias de workers que gerem cada uma um pool de processos Chromium
• PostgreSQL para resultados de análise duráveis, conclusões e metadados
• Armazenamento de objetos para artefactos de evidência (capturas de ecrã, ficheiros HAR, PDFs)
• Limitação de taxa e controlos de concorrência para evitar sobrecarregar sites alvo ou a nossa própria rede

Cada análise demora aproximadamente 30-90 segundos dependendo da complexidade do site, pelo que o estudo completo exigiu execução paralela sustentada em muitos workers durante vários dias.

A API

O mesmo motor de scanner que alimentou este estudo está disponível através da API pública do GDPR Monitor. Pode submeter pedidos de análise, consultar resultados e obter conclusões estruturadas e artefactos de evidência programaticamente.

Se está a construir ferramentas de conformidade, a integrar verificações de privacidade em CI/CD ou a conduzir a sua própria investigação, a API dá-lhe acesso à mesma análise comportamental sem construir o seu próprio pipeline de automatização Chromium.

---

Experimente você mesmo. A documentação da API está disponível em gdprprivacymonitor.eu/developers/api. Analise um único URL ou integre a monitorização de privacidade no seu fluxo de trabalho.