वेब को gatekeeper की ज़रूरत नहीं: Cloudflare के नए "Signed Agents" प्रस्ताव पर सवाल

 (positiveblue.substack.com)
1 पॉइंट द्वारा GN⁺ 2025-08-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare की Signed Agents नीति सुरक्षा के नाम पर पेश की गई है, लेकिन असल में यह वेब एक्सेस को अनुमति-आधारित बनाने की एक बंद प्रकृति वाली कोशिश है
  • वेब ऐतिहासिक रूप से खुलेपन और standards की वजह से बढ़ा है, और Flash·Silverlight जैसी बंद तकनीकें आखिरकार HTML5 जैसे open standards के सामने पीछे हट गईं
  • आगे चलकर वेब के मुख्य उपयोगकर्ता AI agents होंगे, और इसके लिए distributed और verifiable authentication system के साथ task-level authorization की आवश्यकता होगी
  • सही मॉडल chain-based delegation + request-level proof को जोड़कर भरोसेमंद authentication और granular permission control लागू करता है
  • किसी एक कंपनी के हाथ में चाबी देने के बजाय, open protocols और standards के जरिए ऐसा वेब बचाना चाहिए जिसमें हर कोई भाग ले सके और innovation कर सके

Cloudflare के Signed Agents की आलोचना

  • Cloudflare ने नया Signed Agents system प्रस्तावित किया है, लेकिन यह व्यवहार में allowlist-आधारित access control है
  • किसी खास कंपनी द्वारा यह तय करना कि कौन-सा agent register हो सकता है, internet protocol नहीं बल्कि vendor approval system भर है
  • यह इंटरनेट की खुली प्रकृति से टकराता है, और “form भरकर अनुमति लेना” कोई standard नहीं बन सकता

वेब खुला रहना चाहिए

  • 90 के दशक में Microsoft की “embrace and extend” strategy असफल हुई थी, और यह इसलिए संभव हुआ क्योंकि वेब ने अपना खुलापन बनाए रखा
  • Flash और Silverlight जैसे closed runtimes अंततः HTML5 नामक खुले standard द्वारा प्रतिस्थापित कर दिए गए
  • इतिहास बार-बार साबित करता है कि open standards innovation को बढ़ावा देते हैं

agents के युग का आगमन

  • AI agents आगे वेब के प्रमुख उपयोगकर्ता होंगे और जानकारी खोजना, automation, payment, contract negotiation जैसे काम करेंगे
  • इंसानों और agents की गतिविधियों के बीच की सीमा धुंधली होगी, और इससे delegation-based authentication system अनिवार्य हो जाएगा

Authentication और Authorization

  • Authentication: कौन कार्रवाई कर रहा है?
  • Authorization: वह क्या कर सकता है?
  • Cloudflare इन दोनों अवधारणाओं को मिलाकर “passport” से हर समस्या हल करना चाहता है, लेकिन यह मूल रूप से संभव नहीं है
  • सही authentication को delegation chain और request-level signatures के जरिए लागू किया जाना चाहिए, और DNS-आधारित public key issuance जैसे distributed verification mechanisms का उपयोग करना चाहिए

Permission management

  • मौजूदा software में limited scope होने की वजह से OAuth scope model अच्छी तरह काम करता रहा है
  • लेकिन agents सामान्य-उद्देश्य वाले होते हैं, इसलिए task-scoped authorization की जरूरत है
  • उदाहरण: “डिनर payment” की permission और “3 महीने के खर्च का इतिहास देखना” की permission, एक ही agent के लिए भी अलग tokens से नियंत्रित होनी चाहिए
  • इसके लिए Macaroons, Biscuits जैसे constraint-based tokens और OPA/AWS Cedar जैसे policy engines का उपयोग किया जा सकता है

Protocol पहले, gatekeeper बाहर

  • Authentication, authorization और monetization किसी एक कंपनी के बजाय खुले और interoperable standards पर आधारित होने चाहिए
  • अगर कुछ गिनी-चुनी कंपनियां agents की वैधता तय करेंगी, तो वेब जल्दी ही closed garden (Walled Garden) में बदल जाएगा
  • इसलिए chain-based delegation, request-level proof और task-scoped authorization को open source प्रस्ताव के रूप में साझा किया गया है ताकि कोई भी इन्हें implement कर सके

निष्कर्ष

  • वेब का भविष्य इस बात पर निर्भर नहीं करता कि “gate किसके नियंत्रण में है”, बल्कि इस पर कि ऐसे protocols हों जिन्हें सब मिलकर बना सकें और जिन पर innovation कर सकें

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

1 टिप्पणियां

 
GN⁺ 2025-08-30
Hacker News राय

  • सब लोग पूरी तरह आज़ाद और open web का सपना देखते हैं, लेकिन हकीकत में छोटे ब्लॉग या कंटेंट रखने वाले लोगों के पास AI training bots से खुद को बचाने का लगभग कोई तरीका नहीं है—यह बात निराशाजनक लगती है। Agent और training bots में फर्क करके वे सच में robots.txt का सम्मान करेंगे, इस पर भरोसा करना यथार्थवादी नहीं लगता। और अगर वे robots.txt मान भी लें, तब भी licensed data के नाम पर डेटा को परोक्ष रूप से खरीदने का कॉन्सेप्ट चलता रहेगा। Reddit, X, Google, Meta जैसी लगभग असीम कानूनी संसाधनों वाली कंपनियों के अलावा व्यक्तियों के पास कोई ताकत नहीं है। इस विषय पर एक दिलचस्प वीडियो भी सुझाया गया है.

    • सबके मन का मुक्त और खुला web, और AI training bots को ब्लॉक करने की इच्छा—ये दोनों एक-दूसरे के विरोधाभासी लगते हैं। अगर web सबके लिए खुला है, तो AI training bots को भी बिना किसी अपवाद के पहुँच मिलनी चाहिए.

    • (open web के सपने पर) इंटरनेट पर open content का सपना वास्तविक है। मेरा ब्लॉग किसी के लिए भी—चाहे इंसान हो या मशीन—मुक्त रूप से उपलब्ध है। मेरा server भी मैं घर से self-host करता हूँ, इसलिए मुझे इंसान और AI में फर्क करने की खास जरूरत महसूस नहीं होती। अगर चिंता यह है कि वेबसाइट पर बहुत ज्यादा विज़िटर आ जाएँगे, तो असल समस्या इंसान हों या AI, अत्यधिक traffic ही है। robots.txt में सिर्फ इतनी न्यूनतम गाइडलाइन रखी है कि bots loop में न फँसें, बाकी crawling के लिए खुला छोड़ा है। Amazonbot भी मेरी साइट पर अक्सर आता है, और वह भी हमेशा स्वागतयोग्य है.

    • मेरा मानना है कि हमें hostile software के खिलाफ लड़ने वाला free software बनाना चाहिए। बड़ी कंपनियाँ hostile AI agents बना रही हैं, तो उनके मुकाबले सक्षम hackers को anti-AI-agent बनाने चाहिए। “हमारे पास कोई ताकत नहीं है” जैसी पराजयवादी सोच से मैं सहमत नहीं हूँ.

    • यहाँ Hacker News पर बड़ी IT कंपनियों के अनगिनत engineers मौजूद हैं, फिर भी वे अपने काम में privacy और data governance को लेकर आत्मचिंतन नहीं करते और हमेशा सिर्फ दूसरे मुद्दों पर शोर मचाते हैं—इस वास्तविकता की ओर इशारा किया गया। अगर आत्ममंथन के लिए किसी आईने की ज़रूरत है, तो मैं उसे खरीदने को तैयार हूँ.

    • मुझे समझ नहीं आता कि छोटे ब्लॉग या कंटेंट को AI training bots से बचाने का सवाल उठ ही क्यों रहा है। अगर बुनियादी HTML बनाना भी मुश्किल है, इसलिए भारी और जटिल frameworks इस्तेमाल करने पड़ते हैं और नतीजतन CPU resources बहुत खर्च होते हैं, तो असली समस्या वही है। या फिर अगर कोई अपनी ऑनलाइन लिखाई को content creator वाली दौलत और शोहरत की राह मानता है, तो चिंता समझ में आती है। वरना मुझे लगता है कि यहाँ कोई समस्या है ही नहीं.

  • व्यवहारिक रूप से “web” बहुत पहले से खुला नहीं रहा है। अधिकांश interaction, posting और information flow authentication (login) के पीछे होते हैं। बड़े social networks, newspaper sites आदि ज्यादातर unauthenticated access को सीमित या ब्लॉक करते हैं। ब्लॉग, आम लोगों द्वारा उपभोग की जाने वाली कुल जानकारी का बहुत छोटा हिस्सा भर हैं.

    • “web अब open नहीं रहा” इस दावे से मैं सहमत नहीं हूँ। web को और gatekeepers की जरूरत नहीं है, और अगर पहले से बहुत हैं, तो उन्हें कम किया जाना चाहिए.

  • मुझे AI Agent खुद से दिक्कत नहीं है। अगर उसके पीछे कोई वास्तविक user है, तो ठीक है। लेकिन Meta, Perplexity, OpenAI आदि का मेरी साइट को आक्रामक तरीके से crawl करना बहुत खटकता है। असली users या Google search से भी ज्यादा resources AI crawling खा जाती है। CPU cores का AI crawling में फँस जाना सचमुच झुंझलाने वाला है.

    • मेरे भी कई personal apps online हैं, और पिछले महीने एक AI bot ने 1.6TB डेटा scrape कर लिया, जिसके बाद मुझे Cloudflare का AI bot protection फीचर चालू करना पड़ा। दिन में 13 लाख से ज्यादा लगातार requests आ रही थीं, जिन्हें संभालना संभव नहीं था.

    • मेरी कुछ marketing sites पर 200–300 requests प्रति सेकंड तक आने लगती हैं। यहाँ तक कि अस्तित्वहीन URLs को भी random बनाकर hit किया जाता है, यानी हालात नियंत्रण से बाहर हो जाते हैं.

    • यह जानने की जिज्ञासा होती है कि web crawling की वजह से AI कंपनियाँ कितने CPU cycles (computing resources) खर्च करवाती हैं। आमतौर पर AI के environmental impact की बात करते समय training या serving inference ही गिने जाते हैं, लेकिन web crawling से पड़ने वाला अतिरिक्त load भी ध्यान में रखा जाना चाहिए। सटीक तुलना के लिए यह देखना अर्थपूर्ण होगा कि अगर वही काम इंसानी users खुद करें तो उससे तुलना में क्या bots को अधिक कुशल traffic generation के लिए design किया जा सकता है। यानी अगर tracker, images जैसी अतिरिक्त चीज़ें न्यूनतम रखी जाएँ और सिर्फ target query के लिए जरूरी चीज़ें scrape की जाएँ, तो संभव है कि पूरी मानवता के browser से सीधा visit करने की तुलना में CPU load कम हो.

    • मैं भी यही सोचता हूँ। AI agent का उपयोग हो रहा है, उसके पीछे वास्तविक user है, और वह असामान्य रूप से अत्यधिक access नहीं कर रहा, तो मुझे खास फर्क नहीं पड़ता। (मैंने खुद AI agent के उपयोग का इरादा नहीं किया था, लेकिन कोई कैसे इस्तेमाल करता है, इससे मुझे आपत्ति नहीं है।) लेकिन अत्यधिक crawling पसंद नहीं है। और इससे भी महत्वपूर्ण बात यह है कि कोई व्यक्ति सिर्फ curl से एक file download कर सकता है या Lynx जैसे text-based browser का उपयोग कर सकता है। ऐसे scenarios को भी समर्थन मिलता रहना चाहिए.

    • Cloudflare “user-tried agent” जैसे किसी प्रकार को अनुमति देकर और बाकी agents को रोककर, वास्तविक user की ओर से आने वाले requests और training data जमा करने वाली अंधाधुंध crawling में फर्क करता है। Meta, Perplexity, OpenAI से आने वाली अधिकांश requests वास्तव में user prompts के आधार पर चलने वाले web search फीचर्स से आती हैं, और ये requests अगले LLM models की training में इस्तेमाल नहीं होतीं। Cloudflare ने इन दोनों के बीच की रेखा जानबूझकर धुंधली कर दी है, और आधिकारिक रूप से “creator protection” की बात करता है, जबकि व्यवहार में वह LLM providers से ‘toll’ लेकर अपना लाभ सुनिश्चित करने वाला सिस्टम बना रहा है। अंततः यह निष्पक्षता नहीं, बल्कि आर्थिक प्रेरणा का मामला लगता है.

  • मैं एक दुर्लभ browser इस्तेमाल करता हूँ जो बहुत कम personal information उजागर करता है, लेकिन Cloudflare की नज़र में मैं भी bot जैसा ही दिखता हूँ। मेरा मानना है कि जहाँ host (वेबसाइट मालिक) access permissions तय करता है, वहाँ privacy वास्तव में हो ही नहीं सकती। server load रोकने के लिए rate limiting से मैं सहमत हूँ, लेकिन automated access को पूरी तरह रोकना व्यवहारिक रूप से असंभव है, और आखिरकार ऐसे कदम असली users की पहुँच भी कठिन बना देते हैं.

    • क्या अभी Cloudflare या turnstile की वजह से आपको बार-बार block होने का अनुभव होता है? ऊपर इसकी ओर संकेत था, लेकिन मैं स्पष्ट रूप से पुष्टि करना चाहता हूँ.

    • अगर किसी तानाशाही देश में रहने वाले लोगों को privacy और freedom के लिए VPN का इस्तेमाल करना पड़े, तो इंटरनेट 2-3 कंपनियों द्वारा चलाया जाने वाला captcha-नरक बन जाएगा। मेरे अपने बनाए bot से Cloudflare-सुरक्षित साइटों तक पहुँचना, VPN और privacy browser के साथ सामान्य web surfing करने से कम परेशानी देता है। वैसे, अगर Microsoft web gatekeeping संभालता, तो हालात और भी भयानक होते। खासकर VPN के साथ Microsoft का captcha पार करने के लिए तो मानो 5 मिनट से ज्यादा पूरी एकाग्रता और शोध-पत्र लिखने जैसी मेहनत चाहिए होती है.

    • वेबसाइट मालिकों के भी स्वाभाविक अधिकार हैं। उनके संचालन की वित्तीय स्थिरता के लिए gatekeeping चुनने से उन्हें मना करना अनुचित मांग होगी.

    • मैं भी rare browser इस्तेमाल करने के कारण अक्सर bot blockers में फँस जाता हूँ। लेकिन मैं यह भी मानता हूँ कि host को मेरे request को अपनी इच्छा से संभालने का अधिकार है। खासकर government sites के मामले में, मेरा मानना है कि सबको निष्पक्ष सेवा देने की जिम्मेदारी कहीं अधिक बड़ी है.

  • अगर इससे अधिक open कोई अच्छा विकल्प है तो मैं सुनना चाहूँगा, लेकिन अभी Cloudflare का तरीका AI bots की वास्तविक समस्या को काफी अच्छी तरह हल कर रहा है। इससे पहले IP blocking या user agent के आधार पर रोकने की कोशिश की गई, लेकिन उसकी सीमाएँ थीं। और वास्तव में दूसरी security समस्याएँ भी अक्सर ऐसे ही कुछ हद तक केंद्रीकृत तरीकों से हल की गई हैं। certificate authorities भी कोई खुली प्रणाली नहीं हैं, और attestation providers भी open systems नहीं हैं, फिर भी वे काम करते हैं.

    • अगर ज्यादा open solution चाहिए, तो regulation एक जवाब हो सकता है। वेबसाइट operators ने robots.txt में जिन्हें स्पष्ट रूप से अनुमति नहीं दी, ऐसे crawlers की requests को कानूनी रूप से प्रतिबंधित किया जा सकता है, और enforcement agencies सीधे कार्रवाई कर सकती हैं। अगर operator bot traffic साबित कर दे, तो सरकार को रिपोर्ट करके भारी जुर्माना लगवाया जा सकता है। cloud service providers को यह रिकॉर्ड रखने के लिए बाध्य किया जा सकता है कि किसने कौन-सा IP इस्तेमाल किया। यह 100% समाधान नहीं होगा, लेकिन सही तरह लागू किया जाए तो पर्याप्त मजबूत निवारक असर पैदा कर सकता है.

    • यह शायद सर्वोत्तम समाधान न हो, लेकिन व्यवहार में कुछ हद तक काम करने वाला समाधान है। केंद्रीकरण को लेकर बहुत आलोचना है, पर अगर Cloudflare प्रमुख AI कंपनियों और CDNs दोनों को इसमें शामिल करने में सफल हो जाता है, तो यह व्यावहारिक रूप से standard बन सकता है.

    • certificates आपको इंसान होने के बावजूद bot समझकर block नहीं करते.

    • बल्कि AI poisoning (जानबूझकर गलत जानकारी मिलाकर AI को भ्रमित करना) अधिक प्रभावी सुरक्षा हो सकती है। Cloudflare स्वयं ऐसा service भी दे सकता है जो AI bots को जानबूझकर गलत data परोसे.

    • सच तो यह है कि Let's Encrypt आने से पहले CAs का उपयोग अक्सर सामान्य कॉर्पोरेट वेबसाइटों में, वह भी सिर्फ कुछ login pages तक सीमित था। अगर Let's Encrypt की open policies न होतीं, तो हमारी personal information आज भी ISP या man-in-the-middle के सामने खुली होती। Attestation providers भी असहाय हैं; device vulnerabilities व्यापक रूप से ज्ञात होने पर भी वे business decisions के कारण certification रद्द करने से मना कर देते हैं। निष्कर्षतः, अधिकांश चर्चाओं में वास्तविक विकल्प ढूँढना कठिन लग रहा है। Cloudflare का इंटरनेट का gatekeeper बनना बुरा समाधान है, लेकिन समस्या स्वयं उससे कहीं अधिक गंभीर है। पूरी तरह distributed solutions पहले से मौजूद हैं (जैसे remote attestation, paid visit/subscription models, self-hosted firewalls)। AI के दुष्प्रभावों को अनदेखा करके सिर्फ लागत चुकाने की बात करने वाला रवैया ही Cloudflare को और बड़ा बनाता आया है। अगर ISPs ने spoofing, DDoS, botnets जैसी समस्याओं की अनदेखी न की होती, तो Cloudflare शायद सिर्फ Akamai जैसा एक प्रतिस्पर्धी भर रह जाता.

  • दुनिया में पहले से ही gatekeepers बहुत ज्यादा हैं। किसी भी अतिरिक्त gatekeeper प्रयास को आक्रामक कदम माना जाना चाहिए। Cloudflare और Google दोनों अपने gatekeeper positions को और मजबूत करने में लगे हुए हैं। अगर यह रुझान जारी रहा, तो मैं दोनों को पूरी तरह ढहते देखना चाहूँगा.

    • कई कंपनियाँ AI bot समस्या का समाधान देने की कोशिश कर रही हैं, और अगर Cloudflare चुना गया, तो उसे बहुत बड़ा मुनाफा होगा। लेकिन Cloudflare हट भी जाए, तब भी समस्या खत्म नहीं होगी—बस किसी दूसरी कंपनी का खराब विकल्प अपनाया जाएगा। gatekeeping दरअसल वेबसाइट मालिक द्वारा अपने विवेक से चुना गया विकल्प है (जैसे paywall, अपना bot detection, ID verification आदि)। Cloudflare पहले से ऐसी services देता है, और अगर यह standard भी बन जाए, तो विकल्प और बढ़ेंगे और बाज़ार भी खुलेगा (साइड इफेक्ट्स सहित)। असली open web की स्वतंत्रता सिर्फ visitors पर नहीं, बल्कि site owners पर भी समान रूप से लागू होती है.

    • Google का भविष्य का gatekeeper बनने का “लालच” कुछ ज्यादा नहीं है—वह तो पहले से ही Chrome browser की market share के जरिए वर्षों से gatekeeper की भूमिका निभा रहा है। Firefox की मौजूदगी भी बहुत कमज़ोर हो चुकी है। दृष्टिकोण यह है कि Google पूरे www को अपनी इच्छित दिशा में ले जा रहा है (uBlock पर रोक, .webp format को थोपना आदि).

  • किसी एक कंपनी द्वारा संचालित allowlist को समस्या बताने से पहले यह भी याद रखना चाहिए कि वास्तव में साइट operators ने खुद वह service चुनी है। दिलचस्प बात यह है कि “fairness” पर वैचारिक बहस करने वाले लोग अपने ब्लॉग पर AI tools से बने comics भी पोस्ट कर रहे हैं—यानी वास्तविक जीवन में AI पहले ही गहराई से प्रवेश कर चुका है; यह एक विरोधाभासी स्थिति है.

    • Cloudflare उभरते हुए Web Bot Auth standard को implement कर रहा है, और हम Stytch में भी IsAgent.dev पर वही standard लागू कर रहे हैं। मौजूदा चर्चा कुछ ज्यादा ही गर्म हो चुकी है, इसलिए सावधानी जरूरी है, लेकिन आखिरकार allowlist केवल Cloudflare के ग्राहकों को दिया गया एक विकल्प है। HTTP Message Signature जैसी इसकी core चीज़ें open/distributed तरीके से design की गई हैं, इसलिए कोई भी उनका उपयोग कर सकता है.

    • किसी एक कंपनी की allowlist को अपनी पसंद से इस्तेमाल करना अपने-आप में बड़ी समस्या नहीं है, लेकिन सिर्फ उसी से वह protocol नहीं बन जाती। और fairness की बहस का AI comics के इस्तेमाल से तार्किक रूप से कोई संबंध नहीं दिखता.

    • यह frying pan/fire जैसी स्थिति है—यानी सबसे अच्छा नहीं, बल्कि कम बुरा विकल्प चुनने वाली। डर यह है कि किसी एक कंपनी का समाधान खुल्लमखुल्ला standard जैसा बनकर रह जाए। इस मौके पर सचमुच protocol/standard आधारित समाधान बनाया जा सकता था, लेकिन Cloudflare अपनी अलग blue ocean बनाने की कोशिश कर रहा है। और “fairness” की बात करते हुए खुद रोजमर्रा की जिंदगी में AI का इस्तेमाल करना—इस विरोधाभास पर चतुराई से कटाक्ष किया गया है.

  • यह ईमेल संरचना जैसा लगता है। ईमेल इंटरनेट standards पर आधारित है, लेकिन अधिकांश users बहुत कम सेवा प्रदाताओं—जैसे Gmail—पर निर्भर हैं। Cloudflare भी open standard को आगे बढ़ा रहा है, लेकिन उसकी असली ताकत बड़े ग्राहक आधार से आती है। (साथ ही पूछा गया कि इसका अच्छा विकल्प क्या है?) और जैसे email में spam filtering के कारण delivery reliability कम और implementation कठिन हो जाती है, वैसे ही web भी उसी दिशा में जा सकता है.

    • व्यावहारिक रूप से free CDN के रूप में Cloudflare का कोई ठीक-ठाक विकल्प नहीं है। वह दुनिया भर में servers लगाकर उन्हें मुफ्त में उपलब्ध कराता है, और premium serverless services से कमाई करता है। वहीं बड़े cloud service providers के traffic egress charges असामान्य रूप से महँगे हैं.

  • web को attestation, signed agents, या Cloudflare द्वारा यह तय किया जाना पसंद नहीं कि कौन “वास्तविक” agent है। सबको “public” का अर्थ फिर से समझना चाहिए, और अगर traffic संभालना कठिन है तो बस बुनियादी rate limiting ही पर्याप्त है। web को यह जाँचने की जरूरत नहीं कि कोई इंसान है, bot है या कुत्ता—उसे बस उपलब्ध संसाधनों के भीतर सभी requesters को bytes देनी चाहिए। अगर इस “open web” का सार ही खत्म हो गया, तो सबको अफसोस होगा.

    • बुनियादी rate limiting भी हमलों के सामने कमजोर है। botnets को नज़रअंदाज़ नहीं किया जा सकता, और IPv6 में उपयोगी rate limiting लगभग असंभव हो जाती है। अगर buckets गलत चुने जाएँ, तो कुछ network operators /48 range बहुत आसानी से दे देते हैं, जिससे limit बेअसर हो जाती है, या mobile users के मामले में लाखों लोग एक ही rate limit में बँध जाते हैं.

    • इस तरह की बात का अर्थ आखिरकार यही है कि अनगिनत छोटे websites traffic नहीं संभाल पाएँगे और बंद हो जाएँगे। यह “open internet” के नारे के भी विपरीत है.

    • आधुनिक AI crawlers अब malicious botnets से अलग पहचान में नहीं आते। सामान्य rate limiting अब अर्थहीन होती जा रही है, और यही वह बिंदु है जहाँ Cloudflare इस समस्या को हल करने के लिए सामने आया है.

    • “public का मतलब PUBLIC है” वाला तर्क अच्छा लगता है अगर सिर्फ basic rate limiting से काम चल सके, लेकिन व्यवहार में स्वीकार्य access speed को साफ-साफ सार्वजनिक करना पड़ता है। फिर भी कई मामलों में सिर्फ अलग user-agent होने के कारण, भले request एक ही बार की हो, block कर दिया जाता है। अंततः operators bot के व्यवहार के बजाय identity के आधार पर requests को block करने लगते हैं। निर्णय का यह मानदंड बहुत मोटा है, जिससे false positives बढ़ते हैं। और ऐसी स्थिति में किसी प्रयास या संदर्भ की जाँच किए बिना केवल पहचान के आधार पर block कर दिया जाता है.

    • basic rate limiting लागू करना भी अक्सर आसान नहीं होता। जब तक किसी खास authentication/delegation की जरूरत न हो, public files तक पहुँच के लिए अलग से authentication या delegation की आवश्यकता नहीं होनी चाहिए। और अगर ऐसी delegation की समस्या हो भी, तो वास्तविक delegator की भूमिका के अलावा Cloudflare जैसे third party के दखल की जरूरत नहीं है.

  • मैं लेखक की राय से काफी हद तक सहमत हूँ। enterprise वातावरण में जटिल private networks के भीतर agents के व्यवहार को कैसे नियंत्रित किया जाए, यह एक गंभीर प्रश्न है। हाल ही में मैंने biscuit-आधारित “identity token” system खुद बनाया है। इस token के जरिए पहले कोई अपनी पहचान प्रमाणित करता है, और उसके बाद delegation token बनाकर नीचे के agents को भी सौंप सकता है। मेरे system में authorization token के बिना कुछ भी नहीं किया जा सकता (single scope, single use की अवधारणा)। इंटरनेट पर इसकी कल्पना ऐसे की जा सकती है कि identity token + छोटा भुगतान (जैसे बेहद छोटी crypto transaction) के बदले authorization token दिया जाए। तब मानव users के लिए लागत लगभग शून्य होगी, जबकि AI crawlers को अधिक भुगतान करना पड़ेगा.