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

 (xeiaso.net)
3 पॉइंट द्वारा GN⁺ 2025-04-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Anubis को UNESCO के policytoolbox.iiep.unesco.org पर deploy किया गया है, जिससे यह बड़े संगठनों द्वारा इस्तेमाल किए जाने वाले bot-response tool के एक उदाहरण के रूप में और अधिक ध्यान आकर्षित कर रहा है
  • unesco.org के UNESCO का आधिकारिक domain होने की पुष्टि के बाद, this deployment को United Nations से संबंधित संगठन में वास्तविक उपयोग के उदाहरण के रूप में स्वीकार किया जा रहा है
  • Linux Kernel Mailing List archives, FreeBSD SVN, SourceHut, FFmpeg, Wine, GNOME GitLab जैसे पहले से ज्ञात deployments के साथ इसका उपयोग-क्षेत्र बढ़ता जा रहा है
  • ऐसे संगठनों द्वारा Anubis को अपनाया जाना यह दिखाता है कि इंटरनेट पर bot traffic की समस्या अनुमान से कहीं अधिक गंभीर हो सकती है
  • Anubis और उसके आसपास के stack पर अधिक समय की ज़रूरत है, और पर्याप्त sponsorship मिले तो full-time development और hiring तक संभव हो सकती है

UNESCO deployment की पुष्टि

  • Anubis को United Nations के अधीन UNESCO के policytoolbox.iiep.unesco.org पर deploy किया गया है
  • unesco.org Wikipedia पर United Nations Educational, Scientific and Cultural Organization के आधिकारिक domain के रूप में दर्ज है
  • UNESCO system administrator टीम से संपर्क करके यह सत्यापित करने की कोशिश की जा रही है कि installation के दौरान कोई समस्या हुई थी या नहीं, और installation process को और आसान बनाना लक्ष्य है

ज्ञात deployment उदाहरण और आगे का काम

  • पुष्टि किए गए बड़े deployments में निम्न शामिल हैं
    • Linux Kernel Mailing List archives
    • FreeBSD का SVN, और जल्द ही git
    • SourceHut
    • FFmpeg
    • Wine
    • UNESCO
    • The Science Olympiad Student Center
    • Enlightenment desktop environment
    • GNOME का GitLab
  • यदि इस स्तर के संगठन Anubis का उपयोग कर रहे हैं, तो bot traffic की समस्या पहले के अनुमान से काफी अधिक गंभीर स्तर की हो सकती है
  • जैसे YouTube एक समय मानव traffic की तुलना में bot traffic अधिक हो जाने वाली स्थिति, यानी “the inversion”, के करीब पहुँच गया था, वैसे ही यह सवाल बाकी है कि इंटरनेट भर में ऐसा रुझान कितना व्यापक हो चुका है
  • Anubis और उससे जुड़े stack पर गंभीरता से समय लगाना होगा, और पर्याप्त sponsorship मिलने पर इस पर full-time काम करना और hiring करना भी संभव होगा
  • यदि Anubis मददगार है, तो Patreon पर support देने का अनुरोध है

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

1 टिप्पणियां

 
GN⁺ 2025-04-14
Hacker News टिप्पणियां

  • संबंधित पोस्ट: Anubis: AI क्रॉलर को रोकने के लिए proof-of-work प्रॉक्सी (100 points, 23 days ago, 58 comments) https://news.ycombinator.com/item?id=43427679

  • यह मज़ेदार है कि Xe ने ऐसी चीज़ को, जो पहले लगभग मज़ाक/फालतू पोस्ट जैसी थी, सच में उपयोगी product बना दिया। हमेशा कहते रहे हैं कि timing ही सब कुछ है
    यह थोड़ा हैरान करता है कि इतने सारे sites इसे चाहते हैं या इसकी जरूरत है। कुछ Git servers पर धीमे Git pages की समस्या समझ आती है, जहां बहुत गहराई होती है, cache नहीं होता, और वे धीमी disk से serve किए जाते हैं
    UNESCO थोड़ा अप्रत्याशित था। वह sub-site हजारों documents के साथ काफी बड़ा है, लेकिन static content है, इसलिए उसे serve करना आसान होना चाहिए। देखकर पता चला कि वह Apache पर ढीले-ढाले तरीके से deployed WordPress था, और न cache था, न content compression, न HTTP/2·HTTP/3
    इसे बहुत छोटी machine पर भी बेहद सस्ते में serve करने लायक ठीक करना संभवतः आसान है, लेकिन जाहिर है expertise चाहिए, और expertise अब भी सस्ती नहीं है
    LLM से पूछ सकते हैं, लेकिन जब आपको यह भी पता न हो कि क्या पूछना है, तो वह अभी ज्यादा मददगार नहीं होता। अगर आपको यह तक न पता हो कि site शुरू से ही धीमी है, तो पूछेंगे क्यों। बस यह सुनकर कि traffic से दब रही है, शायद आप furry defender ढूंढने लगेंगे

    • “expertise चाहिए और expertise अब भी सस्ती नहीं है” सही है, लेकिन साथ ही मुझे लगता है कि Anubis configure करना जानने वाले लोग WordPress admin experience रखने वालों से कहीं कम होंगे, इसलिए यह अब भी हैरान करता है
      मेरा मतलब यह नहीं कि यह मुश्किल है, बल्कि यह कि इसके अस्तित्व के बारे में जानने वाले ही कम हैं
      अंदाजा लगाऊं तो WordPress को न छूने की वजह technical समस्या नहीं, बल्कि शायद किसी fragile instance को छूना न चाहना, या संगठन में permissions की समस्या, या admin ने पहले से मान लिया कि WP ठीक से configured है
    • मेरी जिस site पर मैं इसे लगाना चाहता हूं, उसमें बहुत सारे posts हैं, और tag-based faceted search की वजह से संभावित combinations और pages की संख्या practically अनंत हो जाती है
      इसे cache करने का कोई तरीका नहीं है, और bots robots file भी नहीं मानते, इसलिए वे URL लगातार request करते रहते हैं और posts को अलग-अलग numbers और combinations में बार-बार fetch करते हैं। सच में सिरदर्द है
    • AI scrapers की implementation सिर्फ खराब ही नहीं होती, वे जानबूझकर cache invalidation भी करते हैं
      अब तक जो solutions देखे हैं वे Cloudflare, login requirement, Anubis, या फिर हास्यास्पद scale की infrastructure ही थे
      एक site ने कहा कि उसके traffic का 60% bots से आता है, और छोटी sites में शायद यह अनुपात और भी ज्यादा होगा
    • proof-of-work आधारित bot/scraping/DDoS defence 10 साल पहले भी मौजूद था, समझ नहीं आता कि अब जाकर क्यों फैल रहा है
      मुझे ऐसे projects भी याद हैं जो proof-of-work को useful computation बनाने की कोशिश कर रहे थे

  • अगर आप उलझन में हैं कि यह क्या है, तो यह AI scraping को रोकने के लिए है
    “Anubis proof-of-work challenges का इस्तेमाल करता है ताकि यह सुनिश्चित हो सके कि client modern browser चला रहा है और SHA-256 checksum calculate कर सकता है”
    https://anubis.techaro.lol/docs/design/how-anubis-works
    काफी शानदार है, और मेरे एक-दो projects में भी मदद कर सकता है

    • कई सालों से सोच रहा था कि web इंसानों के लिए है या machines के लिए। content serve करने में bots को खास तौर पर block करने की कोई अच्छी वजह तुरंत याद नहीं आती
      content post करने देना या actions execute करवाना जाहिर है कई situations में problem हो सकता है
      लेकिन simple content serving में आम तौर पर human या bot होना filtering या blocking का criteria नहीं होता। अगर कोई specific client system का abuse नहीं कर रहा, तो फर्क क्यों पड़ना चाहिए कि वह इंसान है या नहीं

  • “यह time को भी input के रूप में इस्तेमाल करता है। क्योंकि linear timeline की प्रकृति के कारण server और requester दोनों जानते हैं कि time क्या है”
    docs में मौजूद मजेदार line है

    • ओह, मैं भूल गया था कि मैंने इसे छोड़ रखा है। मजेदार है। इसे ऐसे ही रखने का इरादा है
    • दुर्भाग्य से context से अलग करने पर यह बात गलत है। Anubis time को nearest week तक round करता है, और अगर उसके adjacent week भी valid हों तो शायद काफी है
      कई वजहों से clock synchronization mismatch आम है। users के bottom 10% से date-level accuracy भी expect नहीं कर सकते, और bottom 25% तक में 5 मिनट का अंतर हो सकता है

  • Anubis check खत्म होने तक दिखने वाली intermediate page images वाकई cute हैं। Xe blog की illustrations और characters मुझे हमेशा सुंदर लगे हैं
    एक side note के तौर पर, मैं यह भी सोच रहा था कि इसका general search engines पर क्या असर होगा, और यह AI crawlers को रोकने वाले Cloudflare के solution से कैसे अलग है; GitHub page पर इसकी explanation है [1]
    “अगर आप इसे install और use करते हैं, तो संभव है कि कुछ search engines आपकी website को index न करें। इसे Anubis का bug नहीं, बल्कि feature माना जाता है”
    “यह कुछ हद तक nuclear strike जैसा response है, लेकिन AI scraper bots इतने aggressively scrape कर रहे थे कि कोई और रास्ता नहीं था”
    “ज्यादातर मामलों में आपको इसे use करने की जरूरत नहीं है, और किसी specific origin server को Cloudflare से protect करना शायद काफी होगा। लेकिन जिन situations में आप Cloudflare use नहीं कर सकते या नहीं करना चाहते, वहां Anubis है”
    [1]: https://github.com/TecharoHQ/anubis/

    • सही है। फिलहाल दुर्भाग्य से यह search indexing रोक देता है। आगे चलकर search engine IPs को allowlist में डालना संभव हो सकता है
      हालांकि Google जैसी जगहें AI और search indexing के लिए वही IPs भी use करती हैं
      फिर भी Open Graph tags को pass-through करने जैसी improvements चल रही हैं, ताकि कम से कम rich previews काम करें
    • मैं मानता हूं कि intermediate page images cute हैं। लेकिन यह सोचकर बुरा लगता है कि किसी दिन कोई न कोई उन्हें किसी न किसी तरह “problematic” मान लेगा और आखिरकार हटवा देगा

  • मैंने Anubis के बारे में पढ़ा है और यह शानदार प्रोजेक्ट है। अफसोस, जैसा कि comments में कहा गया है, साइट visitors को JavaScript™ सक्षम करना पड़ता है
    अगर किसी साइट को वैसे भी user experience बेहतर करने के लिए JavaScript™ चाहिए, तो यह पूरी तरह ठीक है, लेकिन ऐसी static sites के लिए यह खास नहीं है जिन्हें JS की बिल्कुल जरूरत नहीं होती
    मैंने इन “खराब bots” को network level पर प्रभावी ढंग से block करने के लिए अपना समाधान बनाया है। MaxMind database और अपने बनाए WAF·reverse proxy का इस्तेमाल करके कई बड़े “Big Tech / Big LLM” networks को ASN(BGP) unit पर पूरी तरह block कर रहा हूं

    • इस लेख में जिस bot traffic की बात है, उसका बड़ा हिस्सा सामान्य residential IP ranges से आता है
      बेशक ASN की चालबाजियां और reputation fraud भी साथ-साथ होते हैं, लेकिन उनसे निपटना बहुत मुश्किल है। Logs की मोटी जांच करने पर लगा कि ये bots किसी खास residential IP से लगभग एक बार request करते हैं, और यह range शायद असली human users द्वारा इस्तेमाल की जाने वाली range भी हो सकती है
      सीधे शब्दों में, legitimate traffic block होने का risk है। इस समाधान में भी risk है, लेकिन ज्यादातर humans के लिए actual risk काफी कम है
      अच्छा होता अगर JavaScript की जरूरत न होती और उसे disabled रखने वाले users को भी support किया जा सकता, लेकिन customers या end users ने JavaScript enable करने की जरूरत पर कभी शिकायत नहीं की
      JavaScript requirement का विरोध करने वाले लोग एक आवाजदार minority हैं, और उनमें से ज्यादातर JavaScript की जरूरत वाली site मिलने पर बस उसे on कर देते हैं। मुझे लगता है तब भी हार मानने जैसी आह भरने वाले बहुत ही कम होंगे
    • जिन लोगों को जिज्ञासा हो, “JavaScript” trademark Oracle के पास है: https://javascript.tm/
    • आपको कैसे पता कि वह LLM है या VPN? MaxMind database से LLM traffic को कैसे अलग करते हैं?
    • क्या आपके बनाए समाधान का link है?

  • idea अच्छा है, लेकिन challenge की प्रकृति साफ होने के बाद शायद इसे protocol level तक नीचे ले जाना पड़ेगा
    proof-of-work challenge को हर website में JavaScript से अलग-अलग implement करने के बजाय TCP के करीब किसी हिस्से का बनना accessibility के लिहाज से आखिरकार बेहतर होगा

    • IETF standard बना Cloudflare PrivacyPass तो है [0], लेकिन वह काफी अजीब है और reference implementation bugs का ढेर है
      [0] https://datatracker.ietf.org/wg/privacypass/about/
    • arbitrary challenge को SPIR-V या MLIR black box में भेज देना चाहिए। challenge-response exchange को HTTP के साथ integrate करने पर व्यापक support और flexible hardware acceleration संभव होगा
      “काफी अच्छा” समाधान पहले से widely used SHA(seed, nonce) है। अगर बड़ी tech companies चाहतीं, तो इसे stack की और निचली layer में आसानी से integrate किया जा सकता था

  • मेरे phone पर bot detection solve करने में पूरे 5 सेकंड लगते हैं

    • मैं F-Droid का Firefox fork Fennec और Pixel 9 Pro XL इस्तेमाल करता हूं, difficulty 4 पर लगभग 8 सेकंड लगते हैं
      निजी तौर पर, मुझे कुछ करना नहीं पड़ता इसलिए user experience इतना खराब नहीं लगता। CAPTCHA से तो निश्चित रूप से बेहतर पसंद है
    • infinite Cloudflare CAPTCHA loop से बहुत बेहतर है
    • किस्मत अच्छी है। मुझे 30 सेकंड लगे
    • मेरे case में करीब 0.5 सेकंड है, इसलिए दिलचस्प है

  • अभी “Enigma webfont” नाम का prototype बना रहा हूं। serve और cache किए जाने वाले webfont पर per-user session custom seed और rotation values लागू करना चाहता हूं
    लक्ष्य OCR compute cost की वजह से web scraping को अव्यावहारिक बनाना है। अभी यह cat-and-mouse game है, इसलिए खेल का पलड़ा थोड़ा बदलना चाहता हूं
    user session न हो तो HTML source लगभग बेकार हो जाएगा, और OTP जैसी behavior से asset cache खत्म हो जाए तो webpage भी पढ़ा नहीं जा सकेगा
    इससे ऐसा CAPTCHA प्रभावी तौर पर बनाया जा सकता है जिसमें user local seed window को तब तक adjust करे जब तक वह कोई खास word पढ़ न सके। जैसे “Foxtrott शब्द पढ़ाई देने तक slider को move करें”
    Xe की राय जरूर सुनना चाहूंगा। क्या हम मिलकर काम कर सकते हैं?
    tech stack Go है, क्योंकि webfont file को बिना समस्या सीधे बदलना आसान लगा, ऐसी यह इकलौती language थी

    • साफ accessibility समस्या को छोड़ भी दें, तो वह ज्यादा से ज्यादा substitution cipher ही नहीं है? corpus पर्याप्त हो तो decryption बहुत आसान हो जाएगा लगता है
    • समस्या यह नहीं है कि website scrape हो रही है, बल्कि requests की मात्रा है जो infrastructure को down करती है या cost बढ़ाती है। search engines 30 साल से ज्यादा समय से यह काम करते आए हैं
      text को बिगाड़ने से मदद नहीं मिलेगी। वे वैसे भी लगातार hit करते रहेंगे। traffic pattern देखें तो इन bots को बनाने वाला बस... <https://www.youtube.com/watch?v=ulIOrQasR18>
      “Xe की राय सुनना चाहूंगा। क्या हम मिलकर काम कर सकते हैं?” के बारे में, मेरी समझ से features और जोड़ने के बजाय इस project को निकट और दूर भविष्य में अधिक sustainable बनाने में मदद चाहिए। Anubis पहले से ही बेहतरीन तरीके से काम करता दिखता है

  • JavaScript disabled रखने वाले users को block करने में यह वाकई अच्छी तरह काम करता है

    • सही। ज्यादा लोगों को आकर्षक लगने की कोशिश के तौर पर यह सचमुच कमजोर है। जब तक nojs version नहीं लाते, web को खराब करने के मामले में यह “AI” scrapers से अलग नहीं है