Como Saber Quando o Scanner Está a Mentir
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
Publiquei um Número que Nada Tinha Medido
Apareceu uma estatística no meu registo de investigação publicado. Parecia uma medição. Era texto fixo dentro de um print, e nada no código a calculava. Como lá foi parar, o que aconteceu quando repeti a experiência a sério, e porque a conclusão óbvia também estava errada.
Um Artigo do ICML Ganhou o Benchmark Sem Responder Nada
Investigadores criaram um método deliberadamente inútil que bate a pontuação-padrão que toda a gente reporta. Repeti a experiência no meu próprio CPU em oito segundos e obtive o número deles. Depois descobri que o código publicado não reproduz o próprio artigo. Eis o que isto significa quando um fornecedor lhe apresenta um benchmark.