बारम्बार सोधिने प्रश्नहरू

• किन यो साइट खराब अनुवाद गरिएको छ? ⎃
• यो सेवा कत्तिको सुरक्षित छ?
• किन म यहाँ एक सन्देश डिक्रिप्ट विकल्प को साथ एक लिंक प्राप्त गर्नुभयो?
• यस साइटमा सबमिट गरिएको सबै चीज तपाई मेट्नुहुन्छ?
• किन यो सेवा प्रयोग गर्ने?
• के यो सन्देश सेवा हो?
• प्रयोगका उद्देश्यहरू के के हुन्?
• यो सेवा के को लागी प्रयोग गर्नु हुँदैन?
• किन PGP / Signal / OMEMO / Matrix / आदिको मात्र प्रयोग गर्नुहुन्न?
• के आवश्यकताहरु अवस्थित छ?
• के प्राप्तकर्ताले सन्देशको प्रतिलिपि बनाउन सक्दछन्?
• के कुनै व्यक्तिगत जानकारी स ?्कलन गरिएको छ?
• कुन जानकारी लग गरिएको छ?
• तपाईं सर्भरहरू सुरक्षित गर्न के गर्दै हुनुहुन्छ?
• यस साइट प्रयोग गर्दा के सुरक्षा जोखिमहरू छन्?
• तपाईं म्यान-इन-द-मिडल (MITM) आक्रमणहरू बारे के गर्दै हुनुहुन्छ?
• ब्राउजर विस्तारले के सुविधाहरू प्रदान गर्दछ?
• म निश्चित रूपमा कसरी थाहा पाउन सक्छु कि सबमिट गरिएको केहि एन्क्रिप्टेड अन्त-देखि-अन्त हो?
• यस साइटमा अन्त-देखि-अन्त ईन्क्रिप्शनले कसरी काम गर्दछ?
• डिक्रिप्शन पासवर्ड URL मा हुन सक्छ?
• तर डिक्रिप्शन पासवर्ड URL मा हुनु पर्दैन?
• यस सेवाले प्राप्तकर्तालाई लिंक प्रदान गर्दैन?
• यो सेवा प्रयोग गर्दा म मेरो गोपनीयतालाई यथासम्भव कसरी जोगाउन सक्छु?
• के हुन्छ यदि म संयुक्त राज्य मा विश्वास गर्दिन?
• तपाईं स्पाम रोक्न के गर्दै हुनुहुन्छ?
• किन त्यहाँ एक विकल्प प्राप्तकर्तालाई क्याप्चा पूरा गर्न आवश्यक छ?
• यो सेवा कसले चलाइरहेको छ र किन नि: शुल्क छ?
• माथिका प्रश्नहरूको जवाफलाई म कसरी विश्वास गर्न सक्छु?

किन यो साइट खराब अनुवाद गरिएको छ? ⎃

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

यो सेवा कत्तिको सुरक्षित छ?

हामीले यस सेवालाई यसको प्रयोगका लागि सुरक्षित बनाउन धेरै चरणहरू लिएका छौं। हामी यी चरणहरू पार गर्नु अघि, निम्नको कुरा बुझ्न यो महत्त्वपूर्ण छ:

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

हाम्रो लक्ष्य भनेको यो सेवाको तरीकाले प्रस्ताव गर्नु हो जुन तपाईंको गोपनीयता र सुरक्षा बढाउन विकल्पहरू प्रदान गर्दछ। यहाँ केहि चरणहरू छन् जुन हामीले तपाईंको जानकारी सुरक्षित राख्न उठाएका छौं।

• सेवा प्रयोग गर्न कुनै व्यक्तिगत जानकारी (जस्तै नाम / ईमेल / फोन / आदि) आवश्यक छैन। त्यहाँ कुनै खाता प्रणाली छैन (उदाहरण लगइन / पासवर्ड / आदि।); त्यसकारण कुनै पनि डाटा उल्ल .्घनले यो जानकारी लीक गर्न सक्दैन।
• सबै सन्देश सामग्री अन्त-देखि-एन्क्रिप्टेड छ । अर्को शब्दहरूमा, डिक्रिप्शन कुञ्जी / पासवर्ड हामीलाई कहिले पनि पठाइएको हुँदैन। त्यसकारण, हामीसँग वा डाटाबेसको स्वामित्वमा कसैको पनि डिक्रिप्ट गर्न र सन्देश सामग्री हेर्नको लागि कुनै साधन छैन।
• हाम्रो डाटाबेसमा प्रत्येक प्रविष्टिको समय-देखि-प्रत्यक्ष १ मिनेट देखि २ हप्ताहरू (१ हप्तामा डिफल्टहरू) हुन्छ। एक पटक यो समय बितिसकेको छ, रेकर्ड स्वत: मेटिने छ। तसर्थ, हाम्रो डाटाबेस मा कुनै पनि जानकारी यसको निर्माण पछि तुरुन्तै मेटिने छ ।
• हामी केवल अन्तिम २ 24 घण्टा वेब सर्भर लगहरू राख्छौं । डाटाबेसमा भण्डारित कुनै पनि आईपी जानकारी सुरक्षित रूपमा ह्याश गरिएको छ मूल आईपी निकाल्न असम्भव बनाउँदै।
• यस सेवालाई पावर गर्ने सबै कोडहरू खुला स्रोत हुन् र समीक्षाको लागि उपलब्ध छ। तपाई सजिलैसँग कोड देख्न सक्नुहुनेछ जुन ईन्क्रिप्शन चल्दछ - जुन जानबूझकर छोटो, संक्षिप्त, र टिप्पणी गरिएको छ।
• सुरक्षालाई मद्दत गर्न धेरै प्राविधिक सावधानीहरू लिईन्छन् - जसमा केहि निम्न समावेश छन्:
  • यो एपीआई बाहेकको सम्पूर्ण वेब साइट स्थिर छ र पृष्ठमा सर्वर-कोड समर्थन गर्दैन (उदाहरणको लागि PHP / JSP / ASP / आदि।)
  • वेब क्राइप्टो एपीआई , जुन ब्राउजरको अंश हो, सबै सन्देश सामग्री ईन्क्रिप्ट गर्न प्रयोग गरिन्छ।
  • TLS तपाईको ब्राउजर र हाम्रो सर्वर बिच ईन्क्रिप्ट संचार गर्न प्रयोग गरीन्छ। यसले यो सुनिश्चित गर्न मद्दत गर्दछ कि ट्रान्जिटमा कोड अवरोध वा परिमार्जन हुन सक्दैन। TLS १.3 समर्थित छ, तर हामी TLS १.२ लाई पनि पुरानो उपकरणहरूको लागि समर्थन गर्दछौं। TLS का पुराना संस्करणहरू असक्षम पारिएका छन् किनकि तिनीहरू सुरक्षित छैनन्।
  • प्रमाणपत्र पारदर्शी लगहरू प्रमाणपत्र misissuance लागि अनुगमन छन्। थप रूपमा हामी अनावश्यक वा मालिसियस गलत मिसिसन्सको जोखिम कम गर्न एक प्रमाणन प्राधिकरण प्राधिकरण (CAA) नीति प्रकाशित गर्दछौं।
  • हामी HTTP सख्त यातायात सुरक्षा (HSTS) को उपयोग यो सुनिश्चित गर्नका लागि कि ब्राउजरहरूले जहिले पनि TLS प्रोटोकल प्रयोग गरेर हाम्रो सर्भरहरूसँग कुराकानी गर्दछ। थप रूपमा, हामी पूर्वलोड सूचीमा हाम्रो डोमेनहरू समावेश गर्दछौं।
  • क्रस साइट स्क्रिप्टि ((XSS) आक्रमणहरू रोक्न एक कडा सामग्री सुरक्षा नीति लागू गरिएको छ।
  • एक क्रस-उत्पत्ति संसाधन नीति , एक क्रस-उत्पत्ति एम्बेडर नीति , र एक क्रस-उत्पत्ति ओपनर नीति प्रयोग गरेर , हामी स्प्याक्टर र मेल्टडाउन जस्ता सट्टा-च्यानल हमलाहरू विरूद्ध शान्त पार्न मद्दतको लागि क्रस मूल कोडलाई निषेध गर्दछौं। यसले समान उदा कागजातहरूमा मात्र ब्राउजिंग प्रसंग अलग गरेर अन्य मूलबाट सम्भावित मालिसियस अनुरोधहरूको बिरूद्ध संरक्षण प्रदान गर्दछ।
  • हामीले ब्राउजरलाई संसाधनहरू लोड गर्नबाट रोक्नको लागि अनुमति नीति प्रयोग गर्दछौं जसले तपाईंको गोपनीयता, जस्तै तपाईंको स्थान, वेब-क्याम, माइक्रोफोन, इत्यादिमा सम्झौता गर्न सक्छ।
  • DNSSEC हाम्रो सबै प्रयोगक्षेत्रहरूमा DNS- आधारित MITM आक्रमणहरू कम गर्न मद्दतको लागि प्रयोग भएको छ।
  • हामी सर्भर सुरक्षित गर्न को लागी धेरै सावधानी अपनाउँदछौं।
  • कुनै तेस्रो पार्टी कोड लोड गरिएको छैन (उदाहरणका लागि jQuery) र धेरै थोरै संसाधनहरू लोड गरिएको छ (अगाडि बढ्नुहोस् र जाँच गर्न देव उपकरणमा नेटवर्क ट्याब खोल्नुहोस्) - यसले अडिट गर्न आवश्यक प्रयासलाई न्यून तुल्याउँछ। एउटा अपवाद हो यदि एक CAPTCHA आवश्यक छ - त्यो hCaptcha बाट तेस्रो पार्टी कोड लोड गर्दछ। यद्यपि hCaptcha कोड यसको आफ्नै URL मा लोड हुन्छ आफ्नै आफ्नै CSP नियम भित्र र कुनै समय कुनै सन्देशमा गर्नुपर्ने केहि पनि पहुँच हुँदैन।
  • MITM आक्रमणको बिरूद्ध सुरक्षित गार्डलाई मद्दत गर्ने साधनको रूपमा, ब्राउजर विस्तारहरू उपलब्ध छन् ।

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

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

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

यस साइटमा सबमिट गरिएको सबै चीज तपाई मेट्नुहुन्छ?

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

• ईन्क्रिप्टेड सन्देशहरू जसको लागि हामीसँग सामग्रीहरू डिक्रिप्ट गर्नको लागि कुनै साधन छैन
• अन्य जानकारी वेबमा सबमिट गर्न अन्तर्निहित (जस्तै तपाईंको आईपी ठेगाना, आदि)।

सन्देशहरूको मामलामा, तपाईं नियन्त्रण गर्न सक्नुहुनेछ जब हामी तिनीहरूलाई निर्दिष्ट गरेर मेटाउछौं:

• हामीले कहिलेसम्म सन्देश राख्नु पर्छ यदि कसैले यसलाई पुनः प्राप्त गर्दैन भने (१ मिनेट देखि २ हप्ता सम्म - डिफल्ट १ हप्ता सम्म)।
• कति पटक सन्देश पुन: प्राप्त गरियो (१ देखि १०० पटक सम्म - पूर्वनिर्धारित १ पटक)

पूर्वनिर्धारित रूपमा, सन्देशको बारेमा सबै कुरा मेटिन्छन् एक पटक पुन: प्राप्त पछि वा १ हप्ता पुरानो - जुन पहिले हुन्छ। जब वेबमा कुनै पनि कुरा सबमिट गर्दा अन्तर्निहित अन्य सबै जानकारी मेटाउने कुरा आउँछ (उदाहरणका लागि तपाईंको आईपी ठेगाना, आदि), हामी तपाईंलाई कहिले वा कसरी मेटाउने भन्ने बारे कुनै नियन्त्रण दिदैनौं - हामी केवल २ 24 घण्टामा सबै हटाउँछौं। ।

किन यो सेवा प्रयोग गर्ने?

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

के यो सन्देश सेवा हो?

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

प्रयोगका उद्देश्यहरू के के हुन्?

त्यसोभए केहि परिदृश्यहरू के छन् जहाँ यो सेवा प्रयोग गर्न उपयुक्त छ? जबकि सबैको आवाश्यकता र आवश्यकताहरू हुन्छन् जब यो उनीहरूको गोपनीयता र सुरक्षाको कुरा आउँदछ, मैले व्यक्तिगत तवरले निम्न परिदृश्यहरू उपयुक्त प्रयोगका मामलाहरूमा भेट्टाएको छु:

• तपाईं स्थानीय वेब फोरम मार्फत यस क्षेत्रमा माउन्टेन बाइकिking ट्रेल्सको बारेमा कुराकानी गर्दै हुनुहुन्छ र कहिलेकाँही फोरममा व्यक्तिहरूसँग नयाँ ट्रेलहरू जाँच गर्नका लागि भेट्नुहोस्। फोरमबाट कोहीले तपाईंलाई तपाईंको ठाउँमा कारपूलको लागि यस साताको अन्तमा टिप्न चाहन्छ। तपाइँ आफ्नो घर ठेगाना चाहनुहुन्न जुन यस वेब साइट फोरम डेटाबेसमा सँधैको लागि बसिरहेको छ। साधारणतया यो सेवा मार्फत ठेगाना पठाउनुहोस् - लिंक त्यो हो जुन वेब साइट फोरम डाटाबेसमा रहन्छ, तर एकपटक यो प्राप्तकर्ताले पढ्यो भने, सन्देश / ठेगाना मेटाइनेछ।
• तपाईंले आफ्नो भाईलाई तपाईंको नेटफ्लिक्स लग इन पठाउन आवश्यक छ किनकि तपाईंको भान्जीले COVID लकडाइनको कारण पागल हो भनेर जाँदैछ र अझै ऊसँग आफ्नै खाता छैन। तपाईं यो लगईनको बारेमा धेरै मतलब गर्नुहुन्न, तर तपाईंको भाइ खास गरी नराम्रो छ जसमा म केवल "डिजिटल स्वच्छता" कल गर्छु र सम्झौता लगइनहरू र मालवेयरका साथ धेरै परीक्षणहरू भएका छन्। त्यसपछिको प्रयासहरू उसको कार्य सफा गर्न को लागी कोशिश गरीयो र सुरक्षित सन्देश पठाउन पनि असफल भयो। साधारणतया यसलाई पाठ सन्देश मार्फत पठाउनु नै उत्तम विकल्प हो (दुःखको कुरा), तर तपाईं विगतका अनुभवका कारण त्यो सन्देशको ईतिहासमा लगइन बस्नु असजिलो हुनुहुन्छ। यो सेवा प्रयोग गरेर पाठ सन्देशमा लिंक मार्फत लगईन पठाउनको लागि संतुष्ट हुन्छ कि च्याट ईतिहासमा लगइनलाई सँधै बाहिर पर्खिदैन।
• तपाईं कहिलेकाँही अफिसमा काम गर्नुहुन्छ जुनसँग धेरै साझेदारहरू छन् जुन आउँदछ र आउँदछ। त्यहाँ प्रयोगको लागि वाइफाइ उपलब्ध छ, तर पासवर्ड हरेक हप्ता घुमाइएको छ किनकि त्यहाँ दुर्व्यवहारको साथ समस्या आएको छ। धेरै भाडावालहरूले ईमेल / पाठ वाइफाइ पासवर्डको लागि सोध्दै यो फ्रन्ट डेस्कमा छ किनकि प्राय: फ्रन्ट मुख्य प्रवेशद्वारबाट प्रवेश गर्दैन। यो सेवा प्रयोग गरेर, कार्यालय प्रबन्धकले ईमेल / पाठ उत्तरमा लिंकको माध्यमबाट वाइफाइ पासवर्ड पठाउन सक्दछ पासवर्ड लामो ढंगमा नदिनुलाई सन्तोष गर्दछ, र प्राप्तकर्तालाई तुरून्त एक प्रतिलिपि बटन मार्फत पासवर्ड प्रतिलिपि गर्न अनुमति दिन्छ जुन मोबाइल उपकरणहरूमा कम अनाड़ीपूर्ण छ।
• तपाईको होस्टिंग प्रदायक मध्ये एकले तपाईलाई सर्भरको बारेमा विवरण सोध्न सोधेको छ जुन तपाईले रिपोर्ट गर्नुभयो हार्ड ड्राइभको स showing्केत देखाउँदैछ जुन नराम्रो देखिन्छ। उनीहरूलाई आवश्यक पर्ने केही जानकारी थोरै संवेदनशील हुन्छ - तपाईले यसलाई तेर्सो पार्टी टिकट प्रणालीमा सधैँ बसिरहेको चाहनुहुन्न। यो सेवा प्रयोग गरेर, तपाईं यो जानकारी टिकट प्रणालीमा नभई समर्थन टेक्नीशियनहरूलाई जानकारी पठाउन सक्नुहुनेछ। किनकि धेरै प्राविधिकहरूले धेरै पटक जानकारीमा सन्दर्भ गर्नु आवश्यक पर्दछ, १-भन्दा ठूलो (पढ्नका लागि-लाईभ सेट गर्नुहोस् (जसमा शायद २०) ताकि सन्देश पहिलो पुन: प्राप्तिमा मेटिने छैन।
• तपाईंले रेडडिटमा अर्को प्रयोगकर्तालाई निजी सन्देश लिन आवश्यक पर्दछ तिनीहरूलाई तपाईंको फोन नम्बर थाहा दिनको लागि कि तिनीहरूले तपाईंलाई कल गर्न सक्छन्। रेडडिट, अन्य धेरै प्रदायकहरूले झैं विगतमा प्रयोगकर्ता जानकारी लीक गरेको छ र तपाईं अर्को फोन लीक नभएसम्म रेडडिट डाटाबेसमा बसिरहेको तपाईंको फोन नम्बर चाहनुहुन्न। यस सेवा मार्फत सरल रूपमा तपाईंको फोन नम्बर पठाउनुहोस्।
• तपाईको पति / पत्नीले तपाईलाई सन्देश पठाउँछन् तपाई काममा हुँदा युटिलिटी चाहिन्छ चाहिन्छ किनभने उनको साथीले भर्खरै एउटा नयाँ प्रोग्राम चलाएर प्रयास गर्यो कि उनको पैसाले उनको बिधुत बिलमा बचत गर्‍यो र उनी जाँच गर्न चाहान्छिन्। त्यहाँ एक साझा पारिवारिक पासवर्ड प्रबन्धक छ कि तपाईं उनको बारे सम्झना दिलाउनुहुन्छ, तर उहाँ तपाईंलाई लगइन पठाउन चाहानुहुन्छ। OMEMO तपाईको जीवनसाथीसँग द्रुत मेसेजिंगका लागि नियोजित गरिएको छ र यसैले तपाईले धेरै विश्वास गर्नुहुन्छ सन्देश सन्देश सुरक्षित छ; जे होस्, कुराकानी ईतिहास आफै ईनक्रिप्टेड भण्डारण गरिएको छ। तपाईंको पति / पत्नी जहिले पनि डाउनलोडहरू, ईमेलहरू, इत्यादि बारे सँधै सतर्क हुँदैनन् र उपयोगिता बिलहरू अलि बढी संवेदनशील हुन्छन् किनकि ती पहिचान चोरीको लागि निवास प्रमाणित गर्न प्रयोग गर्न सकिन्छ। तपाईं उनको लगइन विवरण पठाउन सक्नुहुनेछ यस सेवा प्रयोग गरेर उनको कम्प्युटरमा प्रतिलिपि भण्डारण हुनबाट जोगाउन।

यो सेवा के को लागी प्रयोग गर्नु हुँदैन?

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

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

किन PGP / Signal / OMEMO / Matrix / आदिको मात्र प्रयोग गर्नुहुन्न?

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

के आवश्यकताहरु अवस्थित छ?

एक आधुनिक र अप-टु-डेट वेब ब्राउजर जसले वेब क्रिप्टो एपीआई सहितका मानकहरू सही ढ properly्गले कार्यान्वयन गर्दछ। उदाहरणमा समावेश: क्रोम, फायरफक्स, एज, र सफारी (२०२० वा पछि)।

के प्राप्तकर्ताले सन्देशको प्रतिलिपि बनाउन सक्दछन्?

हो यद्यपि सन्देशले पुनः प्राप्तिमा आफै मेटाउन सक्छ, प्राप्तकर्ताले अझै सन्देश हेर्न सक्दछन्। कुनै पनि समयमा रिसीभर सन्देश पूर्ण रूपमा हेर्न सक्दछ, एक प्रतिलिपि बनाउन सकिन्छ - यो सबै संचारहरूमा लागू हुन्छ। त्यहाँ एक विकल्प छ यसलाई प्राप्त गर्न को लागी एक प्रतिलिपि बनाउन को लागी गाह्रो। यस अवस्थामा प्रतिलिपि गर्नका लागि तीन अवरोधहरू लागू भएका छन्:

• प्रतिलिपि बटन हटाइयो। यो बटन पूर्वनिर्धारित प्राप्तकर्तालाई उनीहरूको क्लिपबोर्डमा सम्पूर्ण सन्देश प्रतिलिपि गर्न अनुमति दिईन्छ।
• डाउनलोड बटन हटाइएको छ। यस बटनले पूर्वनिर्धारित प्राप्तकर्तालाई पाठ फाईलको रूपमा सन्देश डाउनलोड गर्न अनुमति दिँदछ।
• सन्देश पाठ बाकस भित्र पाठ चयन गर्ने क्षमता हटाईन्छ।

जे होस्, यी प्रतिलिपि सुरक्षा कमजोर छन् किनकि तिनीहरूलाई बाइपास गर्न सकिन्छ। साथै, प्राप्तकर्ताले सँधै सन्देशको स्क्रीनशट वा फोटो लिन सक्दछन्।

के कुनै व्यक्तिगत जानकारी स ?्कलन गरिएको छ?

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

कुन जानकारी लग गरिएको छ?

हाम्रो वेब सर्वर सबै वेब गतिविधि मा आम लग ढाँचा को २ hours घण्टा सम्म राख्छ। यसले HTTP ग्राहकहरूको पूर्ण IP ठेगाना लगि includes समावेश गर्दछ। २ hours घण्टा पछि, यो लग गरिएको जानकारी स्वचालित रूपमा मेटाइनेछ। सबै अनुरोधहरू / एपीआईमा पोष्ट गरिएको मतलब पोष्ट गरिएको हो कि कुनै सन्देश विशेष जानकारी वेब सर्भर द्वारा लग इन हुँदैन। थप रूपमा, डाटाबेसमा बचत गरिएको कुनै पनि जानकारी प्रभावी रूपमा लग गरिएको छ। डाटाबेसमा सबै प्रविष्टिहरू, अज्ञात र ह्यास गरिएको आईपी ठेगानाहरू सहित, समयावधि समाप्ति समय (TTL) हुन्छ जुन पछाडि तिनीहरू स्वचालित रूपमा मेटिनेछन्। TTL समय समाप्ति समय १ मिनेट र २ हप्ता बीच भिन्न हुन्छ।

तपाईं सर्भरहरू सुरक्षित गर्न के गर्दै हुनुहुन्छ?

सर्भर सुरक्षा स्पष्ट चिन्ता हो। यसलाई सुरक्षित राख्न हामी ध्यान केन्द्रित गर्ने दुई मुख्य क्षेत्रहरू छन्:

• पहिले, हामी सकेसम्म कम समयको लागि सकेसम्म थोरै भण्डार गर्दछौं यदि सर्वर कहिल्यै सम्झौता गरिएको छ भने, कुनै पनि जानकारी लीक हाम्रो प्रयोगकर्तालाई हानी गर्दैन। डाटाबेसमा भण्डारण गरिएका सबै सन्देशहरू गुप्तिकरण गरीएको छैन तिनीहरूलाई डिक्राइप गर्ने कुनै माध्यमको साथ छैन। हामी कुनै पनि प्रयोगकर्तालाई कुनै पनि सन्देश लिंक गर्ने कुनै पनि कुरा भण्डार गरिएको छैन किनकि हामी हाम्रो प्रयोगकर्ताहरूबाट व्यक्तिगत जानकारी एकत्रित गर्दैनौं। डाटाबेसमा सबै रेकर्डहरूको म्याद सकिने समय हुन्छ (TTL) १ मिनेट देखि २ हप्ता सम्म - यस समय बितिसकेपछि रेकर्ड स्वत: हटाइन्छ। तसर्थ, डाटाबेसमा कहिल्यै भएको बहुसंख्यक जानकारी लामो समय पहिले नै हटाईएको थियो।
• हामी सम्झौता रोकथाम गर्न को लागी धेरै उपायहरु गर्छौं र कुनै पनि सम्झौता भएको हुन्छ:
  • वेब सर्भर, nginx , एक अलग कन्टेनरमा चलाइएको छ असुरक्षित प्रयोगकर्ताको रूपमा लग बाहेक अरू केहि लेख्न पहुँच बिना। कन्टेनरले आफ्नै SELinux प्रसंग भित्र चल्छ कुनै पनि फाइल प्रणाली परिवर्तन वा कन्टेनरबाट सजीलो बच्न रोक्दछ। त्यहाँ पीएचपी / एएसपी / JSP / आदिको लागि कुनै समर्थन छैन। - मात्र स्थिर संसाधनहरू सेवा गर्दै।
  • कोड चालु / एपीआई गो मा लेखिएको छ जसले यसलाई बफर ओभरफ्लो कमजोरीहरू (सामान्य आक्रमण भेक्टर) लाई पर्याप्त लचिलो बनाउनु पर्छ। गो प्रक्रिया पनि एक अलग कन्टेनरमा चलाउँदछ एक unpriveleged उपयोगकर्ता को रूपमा डाटाबेस बाहेक अरू केहि लेख्न पहुँच को लागी। कन्टेनरले आफ्नै SELinux प्रसंग भित्र चल्छ कुनै पनि फाइल प्रणाली परिवर्तन वा कन्टेनरबाट सजीलो बच्न रोक्दछ। डाटाबेस, Badgerdb , Go प्रक्रियाको अंश हो (बाह्य डाटाबेस निर्भरता / प्रक्रिया छैन)।
  • सर्भर सम्झौताको मुख्य खतरा यो हो कि आक्रमणकारीले फाइलहरू परिमार्जन गर्न सक्ने तरीकाले जुन हाम्रो प्रयोगकर्ताहरूको गोपनीयता / सुरक्षामा सम्झौता गर्दछ। एक समर्पित प्रक्रिया को लागी सबै वेब साइट फाईलहरु को लागी कुनै परिवर्तन को लागी निगरानी गर्दछ र घटना मा तुरुन्तै सतर्क गराईन्छ कुनै परिवर्तन छ।
  • सबै प्रशासकीय पहुँच सुरक्षित र आधिकारिक नेटवर्कहरूमा सीमित छन्।

यस साइट प्रयोग गर्दा के सुरक्षा जोखिमहरू छन्?

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

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

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

• यो सेवाका लागि सबैभन्दा ठूलो जोखिम र सबैभन्दा अनौंठो यो हो कि हाम्रा प्रयोगकर्ताहरूले राम्रो निर्णय प्रयोग गर्दैनन् के पठाउनको लागि उपयुक्त छ र के पठाउनको लागि उपयुक्त छैन भन्ने बिचमा भिन्नता छ। कहिलेकाँहि "म यस जानकारीलाई ईमेल गर्न सजिलो लाग्छ - म पढ्छु कि ईमेल मेटाईन्छ" र "म यो जानकारी ईमेल गर्न सहज छैन - ईमेल एक अनुपयुक्त यातायात हो" "बीचको भिन्नता एकदम सूक्ष्म हुन सक्छ।
• त्यहाँ सधैं खतरा छ कि यस साइटका अपरेटरहरू वास्तवमा खराब अभिनेताहरू हुन् जसले मानिसहरूलाई अन्धकारको अन्तिम लक्ष्य प्राप्त गर्न सेवाको प्रयोग गर्न लोभ्याउँछन्। हामी एक प्रशंसनीय भरपर्दो भरि आएका छौं - सबै कुरा सजिलो र निःशुल्क बनाउनुहोस् - सेवा प्रयोग गर्ने धेरै व्यक्तिलाई प्राप्त गर्नुहोस् - सबै जबकि भयावह आशयको साथ। Bwhahahaha! कसरी तपाईं हामीलाई विश्वास गर्न सक्नुहुन्छ?
• त्यहाँ त्यस्तो सम्भावना छ कि हाम्रो कोडमा बगहरू छन् जसले सुरक्षालाई प्रभाव पार्दछ वा हामीले केवल राम्रोसँग चीजहरू सोच्दैनथ्यौं र हाम्रा कमजोरीहरूले अब हाम्रा प्रयोगकर्ताहरूलाई असुरक्षित खतरामा पर्न लायक छन्। हामी निश्चित आशा गर्दैनौं - तर हामी यसलाई रोक्न सक्दैनौं।
• टेक-टाइटन्स विपरीत (जस्तै गुगल / फेसबुक / व्हाट्सएप) एन्क्रिप्टेड डाटाको टेराबिटहरू निरन्तर भित्र आउँछन् र उनीहरूको विशाल नेटवर्कहरू बाहिर रहन्छ, जहाँ निजी सञ्चार अन्य ट्राफिकको साथ मिसाउन सजिलो हुन्छ, स्ट्यान्डअलोन केन्द्रीकृत सेवाहरू (उदाहरणका लागि, टेलिग्राम, र हामी) बाहिर खडा। एक नेटवर्क अपरेटर वा ठूलो संगठन / सरकार को लागी सजिलो छ कि आईपी ठेगाना xxxx XYZ सेवा प्रयोग गरीरहेको छ।
• जबकि यो साइटको लागि वास्तवमै निर्दिष्ट छैन, किनकि यो कुनै पनि वेब साइटको विरूद्ध प्रयोग गर्न सकिन्छ, म्यान-इन-द-मिडल (MITM) हमलाहरू मान्य मान्य चिन्ताको विषय हो ।

तपाईं म्यान-इन-द-मिडल (MITM) आक्रमणहरू बारे के गर्दै हुनुहुन्छ?

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

• HSTS केवल TLS मार्फत जडान गर्न ब्राउजरहरूलाई बल गर्न प्रयोग गरियो। हाम्रो सर्भर पुन: निर्देशित बाहेक गैर TLS संचार बेवास्ता गर्न कन्फिगर गरिएको छ। केवल TLS १.२ वा माथि समर्थित छ।
• DNSSEC प्रयोग गरीएको छ हाम्रो डोमेनको क्षेत्रमा हस्ताक्षर गर्न। यसले DNS स्पूफिंग लागू MITM आक्रमणहरू रोक्न सक्दछ यदि यदि प्रयोगकर्ताले DNSSEC सचेत रिकर्सिभ रिजल्भर प्रयोग गर्दैछ।
• हामी एक सेवा प्रयोग गर्न प्रमाणपत्र प्राधिकरणहरू निरीक्षण गर्न कुनै अनधिकृत TLS प्रमाणपत्रहरू हाम्रो डोमेनलाई सन्दर्भित गर्दै।
• अन्त-प्रयोगकर्ताको उपकरणमा भण्डार गरिएको कोड प्रयोग गरेर हामीले सन्देश ईन्क्रिप्शन समर्थन गर्न ब्राउजर विस्तार प्रकाशित गरेका छौं।

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

ब्राउजर विस्तारले के सुविधाहरू प्रदान गर्दछ?

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

म निश्चित रूपमा कसरी थाहा पाउन सक्छु कि सबमिट गरिएको केहि एन्क्रिप्टेड अन्त-देखि-अन्त हो?

धेरै अन्य लोकप्रिय अन्त देखि अन्त एन्क्रिप्टेड (E2EE) च्याट ग्राहकहरु को विपरीत, यसको सन्देश पठाउनको लागि हामीलाई के पठाइएको हो यो हेर्नको लागि एकदम सरल छ। तलको भिडियो ट्यूटोरियलले कसरी हामीसँग सर्भरमा पठाइएको सन्देशहरू डिक्रिप्ट गर्ने कुनै विधि छैन भनेर यकिन गर्ने प्रर्दशन गर्दछ।

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

यस साइटमा अन्त-देखि-अन्त ईन्क्रिप्शनले कसरी काम गर्दछ?

यस समयमा, हामी पासवर्डबाट व्युत्पन्न कुञ्जीहरू (PBKDF2 / SHA-256 को न्यूनतम १,000०,००० पुनरावृत्ति) का साथ सममित ईन्क्रिप्शन (AES-GCM २66 बिट) प्रयोग गर्दैछौं। असममेट्रिक ईन्क्रिप्शन प्रयोग हुँदैन किनकि आवश्यकताहरू १) प्रेषकको लागि सञ्चारको थालनी गर्ने २) प्रेषक र प्रापक एकै समयमा अनलाइन हुनुहुन्न र)) प्राप्तकर्ताको बारेमा कुनै सूचना छैन र)) हामी चीजहरू वास्तविक राख्नको लागि प्रयास गरिरहेका छौं र कुञ्जी व्यवस्थापन हो। जटिल। मानक वेब क्रिप्टो एपीआई RNG सहित सबै क्रिप्टोग्राफिक कार्यक्षमताको लागि प्रयोग गरिन्छ। सामान्यतया, यहाँ के हुन्छ भनेर छ:

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

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

डिक्रिप्शन पासवर्ड URL मा हुन सक्छ?

हो यसले स्पष्ट रूपमा सुरक्षालाई असर गर्दछ किनकि यदि लिंक पठाउने विधि असुरक्षित छ भने, सन्देश असोसिएसन द्वारा असुरक्षित छ। यस मुद्दालाई हटाउन सबै कार्यक्षेत्रहरूले अतिरिक्त चरणहरू र जटिलताहरू प्रस्तुत गर्दछ जसले प्रयोगकर्ताको अनुभवलाई असर गर्छ (उदाहरणका लागि सन्देश पठाउनु अघि दुबै छेउमा चीजहरू सेटअप हुनुपर्दछ)। एक असममित योजना जहाँ प्राप्तकर्ताले सन्देशको लागि अनुरोध शुरू गर्दछ र अनुरोध लि request्क पठाउँदछ जुन हाम्रो "सबै चीज अल्पकालिक" कुञ्जी आवश्यकतासँग काम गर्न सक्छ - यो कार्यान्वयन हुन सक्छ। अन्तत: यदि दुई पार्टीहरूले एक अर्कालाई बारम्बार सन्देशहरू पठाउँदैछन् भने ती समाधानहरू प्रयोग गरेर दुबै पक्षहरू ह्यान्डल गर्न सक्छन् भन्ने धारणामा राम्रो समाधानहरू अवस्थित छन्।

तर डिक्रिप्शन पासवर्ड URL मा हुनु पर्दैन?

सही। यदि डिक्रिप्शन पासवर्ड लिंक मा शामिल छैन, तब प्राप्तकर्ता पासवर्ड को लागी प्रेरित गरिनेछ। यदि पासवर्ड सुरक्षित रूप बाट प्राप्तकर्ता (वा उनीहरु पहिले नै यो थाहा छ) लाई सञ्चार गरीएको छ, यो अवरोध विरुद्ध सुरक्षा प्रदान गर्दछ। जे होस्, हानि यो हो कि प्राप्तकर्ता लाई थाहा छ र सही पासवर्ड प्रविष्ट गर्नु पर्छ। यहाँ एक तरीका प्राप्तकर्ता को लागी पासवर्ड पठाउन को लागी जो अवरोध को बिरुद्ध केहि सुरक्षा प्रदान गर्दछ:

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

यस सेवाले प्राप्तकर्तालाई लिंक प्रदान गर्दैन?

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

यो सेवा प्रयोग गर्दा म मेरो गोपनीयतालाई यथासम्भव कसरी जोगाउन सक्छु?

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

के हुन्छ यदि म संयुक्त राज्य मा विश्वास गर्दिन?

हाम्रो सर्वरहरू संयुक्त राज्य अमेरिका मा स्थित छन्। थप रूपमा, हाम्रो CDN प्रदायक, क्लाउडफ्लेयर, संयुक्त राज्य अमेरिका मा आधारित एक कम्पनी हो। हामीले हामी वा हाम्रो सर्भरहरू बस्ने देशलाई विश्वास गर्ने आवश्यकता हटाउन कोसिस गरेका छौं किनभने हामी व्यक्तिगत जानकारी स collect्कलन गर्दैनौं, कुनै सन्देशहरू डिक्रिप्ट गर्न सक्दैनौं, र यो प्राप्त हुने बित्तिकै सबै चीज मेटिन्छ। यद्यपि हामी केही अविश्वास बुझ्न सक्दछौं किनकि यो वेब आधारित छ र विशेष गरी यदि तपाईं केहि देशहरूमा बस्नुहुन्छ भने। हामीसँग आइसल्याण्ड र स्विजरल्याण्डमा विकल्पहरू प्रदान गर्ने केही योजनाहरू छन् जुन मानिसहरूलाई अमेरिकामा विश्वास गर्न गाह्रो भएको छ। कृपया हामीलाई सूचित गर्नुहोस् कि यदि यो तपाइँलाई लागू हुन्छ यदि हामी वास्तविक माग नभएसम्म विकल्पहरू प्रस्ताव गर्न प्रेरित हुँदैनौं।

तपाईं स्पाम रोक्न के गर्दै हुनुहुन्छ?

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

• हामी क्याप्चालाई घृणा गर्दछौं - तिनीहरू समय लिन्छन् र कष्टकर छन्
• तेस्रो पक्षको जाभास्क्रिप्ट लोड गर्नु गोपनीयता र सुरक्षाका लागि आक्रामक हुन सक्छ
• हाम्रो आफ्नै क्याप्चा चलाउनु भनेको हामी हक-ए-तिलको कहिल्यै अन्त्य नहुने खेलको लागि साइन अप गर्दैछौं।
• अन्ततः व्यक्तिहरू API का मार्फत यो सेवासँग अन्तर्क्रिया गर्न सक्षम हुन चाहन्छन्

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

• आवश्यक PBKDF2 / SHA-256 पुनरावृत्तिहरूको संख्या बढाउँदै
  सबै सन्देशहरू केवल थोरै पटक मात्र पुनःप्राप्त गर्न सकिन्छ - स्प्यामरहरूको लागि एक अप्रिय विशेषता किनभने तिनीहरू धेरै सन्देशहरू पठाउनमा निर्भर छन्। कुनै पनि स्प्याम अभियानका लागि स्प्यामरले धेरै सन्देशहरू सिर्जना गर्नु पर्ने हुन्छ - हामीले यस कार्यलाई यति कम्प्युटेशनल महँगो बनाएका छौं कि यस सेवालाई स्पामको लागि दुर्व्यवहार गर्ने बनाउन एउटा अपीलिंग प्रयास हुनेछ। यो नेटवर्क पोस्टिंग सन्देशहरूको ट्र्याक राखेर पूरा भयो - सम्भव सम्पूर्ण पुन: प्राप्तिहरूको सर्तमा मापन गरियो। नेटवर्क जानकारी आफैंमा सुरक्षित रूपमा ह्याश गरिएको छ ताकि हामी ह्यासबाट वास्तविक नेटवर्क अनुमान गर्न सक्दैनौं। दिइएको नेटवर्कले अधिक सन्देशहरूको रूपमा, हामी PBKDF2 / SHA-256 पुनरावृत्तिहरूको संख्या बढाउँदछौं अर्को सन्देश पोस्ट गर्नका लागि। यसले एकदम द्रुत परिणाम गर्दछ धेरै CPU समयको लागि मात्र एकल सन्देश पोष्ट गर्न। आशा छ कि यो विधि स्प्याम दुरुपयोग रोक्नको लागि पर्याप्त हुनेछ र एकै समयमा वास्तविक प्रयोगकर्ताहरूलाई प्रभाव पार्दैन।
• प्रयोगकर्ताहरूबाट स्प्याम रिपोर्टहरू भेला गर्नुहोस् जब तिनीहरूले सन्देश पुन: प्राप्त गर्छन्
  सन्देशको ठीक तल एक "रिपोर्ट स्प्याम" बटन छ जब प्रयोगकर्ताले सन्देश पुन: प्राप्त गर्दछ। यदि सन्देश स्प्याम हो भने, आशा छ कि केहि ले seconds सेकेन्ड लिन पर्छ कि बटन क्लिक गर्न आवश्यक। जब हामी एउटा स्पाम रिपोर्ट प्राप्त गर्दछौं, यसले हामीलाई सचेत गराउँदछ र यसले निम्न नेटवर्कको लागि आवश्यक PBKDF2 / SHA-256 पुनरावृत्तिहरूलाई असर गर्न कारक गर्दछ।

यदि तपाईं सचेत हुनुहुन्छ कि स्पामकर्ताहरूले यस सेवालाई दुरुपयोग गरिरहेका छन्, कृपया दुरुपयोग रिपोर्ट गर्नुहोस् ।

किन त्यहाँ एक विकल्प प्राप्तकर्तालाई क्याप्चा पूरा गर्न आवश्यक छ?

जबकि यो सत्य हो कि हामी क्याप्चालाई मनपर्दैनौं, हामी यो पहिचान गर्दछौं कि उनीहरूले उद्देश्यको लागि सेवा गर्दछन् र समय र स्थान छ (कम्तिमा अहिलेको लागि)। प्रेषकलाई केहि आश्वासन प्राप्त गर्ने यो सरल तरीका हो कि प्रापक मानव हो र स्वचालित प्रक्रियाहरूले सन्देश पहुँच गरिरहेका छैनन्।

यो सेवा कसले चलाइरहेको छ र किन नि: शुल्क छ?

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

माथिका प्रश्नहरूको जवाफलाई म कसरी विश्वास गर्न सक्छु?

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