बस मुझे कुछ अंक दर्ज करने दो
(gendignoux.com/blog)- स्विस सरकारी लॉगिन सिस्टम AGOV के 6-अंकीय ईमेल verification input में French AZERTY keyboard पर number input काम नहीं कर रहा था, जिससे account registration ही रुक गया
- input field का JavaScript key input को intercept करके verification code को अलग variable में store कर रहा था और Shift key को ignore कर रहा था, जिससे AZERTY layout पर Shift से टाइप होने वाले numbers practically block हो गए
- Firefox·Chromium·Chrome·Safari और Linux·macOS के कई combinations में वही error आया, लेकिन QWERTY keyboard पर सब सामान्य चला, इसलिए वजह browser या operating system नहीं बल्कि keyboard layout issue निकली
- official support भी उसी email verification से गुजरने के बाद ही इस्तेमाल किया जा सकता था, और email या phone जैसे alternative माध्यम नहीं थे, इसलिए लॉगिन न कर पाने वाले users लॉगिन bug report भी नहीं कर सके
- native input field की जगह जटिल key-handling logic इस्तेमाल करने और product व support channel को एक ही authentication flow से बांधने पर accessibility और failure response दोनों टूट जाते हैं, इसलिए सरल DOM-आधारित input और स्वतंत्र support channel ज़रूरी हैं
डिजिटल पहचान इन्फ्रास्ट्रक्चर बन चुका AGOV
- डिजिटल पहचान हाल में web की बड़ी बहसों में उभरी है और इसके साथ कई interdependencies और controversies जुड़ी हैं
- age verification laws का online anonymity पर असर
- UK में Wikipedia को user identity verify करनी पड़ सकती है
- digital identity wallet के अनिवार्य platform के रूप में official iOS और Android पर निर्भरता की समस्या
- International Criminal Court के judge होने के कारण अमेरिका में digital accounts रद्द किए जाने का मामला
- स्विस सरकारी लॉगिन सिस्टम AGOV 2024 से चालू है और accounts की संख्या 16 लाख तक पहुँच चुकी है
- इसे unemployment insurance इस्तेमाल करने और अनिवार्य tax filing सहित कई सरकारी कामों के login माध्यम के रूप में बढ़ाया जा रहा है
- Zurich canton में citizenship application तक पहुँचने का यही एकमात्र login माध्यम है
ईमेल verification चरण पर अटका registration
- AGOV registration process email address submit करने के बाद 6-digit verification code दर्ज करने से शुरू होती है
- verification code UI में हर digit के लिए कुल 6 input boxes हैं
- number टाइप करने पर भी focus अगले box में नहीं जाता
- current box में digits जमा होते रहते हैं और वह लाल error state में बदल जाता है
- एक-एक digit manually अगले box में जाकर भरने पर भी आखिर में
field requirederror आता है
- developer tools से सीधे DOM values बदलने की कोशिश की गई, लेकिन कोई स्पष्ट form value नहीं दिखी और web console में भी कोई error log नहीं हुआ
- दूसरे email address या
test@example.comजैसे fake address इस्तेमाल करने पर भी वही नतीजा मिलाexample.comRFC 6761 के अनुसार reserved domain है
browser और operating system की संभावना खारिज
- शुरुआत में लगा कि शायद Firefox और Linux का combination supported नहीं है या CAPTCHA fail हो रहा है
- verification code form दिखने से ठीक पहले
eu-api.friendlycaptcha.euसे connection बनता है - official requirements document में supported operating systems के रूप में सिर्फ Windows और macOS लिखे हैं
- वहीं security key guide में Linux और Firefox भी supported बताए गए हैं
- verification code form दिखने से ठीक पहले
- नीचे दिए गए 6 environment combinations में सभी जगह वही error आया
- Linux पर Firefox, Chromium, Chrome
- macOS पर Firefox, Safari, Chrome
- work laptop पर input के बाद focus अपने-आप अगले box में गया, और खाली code की जगह गलत code वाला
Code entered is incorrecterror भी सामान्य रूप से दिखा - एक दोस्त के macOS computer पर भी तीनों browsers ने verification code स्वीकार किया
- सरकारी सेवाओं के साथ लंबे समय तक interaction के लिए employer द्वारा दिए गए computer पर निर्भर नहीं रहा जा सकता था, और work computer पर registration करने के बाद भी personal laptop पर login न कर पाने की आशंका बनी हुई थी
support structure ने bug report भी रोकी
- official support सिर्फ web form से उपलब्ध था, और इस form को इस्तेमाल करने के लिए भी पहले email verification code दर्ज करना पड़ता था
- FAQ साफ कहता है कि participating institutions की support business hours में सिर्फ online ticket creation से मिलती है
- Swiss Federal Chancellery के postal address के अलावा कोई email address या phone number नहीं था
- AGOV के लिए praise, criticism या request भेजने वाला feedback feature भी AGOV या equivalent account login मांगता था
- email verification fail होने वाले users उसी verification प्रक्रिया के कारण समस्या report भी नहीं कर सकते थे; यह एक circular dependency थी
-
AGOV Access और supported devices
- AGOV Access Android app की rating 1.4 थी, लेकिन Google Play reviews में वही verification code समस्या नहीं मिली
- reviews में security और privacy-focused Android derivative OS GrapheneOS support की कई मांगें थीं
- official FAQ के अनुसार tamper protection के लिए इस्तेमाल होने वाला hardening framework GrapheneOS के साथ compatible नहीं है, इसलिए app काम नहीं करती
- Federal Chancellery ने vendor को compatibility सुनिश्चित करने का निर्देश दिया है
- अभी registration और login के लिए second-factor authentication के तौर पर सिर्फ approved stock iOS·Android smartphones या security key की अनुमति है, और दोनों ही मामलों में पहले email verification पार करनी होती है
JavaScript में मिला कारण
- page द्वारा लोड किए जाने वाले resources कम थे, लेकिन unobfuscated minified main JavaScript file 2.4MB की थी और pretty-print करने पर 1 लाख lines से अधिक निकली
field requiredstring खोजकर verification code state सेट करने वाला logic मिला- verification code variable न होने पर state को
REQUIREDकिया जाता है - उसकी length required code length से अलग होने पर
WRONGमाना जाता है - length सही होने पर server के email verification result के आधार पर
VALIDया error state चुनी जाती है
- verification code variable न होने पर state को
verificationCodeEnteredfunction key input को intercept करके verification code को JavaScript variable में इकट्ठा करता हैEnterverification callback चलाता हैBackspacecurrent value मिटाता है- arrow keys और
Tabinput boxes के बीच move कराते हैं - सामान्य keys को
Number(S.key)से number में बदलकर code में store किया जाता है Control,Meta,Shift,v,rजैसी keys को process किए बिना return कर दिया जाता है
- form submit करते समय DOM values पढ़ी ही नहीं जातीं, इसलिए developer tools या browser extension से input boxes बदलने पर भी JavaScript द्वारा separately managed state में उनका असर नहीं पड़ता
सिर्फ AZERTY पर numbers क्यों blocked थे
- French standard AZERTY layout में numbers टाइप करने के लिए Shift key ज़रूरी होती है
- code ने Shift input को ignore किया, इसलिए AZERTY पर numbers को verification code के रूप में store ही नहीं किया जा सका
- work computer English QWERTY layout पर था, और समस्या verify करने वालों में कोई French user नहीं था
- नतीजतन test किए गए devices में सिर्फ दो personal laptops ही खराब दिख रहे थे
- operating system में keyboard layout बदलकर दूसरे layout पर करने से personal laptops पर भी input सामान्य हो गया
- उल्टा, जो device सही चल रहा था उसे French layout पर बदलते ही वही error दोबारा दिखा
- Switzerland का standard French keyboard मध्य यूरोप में आम QWERTZ परिवार का है
- यह French और German दोनों को efficiently टाइप कर सकता है और numbers के लिए Shift की जरूरत नहीं पड़ती, इसलिए वही error सामने नहीं आती
- Swiss Federal Statistical Office के अनुसार Switzerland में French nationality वाले लगभग 171,000 निवासी हैं, और Swiss government से interaction करने वाले cross-border commuters इस संख्या में शामिल नहीं हैं
source code खुलने तक जांच की सीमाएँ
- AGOV FAQ के अनुसार AGOV source code कानूनी requirements पूरी करने के लिए दिसंबर 2026 में प्रकाशित किया जाएगा
- EMBAG Article 9 संघीय संस्थाओं से यह मांग करता है कि वे अपने काम के लिए सीधे विकसित या विकसित करवाए गए software का source code public करें
- third-party rights या security reasons यदि publication को रोकते या सीमित करते हों तो exception लागू होता है
- publication target में AGOV e-ID Verifier सहित project goals हासिल कर चुकी AGOV versions शामिल हैं, और उसके बाद की versions release के बाद तैयार होने वाले release notes के साथ प्रकाशित की जाएँगी
- कुछ services पहले ही AGOV को mandatory login के रूप में इस्तेमाल कर रही हैं, लेकिन source अभी public नहीं है, इसलिए users के लिए developers को सीधे bug बताना या workaround साझा करना मुश्किल था
registration के बाद देखी गई identity verification की सीमा
- keyboard layout बदलने के बाद email address verify किया गया और security key से registration पूरा किया गया
- registration के दौरान name, phone number और date of birth डाले गए, लेकिन इन जानकारियों को verify नहीं किया गया
- basic registration phase में सिर्फ दो चीजें verify हुईं
- email address वास्तव में मौजूद है
- second-factor authentication या तो approved model की security key है, या approved Android·iOS device पर चलने वाला AGOV Access app है
- AGOV remote phishing के जरिए account takeover के खिलाफ मजबूत है, लेकिन basic registration चरण में यह नहीं रोकता कि कोई दूसरा व्यक्ति किसी और के नाम और identity details का उपयोग करके account बना ले
- अतिरिक्त जाँच से पता चला कि sensitive मानी गई services तक पहुँचने के लिए identity verification ज़रूरी है
- registration के तुरंत बाद अभी ऐसी services तक पहुँचा नहीं गया था
- support form के जरिए bug report की गई, लेकिन कोई जवाब नहीं मिला
design से मिली सीख
-
मजबूत न होने वाला input और support design
- 6 input fields और जटिल JavaScript logic से fancy UI बनाना robust नहीं है
- एक native browser input field इस्तेमाल करके CSS से सिर्फ उसका visual style बनाना बेहतर है
- form logic को DOM से पूरी तरह अलग कर देने पर submit के समय DOM values पढ़ी नहीं जा सकतीं, और advanced users या browser extensions भी input values बदल नहीं सकते
- support channel सिर्फ एक हो तो उसी channel के टूटने पर संपर्क का रास्ता खत्म हो जाता है, इसलिए email या phone जैसा दूसरा channel ज़रूरी है
- product और support channel पर एक ही login logic लागू करने से वे users छूट जाते हैं जो login ही नहीं कर सकते और bug report नहीं भेज पाते
- कई internet services अपने status pages को अलग domain पर रखती हैं, वजह भी यही है
- support request को email verification के बाद रखने से spam कम हो सकता है, लेकिन असली users की outage reports भी साथ में कम हो जाती हैं
- कुछ systems में उपयोग अनिवार्य करने के बाद source code public करने से users के problem-solving और bug या workaround sharing पर रोक लगती है
- कानूनी source publication सिर्फ compliance item नहीं, बल्कि वास्तविक outage investigation में भी उपयोगी है
-
जांच में मददगार open web
- संबंधित JavaScript logic obfuscated नहीं था, इसलिए कुछ string searches से ही कारण मिल गया
- advanced decompiler या महंगे LLM की जरूरत नहीं पड़ी
- अगर code obfuscated होता या WebAssembly में compiled होता, तो कारण समझने में बहुत अधिक समय लगता
- code approved closed operating systems तक सीमित नहीं था, बल्कि open web पर दिया गया था, इसलिए minified form में भी उसे डाउनलोड करके जांचा जा सका
-
root cause पहचानने में मदद करने वाली स्थितियाँ
- अलग keyboard layouts वाले कई laptops की तुलना करके browser-specific issue या network issue की संभावना जल्दी कम की जा सकी
- हालांकि यह साबित करने के लिए कि गलती user की नहीं थी, हर browser combination की screens को व्यवस्थित रूप से capture करने में शुरुआती evidence collection पर समय लगा
1 टिप्पणियां
Lobste.rs की राय
इंटरनेट पर जिन practices से मुझे खास चिढ़ है, उनमें से एक है कि वेबसाइटें key input को intercept करके अपनी मर्जी से process करती हैं और उसे browser तक वैसे का वैसा नहीं जाने देतीं
password field में copy-paste रोकने वाली sites कहीं ज्यादा आम हैं, लेकिन यह भी उसी श्रेणी की चीज है और शायद इससे भी ज्यादा गंभीर लगती है
आम तौर पर अटपटे कारणों से सिर्फ complexity बढ़ती है
हर character के लिए अलग input field रखने का तरीका किसी महामारी जैसा है
किसी company ने इसे cool दिखने के लिए अपनाया, और अब हर कोई अपना-अपना version implement कर रहा है
user बिना ध्यान से पढ़े तुरंत समझ सकता है कि यह password input नहीं है
इससे जुड़ा एक उदाहरण है: Medium once had a bug like this which prevented entering the character 'Ś'
दूसरे implementation तरीकों के बारे में सोचा, लेकिन आखिर में साधारण
<input type="text" />से बेहतर तरीका नहीं मिलासामान्य input box से बहुत अलग दिखाने वाली CSS सजावट तक को लेकर हिचक होती है। input value को बड़े boxes में duplicate करके दिखाया जा सकता है, लेकिन अगर user allowed length से ज्यादा type कर दे तो क्या करें जैसी तमाम समस्याओं के जवाब देने पड़ेंगे, और इसका फायदा इतना बड़ा नहीं कि वह मेहनत justified लगे। बहुत हुआ तो input field का font और size ही बदलूंगा
1234की जगह1224जैसी एक digit गलत डालना हैदूसरी
2पर click करके3दबाना सबसे तेज correction है, लेकिन HTML+CSS भर से यह implement नहीं किया जा सकता<input type="text" pattern="[0-9]+" minlength=6 maxlength=6>पर अजीब letter-spacing लगाकर उसे visually छह boxes जैसा दिखाया जा सकता हैआसान तरीका यह होगा कि user single text input में type करे और JavaScript DOM में किसी दूसरी जगह छह boxes draw करे, फिर हर key press पर होने वाले
inputevent से उन्हें update करेaccessibility के लिहाज से कौन सा बेहतर होगा, यह पक्का कहना मुश्किल है। screen reader के perspective से साधारण
<input>और decorative<canvas alt="">साथ रखने वाला दूसरा तरीका उल्टा बेहतर हो सकता है, और keyboard operation भी अजीब नहीं बनेगा। लेकिन screen reader के अलावा दूसरी assistive tools इस्तेमाल करने वाले users के लिए<input>को visually hide करना accessibility disaster बन सकता है, इसलिए बहुत सावधानी चाहिएकई services की तरह email में code और activation link दोनों साथ दे सकते हैं
इससे भी वही समस्या हल हो सकती है
इसे exceptional situation माना जा सकता है, लेकिन accessibility का मतलब ही ऐसे exceptions को ठीक से handle करना है
Tridactyl में भी बिलकुल यही समस्या है https://github.com/tridactyl/tridactyl/issues/3257
यह पहली बार 2019 में report हुआ था; शायद इस घटना के बाद शर्म के मारे ही इसे ठीक कर दिया जाए
यह फिर दिखाता है कि बस ठीक से काम करने वाली website की तुलना में टूटी हुई या धीमी website बनाने में कहीं ज्यादा effort लगता है