- एक दृष्टिबाधित यूज़र ने Brave में hCaptcha accessibility account cookie सेट न होने की समस्या पूछी, लेकिन support team ने कहा कि accessibility का यह उपयोग supported नहीं है, और account deletion व दोबारा signup block करने की सूचना दी
- उस समय hCaptcha audio CAPTCHA के बजाय एक special account देता था, जो cookie के जरिए CAPTCHA challenge को bypass करता था; बाद में update में text CAPTCHA option जुड़ने की correction जोड़ी गई
- Firefox और Chromium में account काम करता था, लेकिन Brave में करीब 1 साल तक cookie सेट नहीं हुई, और JavaScript console में set cookie endpoint ने 401 Unauthorized लौटाया
- support team ने यह मानकर कि user दृष्टिबाधित नहीं है, accessibility account का उपयोग रोक दिया, और user के यह बताने के बाद भी कि वह वास्तव में दृष्टिबाधित है, block बरकरार रखा
- accessibility को अलग bypass workaround पर छोड़ने वाला system, जैसे ही वह workaround मनमाने ढंग से रोका जाता है, वास्तविक users को service इस्तेमाल करने से बाहर कर सकता है
hCaptcha का accessibility bypass तरीका
- hCaptcha एक CAPTCHA service है, जिसमें user checkbox दबाने के बाद घर जैसी किसी खास चीज़ वाली images चुनता है
- उस समय hCaptcha दृष्टिबाधित लोगों के लिए audio CAPTCHA नहीं देता था, और इसका कारण यह बताया गया था कि इससे bots के लिए पास होना आसान हो जाता है
- इसके बजाय दृष्टिबाधित लोगों को special account दिया जाता था, जिससे cookie सेट होती थी और CAPTCHA challenge से गुजरना नहीं पड़ता था
- बाद में hCaptcha में text CAPTCHA option आने की update जोड़ी गई, लेकिन बताया गया कि लेख की मूल आपत्ति अब भी valid है
सिर्फ Brave में cookie सेट नहीं हुई
- user अपना मुख्य browser Brave इस्तेमाल करता था, और करीब 1 साल तक hCaptcha accessibility account Brave में cookie सेट नहीं कर पाया
- वही account Firefox, Chromium जैसे दूसरे browsers में ठीक से काम करता था
- निर्देशों के अनुसार third-party cookies allow करने जैसे basic उपाय check किए गए, लेकिन Brave में समस्या जारी रही, और error message में कहा गया कि समस्या बनी रहे तो support team को email करें
support request शक में बदल गई
- user ने आखिरकार hCaptcha support team को email भेजा, और support team ने basic troubleshooting steps बताए
- समस्या को narrow down करने के लिए JavaScript console देखने पर पता चला कि Brave में hCaptcha के set cookie endpoint call से
401 unauthorizedलौटता दिख रहा है, और user ने यह बात बताई - user ने technical support में मदद के लिए यह जानकारी दी थी, लेकिन उसे लगा कि शायद इसी जानकारी से support team को शक हुआ
accessibility account deletion और re-signup block
- support प्रतिनिधि से बातचीत के दौरान दूसरे support प्रतिनिधि ने इस आशय का जवाब भेजा
- इस तरह का उपयोग supported नहीं है
- accessibility pass के लिए credit नहीं मिलता
- इस तरह इस्तेमाल किए जाने वाले सभी accounts hCaptcha से delete कर दिए जाते हैं
- अगर user accessibility account के लिए फिर से signup करने की कोशिश करेगा, तो उसे block कर दिया जाएगा
- user confused था, क्योंकि उसने कोई unauthorized काम नहीं किया था, बस Brave में इसे काम करवाने की कोशिश की थी
- इसके बाद support team ने सफाई दी कि user दृष्टिबाधित नहीं है, इसलिए उसे accessibility account इस्तेमाल नहीं करना चाहिए
वास्तव में दृष्टिबाधित होने की आपत्ति के बाद
- user ने बताया कि वह वास्तव में दृष्टिबाधित है और block हटाने का अनुरोध किया, लेकिन support team ने account block बनाए रखने वाला एक templated जवाब भेजा
- account सचमुच blocked था, और user ने कहा कि hCaptcha पास करने के लिए अब उसे service terms तोड़कर automated solver program इस्तेमाल करने की स्थिति में डाल दिया गया है
- यह चेतावनी बन गई कि जो company जानबूझकर inaccessible product देती है, उस पर अलग accessibility bypass workaround को भरोसेमंद तरीके से बनाए रखने का भरोसा नहीं करना चाहिए
- web operators से आग्रह किया गया कि अगर वे hCaptcha इस्तेमाल करते हैं तो इस अनुभव पर विचार करें, और यह भी जोड़ा कि Cloudflare शायद पहले से अपना खुद का system इस्तेमाल कर रहा है
1 टिप्पणियां
Hacker News की रायें
मैं भी दृष्टिबाधित हूं, और hCaptcha सबसे खराब है
बेवकूफ कुकी expire हो जाती है, इसलिए hCaptcha से सामना होने पर लगभग हर बार ईमेल लेकर कुकी सेट करने की प्रक्रिया से गुजरना पड़ता है
कई डिवाइस और ब्राउज़र इस्तेमाल करने पर यह खास तौर पर भयावह user experience है, और मुझे लगता है बाकी लोग बस हार मान लेंगे
bots इसे दृष्टिबाधित लोगों से ज्यादा आसानी से हल कर सकते हैं, या तीसरी दुनिया के मजदूरों को लगभग मुफ्त में outsource कर सकते हैं। उदाहरण: Anticaptcha [0]:
यह बेहद छोटी-छोटी images दिखाता है जिन्हें एक-दूसरे से अलग पहचानना लगभग मुश्किल होता है, और इसने reCaptcha से भी कहीं ज्यादा खराब बनने में सफलता पा ली है—यह अपने-आप में कमाल है
Google CAPTCHA ज्यादातर बार 3 मिनट से ज्यादा सही हल करने के बाद भी मुझे अंतहीन loop में भेज देता है और हमेशा fail कर देता है, जबकि hCaptcha 1–3 सही हल करने पर पास कर देता है
session cookies इस्तेमाल करता हूं, लेकिन उनकी बेवकूफ CAPTCHA को bypass करने के लिए किसी कंपनी को मेरे system में cookie डालने की अनुमति देने की कोई वजह नहीं है
दूसरे शब्दों में, मुझे उन्हें कुछ भी disclose करने की जरूरत नहीं होनी चाहिए। उनकी नजर में मैं AI हूं तो भी कोई फर्क नहीं पड़ना चाहिए
सिर्फ title देखने पर समस्या असल से कहीं कम गंभीर लगती है
लेख के मुताबिक, लेखक सचमुच दृष्टिबाधित था, फिर भी hCaptcha ने बिना आधार उसे झूठा बताते हुए कई बार बदतमीजी से आरोप लगाया
यह बचाव नहीं, explanation है; लेकिन साथ ही यह भी दिखाता है कि “दृष्टिबाधित लोगों को CAPTCHA bypass का साधन न दो, पर ‘वास्तविक’ दृष्टिबाधित लोगों को ही exception देकर ADA पास कर लो” वाला विचार पूरी तरह असंभव और unscalable क्यों है
Google, Facebook, Amazon के पैमाने पर भी “कौन ‘वास्तविक’ दृष्टिबाधित है” यह तय करने वाले system का load संभालना मुश्किल होगा। यह तो छोड़ ही दें कि “दृष्टिबाधिता” को ठीक-ठीक किस तरह define किया जाए
यह ऐसी चीज नहीं थी जिसे deploy करने के बाद समस्या बनना चाहिए था; proposal meeting में 5 मिनट review करके इसे design stage तक पहुंचने से पहले ही रोक देना चाहिए था
अगर अत्यधिक adversarial attacks वाले environment में “कौन दृष्टिबाधित है” जैसी विशेषता को perfectly पहचानने वाला system है, तो वह CAPTCHA system खुद से कहीं ज्यादा मूल्यवान चीज होगा
यह विचार तभी चल सकता है जब आपके पास CAPTCHA जिस समस्या को हल करना चाहता है, उससे भी मजबूत समाधान पहले से हो; इसलिए logically यह बुनियाद से ही टिकता नहीं है
कुछ CAPTCHA धीरे-धीरे भेदभावपूर्ण होते जा रहे हैं। हर कोई पश्चिमी देशों में नहीं रहता और CAPTCHA जिन objects की मांग करता है, उन्हें पहचान नहीं सकता
हाल ही में मैंने ऐसा भी देखा जिसमें screen पर conoids की संख्या के बराबर shapes चुनने को कहा गया था; अगर सड़क पर लोगों से पूछा जाए कि conoid क्या है, तो काफी लोग खाली नजरों से देखेंगे
फिर भी अब यह पता चल गया कि कुछ लोग उन markings को crosswalk भी कहते हैं
शायद आपका मतलब था “हर कोई अमेरिका में नहीं रहता”
fire hydrant, yellow taxi, yellow bus भी बिल्कुल समझ नहीं आते
हालांकि CAPTCHA जैसी चीजों के जरिए अमेरिकी सांस्कृतिक साम्राज्यवाद के कारण पूरी दुनिया को अमेरिकी सांस्कृतिक मानक जानने ही पड़ते हैं, इसलिए असल में मुझे पता तो है
आज भी नहीं पता कि object का कितना हिस्सा select करना है, और traffic light क्या है यह भी अस्पष्ट है। pole शामिल है या नहीं, पता नहीं
motorcycles भी काफी मुश्किल हैं, और एक बार सिर्फ सीढ़ियों से भरी photo आई थी, लगता है मैंने करीब 15 boxes mark किए थे
Google dictionary इसे zoology में “लगभग cone-shaped” कहती है, और Wikipedia panel geometry में कुछ शर्तें पूरी करने वाली ruled surface बताता है, लेकिन diagram भी बिल्कुल intuitive नहीं है
Merriam-Webster search result कहता है “cone-shaped structure, खासकर किसी organism के सामने के सिरे पर truncated cone-shaped hollow organelle”
यह बिल्कुल related नहीं लगता, इसलिए images tab खोला तो सिर्फ जटिल Mathematica-style graphs दिखे, जो cone जैसे खास नहीं लगते
HN comments में बाकी लोग भी उतने ही अनजान लग रहे हैं
क्या बता सकते हैं कि आपने screen पर क्या देखा था? CAPTCHA ने किसे conoid माना था? क्या traffic cone जैसी कोई चीज?
Google से competition करते समय पहला सबक यह होना चाहिए कि “users को Google से ज्यादा ignore मत करो।” वरना लोग बस Google इस्तेमाल करेंगे
business model ऐसा हो तो भी “कभी Google नहीं इस्तेमाल करने वाले” थोड़े-से लोगों की goodwill पर निर्भर रहना success path नहीं है
जब hCaptcha अपनी reputation खराब कर रहा होगा, बाकी दुनिया reCaptcha ही इस्तेमाल करती रहेगी और hCaptcha के अस्तित्व में कोई दिलचस्पी नहीं लेगी
और हां, spelling “intensional” नहीं, intentional है। इसे “intent” + “-tion” + “-al” की तरह सोचना चाहिए, “in-” + “tension” + “-al” नहीं
लेखक असल में दृष्टिबाधित होने के लिए बहुत ज्यादा smart निकला
उन्होंने शायद सोचा होगा, दृष्टिबाधित व्यक्ति JavaScript console को “देख” कैसे सकता है?
बेशक, “screen reader से JavaScript console की contents पढ़वाई” कहना थोड़ा लंबा तो है
मेरे साथ भी ऐसा बहुत बार होता है। मैं ऐसी जगह पर हूं जहां मुझे “नहीं होना चाहिए” या ऐसा काम कर रहा हूं जो मुझे “नहीं करना चाहिए”, इसलिए कहा जाता है कि मैं दृष्टिबाधित नहीं हूं
CAPTCHA प्रयोग अब जल्द खत्म हो जाना चाहिए। यह काम नहीं कर पाया।
फोन नंबर verification भी अच्छा नहीं है, लेकिन कम से कम वह spam की लागत कुछ हद तक बढ़ा देता है। CAPTCHA ऐसा नहीं करता। लगभग सभी turnkey CAPTCHA services कुछ पैसों में solve हो जाती हैं।
spam और malicious traffic की समस्या हल करना कठिन है, और डर है कि बात आखिरकार तीन संभावनाओं तक सिमट जाएगी।
पहली, users की anonymity छोड़ना। असली पहचान को पर्याप्त रूप से verify कर लिया जाए तो malicious व्यक्तियों को स्थायी रूप से block किया जा सकता है और bots को काफी प्रभावी ढंग से filter किया जा सकता है, लेकिन online anonymity खत्म हो जाएगी। मेरे हिसाब से यह सचमुच असहनीय है।
दूसरी, platform को बंद करना। Web Environment Integrity और Private Access Tokens जैसे approaches web platform को बंद करने का रास्ता बनाते हैं। अधिकांश web users Secure Boot वाले devices पर Google Chrome या Safari इस्तेमाल करते हैं, इसलिए पूरे boot chain को attest किया जा सकता है। समय के साथ इसे लागू कर सकने वाले users की संख्या बढ़ेगी।
ऐसे भविष्य में web meaningful तरीके से open नहीं रह जाएगा। Alternatives धीरे-धीरे कम उपयोगी होते जाएंगे; उदाहरण के लिए machine learning अगर artificial general intelligence तक न भी पहुँचे, तब भी सामने आने वाले हर CAPTCHA को overwhelm कर देगी, इसलिए इस तरीके के बिना websites में प्रवेश करना मुश्किल होने की संभावना बढ़ जाएगी।
तीसरी, network operators की जवाबदेही बढ़ाना। अच्छा लगे या नहीं, internet को कम oversight या transparency वाले gray-area operators से काफी फायदा मिला है। लेकिन malicious traffic हटाने का एक और तरीका network operators पर अधिक जिम्मेदारी डालना और सहयोग न करने वाले businesses को internet से काट देना है। यह भी शायद अच्छा नहीं होगा और power abuse को बढ़ावा देगा।
फिर भी यह पेचीदा है। और क्या किया जा सकता है? malicious traffic के incentives घटाने की कोशिश करें तो services द्वारा दी जाने वाली value घटाए बिना यह मुश्किल है, और obfuscation से malicious traffic को कठिन बनाया जा सकता है, लेकिन बहुत दृढ़ विरोधी को रोकना कठिन है।
किसी भी तरह, open web का युग असल में खत्म हो चुका लगता है। open web मौजूद रह सकता है, लेकिन संभावना है कि एक नए और कहीं ज्यादा बंद web की छाया में दब जाएगा।
हमारी website पर CAPTCHA न हो तो bots रोज दर्जनों forms भर देते हैं। CAPTCHA लगाने पर यह 0 हो जाता है।
CAPTCHA तोड़ने की लागत सस्ती जरूर है, लेकिन हमारे site पर लगता है कोई उस छोटे barrier को पार करने की कोशिश नहीं करता।
CAPTCHA तभी उपयोगी है जब उसे solve करने में लागत लगे। यह request किसी real इंसान, या कम से कम real इंसान के 1 अरबवें हिस्से से तो बड़े entity की cost signal बनती है। यानी यह पूरी तरह automated spam system नहीं है।
postal service की भी लागत होती है। डाक से कुछ भेजना हो तो हर किसी को stamp खरीदना पड़ता है। transport cost traffic को regulate करने और spam रोकने का “natural” तरीका है।
network architecture और cryptocurrency के combination से हर sending attempt या login attempt पर transport cost लगाई जा सकती है। spam email या login guess की एक कोशिश पर सिर्फ 1 cent भी लगे तो अधिकांश पूरी तरह automated spam के लिए यह prohibitive cost बन जाती है।
cryptocurrency वाला तत्व stamp जैसी cash-like transactions को संभव बनाने के साथ-साथ personal wallet access की anonymity बचाने के लिए है।
social media ने USENET को मार दिया, और email ने filtering के जरिए spam समस्या को manage किया है।
बहुत से users prize जीतने के मौके के लिए कुछ भी click कर देंगे, और उसी प्रक्रिया में अपनी identity को spam में इस्तेमाल होने की मंजूरी भी दे देंगे।
Web Environment Integrity या Private Access Tokens जैसी चीजें कभी ठीक से काम नहीं करेंगी। क्योंकि spammers को किसी लोकप्रिय device के सिर्फ एक model को crack करना होगा।
ऐसी चीजें propose करने वाले या तो scammers हैं, या platform companies जो इसे lock-in effect के लिए इस्तेमाल करना चाहती हैं। spammers system तोड़ने में resources लगाते हैं, लेकिन आम users inconvenience बर्दाश्त नहीं करते, इसलिए अंत में competitors और interoperability को block कर दिया जाता है।
network operator responsibility पहले से काफी हद तक हो रही है। खराब reputation वाली IP ranges block कर दी जाती हैं। लेकिन जब कई ISPs में फैले users के botnets बनते हैं, तो कुछ ISPs की response करने की इच्छा अलग होती है, response करें भी तो तुरंत handle नहीं कर सकते, और कुछ जिन्हें फर्क नहीं पड़ता वे ऐसे jurisdictions में होते हैं जिन्हें control नहीं किया जा सकता, लेकिन block करने के लिए वे बहुत बड़े होते हैं।
सबसे अच्छा solution शायद account बनाते समय थोड़ा सा पैसा, cryptocurrency, या proof-of-work में से कुछ देना अनिवार्य करना होगा। सामान्य users को लंबे समय तक रखने के लिए बस कुछ accounts चाहिए होते हैं, लेकिन spammers को ऐसे bulk accounts चाहिए जो लगभग तुरंत block हो जाएंगे, इसलिए functioning system के लिए जरूरी asymmetric cost structure बनता है।
तब भी recognition software से आगे रहने के लिए challenges को लगातार कठिन बनाना पड़ता था।
अब यह उस क्षेत्र में चला गया है जहाँ machines के लिए इसे solve करना इंसानों से आसान है, इसलिए अपने मूल purpose के लिए यह बेकार हो गया है।
दुर्भाग्य से अधिकांश accessibility options सच में इस्तेमाल कराने के लिए बनाए गए नहीं लगते।
अगर government या बड़ी company हो, तो accessibility basic requirements में आती है। उन्हें कहना पड़ता है, “हाँ, हम accessible हैं,” और ऐसा न हो तो public opinion में शोर मचता है।
इसलिए vendor list से उन लोगों को हटा दिया जाता है जो accessibility देने की बात नहीं कहते। vendors भी यह जानते हैं और जरूर कहते हैं कि वे इसे provide करते हैं।
लेकिन यह ठीक से बनाना कठिन feature है, और user base के छोटे हिस्से से ही संबंधित है। हर disability type के लिए जरूरी support भी अलग होता है। development team में कोई भी actual requirements को ठीक से नहीं समझता।
जिन लोगों को accessibility चाहिए वे कहीं और चले जाते हैं, या शिकायत करते हुए किसी तरह काम चला लेते हैं। दोनों में से कोई भी metrics dashboard में नहीं दिखता।
यह combination shelfware को बढ़ावा देता है। यानी ऐसी चीज जिसे खरीदकर कहीं shelf पर रख दिया जाता है, लेकिन असल में इस्तेमाल नहीं होती।
अगर मैंने सही समझा, तो hCaptcha द्वारा बनाई गई accessibility समस्या इस दृष्टिहीन व्यक्ति की कई websites तक access रोक रही है?
hCaptcha के कई customers के लिए ADA के लिहाज से समस्या पैदा नहीं हो सकती क्या?
अगर लेखक lawsuit आगे बढ़ाना चाहते हैं, तो यह लगभग साफ जीत वाला मामला लगता है।
terms of service ADA liability से बचा नहीं सकते।
समझ नहीं आता कि CAPTCHA अब भी क्यों मौजूद है
अगर कोई कुछ scrape करना या automation बनाना चाहता है, तो उसे बस करने क्यों नहीं देते? आखिरकार उन्हें login करने वाले system का सम्मान करना ही चाहिए
इसका privacy फायदा भी है कि visitors को दर्जनों या उससे ज्यादा data sub-processors वाली CAPTCHA service के सामने expose नहीं करना पड़ता
bots दूसरे लोगों के email addresses से हजारों fake accounts बना रहे थे, और हमने जो email verification mails भेजे, उन्हें recipients ने spam के रूप में report कर दिया क्योंकि उन्होंने कभी signup किया ही नहीं था
आखिर में बहुत ज्यादा spam reports के कारण email provider ने हमारा account suspend कर दिया
मैंने लगाया था, और कुछ ही दिनों में bots ने उसी form से spam भेजना शुरू कर दिया
मैंने “2+3=” जैसा hardcoded छोटा-सा CAPTCHA लगाया था, लेकिन scale बड़ा होता तो उसे संभालना नामुमकिन होता
private message spam या free tier abuse के लिए automated account creation के बारे में भी सोचना चाहिए
automation या scraping इससे बचकर निकल जाते हैं
login form से CAPTCHA हटाकर देखिए, तो पता चलेगा कि रोज सैकड़ों ऐसे users पकड़े जाते हैं जिन्हें बिना किसी वजह “कृपया अपना email address verify करें” वाला mail भेजना पड़ता
“उन्हें भी login करने वाले system का सम्मान करना चाहिए” यह विश्वास अच्छा है, लेकिन internet पर कुछ चलाकर देखेंगे तो पता चलेगा कि लोग, जानबूझकर या अनजाने में, system गिरने तक उसे पीटते रहते हैं
ये bots CSS support नहीं करते, इसलिए hidden form fields के साथ मिलाने पर यह और बेहतर काम करता है
हालांकि targeted attack के मामले में, यह legitimate users को ही परेशान करते हुए bot blocking rate को 95% से 99% तक बढ़ाने भर का काम करता है