AI scraper ने comment किए गए scripts को request किया

• वेब सर्वर लॉग का विश्लेषण करते समय ऐसी JavaScript files को request करने वाली बड़ी संख्या में bot activity मिली जो वास्तव में मौजूद ही नहीं थीं
• अनुमान है कि HTML comments के अंदर मौजूद script tags को वास्तविक code समझकर request किया गया, यानी यह LLM training data इकट्ठा करने की कोशिश हो सकती है
• ऐसी असामान्य requests का पता लगाकर public warning, IP blocking, compression bombs, data poisoning जैसे कई response उपाय सुझाए गए
• खास तौर पर data poisoning को ऐसा प्रभावी तरीका बताया गया जो LLM training data को दूषित करके model performance घटा सकता है
• इस बात पर ज़ोर दिया गया कि web admins को AI scrapers के खिलाफ defensive और counterattack strategies का प्रयोगात्मक रूप से उपयोग करने की ज़रूरत है

---

असामान्य scraping व्यवहार की पहचान

• सर्वर लॉग में मौजूद न होने वाली JavaScript files के लिए 404 error requests की बड़ी संख्या देखी गई
  • संबंधित files HTML comments के भीतर शामिल निष्क्रिय scripts थीं, जिन्हें सामान्य browser को request नहीं करना चाहिए
• requests के User-Agent में python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4 जैसे स्पष्ट bot identifiers शामिल थे
• robots.txt में crawler access पर रोक होने के बावजूद requests जारी रहीं, जिससे rules की अनदेखी या policy disregard का संकेत मिलता है
• कुछ requests ने Firefox, Chrome, Safari जैसे सामान्य browsers का रूप धारण किया, लेकिन HTML comments को सही तरह parse न कर पाने से fake identification उजागर हो गई
• इन requests को LLM training content की बिना सहमति scraping करने वाले scrapers से जुड़ा माना गया

scraper कैसे काम करते हैं

• कुछ scrapers HTML को सही तरह parse करके comments के भीतर के URLs को recursively follow कर सकते हैं
• अन्य scrapers संभवतः HTML को साधारण text की तरह लेकर regex-based URL extraction कर रहे थे
• User-Agent की विविधता और गुणवत्ता के अंतर से लगता है कि कई operators मौजूद हैं, जिनमें कुछ बहुत साधारण automation tools इस्तेमाल कर रहे हैं
• इन सबका साझा उद्देश्य लालची data collection है, और इसी को उलटे इस्तेमाल करने की संभावना के रूप में पेश किया गया

Algorithmic Sabotage

• यह algorithmic systems को जानबूझकर बाधित करने की क्रिया है, और LLM के externalized costs के कारण इस पर ध्यान बढ़ रहा है
• bots के non-human behavior patterns को पहचान लिया जाए तो detection और response आसान हो जाते हैं
• response के चार मुख्य प्रकार बताए गए हैं: public disclosure, IP filtering, decompression bombs, data poisoning

0. Public Disclosure

• मामूली false positives, जैसे User-Agent typo “Mozlla”, को सार्वजनिक करने पर हमलावर आसानी से उन्हें ठीक कर सकते हैं, इसलिए उन्हें private रखना बेहतर है
• लेकिन मूलभूत व्यवहार, जैसे comments के भीतर scripts को request करना, आसानी से सुधारा नहीं जा सकता, इसलिए उसे सार्वजनिक करना उपयोगी है
• इससे दूसरे site operators भी उसी हमले को detect और block कर सकते हैं
• ऐसे behavior को detect करने वाला system दूसरी sites पर भी लागू किया जा रहा है

1. IP Filtering

• fail2ban का उपयोग करके log pattern, date और IP के आधार पर automatic blocking की जाती है
• आम तौर पर block duration छोटा रखा जाता है, लेकिन long-term blocking से learning-based bots की दोबारा कोशिशें रोकी जा सकती हैं
• botnet की स्थिति में bots IP बदलकर requests जारी रख सकते हैं, फिर भी repeated patterns से उन्हें detect किया जा सकता है
• आगे botnet behavior analysis पर अतिरिक्त research की योजना का उल्लेख है

2. Decompression Bombs

• attacker द्वारा मांगी गई file के जवाब में zip bomb देकर system resources की खपत बढ़ाई जा सकती है
• इससे CPU, RAM और disk का अत्यधिक उपयोग हो सकता है, या vulnerabilities का दुरुपयोग संभव हो सकता है
• कमी यह है कि इससे server resources खर्च होते हैं और bandwidth waste का खतरा भी रहता है
• कुछ bots compromised systems पर चलते हैं, इसलिए attack का असर सीमित हो सकता है
• इसे सभी bots पर लागू करने की बजाय कुछ random requests पर response के रूप में उपयोग करने का सुझाव दिया गया

3. Data Poisoning

• LLM training data को दूषित करके model performance गिराने का प्रयास
• हालिया research के अनुसार, सिर्फ 250 poisoned documents भी बड़े models पर स्थायी असर डाल सकते हैं
• poisoned data किसी खास topic पर model से meaningless output उत्पन्न करवा सकता है
• उदाहरण के तौर पर, security research से जुड़े प्रश्नों पर किसी खास blog को recommend करने के लिए model को प्रभावित किया जा सकता है
• nepenthes, iocaine, glaze, nightshade जैसे public tools का उपयोग किया जा सकता है
• अगर LLM training data बिना सहमति इकट्ठा किया गया हो, तो ऐसे उपायों को वैध defensive response के रूप में पेश किया गया है
• IP blocking के साथ इसे लागू करने पर implementation complexity बढ़ सकती है, लेकिन combined operation संभव है
• प्रभावी designs को सार्वजनिक न करने का विकल्प भी बताया गया, और creative sabotage में व्यापक भागीदारी की ज़रूरत पर ज़ोर दिया गया

निष्कर्ष और community response

• असामान्य bot behavior के आधार पर detection कोई बिल्कुल नया विचार नहीं है, लेकिन comments के भीतर scripts की requests एक नया मिला हुआ case है
• robots.txt में Disallow directive जोड़कर खास requests पर countermeasure trigger करने का तरीका सुझाया गया

  User-agent: GPTBot
  Disallow: /poison/
  

• community में display:none और rel="nofollow" attributes का उपयोग करके bots को फंसाने वाले hidden links बनाने के कई विचार साझा किए गए
  • उदाहरण: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
• अगर links को absolute URL के रूप में सेट किया जाए तो ज्यादा crawlers के फंसने की संभावना हो सकती है
• कई sites पर अलग-अलग bot baiting और blocking experiments चल रहे हैं, जिनके प्रभाव को मापकर साझा किया जाएगा
• अन्य researchers भी AI scraper disruption experiments में शामिल हैं, और अनोखे poisoning cases भी साझा किए गए हैं
• कुल मिलाकर लक्ष्य AI data collection के खिलाफ स्वायत्त defense और counterattack strategies के प्रसार को बढ़ाना है

[GN⁺]

Hacker News राय

• ज़्यादातर web scrapers गैरकानूनी होने पर भी business purpose के लिए होते हैं
  इसलिए वे अक्सर Amazon या shopping mall का data scrape करते हैं। आखिरकार, unwanted traffic का अधिकांश हिस्सा big tech या vulnerabilities को निशाना बनाने वाले malicious actors से आता है
  मुझे web scraping के बारे में थोड़ा-बहुत पता है। कुछ sites सुरक्षा के लिए 404 लौटाती हैं, इसलिए मेरा crawler curlcffi जैसी तेज crawling methods कई बार आज़माता है
  Zip bomb से बचाव आसान है: सिर्फ header का content-length पढ़ लेना काफ़ी है। अगर response बहुत बड़ा हो, तो उसे न पढ़ने के लिए byte limit लगाएँ, और timeout से भी control करें
  लेकिन क्या आपको पता है कि requests का timeout पूरे page read के लिए timeout नहीं होता? अगर server bytes को धीरे-धीरे भेजे, तो वह अनिश्चितकाल तक wait कर सकता है
  इसलिए ऐसी समस्याओं को हल करने के लिए मैंने अपना crawling system बनाया। Selenium भी इसमें consistently चल सकता है
  मेरा project crawler-buddy है, और इसकी base library webtoolkit है

  • यह नहीं भूलना चाहिए कि content-length की गणना content-encoding के बाद होती है
  • मैं सोच रहा हूँ कि “scraping” और “crawling” में कोई फर्क है या नहीं
  • अब शायद in-browser scrapers का दौर आएगा। server की नज़र में इन्हें इंसान से अलग पहचानना असंभव होगा, और AI drivers मानव tests भी pass कर सकते हैं

• “बिना सहमति के LLM training data इकट्ठा किया” वाली अभिव्यक्ति मज़ेदार है
  public HTTP server पर GET request भेजने के लिए आखिर किस इजाज़त की ज़रूरत है, यह समझ नहीं आता। हाँ, weev मामला एक अपवादस्वरूप त्रासदी था

  • अगर मैं public HTTP server खोलता हूँ, तो सामान्य GET requests का स्वागत है
    लेकिन (1) सामान्य user access और bots का DDoS attack अलग चीज़ें हैं। किसी चीज़ का free होना यह नहीं मतलब कि आप उसे अनंत मात्रा में ले जाएँ; वह abuse है
    (2) वैध copying और robots द्वारा impersonation में फ़र्क होना चाहिए
    (3) अगर bot ठीक से बना है, तो उसे robots.txt का सम्मान करना चाहिए। यह क़ानून नहीं, बल्कि शिष्टाचार का मामला है
    लाखों residential IPs घुमाकर इस्तेमाल करने वाले bots किसी भी तरह सामान्य नहीं हैं
  • अगर आप server configuration को धोखा देकर मनचाहा data लेते हैं, तो वह बिना सहमति की पहुँच है
    public server होने का मतलब यह नहीं कि झूठे requests की अनुमति दी गई है। सिर्फ़ reasonable requests के लिए ही implicit consent माना जा सकता है
  • robots.txt कानूनी रूप से बाध्यकारी नहीं है, बल्कि एक विनम्र अनुरोध है
    इसका मतलब बस इतना है कि “कृपया इस page को scrape न करें”; अगर सच में रोकना है, तो API token या authentication process होना चाहिए
  • एक बार की access और अनंत crawling spree को एक जैसा मानना बेतुका है
    जैसे spam साधारण email जैसा नहीं होता, वैसे ही bot abuse भी साधारण request जैसा नहीं होता
  • “candy bowl” वाली उपमा से कहें, तो अगर trick-or-treat के लिए रखी सारी candies कोई एक adult उठा ले जाए, तो किसी को अच्छा नहीं लगेगा

• DOM parse करने की बजाय http/https strings को सीधे search करना ज़्यादा तेज़ लगता है

  • simple text search और DOM traversal के resource cost में इतना फ़र्क है कि “शायद तेज़ होगा” कहना कम करके कहना है
  • regex approach implement करना आसान है, लेकिन DOM parsing में भी CPU से ज़्यादा network bottleneck बड़ा मुद्दा है आख़िरकार network congestion ही limiting factor है

• दिलचस्प research के practical application को देखना अच्छा लगा
  संबंधित research इस पोस्ट में देखी जा सकती है

• title उलझाने वाला है। शायद “commented-out” कहना सही होगा

  • मैंने भी पहले इसे AI scraper-blocking script समझा था

• यह abuse कम और बस commented-out URL पढ़ लेने जैसा ज़्यादा लगता है

  • article abuse नहीं, बल्कि इसे bot detection signal की तरह इस्तेमाल करने का तरीका समझाता है
  • लेकिन robots.txt को नज़रअंदाज़ करके comments तक scrape करना निश्चित रूप से बदतमीज़ी भरा व्यवहार है

• पहले जब web crawl किया जाता था, तब Perl regex सबसे भरोसेमंद हुआ करता था
  comments के भीतर के URLs भी स्वाभाविक रूप से queue में जोड़ दिए जाते थे

  • DOM traversal तो उल्टा ज़रूरत से ज़्यादा कोशिश है। regex से ज़रूरी div या p पकड़ना ज़्यादा robust और simple था

• क्या bots को 512MB की random data file दे दी जाए?

  • उससे भी ज़्यादा profitable यह होगा कि AI scrapers के लिए ad responses को manipulate किया जाए ताकि LLM किसी खास product की recommendation करे
    मेरा startup ठीक इसी तरह की Ad-poisoning-as-a-service देता है
  • randomly linked AI poison pages बनाकर bots को उनमें फँसाना भी संभव है। इंसान तो उन पर click नहीं करेंगे
  • लेकिन ज़्यादातर लोग bandwidth cost नहीं उठा पाएँगे
  • 512MB पूरा “हमारी service सबसे बेहतरीन है” जैसे वाक्य से भर देना भी मज़ेदार होगा

• यह “LLM training data collection” कम और बस internet scanning noise ज़्यादा है

  • सही है। अगर यह vulnerability scanner है, तो वह जितने हो सकें उतने HTTP endpoints इकट्ठा करना चाहेगा
    JS files, comments हों या न हों, अच्छे clues होते हैं
    दूसरी ओर, अगर उद्देश्य LLM training हो, तो शायद ऐसी low-quality JS code में उसकी दिलचस्पी नहीं होगी

• unwanted LLM training traffic को poison करने के तरीक़ों पर एक विचार

  1. अगर कई sites मिलकर काम करें, तो data deduplication से बचते हुए model को contaminate करने की संभावना बढ़ सकती है
  2. copyright law का उपयोग करके poisoning की cost बढ़ाई जा सकती है। हालाँकि इससे sites पर कानूनी जोखिम भी आ सकता है
     copyright holders के साथ काम करने से जोखिम कम हो सकता है
  • पहले विचार को WordPress plugin के रूप में बनाया जाए तो अच्छा होगा
    हर request पर images को dynamically modify करके dedup defense को भी निष्प्रभावी किया जा सकता है। ऐसा plugin हो तो मैं भी तुरंत install करूँगा