लगातार पूछे जाने वाले प्रश्न

इस साइट का खराब अनुवाद क्यों किया गया है? ⎃

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

यह सेवा कितनी सुरक्षित है?

हमने इस सेवा को इसके इच्छित उपयोग के लिए सुरक्षित बनाने के लिए कई कदम उठाए हैं। इससे पहले कि हम उन चरणों को देखें, निम्नलिखित को समझना महत्वपूर्ण है:

हमारा लक्ष्य इस सेवा को ऐसे तरीके से पेश करना है जो आपकी गोपनीयता और सुरक्षा को बढ़ाने के विकल्प प्रदान करता है। आपकी जानकारी की सुरक्षा के लिए हमने यहां कुछ कदम उठाए हैं:

मुझे यहां एक संदेश को डिक्रिप्ट करने के विकल्प के साथ एक लिंक क्यों प्राप्त हुआ?

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

आप इस साइट पर सबमिट की गई सभी चीज़ों को हटा देते हैं?

हमारे ट्रैश कैन लोगो के लिए सही है... प्राप्त करने के तुरंत बाद सब कुछ हटा दिया जाता है। सब कुछ हटाना स्वचालित है - इसे सर्वर में लिखा गया है। इसे इस तरह से सोचें - सबमिट की गई जानकारी के दो वर्ग हैं:

संदेशों के मामले में, आप यह निर्दिष्ट करके नियंत्रित कर सकते हैं कि हम उन्हें कब हटाते हैं: डिफ़ॉल्ट रूप से, किसी संदेश के एक बार पुनर्प्राप्त होने के बाद या 1 सप्ताह पुराना होने पर - जो भी पहले हो, उसके बारे में सब कुछ हटा दिया जाता है। जब वेब पर कुछ भी सबमिट करने में निहित अन्य सभी जानकारी (यानी आपका आईपी पता, आदि) को हटाने की बात आती है, तो हम आपको इस पर कोई नियंत्रण नहीं देते हैं कि इसे कब या कैसे हटाया जाए - हम इसे हर 24 घंटे में हटा देते हैं .

इस सेवा का उपयोग क्यों करें?

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

क्या यह एक संदेश सेवा है?

नहीं। यह सेवा मौजूदा संदेश सेवाओं जैसे इंस्टेंट-मैसेजिंग/ईमेल/टेक्स्ट/आदि के पूरक के लिए डिज़ाइन की गई है। भेजे गए संदेशों को लंबे समय तक संग्रहीत होने से रोकने की क्षमता जोड़कर। हम प्राप्तकर्ता को उत्पन्न लिंक वितरित नहीं करते हैं ।

इच्छित उपयोग के मामले क्या हैं?

तो ऐसे कौन से परिदृश्य हैं जहां इस सेवा का उपयोग करना उचित है? जब उनकी गोपनीयता और सुरक्षा की बात आती है तो हर किसी की अलग-अलग ज़रूरतें और आवश्यकताएं होती हैं, मैंने व्यक्तिगत रूप से निम्नलिखित परिदृश्यों को उपयुक्त उपयोग के मामलों के रूप में पाया है:

इस सेवा का उपयोग किस लिए नहीं किया जाना चाहिए?

इस एफएक्यू में बताए गए सभी कारणों के लिए इस सेवा का उपयोग बहुत संवेदनशील जानकारी के लिए नहीं किया जाना चाहिए। नीचे कुछ उदाहरण दिए गए हैं कि क्या नहीं करना चाहिए:

क्यों न केवल पीजीपी/सिग्नल/ओएमईएमओ/मैट्रिक्स/आदि का उपयोग करें?

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

क्या आवश्यकताएं मौजूद हैं?

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

क्या प्राप्तकर्ता संदेश की प्रतिलिपि बना सकता है?

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

हालाँकि, ये कॉपी सुरक्षा कमजोर हैं क्योंकि इन्हें बायपास किया जा सकता है। इसके अलावा, प्राप्तकर्ता हमेशा संदेश का स्क्रीनशॉट या फोटो ले सकता है।

क्या कोई व्यक्तिगत जानकारी एकत्र की जाती है?

हम उपयोगकर्ता खातों (अर्थात उपयोगकर्ता नाम/पासवर्ड) का समर्थन नहीं करते हैं। हम ऐसी कोई जानकारी एकत्र नहीं करते जो आपकी पहचान कर सके (अर्थात नाम/पता/ईमेल/फोन)। यह संभव है कि आपके द्वारा भेजे जा रहे संदेश में कुछ व्यक्तिगत जानकारी हो, लेकिन वह एन्क्रिप्टेड है और हमारे पास इसे पढ़ने का कोई तरीका नहीं है। पूर्ण विवरण के लिए कृपया हमारी गोपनीयता नीति की समीक्षा करें।

क्या जानकारी दर्ज है?

हमारा वेब सर्वर सभी वेब गतिविधियों पर 24 घंटे तक सामान्य लॉग प्रारूप रखता है। इसमें HTTP क्लाइंट का पूरा IP पता लॉग करना शामिल है। 24 घंटे के बाद, यह लॉग की गई जानकारी स्वचालित रूप से हटा दी जाती है। /एपीआई को भेजे गए सभी अनुरोध पोस्ट किए गए हैं, जिसका अर्थ है कि वेब सर्वर द्वारा कभी भी कोई संदेश विशिष्ट जानकारी लॉग नहीं की जाती है। इसके अतिरिक्त, डेटाबेस में सहेजी गई कोई भी जानकारी प्रभावी रूप से लॉग की जाती है। अनाम और हैश किए गए आईपी पते सहित डेटाबेस में सभी प्रविष्टियों की समाप्ति समय (टीटीएल) है जिसके बाद वे स्वचालित रूप से हटा दिए जाते हैं। टीटीएल समाप्ति समय 1 मिनट और 2 सप्ताह के बीच भिन्न होता है।

सर्वर को सुरक्षित करने के लिए आप क्या कर रहे हैं?

सर्वर सुरक्षा एक स्पष्ट चिंता है। इसे सुरक्षित रखने के लिए हम दो मुख्य क्षेत्रों पर ध्यान केंद्रित करते हैं:

इस साइट का उपयोग करते समय कौन से सुरक्षा जोखिम मौजूद हैं?

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

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

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

आप मैन-इन-द-मिडिल (MITM) हमलों के बारे में क्या कर रहे हैं?

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

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

ब्राउज़र एक्सटेंशन क्या लाभ प्रदान करते हैं?

हम अतिरिक्त सुविधा और अतिरिक्त सुरक्षा प्रदान करने के साधन के रूप में ब्राउज़र एक्सटेंशन प्रदान करते हैं। सीधे शब्दों में कहें... एक्सटेंशन अस्थायी संदेश भेजने को तेज़ और आसान बनाते हैं। कुछ सुरक्षा भी प्राप्त होती है क्योंकि एन्क्रिप्ट करने और संदेश तैयार करने के लिए उपयोग किए जाने वाले सभी कोड एक्सटेंशन के भीतर स्थानीय रूप से संग्रहीत होते हैं। क्योंकि कोड स्थानीय रूप से संग्रहीत है, यह प्रेषक को MITM हमलों के खिलाफ कुछ सुरक्षा प्रदान करता है। हालांकि, यह ध्यान देने योग्य है कि जबकि एक्सटेंशन एमआईटीएम हमले के खिलाफ अधिक सुरक्षा प्रदान करते हैं जो संदेश सामग्री से समझौता करते हैं, एक एमआईटीएम हमला अभी भी प्रभावी हो सकता है (यानी टीओआर/वीपीएन/आदि का उपयोग नहीं करने पर प्रेषक का आईपी पता निर्धारित करने के लिए)।

मैं यह सुनिश्चित करने के लिए कैसे जान सकता हूं कि सबमिट की गई कोई भी चीज़ एंड-टू-एंड एन्क्रिप्टेड है?

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

इसके अलावा, यदि आप इसके बारे में सोचते हैं, जब तक हम संवेदनशील संदेशों को एकत्र करने की कोशिश कर रहे कुछ गुप्त एजेंसी नहीं हैं, तब तक संदेशों को डिक्रिप्ट करने में सक्षम होने का कोई फायदा नहीं है क्योंकि यह क्षमता केवल हमारे लिए समस्याएं पैदा करती है। हम संदेशों को संग्रहीत भी नहीं करना चाहते - हालांकि उन्हें वितरित करने के लिए यह एक आवश्यक बुराई है।

इस साइट पर एंड-टू-एंड एन्क्रिप्शन कैसे काम करता है?

इस समय, हम पासवर्ड से प्राप्त कुंजियों के साथ सममित एन्क्रिप्शन (एईएस-जीसीएम 256 बिट) का उपयोग कर रहे हैं (पीबीकेडीएफ2/एसएचए-256 के न्यूनतम 150,000 पुनरावृत्तियों)। असममित एन्क्रिप्शन का उपयोग नहीं किया जाता है क्योंकि 1) संचार शुरू करने वाले प्रेषक 2) प्रेषक और प्राप्तकर्ता एक ही समय में ऑनलाइन नहीं हैं और 3) प्राप्तकर्ता के बारे में कोई जानकारी नहीं है और 4) हम चीजों को वास्तविक सरल रखने की कोशिश कर रहे हैं और मुख्य प्रबंधन है उलझा हुआ। मानक वेब क्रिप्टो एपीआई का उपयोग आरएनजी सहित सभी क्रिप्टोग्राफिक कार्यक्षमता के लिए किया जाता है। मूल रूप से, यहाँ क्या होता है:

  1. अंतिम उपयोगकर्ता एक पासवर्ड चुनता है या एक स्वतः उत्पन्न होता है
  2. आवश्यक PBKDF2/SHA-256 पुनरावृत्तियों की संख्या प्राप्त करने के लिए एक API कॉल की जाती है ( स्पैम नियंत्रण के लिए यह चरण आवश्यक है )
  3. 32 बाइट नमक उत्पन्न होता है
  4. एक कुंजी नमक और पासवर्ड से ली गई है
  5. एक 12 बाइट आरंभीकरण वेक्टर (IV) उत्पन्न होता है
  6. संदेश कुंजी + IV . का उपयोग करके एन्क्रिप्ट किया गया है
  7. पुनरावृत्ति गणना, नमक, IV, और सिफरटेक्स्ट सर्वर को भेजे जाते हैं (कुछ अन्य जानकारी जैसे TTL, RTL, आदि के साथ)
  8. सर्वर संदेश का जिक्र करते हुए एक यादृच्छिक आईडी देता है
  9. ब्राउज़र तब एंड-यूज़र को एक लिंक के साथ प्रस्तुत करता है जिसमें लौटाई गई आईडी और पासवर्ड या पासवर्ड के बिना एक लिंक होता है (जिस स्थिति में प्राप्तकर्ता को पासवर्ड पता होना चाहिए और दर्ज करना चाहिए)
  10. यदि पासवर्ड लिंक का हिस्सा है, तो यह यूआरएल हैश में है , और इसलिए जब प्राप्तकर्ता जीईटी अनुरोध करता है तो सर्वर को कभी नहीं भेजा जाता है
  11. प्राप्तकर्ता को संकेत दिया जाता है कि क्या वे संदेश को डिक्रिप्ट और देखना चाहते हैं
  12. ब्राउज़र संदेश आईडी निर्दिष्ट करने का अनुरोध करता है
  13. यदि प्रेषक को कैप्चा पूरा करने की आवश्यकता होती है, तो प्राप्तकर्ता को यह साबित करने के लिए दूसरे यूआरएल पर निर्देशित किया जाता है कि वे मानव हैं (एक बार जब वे पास हो जाते हैं तो उन्हें वापस निर्देशित किया जाता है)
  14. सर्वर एन्क्रिप्टेड संदेश भेजता है और डिफ़ॉल्ट रूप से इस बिंदु पर संदेश को हटा देगा यदि रीड-टू-लाइव (आरटीएल) एक है
  15. प्राप्तकर्ता संदेश को पासवर्ड से डिक्रिप्ट करेगा (और यदि URL में नहीं है तो पासवर्ड के लिए संकेत दिया जाएगा)
यह सेटअप बेहद सरल है, और प्रेषक के डिवाइस से प्राप्तकर्ता के डिवाइस पर संदेश एन्क्रिप्शन प्रदान करता है, लेकिन निश्चित रूप से इस गारंटी की कमी है कि असममित एन्क्रिप्शन केवल प्राप्तकर्ता की निजी कुंजी के कब्जे वाले किसी व्यक्ति को संदेश को डिक्रिप्ट कर सकता है। लिंक वाला कोई भी व्यक्ति डिफ़ॉल्ट परिदृश्य में संदेश खोल सकता है जिससे पासवर्ड यूआरएल का हिस्सा होता है - यह लिंक के लिए उपयुक्त परिवहन का उपयोग करने के महत्व को रेखांकित करता है (यानी ईमेल/चैट/टेक्स्ट/आदि) - एक निर्णय छोड़ दिया प्रेषक। यदि कोई रुचि है, तो हम एक बहुत ही बुनियादी असममित योजना के लिए समर्थन भी शुरू कर सकते हैं जिससे प्राप्तकर्ता संदेश के लिए अनुरोध शुरू करता है और उस अनुरोध लिंक को संदेश भेजने वाले को भेजता है। यह सेटअप URL में पासवर्ड रखने की आवश्यकता को समाप्त कर देगा, लेकिन प्रेषक के लिए आरंभ करने की क्षमता को भी समाप्त कर देगा।

डिक्रिप्शन पासवर्ड URL में हो सकता है?

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

लेकिन डिक्रिप्शन पासवर्ड का यूआरएल में होना जरूरी नहीं है?

सही। यदि डिक्रिप्शन पासवर्ड लिंक में शामिल नहीं है, तो प्राप्तकर्ता को पासवर्ड के लिए संकेत दिया जाएगा। यदि पासवर्ड प्राप्तकर्ता को सुरक्षित रूप से संप्रेषित किया जाता है (या वे इसे पहले से जानते हैं), तो यह अवरोधन से सुरक्षा प्रदान करता है। हालांकि, नुकसान यह है कि प्राप्तकर्ता को पता होना चाहिए और पासवर्ड सही ढंग से दर्ज करना चाहिए। यहां प्राप्तकर्ता को पासवर्ड भेजने का एक तरीका है जो अवरोधन के खिलाफ कुछ सुरक्षा प्रदान करता है:

  1. डिफ़ॉल्ट सेटिंग्स वाले संदेश में पासवर्ड एन्क्रिप्ट करें और प्राप्तकर्ता को यह लिंक भेजें।
  2. जब प्राप्तकर्ता लिंक पर क्लिक करता है और संदेश को डिक्रिप्ट करता है, तो वे जानते हैं कि किसी और ने उनसे पहले पासवर्ड प्राप्त नहीं किया है क्योंकि पासवर्ड युक्त संदेश पुनर्प्राप्ति पर हटा दिया गया है। हालाँकि, यदि कोई सक्रिय MITM हमला है या यदि आपके उपकरण या प्राप्तकर्ता के उपकरण से छेड़छाड़ की गई है, तो यह अभी भी संभव है कि कोई अन्य पक्ष पासवर्ड प्राप्त कर सके।
  3. प्राप्तकर्ता से पुष्टि करें कि उन्होंने सफलतापूर्वक पासवर्ड प्राप्त कर लिया है। उदाहरण के लिए, यदि प्राप्तकर्ता आपको सूचित करता है कि जब वे पासवर्ड पुनर्प्राप्त करने गए थे, तो संदेश पहले ही हटा दिया गया था, तो आप जानते हैं कि प्राप्तकर्ता से पहले किसी और ने पासवर्ड प्राप्त किया है और इसलिए पासवर्ड से समझौता किया गया है और इसका उपयोग नहीं किया जाना चाहिए।
  4. पासवर्ड का उपयोग करके प्राप्तकर्ता ने पुष्टि की कि उनके पास है, अब आप एन्क्रिप्शन के लिए उसी पासवर्ड का उपयोग करके एक संदेश भेज सकते हैं - बस उस लिंक का संस्करण साझा करें जिसमें पासवर्ड नहीं है।

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

मैं इस सेवा का उपयोग करते हुए यथासंभव अपनी गोपनीयता की रक्षा कैसे कर सकता हूं?

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

क्या होगा अगर मुझे संयुक्त राज्य अमेरिका पर भरोसा नहीं है?

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

स्पैम को रोकने के लिए आप क्या कर रहे हैं?

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

हम संभवतः कुछ एपीआई कुंजी प्रणाली का उपयोग करके एपीआई समस्या को हल कर सकते हैं, लेकिन फिर हमें उपयोगकर्ता की जानकारी एकत्र करनी होगी जो हम नहीं करना चाहते हैं। साथ ही, स्पैमर को बहुत सारी API कुंजियाँ प्राप्त करने से रोकने के लिए क्या है? हम संदेशों की जांच नहीं कर सकते ताकि उनके स्पैम होने का अनुमान लगाया जा सके (जो कि बहुत ही समस्याग्रस्त है), क्योंकि संदेशों को एन्क्रिप्ट करने के अलावा, हमारे पास संदेश सामग्री पर एक व्यावहारिक नीति है। इन आवश्यकताओं को देखते हुए, हम स्पैम को रोकने के लिए दो तरीके अपनाते हैं: यदि आप जानते हैं कि स्पैमर इस सेवा का दुरुपयोग कर रहे हैं, तो कृपया दुर्व्यवहार की रिपोर्ट दर्ज करें ।

कैप्चा को पूरा करने के लिए प्राप्तकर्ता की आवश्यकता का विकल्प क्यों है?

हालांकि यह सच है कि हम कैप्चा को नापसंद करते हैं, हम मानते हैं कि वे एक उद्देश्य की पूर्ति करते हैं और उनके पास एक समय और स्थान है (कम से कम अभी के लिए)। प्रेषक के लिए कुछ आश्वासन प्राप्त करने का यह एक आसान तरीका है कि प्राप्तकर्ता मानव है और स्वचालित प्रक्रियाएं संदेश तक नहीं पहुंच रही हैं।

यह सेवा कौन चला रहा है और यह मुफ़्त क्यों है?

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

मैं ऊपर दिए गए सवालों के जवाबों पर कैसे भरोसा कर सकता हूं?

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