सुरक्षा नीति

Herkos निजी कुंजियाँ और एन्क्रिप्ट किए गए संदेश संभालता है, इसलिए हम सुरक्षा रिपोर्ट को गंभीरता से लेते हैं और किसी समस्या के बारे में देर से नहीं, जल्दी जानना पसंद करते हैं।

किसी कमज़ोरी की रिपोर्ट करना

कृपया सुरक्षा समस्याओं के लिए कोई सार्वजनिक issue न खोलें।

इसकी रिपोर्ट निजी तौर पर security@herkos.email पर ईमेल करके करें।

रिपोर्ट में ये बातें शामिल करना उपयोगी है: समस्या क्या है, उसे दोबारा कैसे पैदा करें, आपने किस प्लेटफ़ॉर्म और वर्शन पर जाँच की, और कोई हमलावर इससे क्या हासिल कर सकता है। प्रूफ़ ऑफ़ कॉन्सेप्ट से बहुत मदद मिलती है।

रिपोर्ट में अपनी nsec, निजी कुंजी या बंकर सीक्रेट कभी शामिल न करें।

हमारा लक्ष्य कुछ ही दिनों में रिपोर्ट मिलने की पुष्टि करना है। क्योंकि Herkos एक छोटा प्रोजेक्ट है, कृपया सार्वजनिक रूप से बताने से पहले सुधार के लिए उचित समय दें। अगर आप न चाहें तो बात अलग है, वरना हमें सुरक्षा सलाह (advisory) में आपको श्रेय देने में ख़ुशी होगी।

दायरे में क्या है

ख़ुद Herkos ऐप्लिकेशन: कुंजी को संभालना और स्टोर करना, संदेशों का एन्क्रिप्शन और डिक्रिप्शन (local_packages/nostr_mail में NIP-59 भेजने वाले की जाँच और Bcc को अलग रखने समेत), ऐप लॉक, रिले और ब्रिज के साथ संचार, अटैचमेंट को संभालना, और बिल्ड और रिलीज़ पाइपलाइन। Herkos Drive के लिए, उसका प्रोटोकॉल पैकेज (packages/herkos_drive_protocol) और उसके लिंक खोलने वाला पेज (herkos.app/f/) भी; नीचे उसका अपना भाग देखें।

दायरे से बाहर क्या है

• ख़ुद Nostr प्रोटोकॉल और उसके NIP — इनकी रिपोर्ट मूल स्रोत (upstream) को करें।
• तीसरे पक्ष द्वारा चलाए जाने वाले रिले, ब्रिज और Blossom सर्वर। Herkos इन्हें डिफ़ॉल्ट के रूप में देता है, लेकिन इन्हें चलाता नहीं; समस्याओं की रिपोर्ट इनके ऑपरेटरों को करें।
• मूल प्रोजेक्ट Nostr Mail Client, जब तक कि समस्या Herkos में किए गए बदलावों से जुड़ी न हो।
• ऐसी सुरक्षा कमियाँ जिन्हें हम पहले से ज्ञात सीमा के रूप में दर्ज कर चुके हैं (नीचे देखें)।

ज्ञात सीमाएँ, साफ़-साफ़

ये डिज़ाइन से जुड़े समझौते हैं, कमज़ोरियाँ नहीं। हम इन्हें पहले ही लिख देना पसंद करते हैं, बजाय इसके कि किसी को ये मुश्किल से पता चलें:

• पारंपरिक पतों पर भेजा गया मेल एंड-टू-एंड एन्क्रिप्टेड नहीं होता। Nostr उपयोगकर्ताओं के बीच संदेश NIP-17 गिफ़्ट रैप का इस्तेमाल करते हैं और E2E एन्क्रिप्टेड होते हैं। जब आप किसी सामान्य ईमेल पते पर लिखते हैं, तो ब्रिज संदेश को बदलता है और उसे पढ़ सकता है।
• ऐप लॉक (PIN और बायोमेट्रिक्स) सुविधा के लिए एक रुकावट है, स्टोर किए गए डेटा का एन्क्रिप्शन नहीं। यह उस व्यक्ति को रोकता है जो किसी अनलॉक डिवाइस को उठा ले; यह उस हमलावर से सुरक्षा नहीं देता जिसके पास डिवाइस या उसके स्टोरेज का पूरा ऐक्सेस हो।
• Windows पर सिर्फ़-बायोमेट्रिक प्रमाणीकरण लागू नहीं किया जा सकता। Windows Hello तरीका चुनने नहीं देता, इसलिए सिस्टम PIN हमेशा विकल्प के रूप में उपलब्ध रहता है।
• कुंजी खोने का मतलब है खाता खोना। कोई रिकवरी नहीं है, यह जान-बूझकर ऐसा है।
• मेटाडेटा पूरी तरह छिपा नहीं है। रिले कनेक्शन के पैटर्न देख सकते हैं, और हर रिले आपका IP पता देखता है, तब भी जब वह संदेश की सामग्री नहीं पढ़ सकता। Herkos जो ज़ाहिर नहीं करता (30-09-2026 से), वह यह है कि कौन किसे लिख रहा है, जब कोई रिले NIP-42 प्रमाणीकरण माँगता है:
• कहाँ डिलीवर करना है, यह पता करना। पाने वाले के रिले और Blossom की सूचियाँ एक अलग कनेक्शन पर माँगी जाती हैं, जो कभी आपकी पहचान नहीं बताता, और पहले उन रिले पर जिन्हें प्रमाणीकरण की ज़रूरत नहीं होती (purplepag.es, user.kindpag.es, nos.lol, offchain.pub)।
• प्रोफ़ाइल और शेड्यूलर। किसी और के लिए दिखाया जाने वाला नाम और तस्वीर (kind 0), और जब आप कोई ईमेल शेड्यूल या रद्द करते हैं तो शेड्यूलर DVM के रिले की सूची, इसी तरह माँगी जाती है: पहले गुमनाम रूप से और, अगर कोई रिले ज़िद करे, तो नीचे बताई गई अस्थायी कुंजी से, आपकी कुंजी से कभी नहीं (01-10-2026 से; उससे पहले, प्रमाणीकरण माँगने वाले रिले को आपकी कुंजी मिल जाती थी, और वह बता सकता था कि आप किसकी प्रोफ़ाइल देख रहे हैं)। सिर्फ़ आपकी अपनी प्रोफ़ाइल अब भी आपकी पहचान से पढ़ी जाती है।
• डिलीवर करना। गिफ़्ट रैप पाने वाले के DM रिले पर जाते हैं, उसी अलग कनेक्शन पर। अगर उनमें से कोई प्रमाणीकरण माँगता है, तो Herkos इसी काम के लिए बनाई गई और सिर्फ़ मेमरी में रखी गई कुंजी से जवाब देता है, आपकी कुंजी से कभी नहीं; डिवाइस पर हर खाते की अपनी अलग कुंजी होती है। रिले फिर भी देख सकता है कि एक ही डिवाइस (एक ही IP, एक ही अस्थायी कुंजी) ने एक सेशन के दौरान कई लिफ़ाफ़े भेजे।
• बड़े ईमेल। 32 KB से बड़े ईमेल की एन्क्रिप्ट की गई कॉपी Blossom सर्वर पर अपलोड की जाती है, जिनमें पाने वालों के सर्वर भी शामिल हैं। सिर्फ़ आपके अपने सर्वर (आपकी Blossom सूची) को आपकी कुंजी से अधिकृत अपलोड मिलता है। किसी भी दूसरे सर्वर को यह गुमनाम रूप से मिलता है और, अगर वह प्राधिकरण पर ज़िद करे, तो ऊपर वाली उसी अस्थायी कुंजी से साइन किया गया प्राधिकरण (01-10-2026 से; उससे पहले, हर सर्वर को आपकी कुंजी मिलती थी)। जो सर्वर सिर्फ़ जानी-पहचानी कुंजियाँ स्वीकार करता है, वह इसे मना कर देता है, और कॉपी दूसरे सर्वर पर रहती है।
• आपका अपना डेटा। आपके मेलबॉक्स, लेबल, सेटिंग और ड्राफ़्ट का सिंक, जहाँ कोई रिले माँगे, उसी खाते के रूप में प्रमाणित होता है जिसका वह डेटा है, यहाँ तक कि खाता बदलते समय भी। आपके अपने रिले पर इससे उन्हें कुछ ऐसा पता नहीं चलता जो उन्हें पहले से पता न हो: अनुरोधों में आपकी कुंजी का नाम वैसे भी होता है। आपके अपने रिले और Blossom की सूचियाँ सार्वजनिक हैं और आपकी पहचान बताए बिना माँगी जाती हैं, और ईमेल लिंक में बताए गए रिले के साथ भी ऐसा ही होता है।
• पढ़े जाने की स्थिति और फ़ोल्डर सार्वजनिक मेटाडेटा हैं (फ़िलहाल)। किसी ईमेल को पढ़ा गया, तारांकित, संग्रहित या कहीं ले जाया गया मार्क करने पर एक बिना एन्क्रिप्शन वाला NIP-32 लेबल इवेंट प्रकाशित होता है, जो आपकी सार्वजनिक कुंजी से जुड़ा होता है, जिसमें आपके बनाए फ़ोल्डर के नाम भी शामिल हैं। जो भेजने वाला आपको भेजे गए ईमेल की id जानता है, वह बता सकता है कि आपने उस पर कब कार्रवाई की। इन लेबल को एन्क्रिप्ट करने की योजना है; तब तक, फ़ोल्डर के नामों को सार्वजनिक मानें।
• पुश सूचनाएँ और शेड्यूल करके भेजना तीसरे पक्ष की सेवाओं का इस्तेमाल करते हैं। पुश सर्वर, अगर आप कोई चुनते हैं (डिफ़ॉल्ट रूप से कोई नहीं; माँगने पर relay.nmail.li के साथ api.nmail.li), को आपकी सार्वजनिक कुंजी, एक पुश टोकन और यह पता चलता है कि आपको मेल कब मिलता है; शेड्यूलर DVM को आपकी सार्वजनिक कुंजी और वे पहले से एन्क्रिप्ट किए गए संदेश पता चलते हैं जिन्हें उसे प्रकाशित करना है। दोनों वैकल्पिक हैं और PRIVACY.md में दर्ज हैं। पुश सूचना का टेक्स्ट पुश सर्वर चुनता है, और Herkos उस पर तभी भरोसा करता है जब UnifiedPush उसे एन्क्रिप्ट करके (RFC 8291) डिलीवर करे; बिना एन्क्रिप्शन वाला पेलोड सिर्फ़ ऐप को जगाता है, ताकि वह ख़ुद मेल ले आए।
• वेब वर्शन आपकी कुंजी ब्राउज़र में रखता है, जो उसके लिए सबसे कमज़ोर जगह है। इंस्टॉल किए गए ऐप आपकी निजी कुंजी ऑपरेटिंग सिस्टम के सुरक्षित स्टोरेज (Android Keystore, Windows पर DPAPI, libsecret, iOS/macOS Keychain) को सौंपते हैं। ब्राउज़र में इनमें से कुछ भी नहीं होता: कुंजी ओरिजिन के स्टोरेज में रहती है और हर हस्ताक्षर पर JavaScript से गुज़रती है, यानी पेज में चलने वाले किसी भी कोड की पहुँच में — हर साइट तक पहुँच वाला ब्राउज़र एक्सटेंशन, ऐप या किसी डिपेंडेंसी में XSS बग, छेड़छाड़ किया गया डिप्लॉयमेंट — और ब्राउज़र प्रोफ़ाइल कॉपी करने वाले किसी भी इन्फ़ोस्टीलर की पहुँच में भी। ऐसा कोई पल भी नहीं आता जब आप कोड को एक बार जाँच लें: साइन की गई बाइनरी इंस्टॉल के समय जाँची जाती है, जबकि वेब पेज हर बार खोलने पर नया कोड भेजता है। वेब वर्शन में रिमोट साइनर (NIP-46 बंकर, Amber) से साइन इन करें, ताकि कुंजी कभी ब्राउज़र तक न पहुँचे, या उसे एक फेंकने लायक पहचान मानें और अपनी असली कुंजी किसी इंस्टॉल किए गए ऐप में रखें।
• ब्रिज से आया मेल उतना ही भरोसेमंद है जितना ब्रिज। Herkos यह जाँचता है कि ब्रिज से आया बताया गया संदेश सच में किसी ऐसे ब्रिज ने साइन किया है जिसे आपने सेट किया है (या डिफ़ॉल्ट में से किसी एक ने)। ब्रिज जो पारंपरिक From: पता आगे भेजता है, उसके बारे में यह कुछ भी जाँच नहीं सकता।
• अटैचमेंट ऑपरेटिंग सिस्टम खोलता है। Herkos कभी भी एक्ज़ीक्यूटेबल या स्क्रिप्ट फ़ाइल टाइप लॉन्च नहीं करता और किसी भी दूसरे ऐसे अटैचमेंट को, जिसका प्रीव्यू नहीं हो सकता, सिस्टम के डिफ़ॉल्ट ऐप को सौंपने से पहले पूछता है, लेकिन फ़ाइल खोलने वाला ऐप हमारे नियंत्रण से बाहर है।

Herkos Local Relay: यह किससे बचाता है और किससे नहीं

Herkos Local Relay आपके ऐप के इवेंट आपके डिवाइस पर रखता है, निजी इवेंट भी (ड्राफ़्ट, निजी सूचियाँ, आपको मिले लिफ़ाफ़े)। यहाँ बताया गया है कि उन्हें क्या सुरक्षित रखता है और सीमा कहाँ है, हर प्लेटफ़ॉर्म के हिसाब से। रिले की सुरक्षा समस्याओं की रिपोर्ट भी बाकी समस्याओं की तरह ही करें (ऊपर देखें)।

पूरा डेटाबेस एन्क्रिप्ट किया जाता है, उसका जर्नल भी (SQLite3 Multiple Ciphers, AEGIS-256)। कुंजी डिवाइस पर बनाए गए 32 रैंडम बाइट हैं, जो सिस्टम के सुरक्षित स्टोरेज में रखे जाते हैं: Android पर Keystore, Windows पर DPAPI, Linux पर कीरिंग (libsecret)। इसमें आपका कोई पासवर्ड नहीं लगता, क्योंकि रिले को अपने-आप शुरू होना होता है। कुंजी के बिना रिले शुरू नहीं होता और यह बता देता है: यह कभी बिना एन्क्रिप्शन वाला डेटाबेस नहीं खोलता या बनाता, और जिस डेटाबेस को खोल नहीं पाता, उसे कभी नहीं मिटाता।

डेस्कटॉप पर, DPAPI और कीरिंग की सीमा वही है जो किसी भी प्रोग्राम की होती है: ये दूसरे उपयोगकर्ताओं से और डिस्क ले जाने वाले से बचाते हैं, उस दुर्भावनापूर्ण प्रोग्राम से नहीं जो पहले से आपके रूप में चल रहा हो। अगर यह स्थिति आपको चिंतित करती है, तो आपको सिस्टम डिस्क का एन्क्रिप्शन (BitLocker, LUKS) और उन प्रोग्राम को न चलाना बचाता है जिन पर आपको भरोसा नहीं है। बिना कीरिंग वाले Linux पर (Secret Service न हो तो) रिले शुरू नहीं होता और इसकी वजह बताता है: यह कुंजी को कभी सादे टेक्स्ट में नहीं रखता।

डिवाइस पर ही कौन अंदर आ सकता है। रिले सिर्फ़ 127.0.0.1 पर सुनता है, और डिवाइस का कोई भी ऐप, या ब्राउज़र में खुला कोई वेब पेज, उस पते तक पहुँच सकता है। इसलिए:

• किसी ऐप को पेयर होना पड़ता है: वह रिले की स्क्रीन पर दिखता है और आप उसे मंज़ूरी देते हैं (PIN या फ़िंगरप्रिंट से, अगर आपने उन्हें सेट किया है)। कोई भी ऐप ख़ुद को कोई भी नाम दे सकता है: मंज़ूरी तभी दें जब आपने अभी-अभी उसी ऐप से इसका अनुरोध किया हो।
• वेब पेज को हमेशा पेयर होना पड़ता है, और कोई पेयरिंग सिर्फ़ वहीं से काम करती है जहाँ वह की गई थी: डिवाइस के किसी ऐप की पेयरिंग किसी वेब पेज के लिए कुछ नहीं खोलती, चाहे वह पेज उसी कुंजी से साइन करे।
• पेयर किया गया ऐप सिर्फ़ उन्हीं प्रकार के इवेंट पढ़ता और लिखता है जो आपने उसे दिए, और सिर्फ़ वही मिटाता है जिन्हें वह लिख सकता है। उसकी अनुमति रद्द करने पर वह तुरंत डिस्कनेक्ट हो जाता है।
• जो ऐप पेयर नहीं है, वह सिर्फ़ आपके सार्वजनिक इवेंट पढ़ता है (जो वैसे भी सार्वजनिक हैं) और कुछ नहीं लिखता, जब तक आप वह सेटिंग चालू न करें जो डिवाइस के बिना पेयर किए गए ऐप को अंदर आने देती है।
• निजी इवेंट सिर्फ़ उसी को दिए जाते हैं जो NIP-42 से साबित करे कि उसके पास वह कुंजी है जिसके वे हैं, और कोई लिफ़ाफ़ा सिर्फ़ उसके पाने वाले को।

यहाँ यह किससे नहीं बचाता:

• डिवाइस का कोई दुर्भावनापूर्ण ऐप रिले को धीमा कर सकता है या उससे मेमोरी ख़र्च करवा सकता है। इस तरह वह कुछ भी निजी नहीं पढ़ सकता।
• जब रिले सो रहा हो या चल न रहा हो, तब उसका पोर्ट ख़ाली रहता है। Android पर यह 10 मिनट तक कोई कनेक्शन न होने पर सो जाता है; डेस्कटॉप पर, जब तक आपने इसे शुरू नहीं किया, पोर्ट ख़ाली रहता है। कोई दूसरा ऐप वहाँ सुन सकता है और ख़ुद को रिले बता सकता है। Herkos ऐप रिले को कुछ भी निजी भेजने से पहले उसकी कुंजी जाँचेंगे; अभी वे ऐसा नहीं करते, और तब तक यह एक असली सीमा है।
• डेस्कटॉप पर, कंप्यूटर के दूसरे उपयोगकर्ता बिना पेयर किए गए ऐप के रूप में कनेक्ट कर सकते हैं: आपके सार्वजनिक इवेंट पढ़ सकते हैं और पेयर होने का अनुरोध कर सकते हैं।

लोकल नेटवर्क, अगर आप उसे चालू करें (डिफ़ॉल्ट रूप से यह बंद रहता है):

• सिर्फ़ wss://, रिले के अपने सर्टिफ़िकेट के साथ; डिवाइस के बाहर कभी बिना एन्क्रिप्शन वाला ws:// नहीं।
• आपकी सूची की किसी कुंजी से प्रमाणीकरण (NIP-42) से पहले कुछ नहीं। जो कनेक्शन 30 सेकंड में ऐसा नहीं करता, उसे बंद कर दिया जाता है, और लोकल नेटवर्क के कनेक्शन की अपनी अलग संख्या है: वह कभी डिवाइस के ऐप के कनेक्शन नहीं लेता।
• सूची की कोई कुंजी आपके सार्वजनिक इवेंट और अपने निजी इवेंट पढ़ती है, और सिर्फ़ अपने साइन किए हुए इवेंट लिखती है। उसे सूची से हटाने पर वह डिस्कनेक्ट हो जाती है।
• सर्टिफ़िकेट सिर्फ़ घर के नामों (localhost, .local, निजी पते) के लिए मान्य है: अगर कोई उसकी कुंजी चुरा भी ले, तो जिन डिवाइस ने उसे इंस्टॉल किया है, उन पर वह किसी इंटरनेट डोमेन को साइन करने के काम नहीं आएगी।

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

कॉपी। एन्क्रिप्ट की गई कॉपी का एक पासवर्ड होता है (scrypt और XChaCha20-Poly1305): उसके बिना कोई उसे नहीं खोल सकता, हम भी नहीं। JSONL एक्सपोर्ट एन्क्रिप्टेड नहीं होता और उसमें आपके निजी इवेंट सादे टेक्स्ट में होते हैं; ऐप आपको इसकी चेतावनी देता है।

लॉक (एक PIN, साथ में फ़िंगरप्रिंट या Windows Hello) ऐप खुलने पर, 30 सेकंड दूर रहने के बाद, और किसी पेयरिंग को मंज़ूरी देने के लिए माँगा जाता है। यह सुविधा के लिए एक रुकावट है, जैसे Mail में: यह कुछ भी एन्क्रिप्ट नहीं करता। Android पर, PIN सेट होने पर कोई स्क्रीनशॉट नहीं लिया जा सकता और हाल के ऐप में कोई थंबनेल नहीं दिखता, और Android 12 से, जब आप रिले इस्तेमाल कर रहे हों, तब किसी दूसरे ऐप की विंडो उसकी विंडो के ऊपर नहीं आ सकती।

Herkos Drive: यह किससे बचाता है और किससे नहीं

Herkos Drive आपकी फ़ाइलें Blossom सर्वर पर और आपकी फ़ाइलों और फ़ोल्डरों की सूची Nostr रिले पर रखता है, दोनों आपके डिवाइस पर एन्क्रिप्ट की हुई। यहाँ बताया गया है कि उन्हें क्या सुरक्षित रखता है और सीमा कहाँ है। पूरा विवरण packages/herkos_drive_protocol/ में spec-drive.md और ख़तरा मॉडल amenazas-drive.md में है; हर रिले और सर्वर क्या देखता है, यह गोपनीयता नीति में है। Drive की सुरक्षा समस्याओं की रिपोर्ट भी बाकी समस्याओं की तरह ही करें (ऊपर देखें)।

रिले और सर्वर क्या नहीं कर सकते:

• आपकी फ़ाइलें या उनके नाम पढ़ना। किसी फ़ाइल का हर ब्लॉक उसके अपने संशोधन की कुंजी के तहत AES-256-GCM से एन्क्रिप्ट किया जाता है; नाम, फ़ोल्डर, आकार, तारीख़ें और कुंजियाँ उस फ़ोल्डर की कुंजी के तहत XChaCha20-Poly1305 से सील होकर जाती हैं जिसमें वे हैं। सामग्री से कुछ भी नहीं निकाला जाता: एक ही फ़ाइल दो बार अपलोड करने पर अलग-अलग ब्लॉक बनते हैं।
• बिना पता चले कुछ भी बदलना, अदला-बदली करना या खिसकाना। हर ब्लॉक को उसकी फ़ाइल की एंट्री में सील किए गए मैनिफ़ेस्ट से जाँचा जाता है, और हर एंट्री वॉल्यूम कुंजी से साइन होती है और अपनी जगह (वॉल्यूम, पहचानकर्ता और फ़ोल्डर) के लिए सील होती है: कोई रिले एक एंट्री को दूसरी, या एक ब्लॉक को दूसरा बताकर नहीं चला सकता।
• कोई पुराना वर्शन वापस लाना। ऐप किसी पहचानकर्ता के लिए ऐसी एंट्री कभी स्वीकार नहीं करता जो उसके पास पहले से मौजूद एंट्री से पुरानी हो।
• सिर्फ़ वॉल्यूम कुंजी से आपकी ओर से लिखना। आपके डिवाइस जो लिखते हैं, उस पर मालिक का निशान होता है, एक ऐसी कुंजी वाला HMAC जो कोई लिंक नहीं देता; जिस एंट्री या मिटाने पर यह निशान नहीं होता, उसे स्वीकार नहीं किया जाता, और ऐप आपको चेतावनी देता है।

यह किससे नहीं बचाता:

• आपके Drive का पैटर्न। रिले आपकी फ़ाइलें और फ़ोल्डर गिन सकते हैं, ट्री की बनावट और यह देख सकते हैं कि हर एंट्री कब बदलती है; सर्वर देखते हैं कि हर फ़ाइल लगभग कितनी बड़ी है (ब्लॉक 64 KiB तक पैड किए जाते हैं, एंट्री दो की घात तक)। हर रिले और सर्वर आपका IP पता देखता है। अगर यह आपके लिए मायने रखता है, तो सिस्टम स्तर पर Tor या Orbot इस्तेमाल करें।
• जो किसी ने पहले ही डाउनलोड कर लिया। कोई लिंक, या कोई व्यक्ति, हटाने पर, वे जो खोल सकते थे उसे तुरंत नई कुंजियाँ मिल जाती हैं, ताकि आप बाद में जो जोड़ें उसे वे न खोल सकें; जो उन्होंने पहले ही सहेज लिया, उसे यह वापस नहीं ले सकता।
• लीक हुआ लिंक। बिना पासवर्ड वाला लिंक ही कुंजी है। पेज के एड्रेस बार से उसे हटाने से पहले ब्राउज़र उसे अपनी हिस्ट्री में रख सकता है। किसी भी संवेदनशील चीज़ के लिए, लिंक को पासवर्ड दें, जो किसी और तरीके से भेजा जाए, या उस व्यक्ति के खाते के साथ साझा करें। कमज़ोर पासवर्ड समय के साथ तोड़ा जा सकता है: जिसके पास लिंक है, वह ऑफ़लाइन कोशिश कर सकता है।
• पेज herkos.app/f/ उस व्यक्ति के ब्राउज़र में चलता है जो लिंक खोलता है। इसे सख़्त Content-Security-Policy और Subresource Integrity के साथ, बिना किसी तीसरे पक्ष के कोड के परोसा जाता है, पर जो वेब होस्ट को नियंत्रित करता है, वह कोई दूसरा पेज परोस सकता है। ब्राउज़र में डिक्रिप्ट करने वाले हर वेब पेज की यही सीमा है।
• जिसके पास वॉल्यूम कुंजी थी (आपकी, या किसी फ़ोल्डर के लिंक के साथ दी गई), वह उससे अपलोड किए गए ब्लॉक तब तक मिटा सकता है, जब तक वे दोबारा अपलोड न हों। आप वॉल्यूम कुंजी बदल सकते हैं (सेटिंग → वॉल्यूम कुंजी): आपके दूसरे डिवाइस अपने-आप साथ आ जाते हैं।
• आपका डिवाइस। फ़ाइलों की सूची एन्क्रिप्ट करके कैश की जाती है, उसकी कुंजी सिस्टम के सुरक्षित स्टोरेज में रहती है; जो फ़ाइल आप डाउनलोड करते हैं या खोलते हैं, वह आपकी चुनी हुई जगह पर बिना एन्क्रिप्शन के लिखी जाती है। Drive का PIN सुविधा के लिए एक रुकावट है, जैसे Mail में।
• बाद में, कोई क्वांटम कंप्यूटर। ब्लॉक और सील सिमेट्रिक हैं (AES-256, XChaCha20), पर आपका लोकेटर secp256k1 पर NIP-44 से एन्क्रिप्ट होता है: जो उसे आज रख ले और कल secp256k1 तोड़ दे, वह पूरा Drive खोल सकता है।

इसकी जाँच कैसे होती है। ख़तरा मॉडल के आधार पर दो आंतरिक समीक्षाएँ (2 नवंबर 2026) और उनके सुधार; हर इवेंट और ब्लॉक क्या दिखाता है, इसके परीक्षण; बाहर से आने वाली हर चीज़ (इवेंट, सील, मैनिफ़ेस्ट, लिंक, बैकअप) को पढ़ने वाले हर हिस्से की फ़ज़िंग। अभी कोई बाहरी ऑडिट नहीं: सार्वजनिक बीटा से पहले एक ऑडिट की योजना है, और उसकी रिपोर्ट पूरी प्रकाशित की जाएगी। Drive अभी विकास के चरण में है।

समर्थित वर्शन

सुरक्षा सुधार नवीनतम रिलीज़ किए गए वर्शन पर लागू किए जाते हैं। प्रोजेक्ट के आकार को देखते हुए, पुराने वर्शन मेंटेन नहीं किए जाते — कृपया रिपोर्ट करने से पहले अपडेट करें।