Tell HN: Cloudflare injeta silenciosamente suas análises quando você troca os nameservers

Discussão no Hacker News ↗

A Cloudflare está sendo criticada por injetar automaticamente seu beacon de Web Analytics baseado em JavaScript em sites que usam seu proxy reverso/CDN, mesmo quando os donos dos sites acreditavam ter desativado as análises ou queriam apenas serviços DNS. Comentadores argumentam que essa modificação de conteúdo em estilo “man-in-the-middle” corrói a confiança, levanta questões de privacidade e GDPR, e exemplifica padrões obscuros que favorecem a coleta de dados da Cloudflare em detrimento do consentimento do usuário. Outros contrapõem que a terminação TLS e as modificações inline são inerentes à oferta principal de proxy da Cloudflare, observam que o recurso pode ser desligado e sugerem que usuários que querem garantias contra esse tipo de mudança evitem CDNs baseados em proxy por completo.

O que a Cloudflare mudou

  • A Cloudflare agora injeta um beacon JavaScript (cloudflareinsights.com) em sites proxyados para alimentar suas ferramentas de Real User Measurement (RUM), “Web Analytics” e Observatory.
  • Isso vem ativado por padrão nos planos gratuitos; nos planos pagos, é apenas mediante opt-in.
  • Alguns usuários relatam que o Web Analytics aparece como desativado, mas é preciso ativá-lo só para conseguir acessar a opção de desligar o beacon.

Quando a injeção acontece (Proxy vs DNS)

  • A injeção só ocorre quando a Cloudflare está atuando como proxy reverso (nuvem laranja / registros “Proxied”), e não quando os domínios são apenas DNS (nuvem cinza).
  • Com registros proxyados, o TLS termina na Cloudflare, então ela pode ver e modificar respostas HTML em trânsito.
  • Vários usuários não sabiam que tinham ativado o proxy, ou acharam a interface/configuração inicial confusa ou inclinada a manter o proxy ligado.

Reações dos usuários e preocupações com confiança

  • Muitos veem a injeção de script como uma violação séria de confiança, especialmente para sites deliberadamente sem JavaScript ou focados em privacidade.
  • Alguns chamam isso de comportamento de MITM e comparam com antigos hosts gratuitos que injetavam anúncios; outros argumentam que isso é inerente a usar uma CDN que encerra o TLS.
  • Há preocupação com “enshittification”: hoje análises, amanhã anúncios ou modificações mais intrusivas.

Discussão sobre privacidade, aspectos legais e GDPR

  • O blog e o painel da Cloudflare indicam que o tráfego da UE/Reino Unido é excluído por padrão dessa funcionalidade; a ativação global é opcional.
  • Debate sobre conformidade com GDPR:
    • Um lado diz que eles evitam armazenar IPs e dados da UE, então o risco é reduzido.
    • Outros observam que os proprietários dos sites continuam legalmente responsáveis pelo rastreamento de terceiros que talvez nem saibam que existe.
  • Há preocupação de que políticas de privacidade existentes estejam incorretas se não mencionarem esse rastreamento.

Opções de desativação, mitigação e alternativas

  • O RUM pode ser desativado por domínio em Analytics → Web Analytics → configurações de RUM.
  • Definir os registros DNS como “DNS Only” impede que a Cloudflare mexa nos payloads, mas também desativa recursos de CDN/WAF.
  • Contramedidas técnicas como CSP ou Cache-Control: no-transform são apontadas como ineficazes se a Cloudflare puder reescrever respostas.
  • Alguns recomendam provedores alternativos de DNS/CDN e alertam contra o uso desnecessário da Cloudflare, especialmente para sites pequenos.

Defesas da abordagem da Cloudflare

  • Alguns argumentam que o RUM é um recurso gratuito razoável, coerente com o papel da Cloudflare como proxy e valioso para depuração de desempenho.
  • Outros enfatizam que usuários gratuitos devem esperar coleta de dados e que operadores precisam permanecer informados sobre as escolhas de infraestrutura.