80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Cada banner de cookies faz a mesma promessa implicita: clique em "Rejeitar" e o rastreamento para. O banner desaparece, e navega em paz. Este e o acordo sobre o qual o modelo de consentimento esta construido -- a ideia de que os utilizadores tem uma escolha significativa e aplicavel.

Testámos essa promessa em 28.891 websites da UE. Em 80,4% deles, a promessa e quebrada. O rastreamento continua apos o utilizador clicar explicitamente em rejeitar. Os cookies persistem. Os pixeis de publicidade continuam a disparar. E em 1.642 sites, cookies que a acao de rejeicao inicialmente elimina voltam no carregamento de pagina seguinte -- um padrao que chamamos consent respawn.

Esta nao e uma conclusao marginal sobre alguns sites mal configurados. Aponta para um problema sistemico no mecanismo em que centenas de milhoes de residentes da UE confiam para os seus direitos de privacidade.

O Que "Rejeitar" Deveria Fazer -- Legalmente

O enquadramento legal e claro. Ao abrigo do Artigo 5(3) da Diretiva ePrivacy, armazenar ou aceder a informacao no equipamento terminal de um utilizador requer consentimento previo, com uma excecao restrita para cookies estritamente necessarios para um servico que o utilizador tenha explicitamente solicitado. O Artigo 7(3) do GDPR acrescenta que a retirada do consentimento deve ser tao facil como da-lo, e o responsavel pelo tratamento deve agir sobre essa retirada.

As Diretrizes 05/2020 do EDPB sobre consentimento ao abrigo do GDPR especificam o que isto significa para botoes de rejeicao: se um website oferece uma opcao "Aceitar Tudo", deve tambem oferecer uma opcao igualmente proeminente e igualmente acessivel para recusar. E essa recusa deve ser efetiva -- deve realmente prevenir o tratamento que o consentimento teria autorizado.

O TJUE reforcou isto em Planet49 (C-673/17): o consentimento requer um ato afirmativo claro, e caixas pre-assinaladas nao constituem consentimento valido. O corolario logico e que uma recusa -- um ato negativo explicito -- deve ser respeitada tao definitivamente como uma aceitacao. Se clicar em "Aceitar" ativa o rastreamento, clicar em "Rejeitar" deve desliga-lo. Nao parcialmente. Nao temporariamente. Completamente e permanentemente.

E o que a lei diz. Os nossos dados mostram o que realmente acontece.

Como Testamos o Fluxo de Rejeicao

O nosso teste de fluxo de rejeicao foi concebido para ser o mais proximo possivel da experiencia de um utilizador humano real a clicar em rejeitar, com a adicao de instrumentacao abrangente. Eis o processo passo a passo:

Passo 1: Sessao de navegador limpa. O scanner lanca uma instancia Chromium limpa -- sem cookies, sem armazenamento local, sem recursos em cache, sem historico de navegacao. Este e um visitante genuinamente pela primeira vez sem qualquer estado de consentimento previo. Passo 2: Navegar e registar o estado pre-consentimento. O scanner carrega o URL alvo e espera que a pagina estabilize. Antes de qualquer interacao, regista cada cookie presente no navegador, cada pedido de rede efetuado e cada dominio de terceiros contactado. Esta e a linha de base pre-consentimento -- o que o site faz antes de o utilizador ter qualquer oportunidade de fazer uma escolha. Passo 3: Detetar o banner de consentimento. Usando a nossa biblioteca de detecao que cobre 45 CMPs conhecidos e heuristicas genericas, o scanner identifica o mecanismo de consentimento e localiza o botao de rejeicao. Este passo utiliza uma abordagem em camadas: primeiro verificando assinaturas de scripts de CMP conhecidos e as suas estruturas DOM associadas, depois recorrendo a detecao generica de elementos com posicao fixa com texto relacionado com consentimento e rotulos de botoes como "Rejeitar Tudo", "Recusar", "Refuse" ou traducoes equivalentes. Passo 4: Clicar em rejeitar. O scanner clica no botao de rejeicao e espera que a pagina estabilize. "Estabilize" significa esperar que pedidos de rede pendentes terminem, que mutacoes DOM parem e que quaisquer animacoes ou transicoes terminem. Utilizamos timeouts generosos para evitar falsos positivos de implementacoes de CMP lentas. Passo 5: Snapshot pos-rejeicao. O scanner regista o estado completo novamente: todos os cookies, toda a atividade de rede, todos os dominios de terceiros. Este snapshot e comparado com a linha de base pre-consentimento para determinar o que mudou. Passo 6: Recarregar e verificar respawn. O scanner recarrega a pagina e espera que estabilize novamente. Depois tira um snapshot final. Este passo e critico: revela se a acao de rejeicao e persistente (respeitada entre carregamentos de pagina) ou se cookies e rastreamento reativam quando a pagina carrega de novo. Se cookies que foram removidos no Passo 5 reaparecem no Passo 6, isso e consent respawn.

Cada passo produz evidencias com marca temporal e arquivais: inventarios completos de cookies com nomes, valores, dominios, datas de expiracao e flags; logs completos de pedidos de rede com URLs, metodos, codigos de resposta e timing; e capturas de ecra de pagina inteira. Esta cadeia de evidencias permite que qualquer conclusao individual seja verificada e contestada.

Os Resultados: 80,4% de Falha

Dos 28.891 websites onde completámos com sucesso o teste completo de fluxo de rejeicao:

• 5.650 (19,6%) passaram. Apos clicar em rejeitar, cookies nao essenciais foram removidos, pedidos de rastreamento pararam, e a rejeicao persistiu entre recarregamentos de pagina.
• 23.241 (80,4%) falharam. O rastreamento continuou de alguma forma apos o utilizador clicar explicitamente em rejeitar.

As falhas nao sao uniformes. Dividem-se em categorias distintas que se sobrepõem -- um unico site pode exibir multiplos modos de falha simultaneamente.

Cookies persistentes: 10.848 sites

Em 10.848 sites (37,5% dos testados), cookies nao essenciais permaneceram no navegador apos a conclusao do fluxo de rejeicao. Estes sao cookies classificados como analytics, marketing ou relacionados com rastreamento que deveriam ter sido removidos ou impedidos de ser definidos apos uma acao de rejeicao.

Os cookies persistentes mais comuns pertencem ao Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) e varias plataformas de publicidade. Em muitos casos, a CMP remove com sucesso alguns cookies mas falha em apanhar todos -- sugerindo integracao incompleta entre a plataforma de gestao de consentimento e o conjunto completo de scripts de terceiros do site.

A presenca destes cookies apos rejeicao nao e meramente um problema estetico. Cada um e um identificador persistente que liga a sessao atual do utilizador a visitas passadas e futuras. O cookie `_ga`, por exemplo, e um identificador unico de cliente que o Google Analytics utiliza para construir um perfil longitudinal do comportamento do utilizador entre sessoes. Se persiste apos rejeicao, a navegacao do utilizador continua a ser rastreada e agregada independentemente da sua recusa expressa.

Rastreadores persistentes: 14.547 sites

Em 14.547 sites (50,3% dos testados), servicos de rastreamento permaneceram ativos apos rejeicao -- o que significa que o navegador continuou a fazer pedidos para dominios de rastreamento conhecidos mesmo depois de o utilizador clicar no botao de rejeicao.

Este e um modo de falha distinto da persistencia de cookies. Um rastreador pode estar ativo sem definir um cookie: pedidos de pixeis, chamadas de beacon e carregamentos de scripts todos transmitem informacao (no minimo, o endereco IP do utilizador, a pagina de referencia e dados de timing) para servidores de terceiros independentemente de um cookie ser armazenado. Isto e por vezes chamado "rastreamento sem cookies" e e cada vez mais comum a medida que os navegadores apertam as restricoes sobre cookies de terceiros.

A diferenca entre o numero de cookies (10.848) e o numero de rastreadores (14.547) e significativa. Significa que em aproximadamente 3.700 sites, a acao de rejeicao limpou cookies com sucesso mas falhou em impedir que pedidos de rastreamento continuassem. A CMP tratou da limpeza de cookies mas nao bloqueou os scripts que geram trafego de rastreamento em primeiro lugar. Isto aponta para um problema arquitetural comum: a CMP esta configurada para gerir cookies (apaga-los na rejeicao, impedi-los no carregamento) mas nao para gerir a execucao de scripts.

Consent respawn: 1.642 sites, 4.932 cookies

Consent respawn e o padrao mais preocupante que identificámos. Em 1.642 websites, cookies que foram removidos com sucesso pela acao de rejeicao reapareceram apos a pagina ser recarregada. Nesses sites, 4.932 cookies individuais exibiram este comportamento de respawn.

Consent respawn nao e um bug numa CMP ou numa configuracao. E um problema estrutural na forma como o consentimento e implementado no stack web.

Como um cookie volta depois de ser apagado. Quando um utilizador clica em rejeitar, uma CMP devidamente configurada faz duas coisas: apaga cookies nao essenciais existentes (definindo a sua expiracao para uma data passada), e atualiza um registo de consentimento (geralmente um cookie proprio, ou uma entrada em localStorage) que diz a logica de bloqueio da CMP para impedir que scripts nao essenciais sejam executados em futuros carregamentos de pagina. Se ambos funcionam, o utilizador esta limpo: sem cookies de rastreamento, sem scripts de rastreamento.

Consent respawn acontece quando a eliminacao tem sucesso mas o bloqueio falha. O cenario mais comum:

1. A CMP apaga o cookie `_ga` quando o utilizador clica em rejeitar.

2. A CMP define um cookie de estado de consentimento registando que o utilizador recusou analytics.

3. No carregamento de pagina seguinte, a CMP verifica o seu estado de consentimento e sabe que o utilizador recusou.

4. Mas: a tag do script Google Analytics esta incorporada diretamente no template da pagina (fora do gestor de tags) ou e carregada por uma regra do gestor de tags que nao verifica o estado de consentimento.

5. O script GA carrega, nao ve nenhum cookie `_ga`, e cria um novo.

6. A decisao de rejeicao do utilizador foi anulada.

Variacoes deste padrao incluem: scripts de terceiros carregados atraves de tags `