हस्ताक्षर की अखंडता बनाए रखते हुए प्रकट करें

एक डिजिटल उत्पाद पासपोर्ट सभी को एक जैसी जानकारी नहीं दिखाता है। एक खरीदार सार्वजनिक डेटा देखता है। एक मरम्मत की दुकान या नवीनीकरण करने वाला अधिक देखता है। एक बाजार निगरानी प्राधिकरण सब कुछ देखता है। इसे स्पष्ट कर दिया गया है, और अब यूरोपीय मानक इसे स्पष्ट रूप से निर्दिष्ट करते हैं।

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

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

हर कोई पहुँच नियम का एक ही तरह से पालन करता है

डीपीपी में पहुँच अधिकारों, सुरक्षा और गोपनीयता के लिए यूरोपीय मानक, EN 18239, प्रत्येक डेटा-तत्व के आधार पर पहुँच नियंत्रण की आवश्यकता है: प्रत्येक फ़ील्ड के लिए, एक नियम है जो यह नियंत्रित करता है कि इसे कौन देख सकता है। यह सही आवश्यकता है, और इसे पूरा करना मुश्किल नहीं है। हमने इन मानकों की स्थिति को harmonised standards के अंतर्गत विस्तार से बताया है।

इसे हासिल करने का सामान्य तरीका सर्वर-साइड फ़िल्टरिंग के माध्यम से है। सर्वर जानता है कि अनुरोध कौन कर रहा है, यह जाँचता है कि उस व्यक्ति को क्या देखने की अनुमति है, और ठीक उसी खंड को वापस करता है। एक्सेस कंट्रोल: हल हो गया। मानक को इससे ज़्यादा कुछ नहीं चाहिए।

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

जहाँ एकल हस्ताक्षर अपनी सीमा तक पहुँच जाता है

स्पष्ट समाधान डेटा पर हस्ताक्षर करना है। दोनों सिरों के लिए, एक मानक हस्ताक्षर अच्छी तरह से काम करता है: सार्वजनिक दृश्य पर हस्ताक्षर करें, संपूर्ण डेटा सेट पर हस्ताक्षर करें, और सर्वर को मध्यस्थ के रूप में कार्य किए बिना दोनों की सार्वजनिक कुंजी के खिलाफ जांच करें। यह विस्तार से कैसे काम करता है, इसकी व्याख्या DPP में हस्ताक्षर और प्रमाणपत्र में की गई है।

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

इसलिए मध्यवर्ती चरण छूट जाते हैं: मरम्मत की दुकान, बीमाकर्ता, पुनर्चक्रणकर्ता। यदि किसी संभावित ‘कौन-क्या-देखता है’ संयोजन पर पहले से ही हस्ताक्षर किए जाएं, तो प्रत्येक संयोजन के लिए एक अलग हस्ताक्षरित दस्तावेज़ की आवश्यकता होगी, और प्रत्येक अतिरिक्त एक्सेस समूह के साथ संयोजनों की संख्या आसमान छू लेती है। कोई भी ऐसा नहीं करता है। लोग बिना हस्ताक्षर वाले सर्वर फ़िल्टर पर वापस चले जाते हैं, और मध्यवर्ती चरण एक बार फिर से भरोसे पर निर्भर करता है।

प्रत्येक फ़ील्ड को व्यक्तिगत रूप से हस्ताक्षरित करना

एक बेहतर तरीका है, और यह वही तरीका है जिस पर हम प्लेटफ़ॉर्म बना रहे हैं। तैयार दस्तावेज़ को एक ही ब्लॉक के रूप में साइन करने के बजाय, जारीकर्ता एक ही साइनिंग पास में प्रत्येक फ़ील्ड को व्यक्तिगत रूप से निर्दिष्ट करता है (जो मानकों से परिचित हैं उनके लिए: चयनात्मक प्रकटीकरण के लिए W3C विनिर्देश ecdsa-sd-2023)।

हर व्यू सार्वजनिक कोर से शुरू होता है

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

क्यों ‘अखंड’ ही पूरी बात है

एक ऐसे नोटरी की कल्पना करें जो पत्र को पूरे रूप में प्रमाणित नहीं करता है, बल्कि प्रत्येक पैराग्राफ़ को अलग से प्रमाणित करता है। सभी को सार्वजनिक पत्र मिलता है। जिस किसी को भी और अधिक प्राप्त करने का अधिकार है, उसे अतिरिक्त पैराग्राफ मिलते हैं, और इनमें से प्रत्येक पर उसी नोटरी की मुहर लगी रहती है। सामान्य प्रक्रिया में, प्लेटफ़ॉर्म आपके लिए इन पैराग्राफों को टाइप करता है, और जो आपको मिलता है उसमें केवल उसकी अपनी मुहर होती है।

‘अखंड’ इतना महत्वपूर्ण क्यों है, इस पर थोड़ा और विस्तार से समझाना उचित होगा। एक अखंड मुहर का मतलब यह नहीं है कि सामग्री सच है। इसका मतलब है: यह बिल्कुल वही है जो जारीकर्ता ने लिखा था, और तब से किसी ने भी एक अक्षर को भी नहीं बदला है। इसका मतलब है कि जिसने भी केवल दस्तावेज़ को आगे भेजा है - मध्यस्थ, नेटवर्क, अभिलेखागार, हम - वह विश्वास के प्रश्न से बाहर है। पासपोर्ट आपको किसने दिया, यह अब मायने नहीं रखता।

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

देखने के दोनों तरीके

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

दोनों W3C विनिर्देश खुले हैं: दस्तावेज़-व्यापी हस्ताक्षर के लिए eddsa-jcs-2022, और फ़ील्ड-दर-फ़ील्ड प्रकटीकरण के लिए ecdsa-sd-2023। कोई भी जो चाहें, उन्हें लागू कर सकता है। इसमें लगने वाली मेहनत ही वजह है कि कई लोग ऐसा नहीं करेंगे: पूरे दस्तावेज़ पर हस्ताक्षर को स्थापित और संचालित करना काफी सस्ता है, और जो कोई भी केवल सार्वजनिक डेटा प्रदान करता है, वह उससे काम चला सकता है।

यह तथ्य कि टाइम मशीन दोनों विधियों का समर्थन करती है, जानबूझकर है और ऐसा ही रहेगा। यह किसी भी प्लेटफ़ॉर्म से संबंधित नहीं है। एक सत्यापनकर्ता जो केवल अधिक महंगी विधि को स्वीकार करता है, वह हमारे लिए एक उपकरण होगा और किसी और के लिए नहीं।

संरक्षित फ़ील्ड किसके सामने प्रकट किए जाते हैं

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

और ये ही वे क्षेत्र हैं जो मानक दृष्टिकोण के तहत प्रकट नहीं किए जाते हैं। जिनके पास क्रिप्टोग्राफिक सत्यापन चाहने का सबसे बड़ा कारण है, उन्हें वह भी उन क्षेत्रों के लिए नहीं मिलता है, जो उनके निर्णय की नींव हैं।

हमारा मानना है कि एक प्रमाणन चिह्न का अर्थ सभी के लिए एक जैसा होना चाहिए। ‘Transpareo द्वारा सत्यापित’ का अर्थ मरम्मत कार्यशाला की विस्तृत रिपोर्ट पर उतना ही है जितना कि एक खरीदार के सार्वजनिक प्रमाण पत्र पर: प्रदर्शित हर फ़ील्ड जारीकर्ता से उत्पन्न हुई है और तब से उसमें छेड़छाड़ नहीं की गई है। एक मुहर जो केवल सार्वजनिक फ़ील्ड को कवर करती है, वह केवल आधी मुहर है।

मानक की आवश्यकता से अधिक

स्पष्ट रूप से कहें तो: यह सब अनिवार्य नहीं है। EN 18239 यह आवश्यक करता है कि पहुंच को नियंत्रित किया जाए, और एक सर्वर-साइड फ़िल्टर पहुंच को पूरी तरह से नियंत्रित करता है। प्रकटीकृत फ़ील्ड को क्रिप्टोग्राफ़िक रूप से सत्यापनीय बनाना कुछ ऐसा है जो हम इसके अलावा करते हैं; यह विनियमन द्वारा आवश्यक रूप से पूरा किया जाने वाला एक औपचारिकता नहीं है।

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

इसी सिद्धांत का मतलब है कि एक फ़ील्ड की अनदेखी की जाती है

प्रत्येक फ़ील्ड को व्यक्तिगत रूप से प्रतिबद्ध करने से एक दूसरी आवश्यकता सामने आती है, और यह वास्तव में यूरोपीय कानून द्वारा अनिवार्य है। सामान्य डेटा संरक्षण विनियमन लोगों को अपना व्यक्तिगत डेटा मिटाने का अधिकार देता है। एक ही ब्लॉक के रूप में हस्ताक्षरित एक डेटा रिकॉर्ड अपने स्वयं के हस्ताक्षर को नष्ट किए बिना इस अनुपालन को नहीं कर सकता है।

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

फिर भी, यह एक बिल्कुल साधारण पासपोर्ट है

इसमें से कोई भी पासपोर्ट को एक ऐसी विशेष वस्तु में नहीं बदलता जिसे केवल हमारे उपकरण ही खोल सकें। यह JSON-LD में एक सत्यापन योग्य प्रमाणपत्र (Verifiable Credential) बना रहता है, यह वह प्रारूप है जिसकी ओर वेब मानकों की दुनिया बढ़ रही है, और यह वही प्रारूप है जिसका उपयोग संयुक्त राष्ट्र पारदर्शिता प्रोटोकॉल (UN Transparency Protocol) और व्यापक W3C पारिस्थितिकी तंत्र (ecosystem) द्वारा किया जाता है।

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

यह तकनीकी रूप से चुनौतीपूर्ण क्यों है

सबसे पहले, किसी भी गलतफहमी से बचने के लिए: हमने इस प्रक्रिया का आविष्कार नहीं किया है। ecdsa-sd-2023 एक सार्वजनिक W3C विनिर्देश है; इसके पीछे की क्रिप्टोग्राफी हमारी अपनी नहीं है, और इसे लागू करने की इच्छा रखने वाला कोई भी व्यक्ति इसके बारे में पढ़ सकता है। यह विचार लेकर आना मुश्किल नहीं है। कठिनाई इसे इस तरह से बनाने में है कि दस साल बाद भी एक पास मान्य रहे। असली काम वहीं है, और इसके बारे में कुछ उपयोगी बातें कही जा सकती हैं।

यह अंतर मामूली लग सकता है, लेकिन यह मौलिक दृष्टिकोण को बदल देता है: एक मानक हस्ताक्षर दस्तावेज़ के बाइट्स पर गणना करता है। चयनात्मक प्रकटीकरण अपने बयानों के आधार पर गणना करता है। हस्ताक्षर करने से पहले, पासपोर्ट को एक मानकीकृत रूप में बदल दिया जाता है जिसमें प्रत्येक जानकारी को एक अलग, स्व-निहित बयान के रूप में प्रस्तुत किया जाता है। तभी बाकी बयानों से समझौता किए बिना किसी एक बयान को छोड़ना संभव होता है।

यह एक ऐसी समस्या पेश करता है जो बाइट-आधारित हस्ताक्षर में नहीं होती है: दस साल बाद भी बिल्कुल उसी मानकीकृत रूप को फिर से तैयार करना होगा। लगभग नहीं, बल्कि अक्षर-दर-अक्षर; अन्यथा, प्रमाण मान्य नहीं रहेगा। इसके रास्ते में तीन चीजें हैं, और तीनों ही स्पष्ट नहीं हैं।

संख्याएँ अपना प्रकार खो देती हैं। यदि आप किसी संख्या को साधारण JSON के रूप में लिखते हैं, तो यह जानकारी कि यह किस प्रकार की संख्या थी, रास्ते में खो जाती है। JSON से गुज़रने के बाद 2.0 जैसी कोई मान 2 के रूप में वापस आती है। एक इंसान के लिए यह वही है; मानकीकृत रूप के लिए, यह एक अलग कथन है, और सत्यापन विफल हो जाता है।

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

अर्थ आमतौर पर ऑनलाइन मिलते हैं। यह मैपिंग एक शब्दावली में होती है जिसे ज़्यादातर टूल सत्यापन के दौरान वेब से प्राप्त करते हैं। जो कोई भी ऐसा करता है, वह अपने पासपोर्ट की वैधता को एक तीसरे पक्ष के पते पर निर्भर कर देता है जो दस साल बाद भी प्रतिक्रिया दे रहा हो - और अपरिवर्तित बना रहे।

हमने इसे कैसे हल किया

हमने इन तीनों समस्याओं को बाद में पकड़ने के बजाय, स्रोत पर ही हल किया।

प्रकार। हर मान (value) अपने प्रकार (type) के साथ लिखा जाता है, और जैसे ही मानकीकृत रूप में एक भी बिना प्रकार का संख्या (untyped number) दिखाई देता है, प्रकाशन रोक दिया जाता है। इस प्रकार त्रुटि का पता वहीं चल जाता है जहाँ यह कोड की एक ही लाइन की लागत आती है, बजाय इसके कि सालों बाद यह एक अस्पष्ट सत्यापन विफलता के रूप में सामने आए।

शब्दावलियाँ। पास द्वारा संदर्भित हर शब्दावली हमारे सिस्टम पर स्थानीय रूप से संग्रहीत की जाती है और इसे कभी भी इंटरनेट के माध्यम से प्राप्त नहीं किया जाता है। एक अज्ञात पता साइनिंग के दौरान एक कठोर समाप्ति का परिणाम देता है, न कि खाली परिणाम पर चुपचाप वापस जाने का।

पहचानकर्ता। दस्तावेज़ में हर नोड एक स्थिर पहचानकर्ता रखता है, यह सुनिश्चित करते हुए कि मानकीकृत फॉर्म हर रन के साथ नए सहायक नाम सौंपने के बजाय पुन: उत्पन्न करने योग्य बना रहे।

सबसे पेचीदा हिस्सा ‘अपनी कुंजी स्वयं लाएँ’ (Bring Your Own Key) में निहित है। प्रत्येक जारीकरण के लिए, एक अतिरिक्त, अल्पकालिक कुंजी की आवश्यकता होती है, जिसके साथ प्रकटीकरण योग्य फ़ील्डों पर व्यक्तिगत रूप से हस्ताक्षर किए जाते हैं। जारीकर्ता स्वयं इस कुंजी को बनाता है और उसे नष्ट कर देता है। यदि हम इसे अपने पास रखते, तो हम पूर्वव्यापी रूप से व्यक्तिगत फ़ील्ड बना सकते थे, और जारीकर्ता के हस्ताक्षर की स्वतंत्रता केवल एक दावा भर रह जाती। हम इसे भरोसे में लेने से पहले, लौटाए गए प्रमाण को संग्रहीत सार्वजनिक कुंजी के विरुद्ध सत्यापित करते हैं।

प्रत्येक पासपोर्ट में इस तरह के दो प्रमाण होते हैं: एक जारीकर्ता से और एक ट्रांसपेरियो से, और प्रत्येक पाठक के देखने के लिए स्वतंत्र रूप से व्युत्पन्न किया जाता है। दो हस्ताक्षर, दो स्वतंत्र प्राधिकरण - एक ही प्रकट किए गए क्षेत्र के लिए भी।

हमारे लिए, यह प्रयास सार्थक है। हमने सत्यापनीयता को बाद में जोड़ा नहीं है; यह प्लेटफ़ॉर्म बिल्कुल पहले संस्करण से ही इस सिद्धांत पर बनाया गया था। हर पासपोर्ट को प्रकाशित होते ही हस्ताक्षरित किया जाता है और पिछले संस्करण से जोड़ा जाता है। अपरिवर्तनीय दस-वर्षीय अभिलेखागार स्थापित हो जाता है और जैसे ही पासपोर्ट [ईयू डीपीपी रजिस्टर] के साथ पंजीकृत हो जाते हैं, यह प्रभावी हो जाता है।(/de/blog/dpp-register-ist-gesetz). पूरे ब्लॉक के बजाय प्रत्येक फ़ील्ड पर हस्ताक्षर करना इस मुख्य कार्यक्षमता का एक विस्तार है, न कि किसी ऐसी चीज़ का अतिरिक्त हिस्सा जिसका उद्देश्य कभी इस उद्देश्य के लिए नहीं था।

हमारी स्थिति

सरल शब्दों में, विकल्प सीधा है। आप संरक्षित फ़ील्ड्स को प्रकट कर सकते हैं और पाठक से अपने फ़िल्टर पर भरोसा करने के लिए कह सकते हैं - यह मानक को पूरा करता है। या आप उन्हें प्रकट कर सकते हैं और साथ ही प्रमाण भी प्रदान कर सकते हैं - यह एक उच्च मानक को पूरा करता है, जिसके हम मानते हैं कि ये फ़ील्ड्स हकदार हैं।

हमने हर पाठक के हित में प्रमाण का विकल्प चुना है, क्योंकि एक मुहर का एक ही मतलब होना चाहिए, चाहे उसे कोई भी देखे। जो लोग इसे काम करते हुए देखना चाहते हैं: ऊपर दिए गए दो डेमो स्वयं ब्राउज़र में, ऑफ़लाइन, केवल एक सार्वजनिक कुंजी के खिलाफ सत्यापित होते हैं।