Como Saber Quando o Scanner Está a Mentir

Paulo Rodrigues8 min de leitura

Como Saber Quando o Scanner Está a Mentir

Escrevi uma ferramenta para analisar sites à procura de problemas técnicos e de conformidade. Percorreu 65 sites em 83 segundos e apontou seis infrações ao RGPD — sites a carregar analytics que instalam cookies sem pedir consentimento.

Estava errada em três deles.

Só descobri porque confirmei antes de agir. Este artigo é sobre como confirmei, porque é que a ferramenta mentiu de forma tão convincente, e o padrão genuinamente incómodo de quais os casos que errou. Se usa qualquer analisador automático — de segurança, SEO, acessibilidade, conformidade, ou um linter — a falha descrita aqui aplica-se também ao seu.

A mentira

A lógica do scanner parecia razoável. Obter a página. Procurar um script de analytics. Procurar um aviso de cookies. Se há rastreador e não há aviso, é um problema de consentimento.

Seis sites correspondiam. Os achados eram específicos, formatados, e marcados como CRÍTICO.

Depois abri cada um num navegador real, com um perfil limpo, capturei todos os pedidos de rede e despejei os cookies antes de tocar em fosse o que fosse. Três dos seis desfizeram-se:

  • Um corria o Google Consent Mode em estado negado. O script de analytics carrega, mas está impedido de escrever seja o que for. Zero cookies. Aquele site não estava a violar as regras — estava a cumpri-las com cuidado.
  • Num outro, o código de analytics nunca chegou a ser configurado. Ainda trazia o identificador de exemplo do modelo de onde foi copiado, comentado. Nunca recolheu uma única visita na vida.
  • O terceiro tinha mesmo um aviso de cookies. A plataforma onde estava alojado injetava um. O meu scanner simplesmente não o conseguia ver.

Três achados reais, três invenções. E aqui está a parte que devia preocupar qualquer pessoa: a ferramenta reportou os seis com exatamente a mesma confiança. Sem hesitação, sem pontuação mais baixa, sem qualquer marca de incerteza nos três que inventou. CRÍTICO, seis vezes.

Porque é que mentiu

A causa é embaraçosamente simples.

O meu scanner nunca executava JavaScript. Era por isso que era rápido — sem navegador, sem renderização, sem esperas. E os avisos de consentimento de cookies são quase sempre injetados por JavaScript.

Portanto, quando a ferramenta dizia «não foi encontrado nenhum aviso», nunca esteve na verdade a concluir «não existe aviso». Estava a concluir «eu não consigo ver avisos».

As duas frases parecem semelhantes e significam o oposto. Uma é um achado. A outra é uma confissão. A minha ferramenta imprimiu a confissão e rotulou-a de achado.

Isto generaliza-se. A ausência de prova, produzida por uma ferramenta estruturalmente incapaz de perceber essa prova, não é prova de ausência. É ruído de fato e gravata.

As quatro verificações

Esta é a lista que passei a percorrer antes de qualquer achado automático chegar a um ser humano.

1. A ferramenta consegue mesmo ver aquilo que diz estar em falta?

Antes de confiar num achado negativo — «não há aviso», «não há texto alternativo», «não há limitação de pedidos» — pergunte o que a ferramenta teria de fazer para conseguir ver a coisa, e se de facto o fez.

O meu scanner pronunciava-se sobre interfaces injetadas por JavaScript sem executar JavaScript. Assim que se diz esta frase em voz alta, o erro é óbvio. Mas ninguém a diz em voz alta, porque o relatório parece tão acabado.

Os achados negativos são os perigosos. Uma ferramenta que diz «encontrei X» costuma ser fiável — encontrou alguma coisa. Uma ferramenta que diz «falta X» só é tão fiável quanto a sua capacidade de ter encontrado X em primeiro lugar.

2. Teste contra um caso cuja resposta já conhece

Antes de correr o scanner em 65 sites desconhecidos, corri-o contra um site que tinha auditado à mão na semana anterior, onde conhecia cada achado: sem redirecionamento para HTTPS, zero cabeçalhos de segurança, sem etiqueta canónica, sem <h1> na página inicial, compressão corretamente ativa. A ferramenta reproduziu todos — e, o que é importante, não assinalou a compressão que estava a funcionar bem.

É a verificação de correção mais barata que existe para qualquer analisador, e foi o que me permitiu confiar na ferramenta em sites que nunca tinha visto.

Mas repare no que isso não evitou. O scanner passou o teste de referência na perfeição e continuava, ainda assim, estruturalmente cego. O site que usei como referência não tinha aviso de cookies nem rastreadores, por isso o ponto cego nunca chegou a disparar.

Passar num teste de referência é necessário. Não é suficiente. O caso de teste tem de exercitar aquilo que pode falhar.

3. Verifique o mecanismo, não o indício

Foi esta que produziu o meu pior erro.

Eu verificava: existe um script de analytics nesta página?

A lei preocupa-se com: está a ser escrito um cookie no dispositivo do visitante?

Não são o mesmo teste. O primeiro é um indício aproximado do segundo — normalmente correlacionado, fácil de verificar, e errado exatamente nos casos que importam. Eu tinha programado a aproximação e rotulei-a de coisa real.

Todos os analisadores heurísticos estão cheios de aproximações destas, porque são elas que os tornam baratos. Isso é aceitável. O que não é aceitável é esquecer quais das verificações são aproximações, e depois reportar o resultado de uma aproximação como se fosse o do mecanismo.

4. Mantenha um registo de falsos positivos

Escreva cada achado que eliminou, e porquê.

Não por arrumação — por calibração. É o único registo honesto da frequência com que as suas ferramentas estão confiantemente erradas. O meu diz agora: três em seis, no tipo de achado que mais me interessava.

Sem esse registo, teria guardado isto na memória como «o scanner funciona bem». Com ele, sei a taxa real, e sei que nunca devo deixar aquele tipo de achado chegar a um estranho sem verificação.

O registo corta nos dois sentidos, já agora. A passagem pelo navegador também apanhou um pedido a tipos de letra de terceiros que expunha o endereço IP dos visitantes e que a análise rápida tinha falhado por completo. A verificação não serve apenas para matar falsos positivos. Encontra o que a passagem barata não conseguia ver.

Depois acusou-me a mim

Depois de reduzir os seis achados a três, apontei o scanner ao imparlabs.com, como teste de sanidade.

Devolveu CRÍTICO. Uma infração ao RGPD. No meu próprio site.

Estava errado, e vale a pena assentar na razão.

O imparlabs.com usa analytics auto-alojado e sem cookies. Escreve zero cookies no dispositivo de quem o visita. Na ePrivacy não há nada a consentir, logo não precisa de aviso de cookies. Não é uma brecha que eu esteja a explorar — é precisamente o objetivo de o construir assim.

O meu scanner viu «existe um script de analytics e não há aviso de cookies» e chamou-lhe infração. Estava a assinalar exatamente a arquitetura respeitadora da privacidade que torna o aviso desnecessário.

É a verificação 3 a falhar, na sua forma mais pura. O consentimento é desencadeado por um cookie ser escrito, não por um script existir. Eu tinha programado o teste errado, e ele condenava todas as configurações sem cookies do planeta — incluindo aquela que eu construí de propósito para ser limpa.

A correção foi fazer a regra assentar no mecanismo: analytics sem cookies (Umami, Plausible, Fathom) ficam isentos de consentimento, excluídos do achado, e creditados em vez de assinalados. O Matomo mantém-se deliberadamente na coluna dos que exigem consentimento, porque a partir de HTML estático não é possível saber se está auto-alojado em modo sem cookies. Quando a ferramenta não pode saber, não deve adivinhar — deve remeter para uma pessoa.

Se levar apenas uma coisa prática deste artigo, leve esta: se usa analytics na União Europeia, a pergunta que decide se precisa de um aviso de cookies não é «qual é o fornecedor?». É «isto escreve alguma coisa no dispositivo do meu visitante?». Analytics sem cookies, auto-alojado, responde que não — e a exigência do aviso desaparece com essa resposta.

O padrão incómodo

Agora repare em quais foram os três achados errados.

  • O site a correr o Consent Mode em estado negado — a fazer bem.
  • O site cujo analytics nunca foi ligado — a não recolher nada.
  • A minha própria configuração sem cookies — construída de propósito para ser limpa.

Entretanto, os infratores diretos — script carregado, cookies escritos, aviso nenhum à vista — foram apanhados corretamente e sem dificuldade.

Os falsos positivos de um scanner barato não se distribuem por igual pela lista. Concentram-se nos casos sofisticados.

Faz sentido, assim que se vê. Um site que pensou com cuidado no consentimento produz uma assinatura subtil: o script continua lá, mas o comportamento está limitado de uma forma que só se manifesta em execução. Numa análise estática, o cuidadoso e o descuidado são indistinguíveis. O infrator ingénuo, pelo contrário, é trivialmente detetável — não fez nada.

Ou seja: a sua ferramenta está mais errada precisamente sobre as pessoas que vão perceber de imediato que está errada. E é por isso que isto importa muito para além da arrumação técnica:

Um falso positivo apanhado internamente custa um minuto. O mesmo falso positivo enviado a um estranho custa a relação — e contamina todos os achados desse relatório que eram verdadeiros.

Essa assimetria é o argumento inteiro para o passo de verificação.

A regra

Um scanner produz suspeitas, nunca conclusões. Nada chega a uma pessoa antes de algo capaz de ver a verdade o ter confirmado.

Isto não é um argumento contra ferramentas rápidas. A análise de 83 segundos foi genuinamente valiosa — reduziu 65 sites a um punhado que valia a pena examinar, que é exatamente o que devia fazer. A velocidade vem da aproximação. Tornar o scanner lento e exaustivo destruiria aquilo que o tornava útil.

A resposta não é um scanner melhor. É saber de que lado da fronteira de confiança o scanner está.

Use a passagem rápida para decidir onde olhar. Use um navegador — algo capaz de observar mesmo o comportamento — para decidir o que é verdade. E nunca, em circunstância alguma, deixe o primeiro falar diretamente com outro ser humano em seu nome.

Porque um scanner vai mentir. Vai fazê-lo numa tabela bem formatada, marcada a CRÍTICO, com total confiança, e não vai dizer quais dos achados inventou.

Essa parte é trabalho seu.

Perguntas Frequentes

Porque é que o scanner apontou infrações que não existiam?

Porque não conseguia ver a prova que as ilibaria. O scanner obtinha o HTML em bruto com curl e nunca executava JavaScript — e os avisos de consentimento de cookies são quase sempre injetados por JavaScript. Portanto, quando dizia «não foi encontrado nenhum aviso de cookies», não estava a concluir que não existia aviso. Estava a concluir que não conseguia ver avisos. São afirmações completamente diferentes, e a ferramenta não tinha forma de as distinguir. Qualquer verificação que dependa de algo que a ferramenta é estruturalmente incapaz de perceber produz disparates confiantes e bem formatados.

Ter o Google Analytics significa automaticamente que preciso de um aviso de cookies?

Não — e inverter isto foi exatamente o erro que cometemos. Na ePrivacy, o dever de consentimento é desencadeado por escrever ou ler no dispositivo do visitante, o que na prática significa colocar um cookie. Não é desencadeado pela mera presença de um script de analytics. Um site que corra o Google Consent Mode em estado negado carrega o script mas não escreve cookies; um site com analytics sem cookies, auto-alojado, também não escreve nenhum. Nenhum dos dois precisa de aviso. A pergunta correta nunca é «qual é o fornecedor?» — é «isto escreve alguma coisa no dispositivo do visitante?»

Se um scanner é assim tão pouco fiável, para que serve?

Serve precisamente porque é barato à custa de aproximar. O nosso analisou 65 sites em 83 segundos, algo que nenhuma pessoa e nenhum processo com browser conseguiria igualar. O erro não é usá-lo — o erro é deixar o resultado atravessar uma fronteira de confiança sem verificação. Trate os achados de gravidade elevada como uma lista de suspeitas a investigar, nunca como uma conclusão sobre a qual agir. Produz candidatos, não conclusões. É o passo de verificação que torna a velocidade segura.

Pronto para automatizar o seu negócio?

Construímos ferramentas de IA e sistemas de automação para PMEs europeias — desde MVPs rápidos até sistemas em produção, sempre em conformidade com o GDPR.

it's human stuff

Insights semanais de IA para PMEs europeias. Sem exageros, apenas o que funciona.

Continue a Ler