E2EE प्रदाता के पढ़ सकने की सीमा तय करता है; यह हर उस जगह का विवरण नहीं देता जहाँ बातचीत मौजूद हो सकती है।
किसी मैसेजिंग प्रदाता को भेजी गई कानूनी माँग उन रिकॉर्ड तक पहुँच सकती है जो प्रदाता के पास हैं या जिन तक उसकी पहुँच है। एंड-टू-एंड एन्क्रिप्शन निजी संदेशों की सामग्री को प्रदाता के पास पढ़ने योग्य रूप में मौजूद होने से रोक सकता है, लेकिन यह खाते को गुमनाम नहीं बनाता और न जाँचकर्ताओं को अन्य जगहों से जानकारी लेने से रोकता है।
परिणाम सेवा की वास्तविक डेटा प्रतिधारण व्यवस्था, इस्तेमाल की गई संचार सुविधा, साक्ष्य के स्रोत और लागू कानूनी प्रक्रिया पर निर्भर करता है। रिकॉर्ड पेश करने का समन, तलाशी वारंट और उपकरण की जाँच एक-दूसरे के स्थान पर नहीं रखे जा सकते। यह लेख तकनीकी सीमाएँ समझाता है, न कि कोई खास अदालत या क्षेत्राधिकार मामले को कैसे संभालेगा; वास्तविक माँग के लिए योग्य कानूनी सलाह लें।
डेटा के स्रोत से शुरू करें
“क्या पुलिस एन्क्रिप्टेड संदेश पढ़ सकती है?” जैसा सवाल बहुत व्यापक है। पूछें कि प्रति कहाँ से आएगी:
| स्रोत | क्या उपलब्ध हो सकता है | E2EE क्या बदलता है |
|---|---|---|
| मैसेजिंग प्रदाता | खाते के रिकॉर्ड, सहेजा मेटाडेटा, सार्वजनिक पोस्ट और एन्क्रिप्टेड डिलीवरी डेटा | सही ढंग से लागू E2EE निजी प्लेनटेक्स्ट तक पहुँच सीमित करता है, जब प्रदाता के पास कुंजियाँ नहीं होतीं |
| किसी सहभागी का उपकरण | दिखाई देने वाली बातचीत, स्थानीय डेटाबेस, डाउनलोड की गई फ़ाइलें या सूचनाएँ | ट्रांज़िट एन्क्रिप्शन उस डेटा को नहीं छिपाता जो किसी सुलभ एंडपॉइंट पर पहले से उपलब्ध है |
| बैकअप सेवा | बैकअप में जो भी है, उसकी अपनी एन्क्रिप्शन और कुंजी नीति के अधीन | चैट का E2EE अपने-आप बैकअप का E2EE साबित नहीं करता |
| प्राप्तकर्ता या समूह सदस्य | उनकी प्रतियाँ, स्क्रीनशॉट, एक्सपोर्ट या गवाही | प्राप्तकर्ता उसे मिली जानकारी उजागर कर सकता है |
ये श्रेणियाँ एक-दूसरे से मिल सकती हैं। पढ़ने योग्य निजी इतिहास न रखने वाला सर्वर भी उपयोगी रिकॉर्ड रख सकता है; बहुत से रिकॉर्ड वाला प्रदाता अपनी प्रतिधारण नीति के तहत कोई खास वस्तु मिटा चुका हो सकता है। केवल एन्क्रिप्शन के बैज से इनमें से कोई निष्कर्ष नहीं निकाला जा सकता।
दस्तावेज़ित उदाहरण: Signal का प्रकाशित उत्तर
अपने अक्टूबर 2021 के कैलिफ़ोर्निया ग्रैंड ज्यूरी प्रकटीकरण में Signal ने बताया कि माँगी गई संदेश, संपर्क और समूह जानकारी के बजाय उसने खाता निर्माण के टाइमस्टैम्प और अंतिम कनेक्टिविटी की तारीखें दीं। यह उस प्रकाशित उत्तर के लिए Signal के पास उपलब्ध रिकॉर्ड का साक्ष्य है।
यह इस बात का प्रमाण नहीं है कि हर एन्क्रिप्टेड मैसेंजर वही दो फ़ील्ड रखता है। डेटा न्यूनतम रखना एक अलग संरचनात्मक चुनाव है। यह उदाहरण यह भी नहीं बताता कि जाँचकर्ता उपयोगकर्ता के उपकरण, किसी अन्य सहभागी या दूसरी सेवा से क्या प्राप्त कर सकता है।
सर्वर की दृश्यता के बारे में Livara क्या दस्तावेज़ित करता है
Livara का सुरक्षा अवलोकन, जिस पर संस्करण 0.1.68 का लेबल है, LVR1-सुरक्षित सीधे संदेश और LGS1-सुरक्षित संगत निजी समूहों का वर्णन करता है; पुराने असंगत समूह स्पष्ट रूप से E2EE के बाहर रहते हैं। उसका दस्तावेज़ित अटैचमेंट डिज़ाइन अपलोड से पहले फ़ाइलें एन्क्रिप्ट करता है और उनकी कुंजियाँ बातचीत के एन्क्रिप्टेड एनवेलप में पहुँचाता है।
उसी अवलोकन में रखे जाने वाले संचार मेटाडेटा की पहचान की गई है, जिसमें प्रेषक और गंतव्य की जानकारी, टाइमस्टैम्प, आकार और समूह सदस्यता शामिल हैं। सार्वजनिक चैनल सर्वर द्वारा पढ़े जा सकते हैं। वैकल्पिक रूप से सर्वर पर रिकॉर्ड की जाने वाली कॉल, जिन पर स्पष्ट REC निशान होता है, उस रिकॉर्डिंग मोड में E2EE के बजाय ट्रांसपोर्ट एन्क्रिप्शन इस्तेमाल करती हैं। एक ऐप की सभी सामग्री को एक जैसा मानने के बजाय सुविधा-विशिष्ट सीमा पढ़ें।
दस्तावेज़ यह भी कहते हैं कि LSS1 मेटाडेटा सुरक्षा सामान्य भेजने की प्रक्रिया से जुड़ी नहीं है। इसलिए यह कहना भ्रामक होगा कि सामान्य मैसेजिंग सेवा से संचार संबंधों का ग्राफ़ छिपाती है।
ये उत्पाद दस्तावेज़ों के दावे हैं, किसी कानूनी माँग का प्रकाशित उत्तर या हर सर्वर रिकॉर्ड का स्वतंत्र ऑडिट नहीं। अपेक्षित सीमाएँ समझने के लिए खतरा मॉडल सही शुरुआती बिंदु है।
एन्क्रिप्शन और प्रतिधारण अलग सवालों के जवाब देते हैं
एन्क्रिप्शन पूछता है कि सहेजे गए बाइट्स का अर्थ समझने की कुंजियाँ किसके पास हैं। प्रतिधारण पूछता है कि कौन-से बाइट्स और रिकॉर्ड अभी भी मौजूद हैं। एन्क्रिप्टेड फ़ाइल लंबे समय तक रखी जा सकती है; पढ़ने योग्य लॉग कम समय तक रह सकता है। “हम संदेश डिक्रिप्ट नहीं कर सकते” का दावा यह साबित नहीं करता कि IP पते, सहायता बातचीत, दुर्व्यवहार रिपोर्ट या डिलीवरी रिकॉर्ड अनुपस्थित हैं।
उपयोगी पारदर्शिता रिपोर्ट में रिपोर्टिंग अवधि, अनुरोध की श्रेणियाँ, माँगे गए रिकॉर्ड, दिए गए रिकॉर्ड और प्रकटीकरण की सीमाएँ बताई जानी चाहिए। गोपनीयता नीति में संग्रह और प्रतिधारण का अंतर तथा अपवाद समझाए जाने चाहिए। गोपनीयता के सामान्य वादे से “कोई लॉग नहीं” का निष्कर्ष न निकालें।
प्रमाणीकरण के अपने रिकॉर्ड भी होते हैं। SRP ईमानदारी से चल रहे प्रोटोकॉल आदान-प्रदान के दौरान पासवर्ड भेजने से बच सकता है, लेकिन सर्वर एक वेरिफ़ायर रखता है। RFC 5054 खंड 3.3 वेरिफ़ायर चोरी के जोखिम समझाता है, जिनमें पासवर्ड अनुमान लगाना भी शामिल है। “प्लेनटेक्स्ट पासवर्ड नहीं” का अर्थ “कोई संवेदनशील चीज़ उजागर या चोरी नहीं हो सकती” नहीं है।
मैसेंजर पर भरोसा करने से पहले पूछने वाले सवाल
- क्या E2EE ठीक इसी चैट, बैकअप, कॉल और अटैचमेंट मोड को कवर करता है?
- प्रदाता कौन-सा मेटाडेटा दस्तावेज़ित करता है और कितने समय तक रखता है?
- क्या अतिरिक्त उपकरण या खाता रिकवरी के रास्ते स्थानीय प्रति उजागर कर सकते हैं?
- क्या सार्वजनिक पोस्ट, सहायता को भेजी सामग्री और रिपोर्ट किए गए संदेश अलग ढंग से संभाले जाते हैं?
- क्या आधारहीन कानूनी प्रतिरक्षा के दावे के बजाय तारीख वाली पारदर्शिता रिपोर्ट या वास्तव में प्रकट किया गया अनुरोध मौजूद है?
सक्रिय कानूनी मामले में ब्लॉग पोस्ट को रिकॉर्ड मिटाने, प्रतिधारण बदलने या आदेश की अनदेखी करने का निर्देश न मानें। संबंधित क्षेत्राधिकार के अनुकूल सलाह लें और सलाह के अनुसार प्रासंगिक सामग्री सुरक्षित रखें।
क्या पोस्ट-क्वांटम एन्क्रिप्शन जवाब बदलता है?
यह उचित ढंग से डिज़ाइन किए गए कुंजी-स्थापना प्रोटोकॉल को पकड़े गए सिफ़रटेक्स्ट पर भविष्य के क्वांटम हमलों के विरुद्ध मज़बूत कर सकता है। यह मौजूदा मेटाडेटा, सार्वजनिक सामग्री, एंडपॉइंट प्रतियाँ या कानूनी दायित्व नहीं हटाता। व्यावहारिक अंतर वही रहता है: डेटा, उसका स्थान, कुंजियाँ और पहुँच माँगने वाली प्रक्रिया पहचानें।
