नॉलेज बेस

भंडारण में एन्क्रिप्शन

संदेश का हर field लिखे जाने से पहले सील किया जाता है (body, subject, addresses और attachment bytes), ताकि database की प्रति मेल नहीं, ciphertext हो।

अभी नहीं

आज केवल वही credentials इस तरह सील होते हैं जो आप हमें सौंपते हैं; body, subject और attachments जैसे आए वैसे ही संग्रहित होते हैं, और जो envelope उन्हें सील करेगा वह बना हुआ है पर जानबूझकर किसी चीज़ से जुड़ा नहीं है।

विवरण

शिप नहीं हुआ। लिखे जाने से पहले एक ही चीज़ सील होती है और कुछ नहीं: एक webhook signing secret। वह अपनी ही व्युत्पन्न कुंजी से सील होता है ताकि एक तालिका से उठाया गया ciphertext किसी दूसरी के रूप में न खुले, और पूरे codebase में यही अकेली जगह है जहाँ कुछ भी सील होता है। कोई body, subject, contact, नोट, कैलेंडर प्रविष्टि या attachment इससे होकर नहीं गुज़रता।
यह अपने दोनों पड़ोसी दावों से अलग दावा है, और अंतर इसमें है कि कुंजी किसके पास है। सिरे-से-सिरे तक एन्क्रिप्शन का अर्थ है कि कुंजी आपकी है और मेल यहाँ पढ़ी नहीं जा सकती; भंडारण में एन्क्रिप्शन का अर्थ है कि मेल भंडारण में जाते समय इस server की व्युत्पन्न कुंजी से सील होती है, इसलिए database का dump, भटका हुआ बैकअप या ऐसी query जो किसी को नहीं चलानी थी, ciphertext होती है, जबकि server स्वयं उसे thread करने, खोजने और सारांश बनाने के लिए खोल सकता है। पहला आपको हमसे बचाता है। दूसरा आपको बाक़ी सबसे बचाता है, और यही वह है जो दूसरों के साथ बार-बार होता रहता है।
आज जो सच है उसे अनुमान पर छोड़ने के बजाय साफ़ कह देना बेहतर है: मेल ऐसे बुनियादी ढाँचे पर संग्रहित होती है जो अपनी डिस्क खुद एन्क्रिप्ट करता है, उसके ऊपर हमारी अपनी कोई परत नहीं है, और कुंजियाँ हमारे पास हैं, इसलिए server जो संग्रहित करता है उसे पढ़ सकता है, और जो सुविधाएँ आपकी मेल खोजती और सारांश बनाती हैं वे ठीक यही करती हैं। गोपनीयता पेज लिखे जाने से इन्हीं शब्दों में यह कहता आया है, और जब तक यह शिप नहीं होता, कहता रहेगा।
हर field का अर्थ body से कहीं अधिक है। subject, प्रेषक और प्राप्तकर्ता की सूची तथा सूची दृश्य में दिखने वाला अंश साधारण index किए गए columns में बैठते हैं, और वैसे ही संदेश से बने सारांश, thread से जोड़े गए आपके नोट, contact के नाम, कैलेंडर शीर्षक और स्थान, तथा हर फ़ाइल का नाम और प्रकार भी। ऐसा कार्ड जो एन्क्रिप्टेड कहे जबकि subject पंक्ति खुली पड़ी रहे, वही padlock होता जिसे यह उत्पाद और कहीं बनाने से इनकार करता है।
इसकी क़ीमत क्या है, यही खुला सवाल था, और अब उसके खोज वाले आधे हिस्से के सामने बहस नहीं, एक संख्या है। आज खोज हर thread के नवीनतम संदेश के पहले 4,000 अक्षरों पर चलने वाली query है, जो सादे पाठ में रखी है। सील होने पर वह उसी mailbox store के भीतर एक decrypt और एक scan बन जाती है जिसके पास पहले से कुंजी है, और यह एक-एक पंक्ति के बजाय टुकड़ों में होता है: एक कृत्रिम संग्रह पर यह 50,000 बातचीतों पर लगभग 100 से 400 मिलीसेकंड है, और लगभग 200,000 के आगे उसे ऐसे परिणाम चाहिए जो एक साथ नहीं, क्रमशः आएँ। यह किसी जीवित mailbox पर नहीं, विकास मशीन पर बनाई गई मेल के विरुद्ध मापा गया था, इसलिए यह क़ीमत का आकार है, आपके लिए कोई वादा नहीं। इस तरह शब्द के किसी भी अंश पर मिलान ठीक वैसे ही बचा रहता है जैसे अभी है, और किसी को बाद में उठाने के लिए शब्द-hash का index डिस्क पर लिखने की ज़रूरत नहीं पड़ती। वही पाठ सारांशकर्ता, phishing स्कोरर का body पास, AI-लेखन जाँच और शब्दों पर मिलान करने वाला कोई भी rule पढ़ता है, और इनमें से हर एक उसे उसी तरह खोलता है — यही इस दावे का ईमानदार आकार है: database की प्रति के विरुद्ध सील, server के विरुद्ध कभी नहीं।
किसी अपूरणीय चीज़ को सील करने से पहले envelope को अपना संस्करण और अपनी key id साथ रखनी होगी। आज हर व्युत्पन्न कुंजी एक ही secret से लटकती है, और उसे बदलने की क़ीमत आपके webhook signing secrets हैं; body भी उसी तरह सील होने लगें तो उसे बदलने की क़ीमत मेल होगी। वह हिस्सा बना हुआ है, और उससे कुछ भी सील नहीं किया गया। वह जो भी envelope बनाता है, उसमें अपना संस्करण और उसे बनाने वाली कुंजी की id होती है, जो खोलने की कोशिश से पहले ही पढ़ी जा सकती है, और वह खुद को ठीक उसी पंक्ति से बाँधता है जिसकी वह है: एक पंक्ति से उठाकर दूसरी में डाला गया मान खुलता नहीं, और वह ग़लत कुंजी की तरह विफल होने के बजाय कहता है कि उसे हिलाया गया था। अभी इसे कुछ भी नहीं बुलाता, और इसे पहले बनाने का यही मक़सद है। स्वरूप ही प्रतिबद्धता है; उसे एक-एक field करके अपनाना वह हिस्सा है जो पलटा जा सकता रहता है।
एक वाक्य तय करता है कि क्या सील होगा, ताकि उसे ऐसे column पर भी लागू किया जा सके जिसके बारे में अभी किसी ने सोचा ही नहीं: वह सब सील करें जो किसी व्यक्ति ने लिखा या चुना, वह सब छोड़ दें जो मशीन ने चुना। subject, body, thread नोट, contact का नाम, कैलेंडर शीर्षक, फ़ाइल नाम, आपका टाइप किया rule: ये आपसे आए। message id, queue स्थिति, retry गिनती, row id: ये यहीं बने, और इन्हें सील करने से कुछ नहीं मिलता जबकि इन्हें पढ़ने वाली हर query महँगी हो जाती है। इसके ऊपर दो छूटें बैठती हैं। जो मान पहले से अपरिवर्तनीय है, कोई hash या token digest, उसे सील करने से वह और सुरक्षित नहीं होता। जो मान जानबूझकर प्रकाशित है वह पढ़ने योग्य रहता है, क्योंकि उसे सील करने का मतलब उसी चीज़ को सील करना होता जिसे बाँटने के लिए वह मौजूद है।
उस नियम के तहत तीन चीज़ें पढ़ने योग्य रहती हैं, और हर एक वह है जिस पर mailbox टिका है, न कि कोई अधूरा छोड़ा कोना। Timestamps, क्योंकि वे क्रम-कुंजी और pagination cursor हैं, और जो mailbox तिथि से क्रम नहीं लगा सकता वह mailbox ही नहीं है। आपका domain, क्योंकि उसे पढ़ने वाली query ही वह तरीक़ा है जिससे आती हुई मेल अपना tenant ढूँढ़ती है, इससे पहले कि कोई साइन इन हो और कोई कुंजी हाथ में आए। प्रकाशित कुंजियाँ, क्योंकि प्रेषक आपकी कुंजी देखता है। इनमें से हर एक खाते के आकार के बारे में कुछ कहती है, और इनमें से कोई भी आपकी मेल की सामग्री नहीं है।
server द्वारा व्युत्पन्न कुंजी से सील करना पहला पायदान है और वही बनाया जा रहा है। दूसरा, यानी मेल के आते ही उसे आपकी कुंजी से सील करना ताकि यहाँ कोई कुंजी उसे न खोल सके, बड़ा बदलाव और अलग उत्पाद है: body खोज और AI सुविधाओं से हमेशा के लिए निकल जाता है, और कुंजी की हिफ़ाज़त तथा recovery phrase आपके और आपकी अपनी मेल के बीच आ जाते हैं। यह स्विच दबाने जैसा नहीं, सोच-समझकर लिया जाने वाला निर्णय है, और यह कार्ड दोनों को धुँधला करने के बजाय बताएगा कि कौन-सा शिप हुआ।