क्या CAPTCHA हल करना कानूनी है? कानून असल में क्या कहता है

US, UK या EU के किसी भी कानून में CAPTCHA हल करने को अपराध नहीं बताया गया है। इसके ख़िलाफ़ कोई कानून नहीं है, कोई ऐसा मामला नहीं है जो इस पर टिका हो, और कोई रेगुलेटर इस काम को ख़ुद में ग़लत नहीं मानता। तो जब कोई पूछता है कि क्या CAPTCHA हल करना कानूनी है, तो ईमानदार जवाब यह है कि असली सवाल कहीं और है: आपने एक्सेस के साथ क्या किया, आपने पहले किसका समझौता स्वीकार किया, और आपने कौन-सा डेटा लिया। यह पोस्ट उन मामलों के ज़रिए बताती है कि यह रेखा असल में कहाँ खिंचती है, जिन्होंने इसे तय किया। इसे वकीलों ने नहीं, डेवलपर्स ने लिखा है, और यह कानूनी सलाह नहीं है।

छोटा जवाब, और यह छोटा क्यों है

CAPTCHA एक टेस्ट है, ताला नहीं। यह पूछता है कि विज़िटर इंसान है या नहीं, और जो भी इसे पास करता है उसे आगे जाने देता है। यह किसी को authenticate नहीं करता, कोई परमिशन नहीं देता, और किसी राज़ की रक्षा नहीं करता। इसे पास करने पर आपको ठीक वही मिलता है जो किसी भी अनाम विज़िटर के पास पहले से था।

यही अंतर वजह है कि कानूनी होने का सवाल बार-बार दूसरे सवालों में बदल जाता है। किसी कॉपीराइट किए गए काम की रक्षा करने वाले किसी तकनीकी उपाय को दरकिनार करना कई जगहों पर अपने आप में एक अपराध है। CAPTCHA वह नहीं है। किसी ऐसे खाते में घुसना जो आपका नहीं है, लगभग हर जगह एक अपराध है। CAPTCHA कोई लॉगिन भी नहीं है। दोनों को हटा दें तो जो बचता है वह साधारण ऑटोमेटेड ब्राउज़िंग है, जो कानूनी है, आम है, और यही तरीका है जिससे ज़्यादातर वेब इंडेक्स होता है।

सेवा की शर्तें एक अनुबंध हैं, कोई आपराधिक कानून नहीं

ज़्यादातर साइटें अपनी शर्तों में कहीं न कहीं ऑटोमेटेड एक्सेस को मना करती हैं। उस वादे को तोड़ना एक अनुबंध की समस्या है। इससे आप बैन हो सकते हैं, और साइट आप पर मुकदमा भी कर सकती है। यह अपने आप में आपको अपराधी नहीं बनाता, और United States में हुए दो फ़ैसलों ने इसे लगातार साफ़ किया है।

Van Buren v. United States, जिसका फ़ैसला 2021 में हुआ, ने Computer Fraud and Abuse Act की संकीर्ण व्याख्या की। स्वीकृत पहुँच से अधिक जाने का मतलब है सिस्टम के उन हिस्सों तक पहुँचना जो आपके लिए बंद हैं, न कि उस जानकारी का दुरुपयोग करना जिसे देखने की आपको पहले से अनुमति थी। डेटा इस्तेमाल करने के तरीके से जुड़ी किसी नीति को तोड़ना हैकिंग जैसा नहीं है।

hiQ Labs बनाम LinkedIn ने भी Ninth Circuit में वही रुख अपनाया, जिसमें कहा गया कि कोई साइट पूरी दुनिया के लिए जो डेटा प्रकाशित करती है उसे स्क्रैप करना अनधिकृत पहुँच होने की संभावना नहीं है, क्योंकि कुछ भी कभी प्रतिबंधित नहीं था। यह मामला कहानी का सावधानी वाला पहलू भी है: hiQ कंप्यूटर अपराध वाली दलील जीत गई लेकिन बाद में अनुबंध के उल्लंघन के मामले में हार गई, फिर एक निषेधाज्ञा के तहत समझौता किया। स्क्रैपिंग कोई अपराध नहीं थी। जिस समझौते को उसने तोड़ा उसमें अब भी दम था।

तो असली कसौटी यह नहीं है कि कोई चुनौती रास्ते में खड़ी थी या नहीं। असली सवाल यह है कि क्या कॉन्टेंट सार्वजनिक था, और क्या आपने उसे लेने से पहले किसी समझौते को स्वीकार किया था। हमारी अपनी सेवा की शर्तें भी दूसरी तरफ से यही बात कहती हैं: यह टूल कानूनी उपयोग के लिए लाइसेंस प्राप्त है, और टारगेट साइट की ज़िम्मेदारी उसे ऑटोमेट करने वाले व्यक्ति पर होती है।

जो रेखा मायने रखती है: सार्वजनिक पेज या गेटेड खाता

एक ही सवाल लगभग हर सुरक्षित मामले को हर जोखिम भरे मामले से अलग करता है। क्या CAPTCHA किसी ऐसी चीज़ के सामने खड़ा है जिसे कोई भी देख सकता है, या यह किसी खाते के सामने खड़ा है?

स्थिति	चैलेंज किसकी रक्षा करता है	जोखिम प्रोफ़ाइल
एक anti-bot जाँच के पीछे मौजूद एक सार्वजनिक प्रोडक्ट लिस्टिंग	कुछ भी निजी नहीं, हर कोई आर-पार निकल जाता है	ज़्यादा से ज़्यादा अनुबंध का जोखिम
आपका अपना staging या टेस्ट environment	आपका सिस्टम, आपकी अनुमति	कोई नहीं
एक फॉर्म जो आपका अपना है, जिसे एक end-to-end टेस्ट चलाता है	फिर वही, आपका सिस्टम	कोई नहीं
लॉगिन, पेवॉल या एक members area जिसके लिए आपके पास कोई खाता नहीं है	एक authentication सीमा	संभावित रूप से आपराधिक
थोक में खाता बनाना या credential stuffing	पहचान और दूसरे लोगों का डेटा	ज़्यादातर जगहों पर आपराधिक
queue की इजाज़त से तेज़ रफ़्तार में इवेंट टिकट ख़रीदना	US में एक federal कानून	स्पष्ट रूप से ग़ैरकानूनी

आख़िरी पंक्ति का नाम लेना ज़रूरी है। 2016 का Better Online Ticket Sales Act के तहत अमेरिका में टिकट बेचने वाली किसी साइट पर नियमों से ज़्यादा टिकट ख़रीदने के लिए सुरक्षा उपाय या access control सिस्टम को दरकिनार करना ग़ैरकानूनी है। बॉट-चेक को हराने से जुड़े कानून के यह सबसे नज़दीक है, इसे जानबूझकर संकीर्ण रखा गया है, और यह तकनीक पर नहीं बल्कि टिकटिंग पर लागू होता है।

United States के बाहर

आकार एक जैसा रहता है, बस शब्दावली बदल जाती है। UK का Computer Misuse Act 1990 किसी कंप्यूटर तक अनधिकृत पहुँच पर टिका है, जो फिर से चैलेंज की बजाय खातों की ओर इशारा करता है। EU के सदस्य देश information systems पर हमलों से जुड़ी निर्देश को उसी मूल विचार के साथ लागू करते हैं। कहीं भी CAPTCHA निर्णायक तथ्य के रूप में सामने नहीं आता।

जो चीज़ इन सबमें एक जैसी चलती है वह है data protection। अगर आपके इकट्ठा किए गए पेजों में personal data है, तो आपने इसे चाहे जैसे भी हासिल किया हो, GDPR उस पर लागू होता है, और कोई भी anti-bot जाँच कभी भी इसे कानूनी या ग़ैरकानूनी बनाने वाली चीज़ नहीं थी। EU और UK में database rights एक दूसरा, अलग सवाल जोड़ देते हैं, कि किसी संरचित संग्रह के बड़े हिस्से निकालना। दोनों को उनके सामने खड़ी चुनौती से कहीं ज़्यादा ध्यान देने लायक हैं।

वे इस्तेमाल जिन पर कोई बहस नहीं करता

बहुत सारा CAPTCHA हल करना पूरी तरह निर्विवाद है, और यही हमारे ज़्यादातर यूज़र्स करते हैं:

• अपने ही फॉर्म को टेस्ट करना, क्योंकि एक end-to-end सूट जो आपके अपने साइनअप पेज को पार नहीं कर सकता, वह एक ऐसा सूट है जिसमें एक छेद है
• आपके द्वारा चलाई जाने वाली किसी साइट की निगरानी, जहाँ एक synthetic जाँच को वही सफ़र पूरा करना होता है जो एक ग्राहक करता है
• एक्सेसिबिलिटी, जहाँ एक इमेज या ऑडियो चैलेंज एक टेस्ट की बजाय एक रुकावट है, और इसे अपनी ओर से हल करना कोई ख़ामी नहीं बल्कि वह उपाय है जो फॉर्मेट मजबूर करता है
• अधिकृत सुरक्षा काम, जहाँ एक scope दस्तावेज़ पहले से बता देता है कि आप किन सिस्टम तक पहुँच सकते हैं
• सार्वजनिक सामग्री पर रिसर्च और आर्काइविंग, प्रकाशक द्वारा तय की गई किसी भी शर्त पर

एक्सेसिबिलिटी वाली यह बात केवल कहावत नहीं है। W3C ने दो दशकों के रिविज़न में इस समस्या को दर्ज किया है, अपने CAPTCHA दुर्गमता पर कार्यकारी समूह नोटमें, और ऑडियो विकल्पों ने कभी सबके लिए यह अंतर पूरी तरह नहीं पाटा।

ये भी वे मामले हैं जहाँ एक अनमीटर्ड सॉल्वर कानूनी स्थिति को नहीं, बल्कि इंजीनियरिंग को बदलता है: कोई टेस्ट सूट जो दोबारा कोशिश करता है, वह तभी उचित है जब दोबारा कोशिश करना मुफ़्त हो। अलग-अलग तरीकों के बीच व्यावहारिक ट्रेड-ऑफ़ यहाँ दिए गए हैं: हमारी कैप्चा-हल करने वाली सेवाओं की तुलना.

जहाँ इसे लोकल चलाना वाक़ई आपकी स्थिति बदल देता है

यह वह हिस्सा है जो आपराधिक सवाल नहीं बल्कि compliance का सवाल है, और यह अक्सर छूट जाता है।

एक क्लाउड सॉल्विंग API आपका डेटा प्राप्त करके काम करता है। चैलेंज के हिसाब से इसका मतलब हो सकता है पेज URL, sitekey, फॉर्म का एक स्क्रीनशॉट, user agent और कभी-कभी session से जुड़ी सामग्री। आप इसे एक तीसरे पक्ष को भेज रहे हैं, आमतौर पर किसी दूसरे देश में, और अक्सर इसे एक इंसानी वर्कर देखता है। GDPR के तहत यह एक processor संबंध है और काफ़ी संभावना है कि यह एक अंतरराष्ट्रीय ट्रांसफ़र भी हो, और इसके लिए एक अनुबंध, एक कानूनी आधार और एक रिकॉर्ड चाहिए। इंसानों से चलने वाले सॉल्विंग फ़ार्म काम करने वाले लोगों को लेकर एक दूसरा सवाल भी साथ लाते हैं।

आपकी अपनी मशीन पर चलने वाले एक सॉल्वर में यह कुछ भी नहीं है। पेज का डेटा कभी आपके इन्फ़्रास्ट्रक्चर से बाहर नहीं जाता, इसलिए न कोई ट्रांसफ़र होता है, न कोई processor, और न ही data map में बताने के लिए कुछ बचता है। यह Server mode पर भी लागू होता है: सॉल्वर को अपने नेटवर्क या public IP पर पॉइंट करना ताकि कोई VPS या CI रनर इसे पहुँच सके, बस प्रोसेस को आपके ही किसी दूसरे बॉक्स पर ले जाता है, और कनेक्शन सेटिंग्स दोनों मोड को कवर करती हैं। यह अब भी आपका ही हार्डवेयर है, इसलिए डेटा अब भी कभी आपके दायरे से बाहर नहीं जाता।

अक्सर पूछे जाने वाले सवाल

क्या किसी साइट की सेवा की शर्तें तोड़ने से मैं अपराधी बन जाता हूँ?

आम तौर पर नहीं, कम से कम Van Buren के बाद United States में तो नहीं। यह आपको एक ऐसा पक्ष बना देता है जिसने एक समझौता तोड़ा, जिससे आप पर आरोप लगने के बजाय बैन होने या मुकदमा झेलने का ख़तरा रहता है। यह अब भी एक असली जोखिम है और असल में ज़्यादातर स्क्रैपिंग विवाद इसी पर टिके होते हैं, इसलिए किसी साइट के ख़िलाफ़ कुछ बनाने से पहले शर्तें पढ़ें, बाद में नहीं।

क्या अपनी ही साइट पर CAPTCHA हल करना जायज़ है?

हाँ, बिना किसी शर्त के। सिस्टम आपका है, नियम आप तय करते हैं, और एक ऑटोमेटेड टेस्ट जो आपके अपने साइनअप फ़्लो को पूरा करता है वह किसी भी दूसरे टेस्ट से अलग किस्म का नहीं है। अगर widget आपका है, तो staging में एक feature flag से उसे बंद कर देना आमतौर पर और भी आसान होता है। इसे तभी हल करें जब staging को production जैसा बिल्कुल एक जैसा दिखाना ज़रूरी हो, या जब चैलेंज वाला रास्ता ख़ुद टेस्ट के अंदर हो।

अगर रास्ते में कोई चैलेंज है तो क्या सार्वजनिक डेटा स्क्रैप करना कानूनी है?

यह चैलेंज तय नहीं करता। अदालतों ने देखा है कि डेटा सार्वजनिक था या नहीं और आपने शर्तें स्वीकार की थीं या नहीं, और प्रमुख मामलों में anti-bot जाँच निर्णायक तथ्य नहीं रही है। Personal data अलग से GDPR को इसमें ले आता है, और कॉपीराइट या database rights ख़ुद कॉन्टेंट पर लागू हो सकते हैं। जवाब देने के लिए यही तीन सवाल हैं।

क्या आप यह निगरानी करते हैं कि ग्राहक क्या हल कर रहे हैं?

नहीं कर सकते, और यह सीधे डिज़ाइन का नतीजा है। सॉल्वर आपकी मशीन पर चलता है और कुछ भी वापस रिपोर्ट नहीं करता, इसलिए यहाँ जाँचने के लिए jobs की कोई queue ही नहीं है। इसके बजाय सीमा लाइसेंस तय करता है। हमारे FAQ में बताया गया है कि सॉफ़्टवेयर क्या भेजता है और क्या कहीं नहीं भेजता।

संक्षेप में

कोई कानून इस काम का नाम नहीं लेता। इसके बजाय तीन सवाल पूछें: क्या कॉन्टेंट सार्वजनिक था, क्या आपने कोई समझौता स्वीकार किया, और क्या आपने जो इकट्ठा किया उसमें personal data है। यही नतीजा तय करते हैं, और रास्ते में खड़ी कोई चुनौती इनमें से किसी को नहीं बदलती।

जहाँ तकनीकी चुनाव सचमुच मायने रखता है वह है disclosure, क्योंकि एक क्लाउड सेवा आपका डेटा पाने वाला एक तीसरा पक्ष होती है, और आपका अपना लोकल captcha सॉल्वर नहीं है। अगर आप सार्वजनिक पेजों के ख़िलाफ़ ऑटोमेशन बना रहे हैं, हमारा वेब स्क्रैपिंग पेज इसमें वे पैटर्न और शिष्टाचार बताए गए हैं जो आपको इसके सही पक्ष पर बनाए रखते हैं। असली पैसे या असली जोखिम वाली किसी भी चीज़ के लिए, अपने क्षेत्राधिकार के किसी वकील से पूछें। यह पोस्ट एक नक़्शा है, सलाह नहीं।