Tell HN: Cloudflare नामसर्वर बदलने पर चुपचाप अपना एनालिटिक्स इंजेक्ट करता है

Cloudflare की आलोचना हो रही है कि वह अपनी reverse proxy/CDN का उपयोग करने वाली साइटों में अपने JavaScript-आधारित Web Analytics beacon को अपने-आप इंजेक्ट करता है, भले ही साइट मालिकों को लगता हो कि उन्होंने analytics बंद कर दिए हैं या केवल DNS services चाहिए थीं। टिप्पणीकारों का तर्क है कि यह “man-in-the-middle” content modification भरोसे को कमजोर करता है, privacy और GDPR संबंधी सवाल उठाता है, और dark-pattern defaults का उदाहरण है जो user consent की बजाय Cloudflare की data collection को प्राथमिकता देते हैं। दूसरे लोग जवाब देते हैं कि TLS termination और inline modifications Cloudflare के core proxy offering का हिस्सा हैं, बताते हैं कि feature बंद किया जा सकता है, और सुझाव देते हैं कि जो लोग ऐसे changes के खिलाफ गारंटी चाहते हैं, उन्हें proxy-based CDNs से बचना चाहिए।

Cloudflare ने क्या बदला

  • Cloudflare अब अपने Real User Measurement (RUM) “Web Analytics” और Observatory टूल्स को चलाने के लिए प्रॉक्सी किए गए साइटों में एक JavaScript beacon (cloudflareinsights.com) इंजेक्ट करता है।
  • यह फ्री प्लान्स पर डिफ़ॉल्ट रूप से सक्षम है; पेड प्लान्स में केवल opt-in है।
  • कुछ उपयोगकर्ताओं ने बताया कि Web Analytics disabled दिखता है, लेकिन beacon बंद करने का विकल्प पाने के लिए भी उसे enable करना पड़ता है।

इंजेक्शन कब होता है (Proxy बनाम DNS)

  • इंजेक्शन केवल तब होता है जब Cloudflare reverse proxy के रूप में काम कर रहा होता है (orange cloud / “Proxied” records), DNS-only (grey cloud) होने पर नहीं।
  • Proxied records के साथ TLS Cloudflare पर terminate होता है, इसलिए वह ट्रांज़िट में HTML responses देख और बदल सकता है।
  • कई उपयोगकर्ताओं को पता ही नहीं था कि उन्होंने proxying सक्षम की हुई है, या उन्हें UI/initial defaults भ्रमित करने वाले या proxy-on की ओर झुके हुए लगे।

उपयोगकर्ताओं की प्रतिक्रियाएँ और भरोसे को लेकर चिंताएँ

  • बहुत से लोग script injection को भरोसे का गंभीर उल्लंघन मानते हैं, खासकर जानबूझकर JS-free या privacy-focused साइटों के लिए।
  • कुछ इसे MITM व्यवहार कहते हैं और पुराने free hosts द्वारा ads इंजेक्ट करने से तुलना करते हैं; दूसरे तर्क देते हैं कि यह TLS terminate करने वाले CDN के उपयोग की अंतर्निहित बात है।
  • “Enshittification” को लेकर चिंता है: आज analytics, कल ads या इससे भी अधिक दखल देने वाले बदलाव।

Privacy, कानूनी, और GDPR चर्चा

  • Cloudflare का blog और dashboard संकेत देते हैं कि इस feature के लिए EU/UK traffic को डिफ़ॉल्ट रूप से बाहर रखा गया है; global enablement वैकल्पिक है।
  • GDPR अनुपालन पर बहस:
    • एक पक्ष कहता है कि वे IPs और EU data store नहीं करते, इसलिए जोखिम कम हो जाता है।
    • दूसरे लोग नोट करते हैं कि site owners तीसरे पक्ष की tracking के लिए कानूनी रूप से जिम्मेदार रहते हैं, जिसके बारे में उन्हें पता भी नहीं हो सकता।
  • चिंता है कि यदि privacy policies में इस tracking का उल्लेख नहीं है, तो वे गलत हैं।

Opt-outs, mitigations, और alternatives

  • RUM को Analytics → Web Analytics → RUM settings के जरिए प्रति domain disable किया जा सकता है।
  • DNS records को “DNS Only” पर सेट करने से Cloudflare payloads को छूना बंद कर देता है, लेकिन CDN/WAF features भी बंद हो जाते हैं।
  • CSP या Cache-Control: no-transform जैसे technical countermeasures को बेअसर माना गया है यदि Cloudflare responses को rewrite कर सकता है।
  • कुछ लोग alternative DNS/CDN providers की सिफारिश करते हैं और Cloudflare के अनावश्यक उपयोग, खासकर छोटे sites पर, से सावधान रहने को कहते हैं।

Cloudflare के दृष्टिकोण के बचाव

  • कुछ लोगों का तर्क है कि RUM एक उचित free feature है, Cloudflare की proxy भूमिका के अनुरूप है, और performance debugging के लिए उपयोगी है।
  • दूसरे इस बात पर ज़ोर देते हैं कि free users को data collection की उम्मीद करनी चाहिए और operators को अपनी infrastructure choices के बारे में informed रहना चाहिए।