खुद से मत बनाइए …

• Don't Roll Your Own ... सिद्धांत सिर्फ encryption पर ही नहीं, web UI पर भी लागू होता है; browser जो सुविधाएँ पहले से भरोसेमंद तरीके से देता है, उन्हें बेवजह replace नहीं करना चाहिए
• custom scrolling, link handling, text selection, copy-paste जैसी मूलभूत behavior को replace करने से परिचित input response टूट जाता है और user को फिर से यह सोचना पड़ता है कि interface कैसे operate करना है
• GitHub के file और issue links की तरह, जब JavaScript link navigation को intercept करता है, तो कभी-कभी current tab में उसके process होने का इंतज़ार करने से बेहतर link को new tab में खोलना तेज़ होता है
• default password field और <input type="date"> autocomplete, password manager, accessibility tools और mobile keyboard के साथ काम करते हैं; इन्हें fake UI से बदलने पर functionality टूट सकती है
• हर कुछ महीनों में बदलने वाले layout और form controls users को काम से ज़्यादा दोबारा सीखने में समय लगवाते हैं; browser के stable default behavior को बनाए रखना बेहतर है

---

web UI में “खुद से मत बनाइए” सिद्धांत का उपयोग

• encryption खुद implement न करें का सिद्धांत यह कहता है कि sensitive data की रक्षा करने वाले production software में unverified private implementation पर निर्भर नहीं होना चाहिए
• इसका मतलब यह नहीं कि कोई भी कभी encryption code न लिखे, बल्कि इसका मतलब ज़्यादा यह है कि जहाँ संभव हो reviewed और verified packages तथा tools का उपयोग करना चाहिए
• लगभग 20 साल पहले ऐसी custom RC4 implementations वास्तव में मौजूद थीं जिनमें improper initialization vector, predictable keystream और plaintext का कुछ हिस्सा leak होने जैसी समस्याएँ थीं
• आज बड़े e-commerce sites या banks आम तौर पर web services में अपनी खुद की encryption इस्तेमाल नहीं करते, और payments, healthcare, personal data processing जैसे regulated क्षेत्रों में strong encryption requirements का उल्लंघन बड़े fines तक ले जा सकता है
• website design encryption जैसा नहीं है, लेकिन browser जिन चीज़ों को पहले से अच्छी तरह संभालता है और जिन पर users रोज़ निर्भर रहते हैं, उन्हें दोबारा implement करने से user experience खराब हो सकता है

browser की default functionality को replace करने पर आने वाली समस्याएँ

• अगर page scrolling को खुद implement किया जाए, तो mouse, touchpad और keyboard input पर मिलने वाला familiar response टूट सकता है
• default scrolling behavior को override करने पर page बहुत धीमा या बहुत तेज़ चल सकता है, और keyboard scrolling काम भी न करे
• जब user बिना सोचे-समझे इस्तेमाल होने वाला behavior किसी अनजाने behavior में बदल जाता है, तो उसे page operate करने पर फिर से ध्यान देना पड़ता है
• जिन representative features को खुद implement नहीं करना चाहिए, उनमें link navigation, text selection, context menu, copy-paste, password field और date picker शामिल हैं
• गंभीर कामकाजी websites में user interface features जोड़ते समय यह फैसला सावधानी से करना चाहिए कि कोई flashy feature जोड़ना है या browser के default behavior पर छोड़ना है

link navigation और GitHub का मामला

• web browser links को follow करने का काम पहले से अच्छी तरह करते हैं, और link navigation browser की core functionality है
• अगर आपको लगता है कि normal link behavior में दखल देना चाहिए, तो फिर से जाँचना चाहिए कि आपका लक्ष्य इतना महत्वपूर्ण है भी या नहीं कि सामान्य link navigation को तोड़ा जाए
• GitHub में file link या issue link पर click करने पर JavaScript से implemented बड़ा feature click handling अपने हाथ में ले लेता है
• Firefox या Chrome में F12 से developer tools खोलकर, Debugger या Sources tab के Event Listener Breakpoints में Mouse के click को चुनने के बाद GitHub link पर click करें, तो यह behavior देखा जा सकता है
• GitHub में current tab के JavaScript navigation processing का इंतज़ार करने से कभी-कभी link को new tab में खोलना तेज़ होता है

password input और date picker

• browser का password input field password save करने, autofill करने और नए account के लिए strong password generate करने की सुविधा दे सकता है
• default password field असुरक्षित HTTP connection पर password submit होने पर warning देता है, और password manager, autocomplete, mobile keyboard तथा accessibility tools के साथ भी काम करता है
• अगर इसे fake password field से replace किया जाए, तो ये सुविधाएँ टूट सकती हैं; और अगर plain text field को manually mask किया जाए, तो browser, operating system और assistive tools password को सामान्य visible text की तरह treat कर सकते हैं
• <input type="date"> सीधे date range selection को support नहीं करता, लेकिन start date और end date के लिए 2 input fields देने से browser का default date picker बनाए रखा जा सकता है
• custom date picker हर implementation में अलग तरह से काम कर सकता है: कहीं year view तक zoom out करना पड़ता है, कहीं birth year चुनने के लिए पिछले साल वाले button को दर्जनों बार दबाना पड़ता है, और कहीं direct date input ही block हो जाता है
• अगर किसी ऐसे browser में calendar widget चाहिए जहाँ default date picker support कमज़ोर है, तो <input type="date"> को replace करने के बजाय उसी field को operate करने वाला supplementary widget जोड़ना बेहतर है

बार-बार होने वाले UI बदलाव की लागत

• form controls को लापरवाही से बदलने पर पुराने problems हल होने के साथ लगभग हमेशा नए problems भी आ जाते हैं
• अगर website layout और interface हर कुछ महीनों में बदलते रहें, तो कुछ users भले adapt कर लें, लेकिन उम्रदराज़ users के लिए यह हर बार नया tool सीखने जैसा बोझ बन जाता है
• जब कई websites लगातार interface बदलती रहती हैं, तो users को बिना किसी functional लाभ के परिचित चीज़ों को दोबारा सीखने में काफी समय लगाना पड़ता है
• जैसे Linux distribution अगर हर कुछ महीनों में core commands और command-line options को पूरी तरह redesign कर दे, या washing machine के buttons की arrangement हर सुबह बदल जाए, वैसे ही बार-बार की UI rearrangement एक अप्रिय अनुभव बन जाती है
• web UI वह tool है जिसका उपयोग users अपना काम पूरा करने के लिए करते हैं, इसलिए browser के पहले से दिए गए परिचित और stable behavior को अनावश्यक रूप से replace न करना बेहतर है

[kirinonakar]

शायद हमारे देश की तरह बहुत कम देश होंगे जहाँ इतने ज़्यादा अपने खुद के encryption और security programs हों।

[GN⁺]

Lobste.rs की राय

• पेज स्क्रॉल को खुद implement नहीं करना चाहिए, इस बात से सहमत हूँ। इसे native जितना अच्छा बनाना मुश्किल है, और अपवाद सिर्फ ऐसे मामलों को माना जा सकता है जैसे मैप, जहाँ स्क्रॉल को zoom in/out से मैप करने की परंपरा होती है

  लेकिन लिंक नेविगेशन को खुद implement न करने को नियम बना देना, इसका मैं कड़ा विरोध करता हूँ। सामान्य content साइटों के लिए मैं client-side routing (CSR) की सिफारिश नहीं करूँगा, लेकिन कुछ apps में इसे सक्रिय रूप से recommend किया जा सकता है, और GitHub जैसी सेवाएँ बीच के क्षेत्र में आती हैं

  फिर भी हमेशा असली `` element का इस्तेमाल होना चाहिए ताकि browser की native functionality काम करे। webmail client जैसे apps में CSR सही है, और GitHub में भी पहले जब इसे हल्के तरीके से लागू किया गया था तब सुधार हुआ था, लेकिन हाल का frontend approach काफ़ी खराब हो गया है

  समस्या यह है कि CSR बहुत बार लापरवाही से implement किया जाता है और खराब network conditions में robust नहीं बनाया जाता। browser ऐसे हालात में मज़बूत होते हैं, और tab loading indicator या bfcache जैसी optimizations भी CSR में बाधित हो सकती हैं

  टेक्स्ट चयन को खुद implement करना सिर्फ बहुत विशेष मामलों में ही अपवाद हो सकता है, जैसे मोबाइल पर उंगली को highlighter की तरह इस्तेमाल करने वाले annotation apps। बल्कि मैं यह भी जोड़ना चाहूँगा कि ::selection भी नहीं इस्तेमाल करना चाहिए। सिर्फ ::selection{} को stylesheet में जोड़ देने से selection area दिखाई न दे, यह खराब design है

  context menu को खुद implement करने पर रोक से मैं सहमत नहीं हूँ। email client, file manager, word processor जैसे apps को अपने items चाहिए होते हैं, और browser उन्हें extend करने का तरीका नहीं देता, इसलिए पूरी तरह custom menu अभी व्यावहारिक विकल्प है। Firefox में Shift+right click से native menu को force-open किया जा सकता है, यह अच्छी बात है

  copy/paste को खुद implement न करने वाली बात interpretation पर निर्भर करती है, इसलिए इससे सहमत भी हुआ जा सकता है और असहमत भी; इसे और स्पष्ट होना चाहिए

  password field को खुद implement करने के मामले मैंने tech demo के अलावा लगभग नहीं देखे। show/hide button से `` को password से text में बदलना इसमें शामिल नहीं माना जाना चाहिए

  date picker को खुद implement न करने वाली बात से भी मैं सहमत नहीं हूँ। native controls को recommend करना चाहूँगा, लेकिन उनकी सीमाएँ और असंगतियाँ बहुत बड़ी हैं, और पिछले 10 सालों में उन्हें ठीक करने की दिलचस्पी भी लगभग नहीं रही। picker में अतिरिक्त जानकारी नहीं जोड़ी जा सकती, और जन्मतिथि जैसी पुरानी तारीख़ चुनना कुछ platforms पर बहुत खराब अनुभव है। उदाहरण: Safari's date-picker is the cause of 1/3 of our customer support issues

  custom date picker में accessibility समस्याएँ बहुत होती हैं, लेकिन सामान्य users के लिए वह कई बार बेहतर भी होता है, और native control में न मिलने वाले features की ज़रूरत के कारण उसे न इस्तेमाल कर पाना भी आम है। साधारण date selection के लिए मैं native को पसंद करता हूँ क्योंकि मेरे browser में direct input संभव है, लेकिन बहुत से users के लिए native काफ़ी अच्छा नहीं है। date range को `` दो से बनाना अधिकतर लोगों के लिए कहीं ज़्यादा खराब हो सकता है

  • accessibility की ज़रूरत वाले लोगों को या उससे लाभ पाने वालों को “सामान्य लोगों” के सामने रखकर देखने वाली भाषा कुछ पाठकों को अलग-थलग कर सकती है। आप accessibility aids इस्तेमाल करने वाले लोगों के अनुभव और ज़रूरतों के प्रति काफ़ी सचेत लगते हैं, इसलिए यह बात खास तौर पर उठाना चाहता हूँ

  • Safari का date picker खुद इस्तेमाल करके समझा कि वह कितना सीमित है। लेकिन मुझे हमेशा यह जिज्ञासा रही कि websites native date picker को calendar widget से क्यों बदल देती हैं

    क्या calendar widget को native widget के साथ-साथ नहीं रखा जा सकता? इससे दो input methods दिखने के कारण UI थोड़ा उलझा हुआ लग सकता है, लेकिन सही labeling के साथ उनमें से एक को advanced date picker कहकर शायद इसे हल किया जा सकता है। तब जो लोग native date picker को आराम से इस्तेमाल करते हैं, वे उससे वंचित नहीं होंगे, और जिनके लिए browser का date picker अपर्याप्त है, उन्हें भी मदद मिलेगी

    मुझे समझ आता है कि document authoring tool या diagram editor जैसे web apps में context menu की ज़रूरत होती है, लेकिन right click करने पर browser का सामान्य menu गायब हो जाए तो वह अब भी असुविधाजनक है। इसी वजह से Firefox settings में मैं आम तौर पर dom.event.contextmenu.enabled = false रखता हूँ। तब Firefox menu ऊपर और web app menu उसके पीछे खुलता है, लेकिन native menu काम करता रहता है, इसलिए यह ठीक-ठाक workaround है। जहाँ संभव हो, web app का menu bar इस्तेमाल करना बेहतर है और browser के native context menu को न छेड़ना ही अच्छा है। Shift+right click वाला tip भी अच्छा समाधान है

  • जिन लोगों को accessible controls चाहिए, वे भी सामान्य लोग ही हैं

  • password field को खुद implement करने के उदाहरण पेरू के लगभग सभी बैंकों में देखे जा सकते हैं

    date picker के लिए मैं native इस्तेमाल करना चाहता हूँ, लेकिन implementers की ओर से इसे सुधारने में ज़्यादा रुचि दिखती नहीं। Firefox में time/clock selection UI से जुड़ा issue है, और प्रगति धीमी है: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

• web forms में यह अच्छी बात कही गई है। browser पर निर्भर रहना सबसे सरल, तेज़ और लगभग हमेशा सबसे consistent तरीका है

  लेकिन cryptography code अलग मामला है। सही crypto code लिखना आसान नहीं है, पर असंभव भी नहीं। कुछ परिस्थितियों में विकल्प इतने कम हो सकते हैं कि खुद बनाना ही सबसे अच्छा रास्ता हो

  यहाँ security orthodoxy की समस्या यह है कि वे अक्सर मान लेते हैं कि नया crypto code लिखने के लिए आपको उनके अंदरूनी समूह का हिस्सा होना चाहिए। जैसे अगर आप cryptography में PhD या DJB, Dan Boneh के तहत internship नहीं दिखा सकते, तो आपको crypto code नहीं लिखना चाहिए। “सीखने के लिए” ठीक है, लेकिन जो सीखा उसे वास्तविक दुनिया में लागू नहीं करना चाहिए—ऐसा रवैया रहता है। यहाँ तक कि बाहरी लोगों की वास्तविक क्षमता पहचानने में भी उन्हें दिक्कत होती है। दिलचस्प यह है कि ऐसे security orthodox लोग और papers लिखने वाले वास्तविक cryptographers के बीच overlap बहुत कम दिखता है

  अब यह बात बढ़कर इस तक पहुँच रही है कि memory-unsafe language में कुछ भी नहीं लिखना चाहिए। अगर 70% critical vulnerabilities वैसी हैं भी, तो असली कारण क्या थे? मेरा अनुमान है कि ज़्यादातर समस्याएँ stack पर न होने वाले छोटे objects के लिए malloc() या explicit new का इस्तेमाल करने से, या null-terminated strings को संभालने से आई होंगी। अगर arena और slices का इस्तेमाल किया गया होता, तो ऐसी समस्याएँ बहुत कम होतीं। बेशक कुछ high-risk scenarios में कुछ bug classes को पूरी तरह हटाना ज़रूरी होता है, और तब memory safety सर्वोच्च प्राथमिकता होती है

  तो अगला कदम क्या है—untrusted input को process करने वाली किसी भी चीज़ को न लिखना? या पहिया दोबारा न बनाना, भले मौजूदा सारे पहिए चौकोर ही क्यों न हों? फिर भी अगर आप JavaScript bloat से बचते हैं और browser द्वारा दिए गए forms का इस्तेमाल करते हैं, तो अपना web framework बनाने को शायद मैं बहुत बड़ी समस्या नहीं मानूँगा

  • मुझे लगता है C का मूल पाप यह है कि arrays पास करते समय upper bound information खो जाती है और वे pointers में बदल जाते हैं

  • “अपना crypto मत लिखो” को मैं कभी पूर्ण सत्य नहीं, बल्कि एक मज़बूत चेतावनी के रूप में समझता रहा हूँ। यह सही है कि बिना PhD के भी इसे सुरक्षित रूप से implement किया जा सकता है, लेकिन फिर भी इसमें भारी सीखने की ज़रूरत होती है

    अगर बात सिर्फ specification को ध्यान से implement करने की हो, तो ज़रूरत काफ़ी कम हो सकती है। लेकिन ज़्यादातर software तेज़ crypto implementations चाहते हैं, और तब complexity बहुत बढ़ जाती है। linked Monocypher vulnerability इसका अच्छा उदाहरण है। अचानक आपको समझना पड़ता है कि birational equivalence, Edwards points और Montgomery ladder आपस में कैसे जुड़े हैं

    PhD जैसी credentials दूसरों को यह भरोसा दिलाने में मदद करती हैं कि आपको पता है आप क्या कर रहे हैं। audit एक दूसरा रास्ता है। लगता है Monocypher का audit Cure53 के दो PhD holders ने किया था। समस्या यह है कि ज़्यादातर programmers यह तय करने के लिए तैयार नहीं होते कि कोई crypto library सुरक्षित है या नहीं, इसलिए वे credentials या auditors की credentials जैसे non-technical signals पर निर्भर हो जाते हैं। बेहतर होता अगर कोई अधिक प्रत्यक्ष तरीका होता, लेकिन credentials काफ़ी ठीक काम करते हैं

  • यह तो स्पष्ट है कि अपना crypto लिखना संभव है। अगर ऐसा नहीं होता, तो crypto libraries भी मौजूद नहीं होतीं। सवाल यह नहीं कि किया जा सकता है या नहीं; सवाल यह है कि user passwords hash करने और personal data की रक्षा करने वाले production environment में क्या हम आपके या मेरे हाथ से लिखे crypto पर भरोसा कर सकते हैं? मैं नहीं कर सकता

  • पुरानी नौकरी में legacy code license checking के लिए MD5 इस्तेमाल कर रहा था, और मुझे उसे ऐसे environment में verify करना था जहाँ उस पुराने C++ code को चलाया नहीं जा सकता था, इसलिए MD5 को फिर से implement करना पड़ा। existing libraries ढूँढीं, लेकिन ऐसी कोई नहीं मिली जो IV बदलने का support देती हो

  • अपना crypto लिखने की हिम्मत तो नहीं है, लेकिन security industry का अब यह कहना कि अपनी authentication भी मत करो, थोड़ा ज़्यादा लगता है

• अच्छा होता अगर browser खुद implement किए बिना इस्तेमाल लायक multi-select field दे पाते

  • है तो, लेकिन बहुत खराब है

• date range के लिए `` दो लेकर start date और end date लेना बोझिल है और सहज भी नहीं। इससे जो चीज़ conceptually एक है, उसे visually असंबंधित लगने वाले दो अलग views में बाँटना पड़ता है

  date range का न होना `` की कई समस्याओं में सिर्फ एक है। उदाहरण के लिए, इसमें कुछ dates को exclude नहीं किया जा सकता, इसलिए booking service देने वाले लगभग हर मामले में यह शुरू से ही अनुपयोगी हो जाता है

  मुझे संदेह है कि हर जगह तारीख़ को एक ही तरीके से लिखने के लिए दो input fields की छोटी-सी लागत स्वीकार करने वाला दृष्टिकोण वास्तव में मुख्यधारा में है। औसत user को fields पसंद नहीं होते, और एक field से बदतर चीज़ दो fields हैं। familiarity वाला तर्क भी कमज़ोर लगता है। मेरे अनुभव में web पर native date input अब भी दुर्लभ है

  • मैंने कई websites देखी हैं जिनमें date range start और end के लिए दो custom calendar widgets लगे होते हैं, और दोनों ठीक से काम नहीं करते। यानी बुरे पर और बुरा

  • date range वाले हिस्से से मैं भी सहमत नहीं था। मैं अक्सर date range को उस उदाहरण के रूप में इस्तेमाल करता हूँ जो दिखाता है कि conceptually एक single control वास्तव में कितना complex हो सकता है। “हमेशा native controls का इस्तेमाल करो” वाला नारा कई बार user experience को बदतर बना सकता है, जब समस्या-विशेष के लिए इससे बेहतर control दिया जा सकता हो

    native से implement न किए जा सकने वाले date/date-range controls की एक उपयोगी विशेषता price display है। जब आप flights या hotels खोज रहे हों, तो date picker के अंदर ही यह दिखना कि कौन-सी तारीख़ सस्ती है और कौन-सी महँगी, बहुत उपयोगी होता है। native control में वही जानकारी देखने के लिए कहीं ज़्यादा clicks करने पड़ते हैं या अलग table देखनी पड़ती है, जबकि custom control हर date के साथ ऐसा metadata जोड़ सकता है

    एक क्लासिक उदाहरण जन्मतिथि input है। date picker आम तौर पर वर्तमान महीने को default दिखाता है, जो वांछित तारीख़ से लगभग असंबंधित होता है, इसलिए अनुभव बहुत खराब होता है। यहाँ custom control इस्तेमाल किया जा सकता है, लेकिन text box का संयोजन कई बार बेहतर होता है। यह पूरी तरह custom control की बजाय native controls का संयोजन है, लेकिन बात यह है कि ऐसा कोई “one-size-fits-all” date picker नहीं है जो हर मामले में अच्छा हो

• यह कई साल पहले की बात है, इसलिए दोबारा जाँचना पड़ेगा, लेकिन html5 date picker की जगह custom implement करने की मजबूरी का एक दुखद कारण था। कुछ browsers का `` UI सचमुच बहुत भयानक था

  context menu को खुद implement करना दुर्लभ है, लेकिन जब ज़रूरत हो तो बहुत उपयोगी होता है। उदाहरण के लिए, अगर web page के अंदर diagram editor बनाया गया हो, तो diagram के node पर click करके उपयोगी actions करने के लिए custom context menu मिलना अच्छा लगेगा। सारी interaction को सिर्फ left-click UI, जैसे action palette और node के बीच बारी-बारी click करने पर ठूँस देना अच्छा नहीं है

  सूची के बाकी बिंदुओं से मैं मज़बूती से सहमत हूँ

• मुझे समझ नहीं आता कि cryptography वाले उदाहरण और scrolling behavior की समस्या को साथ रखकर कैसे पढ़ा जाए। दोनों बहुत अलग क्षेत्र लगते हैं

  मैं इस सामान्य बात से सहमत हूँ कि websites बहुत ज़्यादा काम करने लगती हैं। लेकिन वह behavior user और website के goals के अनुसार बदलता है

  prefers-reduced-motion की तरह prefers-user-scroll जैसी कोई setting बीच का समाधान हो सकती है क्या?

  • vertical scroll area implement करने के लिए scrolljacking का कोई वैध use case नहीं है। ऐसा code शुरू से लिखा ही नहीं जाना चाहिए था

    हालांकि यह बात सिर्फ vertical scroll areas तक सीमित है। स्क्रॉल को non-scroll behavior में remap करने के मामले में कुछ use cases हैं, और वे अब भी बहुत समस्याग्रस्त हैं, लेकिन vertical writing systems में vertical को horizontal में map करने जैसी चीज़ों पर चर्चा की जा सकती है। इसके अलावा एक-दो और वैध use cases हो सकते हैं, लेकिन वास्तविक implementation तरीक़े फिर भी आम तौर पर गलत ही होते हैं

• पेज स्क्रॉल को खुद implement न करना—इससे मैं पूरी तरह सहमत हूँ। KotlinConf में Compose Multiplatform for Web के scroll implementation की कठिनाइयों पर एक दिलचस्प talk सुनी थी

  एक समस्या यह थी कि web browsers native apps की तुलना में scroll events कम भेजते हैं, जिससे scroll direction की गणना करने वाला algorithm विफल हो गया। तरीका यह था कि सभी points से गुजरने वाली parabola खींची जाए और आख़िरी point पर उसकी slope ली जाए, लेकिन points कम होने पर scroll direction उल्टी निकल सकती थी

  दूसरे platforms से port करते समय या ऐसे interactions को फिर से implement करते समय, गलत assumptions से शुरुआत करना आसान होता है, या browser द्वारा default दिए जाने वाले “अजीब” behaviors भूल जाना भी आसान है

  • जिज्ञासा है कि मूल app में ऐसे scroll events का इस्तेमाल किस लिए हो रहा था, जो web context में भी उसकी नकल ज़रूरी थी। scroll को किसी और चीज़ के driving input की तरह इस्तेमाल करने पर मुझे थोड़ा संदेह होता है

• “platform पर भरोसा करो” वाली सलाह सही है, लेकिन platform के साथ लगातार बने रहना कठिन है। enterkeyhint या inputmode जैसी चीज़ें हैं, जिनके बारे में मोटे तौर पर पता तो होता है, लेकिन उनका प्रभाव याद नहीं रहता

  इस हफ़्ते हमारी team ने इसमें मदद के लिए [0] जारी किया। यह implementation best practices को skills के रूप में देता है। docs भी लोगों के पढ़ने के लिए काफ़ी अच्छे हैं। उदाहरण: [1]

  [0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…

• लेख का tone थोड़ा चूक गया है। लोगों को यह ठीक से समझाने पर ज़्यादा productive चर्चा होगी कि कब और क्यों पहिया दोबारा बनाने की ज़रूरत नहीं होती

  लेख reasons अच्छी तरह समझाता है, लेकिन “खुद मत बनाओ” जैसी हुक्मी भाषा के कारण कमजोर हो जाता है

  “अपना crypto मत लिखो” वाला नारा भी आख़िरकार एक doctrine जैसा लगता है। जो लोग इसे कहते हैं वे expert कौन हैं, और उन्हें किसने नियुक्त किया? ऐसा कहने से पहले क्या उन्होंने खुद code देखा है? Heartbleed जैसी vulnerabilities को देखकर क्या यह नहीं लगता कि असल में वहाँ बहुत शुरुआती स्तर की गलतियाँ थीं?

  • वे लोग हैं जिन्होंने अपनी ज़िंदगी cryptography को दी है। उन्हें किसी ने नियुक्त नहीं किया; उन्होंने उपयोगी research प्रकाशित करके और क्षेत्र को समझने वालों की जाँच-परख से अपना स्थान अर्जित किया है

    algorithms सार्वजनिक होते हैं, review होते हैं, सार्वजनिक रूप से attack किए जाते हैं, सुधारे जाते हैं और standardize होते हैं। यह बंद दरवाज़ों के पीछे नहीं होता। papers भी public हैं और code भी public है। आप जब चाहें देख सकते हैं। सिर्फ इसलिए कि आपने नहीं देखा, इसका मतलब यह नहीं कि किसी ने नहीं देखा। लोग इन्हें देखते हैं और तोड़ने की कोशिश करते हैं। हम इन्हें इसलिए इस्तेमाल करते हैं क्योंकि इन्होंने हमलों को झेला है

    अगर Heartbleed देखकर आपका समाधान OpenSSL को खुद फिर से implement करना है, तो मैं शर्त लगा सकता हूँ कि आपके OpenSSL में असली OpenSSL के हर एक Heartbleed पर पचास Heartbleed होंगे। फ़र्क सिर्फ इतना है कि असली OpenSSL को जानकार लोग review, test, audit, attack और fix करते हैं। आपका संस्करण चुपचाप गलत ही बना रहेगा

  • मुख्य बात यह नहीं कि कोई त्रुटिहीन expert है जो निडर होकर AES call कर सकता है। असली फायदा यह है कि अगर आप कोई लोकप्रिय wrapper इस्तेमाल करते हैं जो सुरक्षित रूप से काम करता है, तो bug मिलने पर उसे एक ही जगह खोजकर ठीक किया जा सकता है

    अगर कोई नया side-channel attack मिलता है, तो उसका जवाब भी एक ही जगह दिया जा सकता है। अपने हाथ का बनाया हुआ समाधान आपको ऐसे सुधार नहीं देगा, जब तक आप खुद नई attacks को track करने में full-time समय न लगाएँ

• यह ज़्यादा उन लोगों के बारे में शिकायत जैसा है जो web tools का खराब इस्तेमाल करते हैं। अगर इसमें उन use cases को भी शामिल किया जाता जहाँ खुद implement करना उचित है, तो यह अधिक दिलचस्प होता। तब पाठक “कभी खुद मत करो” जैसे बचकाने मॉडल की बजाय कुछ उपयोगी सीख पाते

  निपुणता का मतलब है खुद बनाने का ज्ञान और कौशल होना, और साथ ही यह जानने की बुद्धि भी कि कब ऐसा नहीं करना चाहिए

  फिर भी शिकायतों से सहानुभूति है। मेरी भी ऐसी कई शिकायतें रही हैं। समस्या यह है कि web interactions को इस स्तर तक गहराई और व्यापकता से document करने का प्रयास बहुत कम रहा है कि web developers आसानी से उनका संदर्भ ले सकें। programming से जुड़ा ज्ञान ठीक से document नहीं होता और अगली पीढ़ी तक पहुँचा नहीं पाता—यह एक गंभीर समस्या है—इसलिए वही समस्याएँ बार-बार फिर खोजी जाती हैं। आम तौर पर industry के भीतर standard behaviors और interactions के कुछ समूह विजेता बनकर उभरते हैं, लेकिन कोई उन्हें लिखकर नहीं रखता