- AI scrapers का ट्रैफ़िक सार्वजनिक विकियों की लागत और स्थिरता को हिला रहा है, और यदि इसे कम न किया जाए तो यह पूरे मानव ट्रैफ़िक की तुलना में लगभग 10 गुना अधिक computing resources इस्तेमाल कर सकता है
- बॉट GPTBot जैसे पहचाने जा सकने वाले User Agent से आगे बढ़कर headers को latest Chrome जैसा बनाते हैं, और रोज़ 10 लाख IP घुमाने वाले residential proxies से बच निकलते हैं
- विकी, articles से कहीं ज़्यादा पुराने revisions·edit screens·special pages URLs उजागर करती हैं, इसलिए भोला-भाला crawling cache को bypass कर सकता है और सामान्य requests की तुलना में 50~100 गुना महँगा पड़ सकता है
- Cloudflare Challenge, Anubis, manual firewall, और human behavior requests आधारित detection असरदार हैं, लेकिन इनके साथ false positives, maintenance burden, और readers के लिए friction भी आता है
- login अनिवार्य करना या सभी पर challenge लागू करने जैसी चरम blocking नई contributions घटा सकती है, इसलिए operators के बीच public discussion और bot collection incentives बदलने वाले API approaches की ज़रूरत है
AI स्क्रैपर से विकी संचालन पर बढ़ता बोझ
- LLM training data के लिए bot scraping अभूतपूर्व पैमाने पर बढ़ रही है और सार्वजनिक websites की लागत व स्थिरता को हिला रही है: संबंधित मुद्दों पर FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline?, Smart TV web crawler AI में भी चर्चा हुई है
- Weird Gloop Minecraft Wiki, OSRS Wiki, League Wiki जैसी बड़ी gaming wikis होस्ट करता है, और पिछले 3 वर्षों में bot traffic response पर लगातार अधिक समय खर्च कर रहा है
- यदि लगातार mitigation न किया जाए, तो bots लाखों मानव pageviews और रोज़ के हज़ारों edits सहित बाकी सबकी तुलना में लगभग 10 गुना अधिक computing resources इस्तेमाल कर सकते हैं
- Wikimedia Foundation ने भी crawlers के संचालन पर प्रभाव को लेकर एक लेख प्रकाशित किया है, बड़े wiki farms ने विभिन्न स्तर की outages झेली हैं, और कुछ छोटे स्वतंत्र wikis पूरी तरह offline हो गए
- अनुमान है कि इस वर्ष wiki ecosystem की लगभग 95% server समस्याओं के पीछे खराब scrapers हैं
इंसानों जैसा दिखने की कोशिश करने वाले स्क्रैपर
- GPTBot, ClaudeBot, PerplexityBot जैसी बड़ी AI कंपनियों के “official” bots कई बार robots.txt का पालन नहीं कर पाए हैं, लेकिन आमतौर पर User Agent string में पहचाने जा सकते हैं, इसलिए Cloudflare के AI bot blocking या nginx से इन्हें रोकना आसान होता है
- जैसे-जैसे webmasters ने User Agent आधारित AI scrapers को block करना शुरू किया, bots के पास मानव ट्रैफ़िक जैसा भेष बनाने की मज़बूत प्रेरणा पैदा हुई
- हाल में wikis तक पहुँचने वाला अधिकांश AI scraper traffic ऐसे headers भेजता है कि वह latest Google Chrome जैसा लगे, और requests को काफ़ी परिष्कृत ढंग से बनाता है
- पहले इस्तेमाल होने वाले साफ़ “bot या असली इंसान” संकेत अब गायब हो गए हैं, जिससे blocking कठिन हो गई है
करोड़ों IP और proxy bypass
- 2023 से पहले समस्याग्रस्त scraping का 95% single IP address या छोटे datacenter subnet से आता था, इसलिए IP या ISP विशेषताओं पर आधारित blocking आम तौर पर प्रभावी थी
- Residential proxies का उपयोग करके केवल credit card के सहारे लाखों IP addresses के network के ज़रिए scraping requests को धोया जा सकता है
- Wikis कभी-कभी ऐसे scrapers से टकराती हैं जो रोज़ 10 लाख IP घुमाते हैं, और Comcast, AT&T, Charter जैसे residential ISPs से आए वैध requests जैसे दिखते हैं
- संभव है कि संबंधित ग्राहक को पता भी न हो कि उसका IP residential proxy के exit node की तरह इस्तेमाल हो रहा है
- कुछ दुर्भावनापूर्ण actors facebookexternalhit link preview या Google Translate का उपयोग करके requests को Google/Facebook servers से आया हुआ दिखाते हैं, और असली source छिपा देते हैं
- Google Translate URL tool के ज़रिए आने वाली requests में 99.99% तक दुरुपयोग वाली हो सकती हैं, इसलिए एक समय सभी wikis पर उस tool को तोड़ना पड़ा था
विकी में खास तौर पर महँगी “बेवकूफ़ URL” crawling
- कई AI scrapers wiki homepage पर जाने के बाद उस page के सभी links पर जाते हैं, फिर उन pages के सभी links पर जाने के तरीके से URLs चुनते हैं
- robots.txt और sitemap यह बताते हैं कि कौन से URLs scraping के लायक हैं, फिर भी ऐसा लगता है कि इन्हें पहचाना नहीं जाता
- OSRS Wiki में लगभग 40 हज़ार articles हैं, और यही URLs साइट की अधिकांश उपयोगी जानकारी बनाते हैं
- लेकिन पुराने revisions, edit screens, special pages को शामिल करें तो crawl किए जा सकने वाले URLs कम से कम 1 अरब तक पहुँचते हैं
- इस तरह की naive crawling कभी ख़त्म नहीं होती, और लगता है कि यह LLM training data के लिए बेकार URLs पर भारी resources खर्च करती है
- अजीब requests उन cache layers को bypass कर देती हैं, जैसे असली user requests इस्तेमाल करने वाली MediaWiki parser cache, जिससे service cost बढ़ जाती है
- cache hit requests का processing time आम तौर पर 20 milliseconds से कम होता है, लेकिन पुराने diff जैसी requests में अक्सर 1~2 seconds लगते हैं
- “रोज़ 80 लाख bot requests”, “bots 65% bandwidth इस्तेमाल करते हैं” जैसे top-line metrics समस्या को कम करके दिखाते हैं
- असली bottleneck ज़्यादातर CPU capacity होती है, और अजीब query parameters वाली bot requests सामान्य requests की तुलना में अक्सर 50~100 गुना महँगी पड़ती हैं
औसत metrics में न दिखने वाले traffic spikes
- मासिक bot requests लगभग 25 करोड़ हैं, और औसतन लगभग 100 requests प्रति second रहती हैं, लेकिन यह केवल लंबी अवधि का average है
- scrapers अक्सर छोटे समय में 1,000+ requests per second भेजते हैं, और पारंपरिक DDoS attacks से इन्हें अलग करना लगभग असंभव हो जाता है
- लंबी अवधि में bots यदि कुल CPU usage का केवल 50% ही लें, तब भी दुर्भावनापूर्ण traffic spikes wiki की सुस्ती और outages के लगभग 95% के लिए ज़िम्मेदार होते हैं
यह पता लगाना मुश्किल कि असल में कौन कर रहा है
- इस traffic को “AI scrapers” कहा जाता है, लेकिन चूँकि सब Google Chrome जैसा भेष बनाते हैं, इसलिए असली ज़िम्मेदार पक्ष या wiki data का उपयोग किस काम में हो रहा है, यह जानना कठिन है
- संभावित actors में data brokers, frontier labs की duplicate collection, या residential proxies तक पहुँच रखने वाले independent projects शामिल हो सकते हैं
- entry barrier वास्तव में कितना कम हो चुका है, यह भी स्पष्ट नहीं है
- यदि कोई बेहतर तरीका हो, तो वे वास्तविक collectors से सीधे संपर्क कर कम अक्षम तरीका खोजने की इच्छा रखते हैं
अब तक असरदार रहे जवाब
-
Cloudflare Challenge और Anubis
- पिछले एक साल में websites को Cloudflare challenge या Anubis जैसे tools के पीछे रखना इंटरनेट पर व्यापक रूप से इस्तेमाल होने लगा है
- यह कुछ हद तक प्रभावी है, लेकिन कुछ अवधियों में कुछ bots लगातार challenge पार कर लेते हैं
- ऐसा लगता है कि Cloudflare और bot developers के बीच एक अदृश्य arms race चल रही है, जिसमें Cloudflare लगभग 90% मामलों में जीतता है, लेकिन बाकी 10% संचालन के लिए काफ़ी मुश्किल बनाते हैं
- असली readers को wiki तक पहुँचने से पहले challenge देखना पसंद नहीं आता
- ज़्यादातर लोगों को प्रभावित किए बिना काम करना हो तो यह तय करने के लिए अच्छे heuristic rules चाहिए कि किस traffic पर ही challenge लगाया जाए, लेकिन automated traffic को स्थिर रूप से detect करना अपने आप में कठिन है
-
Manual firewall rules
- अधिकांश operators के पास अपनी infrastructure और पुराने attacks के अनुरूप manual firewall rules होते हैं
- ये filters आमतौर पर specific User Agent strings, IP groups, और ASN पर आधारित होते हैं
- Weird Gloop अधिकांश चीज़ें Cloudflare/CDN स्तर पर संभालता है, जबकि दूसरी wikis nginx या web server स्तर पर इन्हें संभालती हैं
- अब कई मामलों में केवल User Agent/IP पर्याप्त नहीं है, इसलिए HTTP version, headers, TLS cipher, ja4 से जुड़े hashes जैसी अधिक जटिल request properties देखनी पड़ती हैं
-
“जो इंसान करते हैं, बॉट नहीं” उसे ढूँढना
- एक उपयोगी दृष्टिकोण यह है कि इंसानों के सामूहिक व्यवहार में ऐसी चीज़ें खोजी जाएँ जो bots नहीं करते
- MediaWiki आधारित wikis में असली browser users जब wiki का इस्तेमाल करते हैं तो कई प्रकार की HTTP requests बनती हैं, जिन्हें bots आमतौर on नहीं बनाते
- यदि headers, ja4 hash आदि से अलग की जा सकने वाली traffic की कोई श्रेणी बहुत से articles देखती है लेकिन सामान्य “मानव” requests नहीं बनाती, तो उस traffic पर challenge लगाने का यह मज़बूत संकेत है
- bot traffic में गायब human behavior requests को देखना एक शक्तिशाली तरीका है
- “गायब” traffic का विश्लेषण करके यह तय करने के लिए decision tree आधारित heuristics को स्वचालित रूप से सुझाने वाली system बनानी शुरू की गई है कि किस traffic पर challenge लगाया जाए
- tests में यह लगभग सभी scrapers को अच्छी तरह पकड़ती दिखी, लेकिन NoScript users, screen reader users, या अनपेक्षित devices वाले लोगों जैसी असामान्य browsing habits रखने वालों पर किस तरह के false positives होंगे, यह स्पष्ट नहीं है
- अपनी ML/data analysis infrastructure बनाना और उसे स्थायी रूप से बनाए रखना भी एक बोझ है
-
और भी असामान्य detection techniques
readers के लिए खराब चरम विकल्प
- AI scrapers को रोकने वाले “nuclear options” असली users के लिए कहीं ज़्यादा विनाशकारी हैं
- एक आम तरीका यह है कि जिन pages को बनाने की लागत अधिक हो सकती है, उन्हें देखने के लिए login अनिवार्य कर दिया जाए
- Fandom ने कुछ महीने पहले अपनी सभी wikis पर ऐसा कदम लागू किया
- दूसरा तरीका सभी traffic को Cloudflare challenge दिखाना है
- webmasters के नज़रिए से यह समझ में आता है, लेकिन wikis और communities की लंबी अवधि की सेहत के लिए यह बुरा है
- 16 वर्षों तक wiki community बनाने से मिला मुख्य सबक यह है कि नए contributors को लाने का सबसे अच्छा तरीका friction हटाना है
- editing को आसान बनाना, wiki की internal structure को समझना आसान करना, और readers व editors के बीच entry barriers कम करनी चाहिए
- चरम anti-bot techniques नया friction पैदा करती हैं और अनुमानित नतीजे लाती हैं
- Fandom ने account के बिना आने वाले 95%+ readers से “internal pages” छिपाने के बाद, Fandom भर में नए user contributions में लगभग 40% की गिरावट देखी गई
- ऐसे trade-off को मूल्यवान मानना कठिन है
आगे की दिशा
- Weird Gloop अभी भी wiki hosting जारी रखे हुए है, और Fandom से बाहर निकलना चाहने वाली wikis की मदद भी करता रहेगा
- लंबी अवधि में “AI Overviews” wiki readers को wiki contributors में बदलने वाली pipeline को नुकसान पहुँचा सकते हैं, लेकिन इसे अलग मुद्दा माना गया है
- कुछ परिचितों का मानना है कि bots की यह लहर Weird Gloop के लिए फ़ायदेमंद भी हो सकती है, लेकिन यदि लोग आसानी से wikis होस्ट न कर सकें तो इंटरनेट और बदतर हो जाएगा
- ऐसा परिदृश्य जिसमें wiki को स्थिर रूप से होस्ट करने के लिए on-call rotation, ML engineers, और enterprise products की ज़रूरत पड़े, स्वतंत्र wiki communities के लिए बहुत बुरी ख़बर है
- bot owners और webmasters के बीच arms race तब तक जारी रहने की संभावना है जब तक scraping की संरचनात्मक incentives बदलने का कोई चतुर तरीका नहीं निकलता
- Cloudflare का नया crawling API समीकरण बदल सकता है, यदि bots के लिए robots.txt को नज़रअंदाज़ कर समस्याग्रस्त internal systems बनाने की बजाय API इस्तेमाल करना अधिक आसान हो जाए
- scraping का बिल्कुल न होना बेहतर होता, लेकिन जो शुरू हो चुका है उसे पलटना कठिन है
सार्वजनिक चर्चा और सहयोग की ज़रूरत
- हज़ारों operators अपनी-अपनी websites चला रहे हैं और bots से निपटने के लिए अधिक चतुर techniques खोज रहे हैं
- दूसरे system administrators के साथ निजी बातचीत में ठोस और अच्छे ideas सामने आए हैं, और Slack, Discord, तथा छोटे groups में भी काफ़ी चर्चा चलती होगी
- वास्तविक operational details को लेकर और अधिक public discussion की ज़रूरत है
- कई system administrators को यह पर्याप्त रूप से पता ही नहीं कि उनकी समस्या दूसरे operators की समस्या से लगभग एक जैसी है
- हर कोई अपनी defense methods सार्वजनिक नहीं करना चाहता, और यह चिंता भी रहती है कि सार्वजनिक करने पर बढ़त खो सकती है
- फिर भी, यदि लोगों को साथ सोचने में मदद मिलती है, तो कुछ tactics की प्रभावशीलता घटने का जोखिम उठाया जा सकता है
- AI scrapers से निपटने वाले system administrators के लिए बेहतर होगा कि वे अपने अनुकूल स्थानों पर असरदार तरीक़े साझा करें
- bot problem solving products बेचने वाली कंपनियों को precision and recall अनुपात पर वास्तविक, गैर-कृत्रिम परिस्थितियों के data वाले अधिक case studies सार्वजनिक करने चाहिए
- खरीद निर्णय लेने वाले लोग checkbox नहीं, बल्कि वास्तविक परिणाम को महत्व देते हैं
- यदि आप wiki या independent website चलाते हैं और bot detection पर चर्चा करना चाहते हैं, तो email या Discord message के ज़रिए संपर्क किया जा सकता है
2 टिप्पणियां
असल में GeekNews पर भी बहुत बड़ी संख्या में crawler आते हैं, इसलिए हम उन्हें block करने और लागत को optimize करने के लिए कई तरह के तरीके अपना रहे हैं। खासकर चीन की ओर से आने वाले AI bots वाकई बेहद आक्रामक तरीके से crawling करते हैं.
लेकिन दूसरी ओर CDN स्तर पर उन्हें block करने के लिए भी लागत लगना अपने आप में एक समस्या है.
Lobste.rs राय
Anubis की कमियों को पूरा करने के लिए proof-of-wait challenge आज़माया, और यह काफ़ी असरदार रहा
मूल रूप से, अगर global request rate threshold से नीचे हो तो filter बंद रहता है, और threshold पार होने पर user को आगे बढ़ने से पहले N सेकंड इंतज़ार करना पड़ता है
उसके बाद उस IP से बंधा एक token जारी किया जाता है, जो expiry time के भीतर थोड़ी संख्या में requests की अनुमति देता है, और token पर भी rate limit लगती है
successful requests आती रहें तो wait time धीरे-धीरे बढ़ता जाता है
यह काफ़ी सफल रहा, mobile devices के लिए इसे धीरे-धीरे degrade होने वाला बनाया गया ताकि उन पर ज़्यादा अन्याय न हो, और यह JavaScript के बिना भी काम करता है
लगता है ऐसी चीज़ें TLS या यहाँ तक कि OS के IP stack जैसी कहीं और भी नीची layer में होनी चाहिए
मैंने proof-of-wait के बारे में ज़्यादा गहराई से नहीं सोचा, लेकिन क्या वैध users के लिए इंतज़ार automated scrapers की तुलना में ज़्यादा बुरा नहीं होगा? इंसान इंतज़ार से चिढ़ते हैं, लेकिन scraper token store करके N सेकंड बाद लौट सकता है
proof-of-work को लेकर भी मिश्रित भावनाएँ हैं, लेकिन कम से कम यह scrapers पर scale के हिसाब से वास्तविक cost डालता है
proof-of-wait शायद उन लोगों को आश्वस्त कर सके जिन्हें proof-of-work पर चिंता है
कुछ खास special pages पर यह तरीका भी काफ़ी अच्छा काम करता है कि एक बार login किया जाए और सिर्फ़ वही client access पाए जिनके पास वह cookie set हो; वरना मना कर दिया जाए
ज़्यादातर crawlers wiki को खंगालने के लिए special pages को target करते हैं, इसलिए उन्हें logged-in users तक सीमित किया जा सकता है
इस setup में wiki user creation की अनुमति नहीं देता
<If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
ErrorDocument 403 "Access denied, please login."
Require all denied
</If>
इससे हमारे system load में काफ़ी कमी आई। पहले special pages की भारी crawling के कारण ऐसे peaks अक्सर आते थे कि wiki लगभग बेकार हो जाता था
इसके अलावा, जाने-पहचाने AI crawler user agents को सीधे 403 कर देते हैं, और Alibaba या Amazon Cloud जैसे कुछ IP ranges को भी block करते हैं
मज़ेदार बात यह है कि उधर वालों ने इसे नोटिस कर लिया। वे Diff view से pages खंगाल रहे थे, तो हमने restrict किया; फिर उन्होंने MobileDiff view से वही कोशिश की
कुछ बार ऐसा आगे-पीछे हुआ, लेकिन कुछ महीनों से यह तरीका ठीक चल रहा है
user-agent से block करोगे तो crawler इंसान जैसा दिखने वाला user-agent लगाकर फिर से कोशिश करेगा और site को explore करेगा
अगर उसे समझ आ गया कि block का trigger user-agent है, तो वह hell mode में चला जाएगा, जहाँ उसे पहचानना बहुत मुश्किल हो जाएगा और वह site को तब तक पीटता रहेगा जब तक मर न जाए
IP range blocking भी मदद करती है, लेकिन crawler mobile malware proxies से crawl करता है, इसलिए यह काफ़ी नहीं है और सबको पकड़ भी नहीं सकती
अगर आप शुरू से block न करें तो वे आम तौर पर काफ़ी शांत रहते हैं
इसलिए block करने के बजाय सस्ते में generated कचरा data खिलाना और hell mode trigger न होने देना ही तरकीब है, और मैं https://iocaine.madhouse-project.org/ का इस्तेमाल करता हूँ
हालाँकि ऐसा करने पर MediaWiki को responses ख़ुद serve करने पड़ेंगे, इसलिए Apache में handle करने का फ़ायदा भी है
थोड़ा अलग मुद्दा है, लेकिन Weird Gloop एक शानदार service है। वे जो wikis चलाते हैं उनकी quality बहुत ऊँची है, और fan-made content को Fandom के भयानक platform से बाहर लाना दुनिया के लिए अच्छा काम है
Gergely Nagy, a.k.a. algernon, जो iocaine के developer भी हैं, इस समस्या से कुछ समय से जूझ रहे हैं, और संभव है कि Weird Gloop के लिए उनके पास उपयोगी insights हों
यह कहना अच्छा नहीं लग रहा, लेकिन मानव व्यवहार के हिसाब से tuning करने का सुझाव आगे चलकर उल्टा पड़ सकता है
bots शायद page की सारी static assets भी request करना शुरू कर देंगे और मान लेंगे कि यह इंसानों की पहचान करने वाले व्यवहार का हिस्सा है
दिलचस्प खेल है, Professor Falken
अगर scraper सामान्य
<a href=...>links को recursively follow करते हुए ऐसी pages तक पहुँचते हैं, तो क्या history diff जैसी महँगी और non-cached pages को सिर्फ़<form method="POST" action=...>submit करके ही accessible बनाकर उन्हें नरमी से कहीं और मोड़ा जा सकता है?इसमें कुछ भी block नहीं किया जाता, और असल में scraper के लिए भी फ़ायदा है क्योंकि उसे लगभग अनंत duplicate information को recursive तरीके से निगलना नहीं पड़ेगा
सामान्य users को शायद फ़र्क भी मुश्किल से महसूस होगा, और मेहनत बनाम असर के हिसाब से यह ठीक लग सकता है। anonymous users के लिए यह Anubis से बेहतर हो सकता है
यह इस धारणा पर टिका है कि scraper
method="POST"वाले HTTP forms submit नहीं करतेअगर यह मोटे तौर पर सच न होता, तो शायद अब तक हम ऐसी headlines देख चुके होते कि AI scrapers ने anonymous edits की बाढ़ लाकर Wikipedia की सामग्री को random कचरे में बदल दिया
सोच रहा हूँ क्या bots
<form method="GET">भी submit करेंगे। इससे caching बनी रहेगी और crawlers से extra logic की माँग की जा सकेगीमेरे छोटे blog के traffic का 95% Singapore और China के LLM scrapers से आता है
इतने साल बीत गए, फिर भी क्या किसी ने IPs की जाँच करके किसी छोटे ISP का ऐसा IP नहीं ढूँढा जिससे संपर्क किया जा सके और सीधे वहाँ जाया जा सके? उस user से विनम्रता से पूछकर कि क्या उनके computer की जाँच की जा सकती है? क्या किसी ने सच में यह पता नहीं लगाया कि crawl कौन-सा software कर रहा है?
अगर site operators यह तक नहीं कर सकते, तो फिर मुझे परवाह ही नहीं करनी चाहिए। असल में वे गंदे मानवीय संपर्क से बचने की इतनी कोशिश कर रहे हैं कि bots मिलना तय है
और residential botnet पर चलने वाले bots के पास कभी-कभी CAPTCHA या Anubis पार करने लायक compute resources भी होते हैं
server side से स्थायी रूप से जीतना असंभव है। उस machine का user भी वैध traffic पैदा करता है
इसलिए जब तक आप remote attestation नहीं चाहते, आपको उन IPs तक जाना पड़ेगा
दुनिया भर में गाड़ी चलाकर घूमने के fuel cost जैसे व्यावहारिक मुद्दों को छोड़ भी दें, तो यह एक बड़ा travelling salesman problem बन जाता है
यह सोचना कि कुछ bots के लिए sysadmins को वीकेंड भर कहीं भी गाड़ी चलाकर जाना चाहिए ताकि वे थोड़ा शालीन हो जाएँ, ख़ासकर जब ज़्यादातर बड़े या विदेशी ISPs से आते हों, बस हास्यास्पद है
सच में समझ नहीं आता आपने क्या पी रखा है
आजकल कौन-सा software crawl कर रहा है? कोई chatbot से कहता है, “इसे scrape करने वाला बनाकर दो,” और हर scraper अलग-अलग तैयार हो जाता है
नहीं तो आप बस अमूर्त रूप से पूरे ब्रह्मांड को दोष दे रहे होते हैं
मैं दावे से कह सकता हूँ कि ज़्यादातर service providers को इस बात की ज़रा भी परवाह नहीं होगी कि उनके IPs का इस्तेमाल किस website scraping में हो रहा है
और वे यह भी कभी नहीं बताएँगे कि उस IP से जुड़ा address क्या है
कहीं ज़्यादा असरदार तरीका है Alibaba, AWS जैसे कई providers से जुड़े ASN traffic को पूरी तरह discard कर देना
यह हमेशा संभव विकल्प नहीं होता। जैसे, अगर किसी blog में Atom feed है, तो इससे feed readers भी block हो सकते हैं
लेकिन कई मामलों में इससे 80% junk traffic हटाया जा सकता है
क्या किसी को पता है कि यह व्यवहार होता क्यों है? ख़ासकर यह जानना चाहता हूँ कि spikes क्यों आते हैं
पता नहीं यह सच है या नहीं, लेकिन कम से कम plausible लगता है
infrastructure को बेहतर समझे बिना कुछ कहना मुश्किल है। यह command-and-control limitations भी हो सकती हैं
अगर botnet मूल रूप से DDoS के लिए बना था, तो संभव है कि उसकी architecture में स्वभावतः fine-grained control की कमी हो