Cloudflare द्वारा ब्लॉक किया गया

 (jrhawley.ca)
1 पॉइंट द्वारा GN⁺ 2023-08-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • काम के लिए ज़रूरी GitLab पेज पर Cloudflare की ब्राउज़र इंटीग्रिटी जांच खत्म न होने वाली “secure connection loop” में फंस गई, और इसके बाद एक अलग आंतरिक कंपनी वेबसाइट पर भी Firefox की पहुंच रुक गई
  • Firefox में privacy.resistFingerprinting का मान बदलकर GitLab तक पहुंच की समस्या तो हल हो गई, लेकिन अगले दिन एक असंबंधित आंतरिक साइट पर ब्लॉक पेज दिखा, और मान वापस करने पर भी समस्या नहीं सुलझी
  • उसी कार्य डिवाइस, कंपनी VPN और सुरक्षा प्रमाणपत्र की शर्तों में Chrome से पहुंच संभव थी, लेकिन केवल Firefox ब्लॉक हुआ, इसलिए लगा कि ब्लॉक का निर्णय ब्राउज़र fingerprint या fingerprint की अनुपस्थिति से जुड़ा था
  • फिलहाल आंतरिक कार्य साइटों के लिए Chrome का उपयोग करना पड़ेगा, और Cloudflare से “सुरक्षित” की गई कितनी और आंतरिक या बाहरी साइटें प्रभावित होंगी, यह उपयोगकर्ता के लिए जानना मुश्किल है
  • अगर remote attestation, Web Integrity API, passkeys जैसी प्रवृत्तियां कंपनियों को और अधिक अधिकार देती हैं, तो व्यक्ति हार्डवेयर, operating system और software चुनने की आज़ादी खो सकता है और उसे अदृश्य नियमों के हिसाब से चलना पड़ सकता है

Cloudflare की secure connection loop

  • Cloudflare इंटरनेट के बड़े हिस्से को content delivery network, distributed denial-of-service attack defense और अन्य network infrastructure services प्रदान करता है
  • Cloudflare इस्तेमाल करने वाली कई वेबसाइटें पहुंच देने से पहले ब्राउज़र इंटीग्रिटी जांच लगाती हैं
    • इसका उद्देश्य malicious actors, bots और अनचाहे traffic को रोकना है ताकि वास्तविक लोग साइट का उपयोग इच्छित तरीके से करें
    • लेकिन सामान्य उपयोगकर्ता भी अच्छे इरादे से पहुंचने पर security page में अटक सकते हैं
  • secure connection loop वह स्थिति है जिसमें उपयोगकर्ता URL दर्ज करता है, Cloudflare अनुरोध को बीच में रोककर “Checking if the site connection is secure” पेज दिखाता है, और जांच कभी पूरी नहीं होती
    • loading indicator घूमता रहता है, या इंसान होने की पुष्टि फिर से मांगी जाती है और उसके बाद refresh बार-बार होता रहता है
    • उपयोगकर्ता मांगी गई प्रक्रिया पूरी करने पर भी अगला चरण फिर से मांग लिया जाता है और वह पार नहीं हो पाता
  • “Cloudflare checking if the site connection is secure” खोजने पर Cloudflare के आधिकारिक दस्तावेज़ों के अलावा उस पेज को bypass करने की कोशिश करने वाले उपयोगकर्ताओं के कई सवाल मिलते हैं, इसलिए यह एक आम समस्या लगती है

GitLab पहुंच समस्या और Firefox सेटिंग में बदलाव

  • काम के कंप्यूटर पर scientific software की जांच करने के लिए GitLab पेज खोलते समय Cloudflare की ब्राउज़र इंटीग्रिटी जांच वाला पेज दिखाई दिया
  • developer console errors देखे, extensions अस्थायी रूप से disable किए, private browsing window इस्तेमाल की, और कंप्यूटर restart किया, लेकिन loop से बाहर नहीं निकल सके
  • खोज परिणामों में Firefox के about:config में privacy.resistFingerprinting विकल्प को disable करने का सुझाव मिला
    • उस समय यह मान पहले से ही false था
    • मान को true करने पर ब्राउज़र इंटीग्रिटी जांच पार हो गई और जिस software की जांच करनी थी, उस तक पहुंच मिल गई

असंबंधित आंतरिक वेबसाइट पर हुआ ब्लॉक

  • अगले दिन काम के लिए ज़रूरी आंतरिक वेबपेज खोलने पर ब्लॉक पेज दिखाई दिया
  • घटनाक्रम के हिसाब से पहले Cloudflare की जांच loop पार नहीं हुई, फिर उसे bypass करने के लिए Firefox की एक privacy-संबंधित setting बदली गई, और उसके बाद एक अलग कार्य साइट पर ब्लॉक लग गया
  • पूरी प्रक्रिया कार्य डिवाइस और कंपनी VPN के पीछे हुई
    • उस VPN तक पहुंच के लिए डिवाइस में एक खास security certificate installed होना ज़रूरी था
    • Cloudflare ने वही certificate मांगा था, इसलिए माना गया कि उसे certificate की मौजूदगी का पता था
  • उपयोगकर्ता के अनुसार पहचान सत्यापित करने के लिए Cloudflare के पास per-user security certificate और कंपनी VPN का IP address जैसे मज़बूत data थे
    • मूल लेख में पहले MAC address का उल्लेख था, लेकिन footnote में सुधार करते हुए कहा गया कि Cloudflare को MAC address नहीं, बल्कि कंपनी VPN के पीछे का IP address ही पता होने की संभावना अधिक है
  • कोई अलग extension install नहीं किया गया, headless browser इस्तेमाल नहीं हुआ, user agent नहीं बदला गया, Tor या nonstandard protocol नहीं अपनाया गया; केवल ब्राउज़र की एक privacy setting बदली गई थी
  • setting को मूल मान पर लौटाने के बाद भी ब्लॉक नहीं हटा, और काम के लिए ज़रूरी resources तक पहुंच अनिश्चित हो गई

ब्लॉक के कारण का अनुमान और Chrome से तुलना

  • secure connection loop की वजह से ब्राउज़र ने कम समय में एक ही पेज तक कई बार पहुंचने का अनुरोध किया, और Cloudflare ने संभवतः इस उच्च request-rejection frequency को संदिग्ध pattern के रूप में देखा होगा
    • यह पक्का कारण नहीं, केवल एक संभावित व्याख्या है
    • इसके बाद fingerprinting block करने के बावजूद पहली पहुंच संभव हुई, लेकिन Cloudflare ने घटनाओं की इस श्रृंखला को malicious behavior मानकर ब्राउज़र को suspect के रूप में चिह्नित कर दिया होगा
  • आंतरिक साइट तक Google Chrome से पहुंचने की कोशिश करने पर ब्लॉक नहीं लगा
  • Firefox में ब्लॉक होना और Chrome में न होना इस निष्कर्ष तक ले गया कि Cloudflare का ब्लॉक ब्राउज़र fingerprint या fingerprint की अनुपस्थिति पर आधारित है
    • दोनों अनुरोध एक ही security certificate, एक ही कंपनी VPN, एक ही डिवाइस और एक ही समयावधि में किए गए थे
    • फर्क सिर्फ इस्तेमाल किए गए browser का था
  • लेखक का मानना है कि Chrome में Firefox जैसी privacy और security hardening नहीं है, और वह fingerprinting का उसी स्तर तक प्रतिरोध नहीं करता या वैसी settings बदलने की ज़रूरत नहीं पड़ती

काम पर प्रभाव

  • निकट भविष्य में आंतरिक कार्य साइटों तक पहुंच के लिए Chrome का इस्तेमाल करना पड़ेगा
  • Cloudflare से “सुरक्षित” की गई कितनी और आंतरिक या बाहरी वेबसाइटें और ब्लॉक होंगी, यह पता नहीं
  • Firefox को फिर से install करने की कोशिश की जा सकती है, लेकिन पहले की अनुमान-आधारित कोशिशों से स्थिति और खराब होने के अनुभव के कारण अगला कदम लेकर भरोसा नहीं है
  • उपयोगकर्ता के पास स्वयं समस्या हल करने की कोई स्पष्ट प्रक्रिया नहीं है, इसलिए संभव है कि कंपनी directory में उस पेज के लिए ज़िम्मेदार system administrator को ढूंढकर access allow करने का अनुरोध करना पड़े

पूरे वेब को लेकर चिंता

  • मज़बूत identity evidence होने के बावजूद अगर अपेक्षित व्यवहार से एक कदम हटते ही ज़रूरी resources तक पहुंच रुक सकती है, तो यह वेब के भविष्य को लेकर चिंता पैदा करता है
  • यदि remote attestation और “security” उपाय online banking जैसे क्षेत्रों में लागू होते हैं, तो वे व्यक्तिगत जीवन के लगभग हर हिस्से को प्रभावित कर सकते हैं
  • de-Googled Android उपयोगकर्ताओं को banking apps चलाने के लिए hardware attestation को सही तरह से काम कराने में काफी मेहनत करनी पड़ती है
    • GrapheneOS की attestation compatibility guide ऐसा ही एक उदाहरण है
    • लेखक के अनुसार अपने निजी डिवाइस से पैसे तक पहुंच रखने और Google को डिवाइस interactions की निगरानी करने देने के बीच का मध्य मार्ग बहुत कम है
  • ऐसे web proposals जो व्यक्तियों की तुलना में कम जवाबदेह कंपनियों को अधिक शक्ति देते हैं, उपयोगकर्ताओं को अदृश्य नियमों के अनुरूप भटकने के लिए मजबूर करने वाली स्थितियां बढ़ा सकते हैं
  • हाल के वर्षों में ही privacy law का उल्लंघन करने वाली कंपनियों पर वास्तविक दंड लगना शुरू हुआ है, और GDPR उल्लंघन के लिए Facebook पर 1.2 billion euro का जुर्माना इसका एक उदाहरण है

Web Integrity API और passkeys से उठते सवाल

  • Web Integrity API proposal वेब के भविष्य को लेकर विरोध पैदा करने वाला एक प्रस्ताव था
    • अगर financial companies अपनी वेबसाइटों पर remote attestation policies लागू करती हैं, तो लोग किस तरह का hardware, operating system और software इस्तेमाल कर सकते हैं, यह और सीमित हो सकता है
    • पुराने और patch न किए जा सकने वाले vulnerable devices को रोकने के वैध कारण हो सकते हैं, लेकिन लेखक का मानना है कि कंपनियों के निर्णय व्यक्तिगत स्वतंत्रता या अधिकारों की कीमत पर corporate control बढ़ाने की दिशा में जा सकते हैं
  • Web Integrity API proposal का पहला उदाहरण यह बताता है कि ad-supported websites पर advertisers को यह सुनिश्चित करने के लिए भुगतान कर पाना चाहिए कि ads robots नहीं बल्कि इंसान देखें
    • लेखक के अनुसार इसका नतीजा यह होता है कि इंसानी उपयोगकर्ताओं पर खुद को इंसान साबित करने का बोझ डाल दिया जाता है
    • प्रस्ताव लिखने वाला व्यक्ति भारी ad revenue वाली Google से जुड़ा था, इस बात पर भी सवाल उठाया गया है
  • passkeys अपनाना अधिक सुरक्षित और सरल वेबसाइट access देने वाला उपयोगी प्रस्ताव हो सकता है
    • लेकिन अगर Cloudflare वाले अनुभव की तरह मज़बूत identity evidence को भी अनदेखा किया जा सकता है, तो यह स्पष्ट नहीं कि Cloudflare जैसे service providers passkeys के साथ कैसा व्यवहार करेंगे
  • passkeys को लेकर कई practical सवाल बचे हुए हैं
    • क्या उपयोगकर्ता passkeys खुद बना और sync कर सकते हैं
    • यदि केवल खास software ही passkeys का उपयोग कर सकता है, तो यह मानक कौन तय करेगा
    • क्या TPM, DeviceCheck, Integrity API जैसी विशेष hardware या software requirements ज़रूरी होंगी
    • क्या passkeys को किसी भी समय एक service provider से export करके दूसरे provider में ले जाया जा सकता है
    • अगर किसी संदिग्ध घटना से कोई passkey जुड़ जाए, तो क्या उसी passkey का उपयोग करने वाले दूसरे डिवाइसों तक भी suspicion flag फैल जाएगा
    • क्या संदिग्ध passkeys वाले डिवाइस भी suspect के रूप में चिह्नित होंगे, और क्या इससे उस डिवाइस से अन्य स्वतंत्र वेबसाइटों तक पहुंच भी प्रभावित होगी
  • passwords में कई कमियां हैं, लेकिन उनकी एक ताकत यह है कि व्यक्ति उन्हें खुद बना सकता है, अपने डिवाइस पर बना सकता है, और अपनी पसंद के तरीके से प्रबंधित कर सकता है
  • VPN, certificates और fingerprinting जैसी तकनीकें passwords और computer security की कमजोरियों की भरपाई करें, तब भी अगर बुनियादी काम करने के लिए privacy छोड़नी पड़े और उसके बाद भी ब्लॉक हो जाएं, तो ऐसी मदद सीमित ही रहती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-09
Hacker News की टिप्पणियाँ

  • जो लोग खुद को privacy को लेकर संवेदनशील बताते हैं, वे भी अक्सर Chrome इस्तेमाल करते हुए यह बात नहीं जानते
    जो पेज Firefox में ब्लॉक हो रहा था, वह Chrome में खुल गया, लेकिन Chrome में Firefox जैसी privacy और security को मजबूत करने वाली design नहीं है; यह browsing history और personal data ज्यादा collect/share करता है और fingerprint tracking के खिलाफ भी कम resistance रखता है
    वही certificate, वही company VPN, वही device, वही time zone होने पर अगर सिर्फ browser बदलने से पास हो गया, तो लगता है कि Cloudflare browser के fingerprint या fingerprint की अनुपस्थिति के आधार पर ब्लॉक कर रहा है
    आजकल अगर आपको थोड़ी भी परवाह है, तो Chrome इस्तेमाल नहीं करना चाहिए

    • मैं Google fan नहीं हूँ, लेकिन “Chrome ने ज्यादा जानकारी दी इसलिए पास हो गया” वाला तर्क बहुत मजबूत नहीं है
      इस स्थिति में यह साफ नहीं है कि Chrome ने Firefox से अलग कौन-सी जानकारी दी, और हो सकता है कि Firefox एक ज्यादा rare user agent होने की वजह से stricter filtering का target बन गया हो
      मैंने देखा है कि किसी site पर browser बदलने से rate limit message गायब हो जाता है; संभव है कि limited information के आधार पर same IP + different user agent = different computer मान लिया गया हो
      कम से कम तीसरे browser से भी test करना चाहिए
    • तथाकथित “bot” और “human” में फर्क करने की कोशिश करने वाले heuristics तब तक अनुपयुक्त हैं, जब तक इंसानों को bot समझकर block किया जाता है
      “Chrome इस्तेमाल करो” कोई समाधान नहीं है, और Firefox या कोई अन्य non-Google software इस्तेमाल करने वाले लोग भी इंसान ही हैं
      JavaScript से “bot नहीं है” verify करने का तरीका ऐसा लगता है जैसे user को JavaScript on रखने और खुद को ज्यादा ad impressions के लिए खुला छोड़ने पर मजबूर करने का साधन हो
    • Chrome इस्तेमाल न करने को कहना आसान है, लेकिन Cloudflare इस्तेमाल न करो कहना कहीं ज्यादा मुश्किल है
      अगर market पर monopoly करने और open internet के भविष्य को खतरे में डालने को कसौटी मानें, तो Cloudflare बड़ा खतरा है; और जिस क्षण Cloudflare की तानाशाही कम benevolent हो जाएगी, सबको इसका एहसास होगा
    • आजकल अगर आपको थोड़ी भी परवाह है, तो Chrome के साथ-साथ Cloudflare भी इस्तेमाल नहीं करना चाहिए
    • “privacy के प्रति संवेदनशील लोग Chrome बहुत इस्तेमाल करते हैं” यह तो पहली बार सुन रहा हूँ

  • मैं Cloudflare के challenge platform का PM हूँ, और समस्या की वजह देखना चाहूँगा
    हम केवल repetitive actions के आधार पर users को penalty नहीं देते, इसलिए सिर्फ उस वजह से browser suspicious के रूप में mark नहीं होगा
    मैं व्यक्तिगत रूप से Firefox काफी इस्तेमाल करता हूँ, लेकिन ऐसा behavior नहीं देखा; अगर यह Firefox-wide issue होता, तो automatic alerts trigger होते और इसे major incident की तरह handle किया जाता
    अगर troubleshooting में रुचि हो, तो amartinetti at cloudflare पर email भेज सकते हैं

    • समस्या की वजह यह है कि software में design-level defect है
      IP address packet routing के लिए होता है, background में users को “behavior score” देने के लिए नहीं। मेरा IP कल किसी पूरी तरह अलग व्यक्ति का IP रहा हो सकता है
      TLS signature के आधार पर यह तय करना कि web के आधे हिस्से तक कौन पहुंच सकता है, लंबे समय में कुछ हल नहीं करता; यह browser monopoly को मजबूत करता है और open web की भावना के सीधे खिलाफ है
      hobby project के तौर पर crawler जैसे bots चलाता हूँ, इसलिए कुछ हद तक गलती मेरी भी है, लेकिन Chrome के TLS signature की नकल करूँ तो वह अब भी काम करता है। मेरे ऐसे दोस्त भी इस block में फंस गए जिनके पास technical knowledge नहीं है और जिन्होंने कुछ भी नहीं किया
      Cloudflare service ने संभवतः लाखों लोगों को एक दिन अचानक WWW के आधे हिस्से से block होने का नुकसान पहुँचाया, और ऐसा नुकसान site access तय करने वाले heuristics का logical परिणाम है
      यह भी हास्यास्पद है कि मेरे देश के बाहर की कोई single company तय करे कि मैं web इस्तेमाल कर सकता हूँ या नहीं; और अब Firefox इस्तेमाल जारी रखने के लिए मुझे shady जगहों से proxy खरीदने के लिए भटकना पड़ेगा
    • मैं Firefox इस्तेमाल करता हूँ, और हाल में Cloudflare का “इंसान हैं या नहीं verify करें” वाला interception page ज्यादा बार दिख रहा है
      आमतौर पर यह अपने-आप खत्म हो जाता है, इसलिए बड़ी बात नहीं, लेकिन पिछले हफ्ते frequency बढ़ी है, ऐसा महसूस हुआ
    • मैं Firefox इस्तेमाल करता हूँ, लेकिन CAPTCHA हल करने की संख्या बढ़ी है, ऐसा महसूस नहीं हुआ; “connection secure” page भी शायद ही दिखता है
      हो सकता है यह मेरे इस्तेमाल किए जा रहे Privacy Pass extension की वजह से हो, हालांकि वह असल में क्या करता है यह ठीक से नहीं जानता
    • जो IP proxy मैं सामान्य तौर पर इस्तेमाल करता था, उसमें datacenter ownership बदलने से ARIN से RIPE में बदलाव हुआ और समस्या आई
      असली location अब भी NYC है, लेकिन जब अमेरिका की Cloudflare-protected sites access करता हूँ तो ऐसा दिखता है जैसे मैं UK से आया हूँ, और local newspapers, grocery stores, card companies आदि में लगातार ज्यादा जगहों पर block हो रहा हूँ
      Cloudflare की IPv6 geolocation information खराब है, और IPv4 से connect करने पर भी यह interfere करता दिखता है। वैसे भी geolocation-based decision शुरू से ही अच्छा idea नहीं है
    • ProtonVPN के जरिए traffic route करने पर Firefox में मैंने यह phenomenon देखा
      हो सकता है VPN के दूसरे users ने bad behavior किया हो, लेकिन लगता है कि बात उससे आगे की है

  • कुछ समय तक मुझे भी बिल्कुल यही समस्या थी, और ब्राउज़र history में “just a moment” खोजकर वे साइटें मिल गईं जिन तक मैं पहुंच नहीं पा रहा था
    https://gitlab.com/users/sign_in, https://steamdb.info/login/, https://www.zabbix.com/forum/, https://casetext.com/, https://namemc.com/login, https://spinroot.com/, https://camelcamelcamel.com/
    यह समस्या कई महीनों, शायद कई सालों से चल रही है, लेकिन Cloudflare इसे ठीक करता नहीं दिखता; ऐसा लगता है मानो उसे open web पसंद नहीं है और वह Chrome/Chromium/Blink के प्रभुत्व को थोपना चाहता है

    • अगर आप ऐसे बार-बार आने वाले challenge में दिखने वाला rayID साझा कर सकें, तो मैं इसे देखना चाहूंगा
      rayID में व्यक्तिगत पहचान योग्य जानकारी नहीं होती, इसलिए इसे सार्वजनिक किया जा सकता है, या amartinetti at cloudflare पर मेल भेज सकते हैं
      हम जल्द ही एक reporting mechanism भी रोल आउट करने वाले हैं, ताकि आगे ऐसी समस्याओं की जल्दी सूचना दी जा सके और उन पर तेजी से कार्रवाई हो सके
    • मेरे साथ भी यह हमेशा होता है, कई सालों से जारी है और समय के साथ साफ तौर पर बदतर होता जा रहा है
      वेब इस्तेमाल करने के लिए आपको किसी न किसी तरह कीमत चुकानी पड़ती है: सख्त privacy settings की वजह से access खो दें, या अपनी privacy छोड़ दें। जीतने का कोई तरीका नहीं है
    • Waterfox में समस्या नहीं थी, लेकिन अब सिर्फ किसी वेबसाइट पर जाने के लिए भी JavaScript की जरूरत होना बेतुका है
    • Cloudflare की वजह से GitLab ने भी login रोक दिया था, तब भी जब मैं paid customer था
      दूसरे कारणों से अब मैं पैसे नहीं देता, लेकिन कुल मिलाकर लगता है कि अच्छा ही हुआ कि रिश्ता टूट गया
    • लगता है users Chrome का प्रभुत्व चाहते हैं और open web या Firefox की परवाह नहीं करते
      यह desktop पर नंबर 1 browser है, जबकि यह operating system में default शामिल भी नहीं है; Windows में Edge है और Mac में Safari, फिर भी users खुद Chrome download करते हैं

  • जब internet traffic का बड़ा हिस्सा किसी एक स्रोत द्वारा नियंत्रित हो, तो ऐसी समस्याएं आती ही हैं
    Cloudflare अगर मनमाने ढंग से तय कर दे कि कौन internet इस्तेमाल कर सकता है, तो व्यवहार में वही बात कानून बन जाती है
    शुरुआत में यह “bad actors को आसानी से रोकने का तरीका” जैसी भोली धारणा से शुरू होता है, लेकिन अंत में मनमाने मानदंडों तक फैल जाता है
    privacy protection की वकालत करनी है तो बुरे लोगों को भी अनुमति देनी पड़ेगी, लेकिन औसत internet user इस बारीकी को नहीं समझता
    सबसे भोले मामले में भी एक गलत commit internet को गिरा सकता है, और Cloudflare में ऐसा पहले हो चुका है
    Cloudflare, Google, Meta जैसी कंपनियों की वजह से antitrust laws मौजूद हैं, लेकिन उन्हें ठीक से इस्तेमाल करने वाला अधिकार-प्राप्त व्यक्ति दिखाई नहीं देता। 20 साल बाद का internet अब तक देखी किसी भी चीज से बिल्कुल अलग होगा, और शायद वह बदलाव अच्छा नहीं होगा

    • आप Cloudflare को पैसे देने वाले customer नहीं हैं; customers वे sites हैं जो अपनी infrastructure protection के लिए भुगतान करती हैं
      Customers कई CDN/WAF providers में से चुन सकते हैं, Cloudflare सबसे बड़ा provider भी नहीं है, Akamai उससे बड़ा है
      सबसे तेजी से बढ़ने वाला CDN CloudFront है और competition भी स्वस्थ दिखता है, इसलिए समझ नहीं आता कि antitrust laws क्यों लागू होने चाहिए
    • सब लोग भूल रहे हैं कि crawlers और bots की वजह से websites लगभग इस्तेमाल लायक नहीं रह जातीं
      site owner इसे रोकने के लिए Cloudflare चुनता है, Cloudflare इसे मजबूर नहीं करता
    • आज का internet भी 20 साल पहले के internet से बिल्कुल अलग है
    • मुझे नहीं लगता कि Cloudflare का market share इतना है कि antitrust चिंता पैदा हो
    • antitrust की बात तभी सही है जब Cloudflare किसी competitor के पास जाने से रोके

  • Cloudflare के कई session cookies, “rubber integrity” pages या “super bot-fight” mode में भेजे जाने वाले man-in-the-middle inserted scripts को खोलकर देखें, तो पता चलता है कि वे असल में web worker से browser integrity check heuristic तरीके से कर रहे हैं
    यानी वे tests की एक series चलाते हैं जिसमें user द्वारा चलाया जा रहा वास्तविक browser pass हो, लेकिन bot द्वारा चलाया जा रहा headless browser fail हो जाए
    उदाहरण के लिए, यह देखने के लिए कि यह real browser है या raw HTML parser, image को canvas पर draw करके PNG के रूप में export कर hash compare करना; या Puppeteer को Lambda/Cloud Function के default container में चलाते समय अक्सर छूट जाने वाले consumer OS के अजीब fonts की जांच करना
    इससे आगे, prompt को activate करने से पहले अनावश्यक mouse movements और key inputs इंसानी गलतियों जैसे दिखते हैं या नहीं, और क्या वे हाल में देखे गए recording playback patterns से मिलते-जुलते तो नहीं, यह भी देखते हैं
    अगर आप verification loop में फंस गए हैं, तो वजह यह है कि आपके browser, device या extensions ने इन heuristics को इतना छिपा या disable कर दिया कि Cloudflare को आपके इंसान होने का पक्का सबूत नहीं मिला; और site owner की settings के आधार पर fail बता देने के बजाय वह सबूत जुटाने की कोशिश जारी रखता है
    क्योंकि bot को failure बता देना ऐसा संकेत देना है कि “जो तरीका काम नहीं कर रहा उसे रोक दो और shield frequency बदलो”

    • user के नजरिए से यह बस website broken है जैसा दिखता है
      कोई console exception नहीं, बस वही page बार-बार reload होता रहता है
    • अगर bot Cloudflare loop में 10 मिनट तक फंसा रहता है, तो मेरे हिसाब से यह काफी मजबूत संकेत है कि कुछ काम नहीं कर रहा
    • अगर ऐसा है, तो कम common browsers या कम common platforms पर होने वाली blocking को कैसे समझाएं, यह मुझे नहीं पता

  • कभी-कभी जो बात छूट जाती है, वह यह है कि Cloudflare इस्तेमाल करने वाला site owner globally तय करता है कि कितना paranoid होना है, और अलग से बहुत granular और aggressive WAF rules भी बना सकता है
    इसलिए कुछ मामलों में site owner ने जरूरत से ज्यादा aggressive rules set किए होते हैं, लेकिन गालियां Cloudflare को मिलती हैं। end user को दिखने वाला असर आम तौर पर वही होता है
    पहले मैंने Google Cloud, OVH, DigitalOcean जैसे बड़े datacenters से आने वाले सभी unverified bot traffic को block करने वाला WAF rule बनाया था, लेकिन यह गलती थी क्योंकि कई companies किसी वजह से अपने traffic को उन ASN के जरिए route कर रही थीं
    वे users Cloudflare पर गुस्सा हुए होंगे, लेकिन असली वजह मेरी गलत configuration थी

  • प्रोग्रामिंग क्लास में उदाहरण के तौर पर एक सरल browser इस्तेमाल किया जाता है; यह CSS या JavaScript प्रोसेस नहीं करता, इसलिए display कच्चा-सा दिखता है, लेकिन काम करता है
    कुछ sites पर यह चलता है, लेकिन खासकर बड़ी sites इसे अज्ञात browser मानकर content भेजने से मना कर देती हैं। शायद वे इसे bot समझती हैं
    भले ही यह bot हो, अगर यह शिष्ट तरीके से व्यवहार कर रहा है तो समस्या क्या है, समझ नहीं आता; और सवाल उठता है कि क्या हमने बड़ी कंपनियों को ऐसा बंद web बनाने की अनुमति दे दी है

    • Site खुद तय कर सकती है कि किसी request का जवाब देना है या नहीं
      हर किसी को service देने की कोई बाध्यता नहीं है
    • शैतान के वकील की भूमिका में, मैं जानना चाहूंगा कि server को यह तय क्यों नहीं करना चाहिए कि वह किस client से बात करेगा

  • यह भी झुंझलाहट भरा है कि Cloudflare का check page Firefox के page refresh को बिगाड़ देता है
    जब Cloudflare आपको मूल page पर वापस भेजता है, तो वह POST के जरिए जाता है; पहला POST Cloudflare intercept कर लेता है, लेकिन page refresh करने पर वही POST असली page तक पहुंच जाता है, और संभव है कि page को समझ न आए कि क्या करना है और वह error दिखा दे
    इसका हल बस इतना है कि refresh के बजाय address bar में Enter दबाकर दोबारा navigate करें, या उस page पर वापस जाने वाला link खोजें
    ऐसे POST की वजह से किसी site पर block हो जाएं तो हैरानी नहीं होगी। वे सोच सकते हैं, “इसे पता है कि उस page पर POST नहीं करना चाहिए, फिर भी भेजा, इसलिए यह hacking की कोशिश करने वाला malicious bot है”

  • Cloudflare जिस बार 15–30 सेकंड वाला “checking your connection” page दिखवाता है, वह बेहिसाब ज्यादा है
    मेरे जैसे ADHD के साथ जीने वाले व्यक्ति के लिए, दिन भर जमा होने वाली ऐसी देरी और रुकावटें गंभीर असर डाल सकती हैं
    दवा ठीक से लेने पर भी यह उपाय सच में असहाय महसूस कराता है, और online experience को भयानक व थकाऊ बना देता है

    • आम तौर पर ऐसा उन sites पर चालू किया जाता है जो गंभीर DDoS attack झेल रही होती हैं
      कोई भी users को यह दिखाना नहीं चाहता, लेकिन मजबूरी में इस्तेमाल करना पड़ता है
    • यह Cloudflare खुद नहीं करवाता; Cloudflare इस्तेमाल करने वाला customer इसे इस तरह configure करता है
    • Cloudflare का Privacy Pass मदद कर सकता है: https://privacypass.github.io/
      यह privacy के लिए बहुत खराब न होने वाले तरीके से दिखने वाले CAPTCHA की संख्या काफी घटा देगा
      Safari में Private Access Tokens चालू किए जा सकते हैं: https://blog.cloudflare.com/how-to-enable-private-access-tok...
      दोनों तरीकों में बाहरी issuer token बनाता है, इस मायने में यह Google के web DRM proposal जैसा है; लेकिन Google की कोशिश के उलट, ये token इस्तेमाल करने वाले page पर ad blocker बंद है, इसकी गारंटी नहीं देते

  • कल ही पता चला कि Safari या Firefox से PayPal login नहीं हो रहा, और सिर्फ Chromium-based browsers में होता है
    हम धीरे-धीरे “यह site Google Chrome के लिए optimized है” वाले दौर में और गहराई तक जा रहे हैं

    • Twitch में भी यह समस्या है
      Firefox में fingerprinting protection चालू हो तो login नहीं कर सकते, और लगता है कि सिर्फ two-factor authentication से account protection पर्याप्त नहीं है
      अगर मैं Twitch को अपने computer को uniquely identify करने की अनुमति नहीं देता, तो वह login की अनुमति नहीं देता, इसलिए मैंने बस Twitch streams देखना छोड़ दिया
    • PayPal की समस्या कुछ समय से झेल रहा हूं
      Windows, Linux, Android के Firefox सभी में ऐसा हुआ; शुक्र है कि app में अभी भी login है, लेकिन Firefox से PayPal में नहीं जा पाने के कारण PayPal balance होने के बावजूद कभी credit card से payment करना पड़ा