क्लाइंट-साइड एन्क्रिप्शन स्टोर किए गए सीक्रेट को ऑपरेटर से और डेटाबेस हाथ लगने वाले किसी भी व्यक्ति से बचाता है, इससे ज़्यादा कुछ नहीं। गलत नीयत वाली JavaScript, कोई ब्राउज़र एक्सटेंशन या लीक हुआ लिंक इसे बेकार कर देता है, क्योंकि एन्क्रिप्शन कुंजी लिंक के साथ ही चलती है। यह हर समस्या का हल नहीं है, और अपनी एक गारंटी की कीमत दूसरी जगहों पर वसूलता है।
यह गाइड बताती है कि ब्राउज़र में होने वाला एन्क्रिप्शन क्या गारंटी देता है, कहां चुपचाप काम करना बंद कर देता है, सर्वर-साइड मॉडल से इसकी तुलना कैसी है, और LinkPilot 29 सितंबर 2026 से दोनों को कैसे मिलाता है। उसी दिन LinkPilot का वन-टाइम सीक्रेट लिंक जनरेटर ब्राउज़र में एन्क्रिप्ट करने लगा।
19 अक्टूबर 2026 को दोबारा लिखा गया। इस लेख का मूल संस्करण LinkPilot के उस समय के सर्वर-साइड मॉडल के बारे में था; 29 सितंबर 2026 को जोड़े गए एक नोट में बदलाव दर्ज किया गया था। यह संस्करण शुरू से अंत तक मौजूदा मॉडल के बारे में है। कौन-सा मॉडल किससे बचाता है और किससे नहीं, यह तर्क नहीं बदला है।
क्लाइंट-साइड एन्क्रिप्शन असल में किससे बचाता है?
स्टोर किए गए सीक्रेट को ऑपरेटर से और डेटाबेस हाथ लगने वाले किसी भी व्यक्ति से। क्लाइंट-साइड एन्क्रिप्शन वाले सीक्रेट टूल में (जिसे एंड-टू-एंड एन्क्रिप्टेड या E2EE भी कहते हैं) काम ऐसे होता है:
- ब्राउज़र एक सिमेट्रिक कुंजी बनाता है, आम तौर पर Web Crypto API (
crypto.subtle.generateKey) से 256-बिट की AES-GCM कुंजी। - उसी कुंजी से पेलोड ब्राउज़र में एन्क्रिप्ट होता है।
- सर्वर को सिर्फ़ एन्क्रिप्ट किया हुआ डेटा (सिफ़रटेक्स्ट) भेजा जाता है, जिसे वह एक रैंडम पहचानकर्ता के तहत स्टोर करता है।
- कुंजी शेयर लिंक के आखिर में फ़्रैगमेंट (
#…) के रूप में जोड़ी जाती है। RFC 3986, सेक्शन 3.5 के अनुसार ब्राउज़र HTTP रिक्वेस्ट में फ़्रैगमेंट कभी नहीं भेजते, इसलिए कुंजी सर्वर तक नहीं पहुंचती। - लिंक खोलने वाले व्यक्ति का ब्राउज़र फ़्रैगमेंट पढ़ता है, एन्क्रिप्ट किया हुआ डेटा मंगाता है और उसे वहीं डिक्रिप्ट करता है।
सर्वर को कभी भी सिर्फ़ एन्क्रिप्ट किया हुआ डेटा दिखता है। ऑपरेटर अपना ही डेटाबेस पढ़े, डेटाबेस का बैकअप लीक हो जाए, या स्टोर किए गए डेटा के लिए कानूनी आदेश आ जाए, किसी से भी सीक्रेट हाथ नहीं लगता। शर्त यह है कि बाकी हर कड़ी मज़बूत रहे।
E2EE सीक्रेट लिंक की बनावट
https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘
# से पहले का सब कुछ रिक्वेस्ट के साथ जाता है और सर्वर और प्रॉक्सी के लॉग में दिख सकता है। फ़्रैगमेंट को सिर्फ़ लिंक खोलने वाले व्यक्ति का ब्राउज़र प्रोसेस करता है। सुरक्षा का पूरा काम यही एक कैरेक्टर करता है। यह तरीका सुंदर है, और नीचे बताई गई ज़्यादातर कमज़ोरियों की जड़ भी यही है।
क्लाइंट-साइड एन्क्रिप्शन किससे नहीं बचाता?
गलत नीयत वाली या हैक हुई JavaScript से, ब्राउज़र एक्सटेंशन से और लीक हुए लिंक से, क्योंकि कुंजी लिंक में ही होती है।
- यह गलत नीयत वाली JavaScript से नहीं बचाता। एन्क्रिप्शन का कोड ब्राउज़र में चलता है, और ब्राउज़र को वह कोड सर्वर से ही मिलता है। अगर सर्वर बदला हुआ कोड भेजे, चाहे ऑपरेटर की नीयत बदल गई हो, उस पर दबाव डाला गया हो या उसे हैक कर लिया गया हो, तो सीक्रेट एन्क्रिप्शन से पहले या डिक्रिप्शन के बाद पढ़ा जा सकता है। ब्राउज़र पर आधारित E2EE की यही बुनियादी सीमा है।
- यह ब्राउज़र एक्सटेंशन से नहीं बचाता। जिस एक्सटेंशन को पेज का एक्सेस है, वह डिक्रिप्शन के बाद असली टेक्स्ट देख सकता है और फ़्रैगमेंट को सीधे पढ़ सकता है।
- यह लीक हुए लिंक को बेअसर नहीं करता। कुंजी लिंक का हिस्सा है। अगर प्राप्तकर्ता पूरा लिंक चैट में पेस्ट कर दे, ईमेल आगे भेज दे या ब्राउज़र हिस्ट्री सिंक चालू रखे, तो कुंजी भी साथ चली जाती है। जिस E2EE लिंक का URL लीक हो गया, उसका सीक्रेट पूरी तरह पढ़ा जा सकता है। इससे बचाव का एक ही तरीका है: किसी दूसरे रास्ते से भेजा गया पासफ़्रेज़। इसी वजह से LinkPilot पासफ़्रेज़ को अलग से जांचने के बजाय उसे कुंजी में मिला देता है।
- यह कंटेंट का ऑडिट, स्कैन या प्रीव्यू नहीं करता। सर्वर पेलोड पढ़ ही नहीं सकता, इसलिए वह उस पर कंटेंट फ़िल्टरिंग, मैलवेयर स्कैनिंग या डेटा-लॉस प्रिवेंशन नहीं कर सकता। कंट्रोल को एन्क्रिप्ट किए हुए डेटा और एक्सेस इवेंट पर ही काम करना पड़ता है।
कोड पहुंचाने की समस्या, साफ़ शब्दों में
इस बात पर ठहरकर सोचना चाहिए: ब्राउज़र E2EE का मतलब है कि जिस सर्वर पर आप भरोसा नहीं करते, उसी पर हर पेज लोड पर ईमानदार JavaScript भेजने का भरोसा करना। नेटिव ऐप एक बार इंस्टॉल होता है, साइन किया हुआ होता है और उसका वर्ज़न तय होता है; वेब पेज हर बार नए सिरे से लोड होता है। Subresource Integrity और पब्लिश किया गया सोर्स कोड इस खाई को कम करते हैं, पाटते नहीं।
इसलिए “हम आपके सीक्रेट नहीं पढ़ सकते” का ईमानदार मतलब है “हम आपके सीक्रेट चुपचाप बैठे-बैठे नहीं पढ़ सकते”। इस निष्क्रिय क्षमता को बदले हुए कोड वाले सक्रिय हमले में बदलना हमलावर के लिए बड़ा कदम है (सक्रिय हमले ज़्यादा जोखिम भरे होते हैं, किसी खास निशाने पर होते हैं और पकड़े जा सकते हैं), लेकिन यह “नामुमकिन” के बराबर नहीं है। यह बात LinkPilot के दावे पर भी उतनी ही लागू होती है जितनी किसी और के दावे पर।
सर्वर-साइड विकल्प
दूसरा आम डिज़ाइन, जिसे LinkPilot सितंबर 2026 तक इस्तेमाल करता था, सर्वर पर स्टोर होते समय एन्क्रिप्ट करता है और सीक्रेट दिखाने की प्रक्रिया को हैश किए गए पासफ़्रेज़ से सुरक्षित रखता है:
- भेजते समय TLS; पेलोड एक अलग टेबल में, ऐसे डेटाबेस पर स्टोर होते हैं जिसकी डिस्क एन्क्रिप्टेड है।
- पासफ़्रेज़ भेजने से पहले ब्राउज़र में हैश होते हैं और हैश से ही मिलाए जाते हैं; असली पासफ़्रेज़ कभी डेटाबेस तक नहीं पहुंचता।
- पूरी तरह मिटाना: पहली बार दिखने, एक्सपायर होने या वापस लिए जाने पर स्टोर किया गया पेलोड ओवरराइट हो जाता है, और बाद की कोशिशों को HTTP 410 मिलता है।
- पासफ़्रेज़ की कोशिशों पर रेट लिमिट होती है और वे लॉग होती हैं।
इस मॉडल में सर्वर किसी चालू सीक्रेट को पढ़ सकता है। इसी से सर्वर पर प्रीव्यू, स्कैनिंग और कंटेंट समझने वाली सुविधाएं मुमकिन होती हैं, और E2EE ठीक यही क्षमता हटा देता है। OneTimeSecret जैसे ओपन सोर्स टूल अब भी इसी मॉडल पर चलते हैं; क्या OneTimeSecret सुरक्षित है? इसके नतीजों को देखता है।
LinkPilot अब क्या करता है
29 सितंबर 2026 से LinkPilot क्लाइंट-साइड एन्क्रिप्शन इस्तेमाल करता है और सर्वर-साइड के वे कंट्रोल रखता है जिन्हें कंटेंट की ज़रूरत नहीं होती। सुरक्षा आर्किटेक्चर पेज के अनुसार:
- ब्राउज़र में एन्क्रिप्शन। पेलोड AES-GCM-256 से, भेजने वाले के ब्राउज़र में बनी 256-बिट कुंजी के साथ एन्क्रिप्ट होता है। सर्वर सिर्फ़ एन्क्रिप्ट किया हुआ डेटा स्टोर करता है और कुछ नहीं; कुंजी शेयर लिंक में # के बाद वाले हिस्से में रहती है।
- पासफ़्रेज़ कुंजी का हिस्सा (Pro)। पासफ़्रेज़ को PBKDF2-SHA256 (2,10,000 इटरेशन) से मज़बूत किया जाता है और HKDF-SHA256 से लिंक की कुंजी के साथ मिलाया जाता है। इसलिए न अकेला लिंक सीक्रेट को डिक्रिप्ट कर सकता है, न अकेला पासफ़्रेज़। कोशिशें हर सीक्रेट के लिए प्रति IP प्रति मिनट 5 तक सीमित हैं, जिसके लिए एक इन-मेमरी लिमिटर और डेटाबेस पर चलने वाली स्लाइडिंग विंडो दोनों काम करते हैं।
- एन्क्रिप्ट किए हुए डेटा पर पढ़ते ही मिटाना। खुलने को एक डेटाबेस फ़ंक्शन एक ही स्टेप में दर्ज करता है, जिसे बीच में तोड़ा नहीं जा सकता, इसलिए एक साथ आई कई कोशिशें सीक्रेट को दो बार लीक नहीं कर सकतीं। स्टोर किया गया डेटा
[REDACTED]से ओवरराइट हो जाता है और बाद की कोशिशों को HTTP 410 मिलता है। - लिंक वापस लेना। सीक्रेट को डैशबोर्ड से कभी भी वापस लिया जा सकता है; वापस लिए गए सीक्रेट नहीं खुलते और 410 लौटाते हैं।
- प्रीव्यू से सीक्रेट नहीं खुलता। लिंक प्रीव्यू बॉट और ईमेल स्कैनर GET रिक्वेस्ट भेजते हैं, जिनके जवाब में सिर्फ़ मेटाडेटा जाता है (स्थिति, और क्या पासफ़्रेज़ ज़रूरी है)। खुलना सिर्फ़ तब दर्ज होता है जब कोई ब्राउज़र से जान-बूझकर सीक्रेट दिखाता है।
- ऑडिट टाइमलाइन (Pro)। बनाया गया, खोला गया, गलत पासफ़्रेज़, मिटाया गया, एक्सपायर हुआ और वापस लिया गया, हर इवेंट के साथ समय, एज सर्वर से मिली देश और शहर की जानकारी, ब्राउज़र स्ट्रिंग और रोज़ बदलने वाले सॉल्ट के साथ एड्रेस का हैश। टाइमलाइन एक्सेस दर्ज करती है, कंटेंट कभी नहीं।
- फ़ाइलें। अटैचमेंट भी ब्राउज़र में ही एन्क्रिप्ट होते हैं, लिंक की कुंजी से बनी एक कुंजी के साथ। फ़ाइल का नाम, साइज़ और प्रकार मेटाडेटा के रूप में LinkPilot को दिखते रहते हैं।
तीन सीमाएं, साफ़ शब्दों में। 29 सितंबर 2026 से पहले बने सीक्रेट एक्सपायर होने तक बिना एन्क्रिप्शन वाले टेक्स्ट के रूप में स्टोर रहे; उन्हें कभी दोबारा नहीं लिखा गया। फ़ाइल का कंटेंट न दिखने पर भी उसका मेटाडेटा दिखता है। और “यह किससे नहीं बचाता” वाले हिस्से में लिखी हर बात लागू होती है: गलत नीयत वाली JavaScript, ब्राउज़र एक्सटेंशन और लीक हुए लिंक की समस्या न यह मॉडल हल करता है, न ब्राउज़र पर आधारित कोई दूसरा मॉडल।
फ़ायदे-नुकसान का सार
| चिंता | क्लाइंट-साइड E2EE (शुद्ध) | सर्वर-साइड + हैश किया गया पासफ़्रेज़ | सितंबर 2026 से LinkPilot |
|---|---|---|---|
| ऑपरेटर स्टोर किए गए सीक्रेट पढ़ता है (निष्क्रिय) | बचाव है | भरोसा करना पड़ता है | बचाव है: सिर्फ़ एन्क्रिप्ट किया हुआ डेटा, कुंजी नहीं |
| ऑपरेटर गलत नीयत वाली JavaScript भेजता है | बचाव नहीं | बचाव नहीं | बचाव नहीं |
| हैक हुई JS / सप्लाई चेन | बचाव नहीं | बचाव नहीं | बचाव नहीं |
| डेटाबेस डंप वाला हमलावर | बचाव है (एन्क्रिप्ट किया हुआ डेटा) | स्टोरेज एन्क्रिप्शन से बचाव; मिट चुके पेलोड पहले ही हटाए जा चुके | बचाव है (एन्क्रिप्ट किया हुआ डेटा; मिट चुके पेलोड हटाए गए) |
| लीक हुआ लिंक, बिना पासफ़्रेज़ | पढ़ा जा सकता है: कुंजी लिंक में है | मिटने या एक्सपायरी तक पढ़ा जा सकता है | मिटने या एक्सपायरी तक पढ़ा जा सकता है; कम एक्सपायरी ही बचाव है |
| लीक हुआ लिंक, पासफ़्रेज़ के साथ | टूल पर निर्भर | हैश की जांच से सुरक्षित | सुरक्षित: पासफ़्रेज़ कुंजी का हिस्सा है (Pro) |
| लिंक प्रीव्यू या स्कैनर लिंक खोलता है | टूल पर निर्भर | टूल पर निर्भर | GET सिर्फ़ मेटाडेटा लौटाता है; सीक्रेट नहीं दिखता |
| ऑडिट लॉग | सिर्फ़ एक्सेस इवेंट | पूरा जीवनचक्र | पूरा जीवनचक्र, एक्सेस इवेंट के आधार पर (Pro) |
| सर्वर पर कंटेंट स्कैनिंग / DLP | नहीं | मुमकिन | नहीं |
| एडमिन और टीम को दिखना | नहीं | सेट किया जा सकता है | वर्कस्पेस रोल, टाइमलाइन, लिंक वापस लेना; कंटेंट नहीं |
अपने आप में कोई मॉडल “ज़्यादा सुरक्षित” नहीं है। वे अलग-अलग खतरों से अलग-अलग कीमत पर बचाते हैं। उन्हें मिलाने से जिन चीज़ों को छोड़ना पड़ता है उनकी सूची छोटी होती है, खत्म नहीं होती।
खतरे के हिसाब से मॉडल: तीन स्थितियां
1. किसी कॉन्ट्रैक्टर को डेटाबेस पासवर्ड भेजना। खतरा यह है कि सीक्रेट ईमेल या चैट में पड़ा रह जाए, या गलती से आगे भेज दिया जाए। कम एक्सपायरी और पढ़ते ही मिटाने के साथ कोई भी मॉडल इसे संभाल लेता है; फ़ैसला इस्तेमाल में आसानी और रिकॉर्ड से होता है। ब्राउज़र में एन्क्रिप्शन, किसी दूसरे रास्ते से भेजा गया पासफ़्रेज़ और लिंक कब खुला यह दिखाने वाली टाइमलाइन, यही व्यावहारिक चुनाव है।
2. किसी पत्रकार को सूत्र से सामग्री मिलना। यहां खतरे में यह भी शामिल है कि प्लेटफ़ॉर्म के ऑपरेटर को जानकारी देने के लिए मजबूर किया जाए। ऑपरेटर खुद खतरे का हिस्सा है, इसलिए E2EE कम से कम ज़रूरत है, और SecureDrop जैसे खास इसी काम के लिए बने टूल, जिनका पूरा सिस्टम इसी खतरे को ध्यान में रखकर बना है, सही चुनाव हैं। जिस वेब टूल को बदली हुई JavaScript भेजने के लिए मजबूर किया जा सकता है, वह अकेले काफ़ी नहीं है।
3. रोज़ लॉगिन की जानकारी सौंपने वाली इंजीनियरिंग टीम। खतरा बिखराव है: भूले हुए लिंक, और कोई रिकॉर्ड नहीं कि किसने क्या देखा। यहां काम की सुविधाएं हैं टाइमलाइन, लिंक वापस लेना, वर्कस्पेस रोल और एक्सपायरी की नीति। पहले इनके लिए ऐसा सर्वर चाहिए था जो कंटेंट पढ़ सके; अब नहीं, क्योंकि ये एन्क्रिप्ट किए हुए डेटा और एक्सेस इवेंट पर काम करती हैं। इस स्थिति का नीति वाला पहलू टीमों के लिए सुरक्षित पासवर्ड शेयरिंग में है।
कैसे चुनें
क्लाइंट-साइड एन्क्रिप्शन चुनें जब:
- आप ऑपरेटर पर भरोसा नहीं करते, उस स्थिति में भी जब ऑपरेटर आप खुद हों और ऐसे क्लाउड इंफ़्रास्ट्रक्चर पर चला रहे हों जिसे आप पूरी तरह जांच नहीं सकते।
- नियमों या कॉन्ट्रैक्ट के मुताबिक प्रोवाइडर के लिए कंटेंट पढ़ना तकनीकी रूप से असंभव होना चाहिए।
- आप पासफ़्रेज़ किसी दूसरे रास्ते से भेजेंगे और एक्सपायरी कम रखेंगे, क्योंकि वरना लीक हुआ लिंक ही पूरा सीक्रेट है।
सर्वर-साइड एन्क्रिप्शन चुनें जब:
- आपको सर्वर से कंटेंट की जांच करवानी हो: मैलवेयर स्कैनिंग, डेटा-लॉस प्रिवेंशन, कंटेंट फ़िल्टरिंग।
- आप एक ही काम वाला टूल सेल्फ़-होस्ट कर रहे हैं और ऑपरेटर आप ही हैं।
दोनों देखें जब:
- आप ऑपरेटर को भरोसे की कड़ी से बाहर रखना चाहते हैं, लेकिन आपको टाइमलाइन, लिंक वापस लेने की सुविधा, टीम रोल और ऐसी व्यवस्था भी चाहिए जिसमें लिंक प्रीव्यू से सीक्रेट न खुल सके। वेंडर से पूछें कि कौन-से कंट्रोल एन्क्रिप्ट किए हुए डेटा पर काम करते हैं और किन्हें चुपचाप असली टेक्स्ट चाहिए।
क्या ऑनलाइन एन्क्रिप्शन टूल सही चुनाव है?
ऑनलाइन एन्क्रिप्शन टूल खोजने वाले लोग आम तौर पर दो में से एक चीज़ चाहते हैं: किसी टेक्स्ट को ऐसे एन्क्रिप्टेड रूप में बदलना जिसे कहीं भी पेस्ट किया जा सके, या कोई संवेदनशील मैसेज किसी एक व्यक्ति तक सुरक्षित पहुंचाना। पहला एक टूल है। दूसरा पूरा काम है, और अकेला टूल उसे पूरा नहीं करता।
टेक्स्ट पेस्ट करके एन्क्रिप्ट करने वाला पेज, अगर ठीक से बना है, तो एन्क्रिप्शन आपके ब्राउज़र में करता है। इसे आप नीचे “दावे की जांच” वाले हिस्से के स्टेप से परख सकते हैं। एन्क्रिप्ट किए हुए डेटा के आसपास का सारा काम आप पर छोड़ दिया जाता है: मज़बूत पासफ़्रेज़ चुनना, पासफ़्रेज़ किसी अलग रास्ते से भेजना, जहां भी एन्क्रिप्टेड टेक्स्ट पेस्ट किया उसे वहां से मिटाना, और यह पता करना कि प्राप्तकर्ता उसे डिक्रिप्ट कर पाया या नहीं। एन्कोडिंग एन्क्रिप्शन नहीं है, इसलिए Base64 टूल किसी चीज़ को सुरक्षित नहीं करता। और कमज़ोर पासफ़्रेज़ ही वह आम वजह है जिससे ब्राउज़र में होने वाला एन्क्रिप्शन असल में नाकाम होता है।
वन-टाइम सीक्रेट लिंक वही ब्राउज़र वाला एन्क्रिप्शन करता है और बाकी काम भी संभालता है: कुंजी लिंक में # के बाद वाले हिस्से में जाती है, पहली बार खुलते ही स्टोर की गई कॉपी मिट जाती है, कोई न खोले तो लिंक एक्सपायर हो जाता है, और भेजने वाला देख सकता है कि सीक्रेट दिखाया जा चुका है। किसी व्यक्ति को मैसेज भेजने के लिए यही बेहतर है। जिस एन्क्रिप्टेड डेटा को आपको खुद रखना है, या अपने कंट्रोल वाले सिस्टम में पेस्ट करना है, उसके लिए age या GPG जैसा लोकल टूल किसी भी वेब पेज से बेहतर है, क्योंकि कुंजी कभी ब्राउज़र को छूती ही नहीं।
कब इनमें से कोई भी इस्तेमाल न करें
कुछ सीक्रेट किसी भी शेयरिंग लिंक से नहीं भेजने चाहिए। लंबे समय तक चलने वाली रूट लॉगिन जानकारी, प्रोडक्शन साइनिंग कुंजियां और बड़े डेटा एक्सपोर्ट एक्सेस कंट्रोल वाले सीक्रेट मैनेजर या KMS में रखे जाने चाहिए, URL में नहीं। और अगर प्राप्तकर्ता को वह जानकारी बार-बार चाहिए, तो बार-बार लिंक भेजने से पासवर्ड मैनेजर के वॉल्ट में रखी एंट्री बेहतर है। एक बार की डिलीवरी सौंपने के लिए है, स्टोर करने के लिए नहीं। सीक्रेट लिंक बनाम पासवर्ड मैनेजर यह फ़र्क साफ़ करता है।
दावे की जांच
किसी टूल को इस आधार पर न चुनें कि कौन ज़्यादा दावे करता है। इस आधार पर चुनें कि आप किस खतरे से बचना चाहते हैं, और जांचें कि ऊपर लिखा दावा अंदर के आर्किटेक्चर से मेल खाता है:
- क्या कुंजी फ़्रैगमेंट में है? लिंक की बनावट देखें; कुंजी
#के बाद होनी चाहिए। - क्या लिंक को सीधे फ़ेच करने पर सीक्रेट मिल जाता है? नहीं मिलना चाहिए।
- पासफ़्रेज़ क्या करता है: सिर्फ़ सीक्रेट दिखाने से पहले जांच, या कुंजी का हिस्सा बनना?
- क्या-क्या लॉग होता है, और क्या ऑपरेटर इसे लिखित में बताता है?
LinkPilot के जवाब, सीमाओं समेत, सुरक्षा आर्किटेक्चर पेज पर हैं। उस पेज पर भी वही जांच लागू होती है जो किसी और के पेज पर।
इससे जुड़े लेख
- वन-टाइम सीक्रेट लिंक कैसे काम करते हैं
- क्या OneTimeSecret सुरक्षित है?
- LinkPilot बनाम PrivateBin
- सीक्रेट लिंक बनाम पासवर्ड मैनेजर
- URL से संवेदनशील जानकारी क्यों लीक होती है
- लिंक स्कैनर और वन-टाइम सीक्रेट
संदर्भ
- W3C, Web Cryptography API.
- NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
- IETF, RFC 3986, section 3.5 Fragment.
- Freedom of the Press Foundation, SecureDrop.