अगर आप बड़ी कंपनियों की तरह Web Scraping करना चाहते हैं (2021)

• सिर्फ AWS Lambda और Headless Chrome से भी Google SERP को प्रति सप्ताह लाखों की संख्या में collect किया जा सका, लेकिन मजबूती से सुरक्षित साइटों के सामने cloud-based bot architecture जल्दी ही अपनी सीमा से टकरा जाता है
• Lambda को दोबारा invoke करने और कई regions का इस्तेमाल करने पर, 16 regions के आधार पर लगभग 16 * 250 = 4000 public IPs एक साथ इस्तेमाल किए जा सकते थे, और यह ढीले targets के लिए पर्याप्त था
• DataDome, Akamai, Imperva जैसी anti-bot कंपनियां browser settings mismatch, automation traces और fingerprint information को track करती हैं, और असली कठिनाई detection से ज्यादा false positive rate को कम रखने के करीब है
• कम detect होने वाले architecture के रूप में Docker या cloud servers के बजाय असली Android devices और mobile IPs इस्तेमाल करने का तरीका सुझाया गया है; 4G/5G/LTE IPs को बड़े शहरों में बहुत सारे normal users share करते हैं, इसलिए उन्हें block करना मुश्किल होता है
• असली device farm में devices खरीदना, शहरों के हिसाब से space rent करना, on-site maintenance और hardware failures सहने पड़ते हैं, और Android emulators में भी emulation detection का जोखिम बना रहता है

---

AWS Lambda से बना बड़े पैमाने का scraping architecture

• पहले scraping service चलाते समय Google SERP को प्रति सप्ताह अधिकतम लाखों की संख्या में collect किया गया, लेकिन Brightdata, Packetstream, Oxylabs जैसे proxy providers का इस्तेमाल नहीं किया गया
  • इसी proxy bandwidth को share करने वाले दूसरे customers पर भरोसा करना मुश्किल माना गया
  • public information की non-DoS scraping ठीक है, लेकिन ad fraud, social media spam, automated SQL injection, XSS जैसे web attacks से स्पष्ट दूरी रखी गई
  • proxy service की cost भी बोझ बनी
• असली setup AWS Lambda में Headless Chrome डालकर, puppeteer-extra और chrome-aws-lambda से 300 seconds तक browser चलाने वाला function था
• Google अपने search engine के लिए bot blocking बहुत कड़ा नहीं करता और मुख्य रूप से IP-based rate limiting लागू करता है, इसलिए माना गया कि सिर्फ Google SERP के लिए curl से भी काम हो सकता था
• Lambda में function invocation 3 बार के बाद नया public IP मिलता था, और 1000 functions को एक साथ invoke करने पर लगभग 250 public IPs तक पहुंचा गया
  • 16 regions इस्तेमाल करने पर एक साथ लगभग 4000 public IPs इस्तेमाल किए जा सकते थे, ऐसा calculate किया गया
  • ये shared datacenter IPs थे, लेकिन Google SERP को प्रति सप्ताह लाखों की संख्या में collect करने के लिए पर्याप्त थे
• Google Cloud Platform भी try किया गया, लेकिन Google ने AWS traffic की तुलना में अपने cloud infrastructure traffic को ज्यादा कड़ाई से block किया
• यह अनुभव 2019 और 2020 के आधार पर है, और उसके बाद स्थिति बदल गई हो सकती है

Cloud bots क्यों block हो जाते हैं

• Lambda-based architecture Google, Bing, Amazon जैसे targets पर काम कर सकता है जो कुछ हद तक scraping allow करते हैं, लेकिन strong protection लागू करने वाली sites के लिए उपयुक्त नहीं है
• DataDome, Akamai, Imperva जैसी anti-bot कंपनियां browser fingerprints, settings mismatch, और human-operated browsers से अलग traces खोजती हैं
• detection techniques के examples काफी व्यापक हैं
  • Browser Red Pills
  • Browser Based Port Scanning
  • Google Picasso
  • Font Fingerprinting
  • TLS Fingerprinting
  • WebGL Fingerprinting
  • WebRTC real IP detection
  • Behavioral Classification
  • Gyroscope API query
  • JavaScript के बिना HTTP headers, CSS feature query और fonts से fingerprinting
• bot detection के तरीके बहुत ज्यादा हैं, और लगभग हर bot architecture कुछ हद तक detection के लिए vulnerable होता है
• bot बनाना detect करने की तुलना में ज्यादा मुश्किल है, और anti-bot कंपनियों की बड़ी चुनौती ज्यादातर bots को पकड़ने से ज्यादा false positive rate को कम रखना है

आसानी से detect होने वाली economic structure

• बड़े पैमाने की scraping करने वाले bot developers अक्सर browser को Docker container में डालते हैं और Docker Swarm या Kubernetes से orchestrate करते हैं
• ऐसे bots अक्सर Hetzner, AWS, DigitalOcean जैसे cloud providers पर host किए जाते हैं
• यह structure human users के environment से काफी अलग है
  • किसी normal user का Hetzner VPS के Docker container के अंदर Instagram browse करना स्वाभाविक स्थिति नहीं है
• successful scraping के लिए दो rules पेश किए गए हैं
  • दूसरा सबसे महत्वपूर्ण rule: browser settings के बारे में झूठ न बोलें
  • सबसे महत्वपूर्ण rule: browser settings के बारे में तभी झूठ बोलें जब पकड़े न जाएं

असली Android device farm

• obfuscated anti-bot fingerprinting libraries को reverse engineer करना मुश्किल होने के कारण, scraping में असली devices इस्तेमाल करने का approach सुझाया गया है
• माना गया structure 500 low-cost Android devices खरीदने और fingerprint diversity के लिए लगभग 5 manufacturers के devices mix करने का है
  • low-cost Android devices प्रति unit 58 dollars से शुरू होते हैं
  • एक बार में 100 units खरीदने पर बड़ा discount मिल सकता है, ऐसा माना गया
• हर device में सस्ता data plan लगाया जाता है और DeviceFarmer/stf से control किया जाता है
• London, Paris, Boston, Frankfurt, Los Angeles जैसे 5 प्रमुख शहरों में 100 devices each deploy करने और mobile cellular antenna के पास सस्ता storage space rent करने की योजना है
• devices में हल्का Android Go install कर unnecessary elements हटाए जाते हैं और उन्हें power से connect किया जाता है
• हर 5 minutes में airplane mode on/off करने पर 4G Carrier Grade NAT के जरिए नया IP मिल सकता है
• mobile IP addresses को बड़े शहरों में अधिकतम लाखों normal users share करते हैं, इसलिए उन्हें practical रूप से block करना मुश्किल है
  • example के तौर पर माना गया कि Instagram कुछ spam users की वजह से LA के 200,000 लोगों को block नहीं करेगा
  • Ofcom document cite किया गया कि CGN में IPv4 address block होने पर पूरे subscriber base पर असर पड़ सकता है
• IPv6 का address space बहुत बड़ा है, इसलिए ज्यादातर anti-bot कंपनियां IPv6 addresses को बहुत कम या बिल्कुल भी IP reputation नहीं देतीं, ऐसा माना गया

असली device structure के detection points और operational burden

• असली devices को पूरे दिन जमीन पर रख देने से rotation या movement न होने की स्थिति बनी रहती है, इसलिए deviceorientation और devicemotion JavaScript events को kernel level पर spoof करना होगा
  • websites Android के rotation और speed data को permission request के बिना access कर सकती हैं
• इस समस्या को छोड़ दें तो यह स्पष्ट नहीं माना गया कि bot detection system इस structure को कैसे block कर पाएगा
• operational burden छोटा नहीं है
  • 500 Android devices खरीदने होंगे
  • प्रमुख शहरों में storage space rent करना होगा और इसकी cost आएगी
  • 5 शहरों में device farm की समस्याएं ठीक करने वाले लोग चाहिए होंगे
  • hardware संभालना होगा और लगातार issues आ सकते हैं
• यह structure एक बड़ा project बन जाएगा, और maintenance में हजारों dollars लग सकते हैं, ऐसा माना गया

Android emulator एक alternative के रूप में

• असली Android devices के बजाय Android emulator इस्तेमाल करना बेहतर माना गया
• cost कम हो सकती है, लेकिन anti-bot कंपनियां emulation environment खोज सकती हैं
• संभावित detection methods कई तरह के हैं
  • browser-based red pill से यह सामने आ सकता है कि browser emulation environment में चल रहा है
  • browser-based port scan से emulated Android device पर ही चलने वाले ports या adb जैसी services खोजी जा सकती हैं
  • Google पूरे mobile device के लिए advertising ID set कर सकता है, और अगर यह ID नहीं है या हमेशा वही है तो यह suspicious signal हो सकता है
  • Social Media Login Detection से Gmail या YouTube account login status check किया जा सकता है, और Android पर Google account login न होना suspicious हो सकता है
  • इसके अलावा emulated Android device detection की कई techniques हो सकती हैं
• Android emulator के imperfect होने की संभावना ज्यादा है, और यह imperfection mobile browser की बहुत बड़ी JavaScript API के जरिए सामने आ सकती है
• फिर भी emulation approach को पसंद किया गया है, और कुछ powerful servers में 4G dongles connect करने का setup सुझाया गया है
• proxidize.com 4G mobile proxy देता है, लेकिन proxy अपने आप में detectable है, इसलिए Android emulator से 4G dongle सीधे इस्तेमाल करना चाहा गया
• final structure regional scraping stations के रूप में है
  • एक geographic location पर 50 4G dongles से जुड़ा 1 powerful scraping server install किया जाता है
  • हर server पर 50–100 emulated Android devices चलाए जाते हैं
  • ऐसे stations 5 प्रमुख शहरों में deploy किए जाते हैं
  • एक simple command-and-control server 5 scraping stations को orchestrate करता है

[GN⁺]

Hacker News की राय

• वेब स्क्रैपिंग क्षेत्र में काम करने वाले एक वकील के तौर पर ऐसे थ्रेड देखकर मुझे हमेशा हँसी आती है। आज जिन लगभग सभी कंपनियों या उनकी सहयोगी इकाइयों को हम टेक क्षेत्र के एकाधिकारवादी उद्यम मानते हैं, उन्होंने अपना व्यवसाय बढ़ाने के दौरान स्क्रैपिंग का इस्तेमाल किया, और अब वही कंपनियाँ स्टार्टअप्स और प्रतिस्पर्धियों को डेटा स्क्रैप करने से रोकती हैं
  और वह डेटा भी अक्सर कानूनी रूप से पहचाने जा सकने वाले अर्थ में वास्तव में “उनका” डेटा नहीं होता। इसलिए वेब स्क्रैपिंग की नैतिकता भी और उससे जुड़े कानूनी मुद्दे भी इतने सरल नहीं हैं। इस बारे में मैंने पिछले पतझड़ में एक लेख लिखा था, जिसे यहाँ भी रुचि मिली थी: https://news.ycombinator.com/item?id=37264676
  • Facebook और पहचान संबंधी जानकारी का मामला भी कुछ ऐसा ही है। अगर मुझे सही याद है, तो Facebook ने शुरुआत में Google contacts का इस्तेमाल करके वृद्धि की थी, लेकिन अगर कोई Facebook के social graph data को लंबे समय तक स्टोर करके उसकी अपनी सीमा के बाहर इस्तेमाल करना चाहे, तो वह उसे आक्रामक तरीके से रोकता है
    आखिरकार, जिन तरीकों का उन्होंने खुद अपनी वृद्धि के लिए उपयोग किया, वही दूसरों को इस्तेमाल नहीं करने देते
  • वेब स्क्रैपिंग की नैतिकता तो मुझे उल्टे बहुत सरल लगती है। “आप मेरे HTTP request का जवाब अपनी मर्ज़ी से दे सकते हैं, और मैं उस response की व्याख्या अपनी मर्ज़ी से कर सकता हूँ” — इतना काफी है
    मानव संचार की शुरुआत से ही बातचीत क्या हमेशा इसी तरह नहीं रही? दूसरी ओर, कानूनी मुद्दे ऐसे लगते हैं जैसे स्थापित व्यवसायों को राज्य की शक्ति के खतरे से बचाने के लिए बुना गया कोई कपड़ा हों; इनमें कुछ नया नहीं, बस दयनीय लेकिन पूर्वानुमेय प्रवृत्ति है। और व्यापक रूप से इसे बौद्धिक संपदा का मुद्दा बनाकर कलाकारों और रचनाकारों की रक्षा से जोड़ने की कोशिश भी तार्किक रूप से बहुत अटपटी लगती है
• मैं पहले एक पेशेवर web scraper था और अब भी इंडस्ट्री के रुझानों पर नज़र रखता हूँ। आजकल लोग वेब स्क्रैपिंग करके नहीं, बल्कि web scrapers को सेवाएँ बेचकर पैसा कमाते हैं
  वेब स्क्रैपिंग SaaS और संबंधित सेवाएँ बहुत हैं, और residential proxy providers भी दर्जनों हैं। ज़्यादातर bot prevention mechanisms इतनी तेज़ी से बदलते हैं कि पारंपरिक software engineering भूमिकाओं के भीतर भी सिर्फ bot mitigation bypass तकनीकों में विशेषज्ञता रखकर अच्छी कमाई की जा सकती है। बदलाव की इसी रफ़्तार की वजह से वेब स्क्रैपिंग को पेशा बनाने की तुलना में किसी वेब स्क्रैपिंग कंपनी में काम करना अधिक स्थिर है। scrapers को प्रोजेक्ट-आधारित भुगतान मिलता है, जो लंबे समय में अस्थिर है; उन्नत स्क्रैपिंग के लिए residential proxies और server rentals जैसे परिचालन निवेश चाहिए; और कम कीमत वाले कामों का भुगतान बहुत कम होता है। सिर्फ Brightdata के वेब स्क्रैपिंग conference आयोजित करने से ही समझ आता है कि बड़े पैमाने की स्क्रैपिंग सेवाएँ बेचना कितना लाभदायक है
  • मैं लंबे समय से सोचता रहा हूँ कि स्क्रैपिंग या बड़े bot networks चलाने के लिए residential proxies अनिवार्य हैं, लेकिन मैंने खुद कभी उनका इस्तेमाल नहीं किया, इसलिए वास्तविक पैमाने पर उनका उपयोग कैसे होता है, यह पुष्टि नहीं कर पाया
    मुझे जिज्ञासा है कि क्या ऐसे उद्देश्यों के लिए कमजोर सुरक्षा वाले IoT devices या malware-संक्रमित उपभोक्ता हार्डवेयर का आम तौर पर उपयोग होता है। ISP के साथ सहयोग करके residential IP हासिल करने का मॉडल न तो लाभदायक लगता है, न ही व्यावहारिक, इसलिए residential proxy service के लिए कोई काफ़ी गुप्त तरीका ही संभव लगता है
  • अगर सामान्य रूप से स्क्रैपिंग के सबसे करीब कोई conference हो, तो मैं सिफारिश चाहूँगा। जहाँ तक मुझे पता है, स्क्रैपिंग-केंद्रित conferences या मज़बूत community लगभग नहीं है, इसलिए मैं सीखना और अपनी क्षमता बढ़ाना चाहता हूँ
  • मैं कई वर्षों से Upwork पर scrapers लिखता रहा हूँ, लेकिन project-based काम से थक गया हूँ और scraping SaaS में काम करना या खुद शुरू करना चाहता हूँ। सलाह जानना चाहता हूँ
  • शुरुआत में मुझे पता ही नहीं था कि यह इतना आसान होगा, इसलिए मैंने कोड open source के रूप में जारी कर दिया। GitHub से इसलिए बचा क्योंकि लगा कि Akamai जैसी जगहें बहुत जल्दी DMCA भेज देंगी, और jurisdiction के अंतर का फायदा उठाकर मैंने इसे चीन के GitHub जैसे Gitee पर डाल दिया
    इस क्षेत्र की पृष्ठभूमि नहीं थी, लेकिन कंपनियाँ जो दावा कर रही थीं उसे मिलाकर देखो तो यह कठिन नहीं था, और sports betting को automate करने जैसा एक व्यावहारिक उद्देश्य भी था। मेरा असली काम भी कुछ हद तक उसी के करीब था, और इससे 20s के उत्तरार्ध में प्रोग्रामिंग जल्दी सीखने में मदद मिली। लेकिन लगभग तुरंत ही चीन के sneaker bot operators और अजीब अंग्रेज़ी लिखने वाले, जो native English speakers नहीं लगते थे, ऐसे लोगों से requests की बाढ़ आ गई। मैंने कोड कानूनी धमकियों की वजह से नहीं हटाया, बल्कि इसलिए कि मैं customer support का काम या किसी और के अधीन काम नहीं करना चाहता था, और ज़्यादातर अनुरोध “तुम काम करो, मुनाफ़ा बाँट लेंगे” जैसे थे — कौन ऐसी पेशकश मानता है, यह समझना मुश्किल है। इंटरनेट हमेशा रहता है, इसलिए Cyberfed-Akamai 0.8~2.3 की नकल करने वाले उस कोड के कुछ हिस्से शायद अब भी कहीं घूम रहे हों। अगर mid-20s में प्रोग्रामिंग सीखकर 3 साल के भीतर डाला गया मेरा कोड चल गया, तो ऐसे उत्पादों के लिए मोटी रकम लेने वाली cybersecurity कंपनियों को शर्म आनी चाहिए। मैंने हाई स्कूल के दूसरे साल के बाद गणित भी नहीं पढ़ी, और ADHD की वजह से न वीडियो लंबे समय तक देख पाया, न लिखित सामग्री; बस GitHub जैसी सेवाओं पर चीज़ें कॉपी करके तब तक सीखता रहा जब तक वे काम न करने लगें। इस इंडस्ट्री में शायद बहुत से snake oil जैसे solutions बेचे जा रहे हैं
  • आप इंडस्ट्री के रुझानों को लगातार कैसे फॉलो करते रहते हैं, यह जानना चाहूँगा
• इस मुद्दे पर मेरी भावनाएँ मिश्रित हैं। bot prevention technology सुरक्षा शोध में लगातार बड़ा pain point बनती जा रही है, और इस क्षेत्र में काम करते हुए मुझे ऐसे सिस्टमों से जूझना पड़ता है
  threat actors Cloudflare जैसी सेवाओं का उपयोग करके malicious payloads तक पहुँच को रोकते हैं। यह उन ग्राहकों के लिए बड़ी समस्या है जो brand impersonation या credential phishing को खोजने और detect करने की कोशिश करते हैं, लेकिन Cloudflare बिल्कुल मदद नहीं करता और बस परवाह नहीं करता
  • सहमत हूँ। threat actors के लिए मुफ़्त Cloudflare accounts बनाना और 2 घंटे पहले बने domain के phishing site को 20 अरब डॉलर की कंपनी द्वारा समर्थित सुरक्षा परत के पीछे छिपा देना detection से बचना बहुत आसान बना देता है
    मज़ेदार बात यह है कि Akamai के पीछे phishing लगभग दिखती ही नहीं। हम भी इस क्षेत्र में काम करते हैं, इसलिए हमारा भी हित है कि हम आगे भी ऐसे खतरों का पता लगा सकें
  • आखिरकार, लगता है कि इस समस्या को हल करने के लिए हम किसी न किसी प्रकार के micropayment mechanism तक पहुँचेंगे
• “misfits” और “normal people” जैसी अभिव्यक्तियाँ अजीब हैं। लोग यह काम इसलिए करते हैं क्योंकि यह किसी उबाऊ corporate React website को बीसवीं बार बनाने से कहीं ज़्यादा दिलचस्प और मज़ेदार है
  यह मज़ेदार है क्योंकि आपको वास्तविक दुनिया की समस्याएँ हल करनी पड़ती हैं और कुछ करने के नए तरीके खोजने पड़ते हैं। exploit development भी ऐसा ही है। ऐसे लोग misfits नहीं हैं; वे बस सामान्य लोग हैं जो वही काम कर रहे हैं जिसके प्रति वे जुनूनी हैं। “जो लोग वह काम करते हैं जो मुझे पसंद नहीं, वे misfits हैं” — यह सोच ही पूरी तरह अजीब है
  • वह पूरा पैराग्राफ़ मज़ाक है। अंत में छोटा-सा wink इसी वजह से है
• bot prevention technology एक security threat होने के साथ-साथ privacy threat भी लगती है। क्योंकि अगर आप virtual machine इस्तेमाल करते हैं, तो साइटें आपकी पहुँच रोक देती हैं, port scan करती हैं, या कई तरह की fingerprinting करती हैं
  • नए आगंतुकों से CPU computation करवाने वाला algorithmic challenge तरीका बेहतर है
    प्रक्रिया स्पष्ट रहती है, privacy risk या अजीब चालबाज़ी नहीं होती, और अगर यह विफल भी हो तो कम-से-कम इंसान उसे देख और report कर सकता है। यह किसी अज्ञात खराबी जैसा लगने से बेहतर है
• इस पर उस समय भी चर्चा हुई थी: Scrape like the big boys - https://news.ycombinator.com/item?id=29117022 - नवंबर 2021, 189 टिप्पणियाँ
• “सभी वेबसाइटें बिना अनुमति के Android के rotation और speed data तक पहुँच सकती हैं”? यह तो सच में बेतुका है
• दिलचस्प। मैं अभी एक ऐसा प्रोजेक्ट बना रहा हूँ जिसमें कम आवृत्ति वाली स्क्रैपिंग की ज़रूरत है
  मैं सोच रहा था कि block होने की स्थिति को कैसे संभालूँ, और शायद एक सस्ता Android device यह कमी पूरी कर सकता है