डेवलपर के औज़ार

लोग Base64 decoder में जो चिपकाते हैं, घटते क्रम में: कोई JWT, कोई Basic Auth हेडर, किसी webhook का payload, कोई कॉन्फ़िग फ़ाइल। चार में से तीन या तो ख़ुद क्रेडेंशियल हैं या उनके भीतर क्रेडेंशियल है। जो पन्ना इन्हें किसी सर्वर पर decode करता है, वह उन्हें देख चुका है — और वे उसके रिक्वेस्ट लॉग में हैं, कोई चाहे या न चाहे।

यह कोई किताबी आपत्ति नहीं है। यही वजह है कि इस पूरी क़िस्म की वेबसाइटें बहुत सी कंपनियों के प्रॉक्सी पर बंद हैं, और जहाँ बंद नहीं हैं वहाँ आम तौर पर कोई नीति मौजूद है जिसे कोई पढ़ता नहीं। इस पन्ने पर जो कुछ है वह ऐसा गणित है जो ब्राउज़र ख़ुद कर लेता है; उसे कहीं और भेजना एक फ़ैसला है, और वह ग़लत फ़ैसला है।

पन्ना CDN से आने वाला स्थिर HTML है। पहली टाइप पर JavaScript का एक छोटा-सा हिस्सा लोड होता है, एक बार और उसके बाद कैश से, और काम आपके ही टैब में होता है। कोई भी रिक्वेस्ट आपका लिखा हुआ लेकर नहीं जाती, और इसे मान लेने के बजाय नेटवर्क पैनल में देख लेना बेहतर है।

दो ईमानदार सीमाएँ। पन्ना ख़ुद एक रिक्वेस्ट है, इसलिए यह तथ्य कि आप यहाँ आए थे हमें और आपके नेटवर्क को दिखता है। और साइट पर विज्ञापन हैं और, आपकी सहमति पर, आँकड़े: इनमें से कोई भी किसी टेक्स्ट खाने की सामग्री नहीं देखता, पर दोनों तीसरे पक्ष की रिक्वेस्ट हैं। फ़र्क़ वही है जो आपके लिखे और आपके यहाँ होने के बीच है — पहला कभी हिलता नहीं, दूसरा हिलना ही पड़ता है।

डिजिटल पर्सनल डेटा प्रोटेक्शन ऐक्ट, 2023 उस पर बाध्यताएँ डालता है जो तय करता है कि निजी डेटा क्यों और कैसे प्रोसेस होगा। अगर डेटा डिवाइस से बाहर ही नहीं जाता, तो आपके चिपकाए हुए पर हमारे पास प्रोसेस करने को कुछ है ही नहीं — और व्यवहार में यही वह बिंदु है जहाँ बात तय होती है, जब खाने में कोई KYC रिकॉर्ड, कोई सपोर्ट संदेश या Aadhaar या PAN नंबर वाला payload पड़ा हो।

जो होता है वह निजता वाले पन्ने पर लिखा है और यहाँ उस पर लीपापोती नहीं की जाती: आपका आना, विज्ञापन और आँकड़ों की रिक्वेस्ट, सहमति। एक औज़ार का लोकल में गणना करना पूरी साइट को तटस्थ नहीं बना देता — वह बस सबसे भारी हिस्सा हटा देता है।

एक ही पन्ना जो किसी चुनने वाले खाने के पीछे Base64, URL और HTML को दोनों दिशाओं में निपटा देता, कम पन्ने होता और बुरा होता। Encode और decode अलग तरह से टूटते हैं, अलग तरह से समझाए जाते हैं और अलग तरह से खोजे जाते हैं: जिसके सामने टूटा हुआ percent sequence है और जो एक query बना रहा है, उन दोनों के पास एक-दूसरे से कहने को कुछ नहीं है।

इसलिए हर दिशा का अपना पन्ना है, अपनी ग़लतियों के साथ: Base64 जब टेक्स्ट नहीं बल्कि बाइट में खुले तो क्या करना है, `encodeURIComponent` विस्मयादिबोधक चिह्न को क्यों जाने देता है, और उससे किसी OAuth हस्ताक्षर का क्या बिगड़ता है। इससे ऐसा पन्ना बनता है जिसे पढ़ना बनता है, और यह सिर्फ़ इसलिए मुमकिन है कि वह एक साथ छह तरह के पाठकों को नहीं सँभाल रहा।

किसी औज़ार का पन्ना एक बार खुल जाने के बाद सब कुछ लोकल है: यह ट्रेन में चलता है, हवाई जहाज़ में चलता है, और उस कॉर्पोरेट प्रॉक्सी के पीछे भी चलता है जो एक घंटे बाद इस डोमेन को रोक दे। कोई service worker नहीं लगाया जाता और सेट करने को कुछ नहीं है; जो पन्ना कभी बाहर बात ही नहीं करता, उसके पास कनेक्शन जाने पर खोने को कुछ होता ही नहीं।

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

पंजीकरण के लिए कुछ है ही नहीं क्योंकि सँभालने के लिए कुछ है ही नहीं। औज़ार दो मुलाक़ातों के बीच कुछ नहीं रखते: टैब बंद करते ही आपका लिखा मिट जाता है, क्योंकि वह उस टैब के अलावा कहीं मौजूद ही नहीं था।

मात्रा की भी कोई सीमा नहीं है, और यह उदारता नहीं है: आपके गणना-समय के लिए हम कुछ नहीं चुकाते, इसलिए राशन करने को कुछ है ही नहीं। एकमात्र छत यह है कि आपका अपना ब्राउज़र एक खाने में कितना टेक्स्ट सँभालना चाहता है।

इन पन्नों पर payload, token, hash, query string और Base64 लिखा है — «भार», «चिह्न», «सारांश» या «प्रश्न-शृंखला» नहीं। यह आलस नहीं है: भारतीय टीमों में इन चीज़ों की बात इसी भाषा में होती है और खोजा भी इसी में जाता है।

जहाँ रोज़मर्रा का हिंदी शब्द ही चलन में है, वहाँ वही लिखा है: बाइट के लिए बाइट, पर पन्ना, खाना, अक्षर, समय-क्षेत्र, जोड़ना, तोड़ना। नियम «जितनी हिंदी हो सके उतनी» नहीं है, नियम «बातचीत में जो शब्द बोला जाता है» है; बाक़ी कुछ भी करने से एक सही-सही अनूदित पन्ना बनता है जिस तक कोई पहुँचता नहीं।

तीन बातें इस पूरे परिवार में लौट-लौटकर आती हैं। पहली, देवनागरी का हर अक्षर UTF-8 में तीन बाइट लेता है, इसलिए अक्षरों में तय की गई हर सीमा हिंदी सामग्री पर तीन गुना तेज़ी से भरती है। दूसरी, Kruti Dev और उसी परिवार के फ़ॉन्ट में टाइप हुआ टेक्स्ट असल में ASCII बाइट है, इसलिए उसका hash, उसका Base64 और उसका hex किसी Unicode रूपांतरण से कभी नहीं मिलेंगे।

तीसरी सबसे चुपचाप काम करती है: zero-width joiner और non-joiner हिंदी टाइपिंग में आम हैं, कुछ दिखाते नहीं, और दो «एक जैसे» नामों को तुलना में अलग बना देते हैं। तीनों को पकड़ने की जगह एक ही है — hex वाला पन्ना, जहाँ बाइट सीधे दिखती हैं। इसीलिए यहाँ के दूसरे पन्ने संदेह होने पर उसी की ओर भेजते हैं।

HTML, CSS या JavaScript का कोई formatter यहाँ नहीं है, और यह एक फ़ैसला है, कमी नहीं। ठीक-ठाक काम करने वाले को असली parser चाहिए; इसके लिए इस्तेमाल होने वाली लाइब्रेरियाँ कई मेगाबाइट की हैं और वे लाइसेंस और लोड-समय दोनों का अपना फ़ैसला होतीं, जबकि घर का बना parser चुपचाप इनपुट बिगाड़ता है। JSON का formatter सिर्फ़ इसलिए बेख़तर है कि वह parser ब्राउज़र के भीतर पहले से मौजूद है।

Markdown या HTML की झलक भी नहीं है। दोनों का मतलब होता किसी और का HTML इसी पन्ने के भीतर रेंडर करना, और HTML entity decode वाला पन्ना ठीक इसी को तर्क के साथ मना करता है, क्योंकि ऐसा parser नेटवर्क रिक्वेस्ट करवा सकता है। जो दलील एक पन्ने पर चलती है उसे अगले पन्ने पर अनदेखा नहीं किया जा सकता।