Tell HN: Cloudflare inyecta silenciosamente sus analíticas cuando cambias los servidores de nombres

Discusión en Hacker News ↗

Cloudflare está recibiendo críticas por inyectar automáticamente su baliza de Web Analytics basada en JavaScript en sitios que usan su proxy inverso/CDN, incluso cuando los propietarios creían haber desactivado las analíticas o solo querían servicios DNS. Los comentaristas sostienen que esta modificación de contenido “man-in-the-middle” erosiona la confianza, plantea cuestiones de privacidad y GDPR, y ejemplifica valores predeterminados de patrón oscuro que favorecen la recopilación de datos de Cloudflare sobre el consentimiento del usuario. Otros responden que la terminación TLS y las modificaciones en línea son inherentes a la oferta principal de proxy de Cloudflare, señalan que la función puede desactivarse y sugieren que quienes quieran garantías contra tales cambios deberían evitar por completo los CDN basados en proxy.

Lo que cambió Cloudflare

  • Cloudflare ahora inyecta una baliza de JavaScript (cloudflareinsights.com) en los sitios proxyados para impulsar sus herramientas de Real User Measurement (RUM) “Web Analytics” y Observatory.
  • Esto está habilitado por defecto en los planes gratuitos; en los planes de pago es solo bajo opción de activación.
  • Algunos usuarios informan que Web Analytics aparece como desactivado, pero que tienen que activarlo solo para acceder a la opción de desactivar la baliza.

Cuándo ocurre la inyección (Proxy vs DNS)

  • La inyección solo ocurre cuando Cloudflare actúa como proxy inverso (nube naranja / registros “Proxied”), no cuando los dominios son solo DNS (nube gris).
  • Con registros proxyados, TLS termina en Cloudflare, así que puede ver y modificar las respuestas HTML en tránsito.
  • Varios usuarios no sabían que habían activado el proxy, o encontraron que la interfaz/los valores predeterminados iniciales eran confusos o estaban sesgados hacia activar el proxy.

Reacciones de los usuarios y preocupaciones sobre la confianza

  • Muchos consideran la inyección de scripts una violación grave de la confianza, especialmente para sitios deliberadamente sin JS o centrados en la privacidad.
  • Algunos lo llaman comportamiento de MITM y lo comparan con viejos hosts gratuitos que inyectaban anuncios; otros sostienen que esto es inherente a usar un CDN que termina TLS.
  • Hay preocupación por la “enshittification”: hoy analíticas, mañana anuncios o modificaciones más intrusivas.

Debate sobre privacidad, legalidad y GDPR

  • El blog y el panel de Cloudflare indican que el tráfico de la UE/Reino Unido se excluye por defecto para esta función; la activación global es opcional.
  • Debate sobre el cumplimiento del GDPR:
    • Un lado dice que no almacenan IPs ni datos de la UE, así que el riesgo se reduce.
    • Otros señalan que los propietarios del sitio siguen siendo legalmente responsables del seguimiento de terceros que quizá ni siquiera conozcan.
  • Preocupación de que las políticas de privacidad existentes sean inexactas si no mencionan este seguimiento.

Opciones de exclusión, mitigaciones y alternativas

  • RUM se puede desactivar por dominio mediante Analytics → Web Analytics → ajustes de RUM.
  • Configurar los registros DNS como “DNS Only” impide que Cloudflare toque los payloads, pero también desactiva las funciones de CDN/WAF.
  • Se señala que contramedidas técnicas como CSP o Cache-Control: no-transform son ineficaces si Cloudflare puede reescribir respuestas.
  • Algunos recomiendan proveedores alternativos de DNS/CDN y advierten contra el uso innecesario de Cloudflare, especialmente para sitios pequeños.

Defensas del enfoque de Cloudflare

  • Algunos argumentan que RUM es una función gratuita razonable, coherente con el papel de Cloudflare como proxy, y valiosa para depurar rendimiento.
  • Otros enfatizan que los usuarios gratuitos deberían esperar recopilación de datos y que los operadores deben mantenerse informados sobre sus decisiones de infraestructura.