Anubis वास्तव में किसे रोकता है?

 (fzakaria.com)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • HTTP एक्सेस से पहले Proof-of-Work मांगने वाला Anubis, AI scraper की तुलना में सामान्य उपयोगकर्ताओं, लो-एंड डिवाइसों और JavaScript-समर्थन न रखने वाले clients पर अधिक और लगातार लागत डालता है
  • LLM द्वारा बनाया गया anubis-fetch Proof-of-Work को सीधे हल करता है, और जरूरत पड़ने पर Chromium चलाता है, साथ ही Chrome के TLS/JA3 fingerprint की नकल करके Cloudflare की मैनुअल blocking को भी पार कर जाता है
  • Scraper जारी किए गए cookies को cache और reuse करके लागत को कई requests में amortize कर सकते हैं, लेकिन इंसानों को हर विज़िट पर कुछ सेकंड का इंतज़ार और battery drain झेलना पड़ता है
  • डिफॉल्ट difficulty 4 में औसतन 65,536 hashes की जरूरत होती है; native Go implementation में इसमें लगभग 1.3ms लगते हैं, browser JavaScript में लगभग 130ms, लेकिन वास्तविक महसूस होने वाला wait time करीब 1~5 सेकंड है
  • अगर प्रति प्रयास 2 सेकंड का महसूस होने वाला समय और 20J ऊर्जा मानें, तो रोज़ 10 लाख challenges पर सालाना लगभग 23 मानव-वर्ष·2MWh, और रोज़ 10 करोड़ challenges पर लगभग 2,300 मानव-वर्ष·200MWh खर्च होते हैं

AI ने Anubis को बायपास किया

  • Linux kernel में binfmt_misc के bpf के जरिए interpreter PT_INTERP में $ORIGIN सपोर्ट जोड़ने वाले patch पर काम करते समय, लेखक ने LLM से Linux kernel mailing list thread पढ़ने को कहा
  • lore.kernel.org ने resource एक्सेस से पहले Proof-of-Work मांगने वाला HTTP proxy Anubis लागू किया हुआ था
  • LLM ने इस प्रतिबंध को संभालने के लिए anubis-fetch बनाया
    • पहले यह Proof-of-Work को native तरीके से हल करता है, और विफल होने पर Chromium से URL खोलता है
    • req का उपयोग करके यह असली Chrome के TLS/JA3 fingerprint की नकल करता है, जिससे Cloudflare की मैनुअल blocking भी पार हो जाती है
    • anubis-fetch <URL> HTML को standard output में देता है, और --text विकल्प पढ़ने में आसान plain text आउटपुट करता है
  • जिन AI और bots को Anubis निशाना बनाता है, वे Proof-of-Work सपोर्ट एक बार जोड़ने के बाद इसे आसानी से बायपास कर सकते हैं
    • Scraper challenge हल करने के बाद मिले cookies को cache और reuse करके लागत को कई requests में amortize करते हैं
    • दूसरी ओर, इंसानों को हर विज़िट पर spinner का इंतज़ार करना पड़ता है, battery खर्च होती है, और वे इस लागत को दूसरे उपयोगकर्ताओं के साथ साझा नहीं कर सकते
    • जितना डिवाइस लो-एंड होगा और खासकर smartphone होगा, बोझ उतना बढ़ेगा; और JavaScript का उपयोग न करने वाले w3m·lynx·screen readers·RSS readers एक्सेस ही नहीं कर सकते
  • AI को रोकने की कोशिश करने वाला यह तंत्र AI के लिए तो आसानी से बायपास हो जाता है, जबकि इंसानों और खुले web पर लगातार लागत डालने वाला प्रतिगामी बोझ बनकर काम करता है

Proof-of-Work से बनने वाली समय और ऊर्जा लागत

  • Difficulty d उस संख्या को दर्शाती है जितने leading zero hex characters hash में होने चाहिए, और प्रति समाधान अपेक्षित काम W = 16^d hashes होता है
    • सामान्य डिफॉल्ट difficulty 4 में 65,536 hashes की जरूरत होती है
      • लगभग 50 MH/s वाली native Go implementation: लगभग 1.3ms
      • लगभग 0.5 MH/s वाला browser JavaScript: लगभग 130ms
      • page load, worker execution और reload सहित महसूस होने वाला समय: लगभग 1~5 सेकंड
    • Difficulty 5 में 1,048,576 hashes की जरूरत होती है
      • native Go implementation: लगभग 20ms
      • browser JavaScript: लगभग 2 सेकंड
      • महसूस होने वाला समय: लगभग 5~15 सेकंड
  • मान लें कि दुनिया भर में प्रतिदिन Anubis challenges हल करने की संख्या C है, प्रति प्रयास महसूस होने वाला समय t = 2 सेकंड है, और screen व CPU सहित device energy E = 20J है
    • सालाना मानव समय C × t × 365 / 3.15×10⁷ से निकाला जाता है
    • सालाना ऊर्जा C × E × 365 / 3.6×10⁶kWh से निकाली जाती है
  • इन मान्यताओं के आधार पर सालाना लागत इस प्रकार है
    • रोज़ 10 लाख बार: लगभग 23 मानव-वर्ष, लगभग 2MWh
    • रोज़ 1,000man बार: लगभग 230 मानव-वर्ष, लगभग 20MWh
    • रोज़ 10 करोड़ बार: लगभग 2,300 मानव-वर्ष, लगभग 200MWh
  • सभी संख्याएँ मोटे अनुमान हैं, और bot farms तथा AI tools इससे कई orders of magnitude अधिक ऊर्जा इस्तेमाल करते हैं, इसलिए यह गणना पर्यावरणीय तर्क देने के लिए नहीं है
  • Robots के लिए समय कोई बाधा नहीं है, लेकिन इंसानी समय सीमित है; इसलिए उपयोगकर्ता AI युग से पहले न मौजूद रही website access देरी पर सामूहिक रूप से काफी समय खर्च करने लगते हैं

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय

  • इस बात से सहमत होना मुश्किल है कि Anubis जिन लोगों को निशाना बनाता है, वे इसे आसानी से निष्क्रिय कर देते हैं। Anubis का मुख्य लक्ष्य LLM एजेंट या vibe coding से बने प्रोग्राम नहीं, बल्कि LLM कंपनियों द्वारा इस्तेमाल किए जाने वाले बेतरतीब web scrapers को रोकना है
    बचने के तरीके हैं और एजेंट या LLM का इस्तेमाल भी किया जा सकता है, लेकिन अधिकतर scrapers सरल होते हैं और उनके ऑपरेटर Anubis लगाने वाली कुछ साइटों को bypass करने की जहमत नहीं उठाते। मकसद bypass की लागत को थोड़ा बढ़ाकर डेटा इकट्ठा करना लायक न रहने देना है

    • Anubis उन स्थितियों को रोकने में अच्छा काम करेगा जहाँ residential proxies इस्तेमाल करने वाले scrapers सर्वर को ठप कर देते हैं। अलग-अलग एजेंट के requests किसी यूज़र के खुद साइट देखने से बहुत अलग नहीं होते
      हालांकि इस मकसद के लिए Anubis ज़रूरत से ज़्यादा engineered है। एक बार बटन दबवाकर access cookie जारी करने से भी वही सुरक्षा मिल सकती है, और Apache में इसे लागू करके देखा तो जटिल proof-of-work के बिना भी यह काफी अच्छी तरह काम करता है
    • निशाना LLM कंपनियों के scrapers से ज़्यादा कुल मिलाकर घटिया और दुरुपयोग करने वाले web scrapers हैं। बस अनुमान है कि उनमें से कुछ LLM कंपनियाँ चलाती हैं
    • वेबसाइटों पर बढ़ा हुआ traffic OpenAI, Anthropic, Meta जैसी जगहों से नहीं बल्कि दूसरे पक्षों से आ रहा है, इसलिए यह अस्पष्ट है कि LLM कंपनी की परिभाषा क्या है
      मेरे data mining काम में भी इस्तेमाल होने वाले modern scraping tools लगभग सभी बाधाओं को पार करने जितने अच्छे हैं, और Anubis को भी आसानी से bypass किया जा सकता है
    • मैं निजी साइटों और software पर RAG access भी रोकना चाहता था, इसलिए basic user agent blocking लगाई। ChatGPT से सीधे साइट access करने को कहकर टेस्ट किया तो यह अच्छी तरह blocked हुआ
      बहुत खास configurations निकल सकती हैं, लेकिन लक्ष्य किसी malicious adversary को नहीं बल्कि आलसी पक्ष को रोकना है
    • Anubis मुख्य रूप से उन शुरुआती स्तर के Python requests scrapers को रोकता है जो खुद को Chrome बताने की कमजोर कोशिश करते हैं; बाकी blocking effect लगभग bonus है

  • Anubis bots को filter नहीं करता, बल्कि client के request rate को limit करता है

  • Anubis AI agents की access रोकने से ज़्यादा denial-of-service attack से बचाव का साधन है, और व्यवहार में AI agents की पहचान करके उन्हें block करना भी मुश्किल है
    लेकिन यह मेरे जैसे users को भी block कर देता है, जो mobile device पर किसी अनजान site पर जाते समय JavaScript बंद रखते हैं

  • वास्तविक संचालन के नतीजे देखें तो लेख के निष्कर्ष से सहमत होना मुश्किल है। मैंने अपने homelab की website को fly.io public proxy और Tailscale forwarding से serve किया था, लेकिन Facebook समेत scrapers की वजह से हर महीने करीब 20 डॉलर bandwidth charge लग रहा था
    proxy पर Anubis लगाने के बाद मैं free tier में लौट आया। अगर ज़रूरत पड़े तो कोई bypass कर सके, इससे फर्क नहीं पड़ता; robots.txt को ignore करने वाले कुछ malicious actors के बड़े पैमाने के collection traffic को अधिकतर block कर देना ही काफी है

  • Smart TV जैसे low-end devices के botnet का इस्तेमाल करने वाले scraping operations के लिए Anubis का proof-of-work सचमुच एक बाधा बन सकता है। https://lobste.rs/s/kpaxih/update_on_scraper_situation में भी इस मुद्दे पर थोड़ा लिखा है

    • अगर मैं गलत नहीं समझ रहा, तो Smart TV सिर्फ proxy के रूप में इस्तेमाल होते हैं, वे proof-of-work खुद perform नहीं करते

  • Anubis में सबसे परेशान करने वाली बात open web से उसका टकराव है। मेरी website मुख्यतः RSS feed के जरिए पढ़ी जाती है; RSS को Anubis से protect करें तो feed काम नहीं करती, और protect न करें तो पूरा content machine-readable रूप में scrapers के सामने खुला रहता है
    ऐसे proof-of-work barriers उस open web या IndieWeb से मूल रूप से मेल नहीं खाते जिसकी हम उम्मीद करते थे

    • पिछले 1 साल से मैं ऐसे असंभव compromises के बीच फँसा हूँ, और मुझे भी कोई अच्छा जवाब नहीं मिला

  • दूसरों द्वारा किए गए choices का सम्मान न करने का रवैया साफ दिखता है

  • सबसे अप्रिय बात यह है कि यह CFAA जैसे कानूनों का साफ उल्लंघन लगता है, फिर भी दूसरे आपराधिक DDoS services की तरह identity छिपाई जाती है
    जिस कंपनी का पूरा business model दूसरों का काम चुराने और open source code को launder करने पर निर्भर हो, उससे कानून मानने की उम्मीद करना ही हास्यास्पद है

  • Anubis आम तौर पर Dillo को block नहीं करता, लेकिन site settings के आधार पर block भी हो सकता है, और यह JavaScript नहीं है तो अस्तित्व का अधिकार भी नहीं जैसी सोच को बढ़ावा देता है, जो बेहद परेशान करने वाला है: https://paste.rs/jNgwd.png
    मैं सोच रहा हूँ कि residential proxies में शामिल सभी IPs की list जुटाकर maintain की जा सकती है या नहीं और उन्हें कुछ समय के लिए block किया जा सकता है या नहीं; ipset शायद इस scale को संभाल सके। logs देखें तो bots CSS या images जैसे दूसरे resources नहीं load करते, लेकिन Dillo repository के हर commit की हर file पर iterate करते हैं, इसलिए उनकी पहचान करना अपेक्षाकृत आसान है
    हर site पर प्रति IP सिर्फ एक request दिखे तो भी संभव है कि वही IP कई sites fetch कर रहा हो, इसलिए कई बार report किए गए IPs को block किया जा सकता है। केवल connection काटने के बजाय किसी अलग port पर explanation page पर redirect करना चाहिए, जिसमें block का कारण और समाधान बताया जाए
    इससे browser extensions या phone apps में reverse proxy backdoor लगाने का incentive भी घटेगा, क्योंकि users सचमुच block होना शुरू हो जाएँगे
    IP reputation system पर निर्भर होना अफसोसजनक है, लेकिन कोई और प्रभावी उपाय ज्यादा दिखता नहीं। कमजोर devices के botnet command-and-control server हट जाने के बाद भी वे अगले attacker के हाथ फिर से लगकर नए botnet में शामिल हो सकते हैं

  • लेख में कहा गया है, “बेशक मैं यह काम LLM की मदद से कर रहा हूँ,” तो फिर यह जानना चाहूँगा कि vibe coding tag क्यों नहीं लगा

    • जिस तरह लेखक compiler या editor इस्तेमाल करने पर वह tag नहीं लगाता, उसी तरह इस लेख का विषय vibe coding नहीं है। vibecoding tag pushcx ने हटा दिया था
    • पोस्ट करते समय लेख में साफ लिखा था कि blocking bypass करने वाली कोई चीज़ vibe-code की गई थी, इसलिए मैंने वह tag लगाया था। इससे कम AI coding का ज़िक्र करने वाली posts पर भी tag लग जाता है, इसलिए इसका हटना हैरान करने वाला था, लेकिन अब लगता है कि इस tag को लागू करने के standards पूरी तरह असंगत हैं