जीवन की निरंतरता के लिए
तैयार की गई आर्किटेक्चर।
आपके डिजिटल लाइफ़ वॉल्ट के पीछे की तकनीक का एक पारदर्शी विवरण। हम नीरस औद्योगिक शब्दावली से आगे बढ़कर आपके परिवार के लिए एक सुरक्षित, मानव-केंद्रित पुल प्रदान करते हैं।
सिस्टम डिज़ाइन
मेरा डेटा असल में कहाँ रहता है?
हम मुंबई में Amazon के डेटा सेंटर्स (ap-south-1) का इस्तेमाल करते हैं। हमारा सिस्टम “सर्वरलेस” है: Soult द्वारा मैनेज किया जाने वाला कोई सर्वर नहीं है जिसे पैच करना हो या जिसमें लॉग इन किया जा सके, और नीचे की मशीनों की सुरक्षा AWS करता है। इससे हमले का दायरा घटता है, पर ख़त्म नहीं होता — हमारे APIs, साइन-इन और क्लाउड कॉन्फ़िगरेशन को अब भी सुरक्षा चाहिए।
AWS Lambda पर सर्वरलेस कंप्यूट, साथ में DynamoDB, S3 और Cognito, ap-south-1 (मुंबई) में। डेटा कई Availability Zones में स्टोर होता है। क्रॉस-रीजन डिज़ास्टर रिकवरी हमारे रोडमैप पर है।
आज एक रीजन, आगे साइलो
हर यूज़र का डेटा कहाँ जाता है?
आज Soult AWS मुंबई, भारत में एक ही silo के रूप में चलता है, और हर उपयोगकर्ता का vault वहीं स्टोर होता है। हम UAE में लॉन्च की तैयारी कर रहे हैं। वहाँ के उपयोगकर्ताओं के vault AWS मुंबई (भारत) में स्टोर किए जाएँगे, और साइन-अप के समय हम इसके लिए उनकी स्पष्ट सहमति माँगेंगे। अलग क्षेत्रीय silo हमारे रोडमैप पर हैं।
आज: हर उपयोगकर्ता के लिए एक silo, ap-south-1 (मुंबई); देश के आधार पर कोई रूटिंग लाइव नहीं है। रोडमैप: साइन-अप पर होम-रीजन रूटिंग, US silo (us-east-1, us-west-2), SEA silo (ap-southeast-1, ap-southeast-3) और एक समर्पित GCC silo।
AWS मुंबई ही क्यों?
स्थानीय अनुपालन और सुरक्षा।
AWS मुंबई हमें भारत में एक परिपक्व, स्वतंत्र रूप से ऑडिट किया गया डेटा-सेंटर ढांचा देता है। आपका डेटा भारतीय ज़मीन पर रहने से आपकी विरासत भारतीय कानून के दायरे में रहती है और बिना किसी उलझन के आपके परिवार की पहुँच में रहती है।
ap-south-1 में कई Availability Zones में फैला सिंगल-रीजन डिप्लॉयमेंट; क्रॉस-रीजन DR हमारे रोडमैप पर है। Native Cognito localised फ़ोन सपोर्ट और AWS KMS में FIPS 140-वैलिडेटेड cryptographic modules।
प्रमाणीकरण प्रवाह
सुरक्षित रूप से साइन अप और लॉग इन करें।
रजिस्ट्रेशन: फ़ोन OTP और ईमेल OTP के माध्यम से सत्यापित। आप एक सुरक्षा प्रश्न और एक 4-अंकीय MPIN सेट करते हैं। विश्वसनीय उपयोग: दैनिक पहुँच के लिए केवल आपके 4-अंकीय MPIN की आवश्यकता होती है। नया डिवाइस: 2-फैक्टर सुरक्षा को ट्रिगर करता है — पहले फ़ोन OTP, फिर आपका MPIN।
Multi-channel OTP वेरिफिकेशन। सुरक्षा उत्तर one-way hash के रूप में संग्रहीत होते हैं; MPIN को AWS Cognito वेरिफ़ाई और संग्रहीत करता है। नए डिवाइस पर Re-auth, MPIN से पहले OTP को ट्रिगर करता है।
शेयर्ड डिवाइस पर MPIN
मेरा परिवार इसे क्यों नहीं खोल सकता?
शेयर्ड फ़ोन वाले घरों में, फिंगरप्रिंट किसी भी नामांकित व्यक्ति को प्रवेश करने की अनुमति देते हैं। एक निजी 4-अंकीय PIN आपके vault को निजी रखता है, जबकि बच्चे गेम खेलते हैं या आपका जीवनसाथी फ़ोन का उपयोग करता है।
4-अंकीय MPIN, जिसे AWS Cognito वेरिफ़ाई और संग्रहीत करता है। 3 असफल प्रयासों पर साइन-इन 24 घंटे के लिए लॉक हो जाता है, जिसे सर्वर-साइड लागू किया जाता है। Reinstall, डिवाइस wipe, या डिवाइस बदलने से lockout रीसेट नहीं होता।
4-अंकीय PIN ही क्यों?
क्या 4 अंक वाकई सुरक्षित हैं?
हाँ — क्योंकि सुरक्षा lockout है, न कि लंबाई। तीन गलत कोशिशें और आपका vault 24 घंटे के लिए लॉक हो जाता है। आपके फ़ोन के साथ चोर को भी दरवाज़ा बंद होने से पहले केवल 3 अनुमान मिलते हैं। हमने जानबूझकर 6 के बजाय 4 को चुना: लंबे PIN से अधिक भूले हुए कोड, lockouts और resets होते हैं — और व्यवहार में सुरक्षा का असली दुश्मन मेमोरी की जटिलता है, न कि कच्ची entropy।
4-अंकीय सर्च स्पेस: 10⁴ = 10,000। Brute-force mitigation: सर्वर-साइड काउंटर, 24 घंटे के लिए 3-स्ट्राइक lockout। Lockout के साथ Practical entropy, unprotected 6-अंकीय की raw entropy से अधिक है। Trade-off स्वीकार किया गया: usability gain > marginal entropy gain।
हार्ड ड्राइव का जोखिम
क्या होगा अगर कोई हार्ड ड्राइव चुरा ले?
डेटा स्टोर होने पर AES-256 से एन्क्रिप्टेड रहता है। चोरी किए गए हार्डवेयर में केवल अर्थहीन ciphertext होता है। एन्क्रिप्शन कीज़ AWS मैनेज करता है, डेटा से अलग — कभी उसी डिस्क पर नहीं।
फ़ाइलें: S3 सर्वर-साइड एन्क्रिप्शन (SSE-S3, AES-256), जो हर ऑब्जेक्ट पर अपने-आप लागू होता है। टेबल्स: DynamoDB encryption at rest। अत्यधिक संवेदनशील फ़ील्ड्स: लिखने से पहले AWS KMS से अतिरिक्त रूप से एन्क्रिप्ट किए जाते हैं।
की मैनेजमेंट (KMS)
चाबियाँ कौन रखता है?
AWS के पास। हमारी फ़ील्ड-एन्क्रिप्शन key AWS KMS के हार्डवेयर सिक्योरिटी मॉड्यूल्स के अंदर रहती है और कभी पढ़ने योग्य रूप में उनसे बाहर नहीं निकलती, इसलिए Soult में कोई भी कभी असली key को हाथ नहीं लगाता। जब आप कोई सुरक्षित फ़ील्ड सेव करते हैं या देखते हैं, तो हमारा एप्लिकेशन KMS से उसका उपयोग करने को कहता है, और इसी से सत्यापित पारिवारिक हस्तांतरण संभव होता है। फ़ाइलों और डेटाबेस टेबल्स की कीज़ AWS मैनेज करता है।
संवेदनशील फ़ील्ड्स: customer-managed key के तहत KMS Encrypt/Decrypt; key material कभी KMS के FIPS 140-वैलिडेटेड HSMs से बाहर नहीं जाता। फ़ाइलें: S3 सर्वर-साइड एन्क्रिप्शन (SSE-S3, AES-256)। टेबल्स: DynamoDB encryption at rest।
फ़ील्ड-स्तर की सुरक्षा
आपके सबसे संवेदनशील फ़ील्ड के लिए दोहरी-ताला सुरक्षा।
आपकी सबसे संवेदनशील जानकारी — आधार, PAN और पासपोर्ट नंबर, कार्ड और अकाउंट नंबर, और Standard Password Keeper के पासवर्ड — के लिए हम एक दूसरा ताला जोड़ते हैं। सेव करने से पहले हमारे सर्वर इनमें से हर फ़ील्ड को AWS KMS key से एन्क्रिप्ट करते हैं, इसलिए डेटाबेस में वे ciphertext के रूप में स्टोर होते हैं।
customer-managed AWS KMS key के साथ सर्वर-साइड फ़ील्ड-लेवल एन्क्रिप्शन, जिसे हमारा बैकएंड लिखने से पहले इन पर लागू करता है: आधार, PAN और पासपोर्ट नंबर; प्राथमिक क्रेडिट और डेबिट कार्ड नंबर; लोन, क्रेडिट-कार्ड, फ़िक्स्ड-डिपॉज़िट, सरकारी-बचत और वैकल्पिक-निवेश अकाउंट नंबर; निवेश ट्रांज़ैक्शन ID; प्रॉपर्टी दस्तावेज़ आइडेंटिफ़ायर; और Standard Password Keeper पासवर्ड। KMS decrypt अधिकारों के बिना टेबल पढ़ने पर उन फ़ील्ड्स के लिए सिर्फ़ ciphertext मिलता है। बीमा पॉलिसी नंबर, बैंक पासबुक अकाउंट नंबर और वसीयत का विवरण सिर्फ़ at-rest एन्क्रिप्शन से सुरक्षित हैं।
Client-side encryption
कौन से सीक्रेट्स Soult भी कभी नहीं पढ़ सकता?
Password Keeper में दो लेवल हैं। रोज़मर्रा के लॉगिन — Wi-Fi, स्ट्रीमिंग — आपके ऐप MPIN से अनलॉक होते हैं, और हम उन्हें रिकवर करने में आपकी मदद कर सकते हैं। अपने सबसे संवेदनशील लॉगिन के लिए आप Advanced चालू करते हैं, जो vault password से एंड-टू-एंड लॉक होता है जो कभी आपके फ़ोन से बाहर नहीं जाता। Advanced एंट्री जोड़ने के लिए किसी पासवर्ड की ज़रूरत नहीं होती; केवल उसे पढ़ने के लिए होती है। हम लॉक किया हुआ रिजल्ट स्टोर करते हैं और उसे खोलने का तरीका कभी नहीं रखते — इसलिए कोई Soult डिक्रिप्ट बटन नहीं है, कोई स्टाफ ओवरराइड नहीं है, और कानूनी आदेश के तहत सौंपने के लिए कुछ भी सार्थक नहीं है। आपको एक 12-शब्दों का रिकवरी वाक्यांश भी मिलता है, जो एक बार दिखाया जाता है, और जिसे हम कभी प्राप्त नहीं करते। यह एक ईमानदार समझौता है: यदि आप vault password और वाक्यांश दोनों खो देते हैं, तो वे पासवर्ड स्थायी रूप से चले जाएंगे, क्योंकि इसका विकल्प यह होगा कि हम एक कुंजी रखें। केवल पासवर्ड ही सील किया जाता है; एंट्री का शीर्षक, यूज़रनेम, वेबसाइट, नोट्स और सुरक्षा प्रश्न व उत्तर Standard protection का उपयोग करते हैं।
Per-user X25519 identity keypair; public key stored in the clear, private seed never stored unwrapped. KEK = Argon2id(vault password, 16-byte random salt) — m=64 MiB, t=3, p=1, 32-byte output; the private seed is wrapped with AES-256-GCM (12-byte nonce, 128-bit tag). These KDF parameters are under active hardening review; the wire scheme is versioned (enc_scheme=e2e_v2) and each wrap is self-describing, so parameters can be raised without re-enrolling users. Adds are sealed public-key style: fresh ephemeral X25519 keypair → ECDH against the identity public key → HKDF-SHA256 (salt = ephemeral public key, info soult-pwk-e2e-v2) → AES-256-GCM. The entry stores ciphertext, IV and the ephemeral public key only. Two independent wraps of the same seed exist — one under the vault password, one under a 12-word phrase drawn from a 256-word list (≈96 bits) that is generated on-device and never transmitted. The MPIN is deliberately excluded from key derivation, since rotating or clearing it would otherwise permanently brick recovery; it is enforced as a separate UI gate at recovery time. enc_key_id = first 8 bytes of SHA-256(public key), so entries sealed to a superseded key after a vault reset are flagged unrecoverable rather than failing silently. The backend bypasses KMS entirely for e2e_ schemes: no server-side key for these fields exists to be compelled, audited or misused. Scope: only the password field is sealed; the protection relies on the integrity of the app you install.
ट्रांज़िट में एन्क्रिप्शन
जासूस-प्रूफ Wi-Fi।
डेटा एक सुरक्षित TLS टनल से होकर गुज़रता है। अगर कोई एयरपोर्ट या कैफे के पब्लिक Wi-Fi पर आपकी जानकारी देखने की कोशिश करता है, तो उसे सिर्फ एन्क्रिप्टेड कोड दिखेगा — उसे यह नहीं पता चलेगा कि आप क्या अपलोड कर रहे हैं या क्या पढ़ रहे हैं।
API Gateway HTTPS के ज़रिए TLS 1.2+ लागू। फ़ाइलें S3 presigned URLs के ज़रिए अपलोड और पढ़ी जाती हैं, जो 15 मिनट बाद एक्सपायर हो जाते हैं।
“कोई रूटीन एक्सेस नहीं” सिद्धांत
क्या Soult का स्टाफ मेरे राज़ देख सकता है?
रूटीन संचालन में नहीं। Soult के कर्मचारी सामान्य कामकाज के दौरान आपके vault की सामग्री नहीं देखते; प्रोडक्शन सिस्टम्स का एक्सेस IAM से सीमित है और लॉग किया जाता है। जब किसी मृत्यु के दावे की समीक्षा हो रही होती है, तो कुछ गिने-चुने अधिकृत कर्मचारी उस अकाउंट के दस्तावेज़ खोल सकते हैं, और हर ऐसा एक्सेस लॉग किया जाता है। आपके सबसे संवेदनशील फ़ील्ड KMS-एन्क्रिप्टेड ciphertext के रूप में भी स्टोर होते हैं।
एप्लिकेशन रोल्स के लिए लीस्ट-प्रिविलेज IAM। प्रोडक्शन एक्सेस कुछ गिने-चुने नामित एडमिनिस्ट्रेटर्स तक सीमित है और लॉग किया जाता है। मृत्यु-दावे के समीक्षक एक छोटी allowlist में हैं, और वे जो भी दस्तावेज़ खोलते हैं, वह लॉग किया जाता है। डेटाबेस लेयर पर सिर्फ़ KMS-एन्क्रिप्टेड फ़ील्ड्स ही ciphertext होते हैं; बाकी सामग्री IAM एक्सेस कंट्रोल और लॉगिंग से सुरक्षित रहती है।
दो Executor की भूमिकाएँ
मेरा vault कौन देख सकता है?
रेगुलर Executor (आमतौर पर परिवार का सदस्य): इनके पास अपना डैशबोर्ड होता है जिसमें उन लोगों की लिस्ट होती है जिनके लिए इन्हें नामित किया गया है। ये मृत्यु का दावा उठा सकते हैं। Soult के उसे वेरिफ़ाई और अप्रूव करने के बाद ही ये साइन इन कर सकते हैं — फ़ोन और ईमेल OTP के साथ — और आपका vault देख सकते हैं।
इमरजेंसी Executor (आपका चुना कोई भी भरोसेमंद व्यक्ति — जीवनसाथी, बच्चा, भाई-बहन या दोस्त): मृत्यु के दावे की ज़रूरत नहीं। फ़ोन और ईमेल OTP के बाद कभी भी साइन इन कर सकते हैं। उनके साइन इन करते ही आपको ईमेल मिलता है।
दोनों भूमिकाएँ आपका vault रीड-ओनली मोड में देखती हैं। इमरजेंसी भूमिका मेडिकल इमरजेंसी और समय-संवेदनशील स्थितियों के लिए है; रेगुलर भूमिका मृत्यु के बाद हैंडओवर के लिए है। आप कितने executors नामित कर सकते हैं, यह आपके प्लान पर निर्भर करता है।
एप्लिकेशन लॉजिक में रोल-आधारित एक्सेस। हर executor के साथ एक is_emergency फ़्लैग होता है (कोई भी रिश्ता; कुल executors की सीमा प्लान से तय)। नॉन-इमरजेंसी executors मृत्यु का दावा अप्रूव होने के बाद ही साइन इन कर सकते हैं; इमरजेंसी executors कभी भी साइन इन कर सकते हैं। Executor साइन-इन के लिए OTP वेरिफ़िकेशन ज़रूरी है और इससे मालिक को ईमेल जाता है। Executor सेशन रीड-ओनली होते हैं।
सौंपने का प्रोटोकॉल
मेरे परिवार को असल में एक्सेस कैसे मिलता है?
नामित रेगुलर Executor अपने डैशबोर्ड से मृत्यु का दावा उठाते हैं और मृत्यु प्रमाण पत्र अपलोड करते हैं; आपको और आपके अन्य executors को ईमेल भेजा जाता है। अप्रूव करने से पहले Soult का एक अधिकृत एडमिनिस्ट्रेटर दावे और प्रमाण पत्र की समीक्षा करता है — बिना वेरिफ़ाई किए अनुरोध पर कुछ भी जारी नहीं किया जाता। अप्रूव होने के बाद, आपका अकाउंट रीड-ओनली हो जाता है, और executor फ़ोन और ईमेल OTP से साइन इन करके vault देख और डाउनलोड कर सकता है। हर बार किसी executor के साइन इन करने पर आपके रजिस्टर्ड पते पर एक ईमेल जाता है। Advanced Password Keeper के पासवर्ड लॉक ही रहते हैं, जब तक कि आपने अपने executor के लिए अपना vault पासवर्ड या रिकवरी किट न छोड़ा हो।
गेट: (1) एक रजिस्टर्ड, वेरिफ़ाइड executor अपने डैशबोर्ड से प्रमाण पत्र अपलोड के साथ मृत्यु का दावा उठाता है; (2) Amazon SES मालिक और अन्य executors को ईमेल करता है; (3) allowlist में शामिल एक Soult एडमिनिस्ट्रेटर दावे की समीक्षा करके उसे अप्रूव करता है; (4) अप्रूवल से executor साइन-इन खुलता है, फ़ोन + ईमेल OTP के साथ, और API लेयर पर अकाउंट रीड-ओनली हो जाता है; (5) हर executor साइन-इन पर मालिक को ईमेल भेजा जाता है। दावे के अपलोड और अप्रूवल एक सिक्योरिटी इवेंट लॉग में दर्ज किए जाते हैं।
कोई शेयरिंग नहीं, डिज़ाइन से ही
क्या मैं एक डॉक्यूमेंट अपने CA या जीवनसाथी के साथ शेयर कर सकता हूँ?
अभी नहीं। इसमें प्रति-आइटम शेयरिंग नहीं है, किसी अकाउंटेंट के लिए प्रति-फ़ोल्डर एक्सेस नहीं है, कोई समय-सीमित शेयर लिंक नहीं है। किसी दूसरे व्यक्ति के लिए आपके vault के अंदर देखने का एकमात्र तरीका ऊपर बताया गया Executor फ़्लो है — और तब भी, वे सब कुछ रीड-ओनली मोड में देखते हैं। अभी प्रति-आइटम या प्रति-फ़ोल्डर ग्रैन्युलैरिटी नहीं है।
कोई कोलाबरेशन मैकेनिज़्म लागू नहीं किया गया है। एकमात्र एक्सेस पाथ: (1) ऑथेंटिकेटेड ओनर सेशन, (2) वेरिफिकेशन के बाद Executor सेशन। कोई शेयर-लिंक जनरेशन नहीं, कोई स्कोप्ड टोकन नहीं, कोई प्रति-रिसोर्स ACL नहीं। केवल रोडमैप पर विचार किया गया है — अभी बनाया नहीं गया है।
हकीकत की जाँच
क्या जोखिम हैं?
हम हैकर्स, अकाउंट पर कब्ज़ा और अंदरूनी एक्सेस से बचाव के लिए काम करते हैं. हम आपको PIN शेयर करने के लिए शारीरिक रूप से मजबूर किए जाने से नहीं रोक सकते. Soult संगठन और परिवार की निरंतरता के लिए है — दबाव में ज़बरदस्ती जानकारी देने से बचाने के लिए नहीं.
थ्रेट मॉडल में शारीरिक ज़बरदस्ती शामिल नहीं है। कम करता है: एक्सफ़िल्ट्रेशन, अकाउंट टेकओवर, इनसाइडर एक्सेस। दायरे से बाहर: दबाव में PIN निकालना, अनलॉक के बाद डिवाइस से समझौता।
भारतीय धरती
मेरा डेटा असल में कहाँ रहता है?
आज, सारा vault डेटा AWS मुंबई में हमारे इंडिया साइलो में रहता है। हम UAE में लॉन्च की तैयारी कर रहे हैं। वहाँ के यूज़र्स के vault AWS मुंबई (भारत) में स्टोर किए जाएँगे, और साइन-अप के समय हम इसके लिए उनकी स्पष्ट सहमति माँगेंगे। US और दक्षिण-पूर्व एशिया के लिए भविष्य के साइलो, और एक समर्पित GCC साइलो, हमारे रोडमैप पर हैं।
एक्टिव साइलो: ap-south-1 (मुंबई), जिसमें डेटा कई Availability Zones में स्टोर होता है। क्रॉस-रीजन DR हमारे रोडमैप पर है। DPDP एक्ट, 2023 के सिद्धांतों को ध्यान में रखकर बनाया गया। कोई दूसरा साइलो लाइव नहीं है, और किसी भी यूज़र को GCC रीजन से सेवा नहीं दी जाती।
डिजास्टर रिकवरी के स्तर
विफलता के हर स्तर पर क्या होता है?
टियर 1 — एक सर्वर फ़ेल होता है: यूज़र्स को पता नहीं चलता; AWS की मैनेज्ड सेवाएँ उसे अपने-आप बदल देती हैं।
टियर 2 — मुंबई का एक डेटा सेंटर फ़ेल होता है: सेवा चलती रहती है, क्योंकि आपका डेटा पहले से ही मुंबई के कई डेटा सेंटर्स में स्टोर है।
टियर 3 — पूरा मुंबई रीजन डाउन हो जाता है: AWS के उसे बहाल करने तक सेवा रुक जाती है। दूसरे रीजन में स्टैंडबाय हमारे रोडमैप पर है, आज लाइव नहीं है।
टियर 4 — मुंबई रीजन हमेशा के लिए खो जाता है: आज हम उससे पूरी तरह रिकवर नहीं कर सकते। क्रॉस-रीजन बैकअप रेप्लिकेशन हमारे रोडमैप पर है। तब तक, अपना ख़ुद का बैकअप रखना सबसे मज़बूत सुरक्षा है।
टियर 1: मैनेज्ड-सर्विस सेल्फ़-हीलिंग (Lambda, DynamoDB, S3)। टियर 2: ap-south-1 के भीतर मल्टी-AZ स्टोरेज। टियर 3–4: आज कोई क्रॉस-रीजन फ़ेलओवर नहीं; दूसरे रीजन में क्रॉस-रीजन बैकअप रेप्लिकेशन हमारे रोडमैप पर है।
ऑडिट ट्रेल
बदलावों का रिकॉर्ड।
आपके vault में हर Create, Update या Delete का रिकॉर्ड, साथ में यह भी कि बदलाव किसने और कब किया।
DynamoDB में ऑडिट लॉग टेबल। राइट ऑपरेशंस (CUD) को ट्रैक करता है। यूज़र प्राइवेसी और परफ़ॉर्मेंस के संतुलन के लिए रीड इवेंट्स शामिल नहीं किए गए हैं। अकाउंट के साथ ही डिलीट हो जाता है।
डेटा उपयोग की सीमाएँ
कोई बिक्री नहीं, कोई ट्रेनिंग नहीं, कोई हैरानी नहीं।
आपके वॉल्ट की सामग्री का उपयोग कभी भी AI मॉडल को प्रशिक्षित करने या मार्केटिंग के लिए नहीं किया जाता है. जब ऐप में AI सुविधाओं का उपयोग किया जाता है, तो उस सत्र का डेटा केवल संदर्भ में संसाधित होता है — मॉडल सुधार के लिए कभी भी बनाए नहीं रखा जाता है. राजस्व केवल सब्सक्रिप्शन-आधारित है. यदि हम कभी भी कमाई का कोई नया तरीका सोचते हैं — कोई भी बदलाव — तो हम आपसे पहले पूछेंगे. सूचित नहीं करेंगे. घोषणा नहीं करेंगे. पूछेंगे. और हम तभी पूछेंगे जब हमें वास्तव में लगेगा कि यह आपके लिए फायदेमंद है.
डेटा आइसोलेशन। vault का कोई भी डेटा AI/ML ट्रेनिंग पाइपलाइन में नहीं डाला जाता। AI फ़ीचर केवल प्रति सेशन संदर्भ में डेटा प्रोसेस करते हैं — मॉडल सुधार के लिए कोई रिटेंशन नहीं। आय मॉडल vault के डेटा से स्वतंत्र है। भविष्य के मुद्रीकरण (monetisation) बदलावों के लिए हर यूज़र की स्पष्ट सहमति ज़रूरी होगी — घोषणा करके आगे नहीं बढ़ेंगे।
प्राइवेसी बनाम हैंडओवर
पुल का चुनाव।
चैट ऐप पूर्ण गोपनीयता पर ध्यान देते हैं — अगर आप कोई key खो देते हैं, तो वे आपकी मदद नहीं कर सकते। एक लाइफ़ vault के लिए यह एक विफलता है। इसलिए हमने Soult को अलग तरह से डिज़ाइन किया: आपका vault डिज़ाइन से ही रिकवर करने लायक है, ताकि फ़ोन खो जाने या PIN भूल जाने पर भी आपका परिवार कभी लॉक आउट न हो, और वेरिफ़ाइड executors वह पा सकें जो आपने उनके लिए छोड़ा है। Soult के कर्मचारियों के पास रूटीन एक्सेस नहीं होता, और हैंडओवर सिर्फ़ एक वेरिफ़ाइड रास्ते से होता है। उन चंद पासवर्ड्स के लिए जिन्हें सिर्फ़ आप ही कभी खोलें, Advanced Password Keeper आपको एकमात्र कस्टडी देता है। Soult आपकी विरासत तक का एक पुल है, न कि एक डिजिटल डेड एंड।
स्टैंडर्ड vault डेटा सर्वर-साइड एन्क्रिप्ट होता है (S3 और DynamoDB encryption at rest, और संवेदनशील फ़ील्ड्स के लिए AWS KMS भी), ताकि उसे आपको वापस दिया जा सके या किसी वेरिफ़ाइड executor को रीड-ओनली दिखाया जा सके। कर्मचारियों का कोई रूटीन एक्सेस नहीं; हैंडओवर के लिए ऊपर बताया गया वेरिफ़ाइड मृत्यु-दावा फ़्लो ज़रूरी है। Advanced Password Keeper की एंट्रीज़ (e2e_v2) ही एकमात्र डेटा है जिसे Soult डिक्रिप्ट नहीं कर सकता।
रोडमैप
आगे क्या आ रहा है?
निकट भविष्य: एक-क्लिक वॉल्ट एक्सपोर्ट (आज उपयोगकर्ता मैन्युअल रूप से बैकअप लेते हैं); US साइलो (N. Virginia, DR Oregon); SEA साइलो (Singapore, DR Jakarta); क्रॉस-साइलो बैकअप रेप्लिकेशन ताकि यदि पूरा क्षेत्र भी खो जाए तो भी कुछ न कुछ हमेशा बचा रहे.
मध्यम अवधि: एक समर्पित GCC साइलो; SOC 2 Type II.
हमेशा चालू: चल रहे ऑडिट, सुरक्षा सुदृढ़ीकरण, इन्फ्रास्ट्रक्चर समीक्षाएं.
चरण 1 (अगला): एक-क्लिक एन्क्रिप्टेड एक्सपोर्ट, US साइलो की शुरुआत। चरण 2: SEA साइलो, क्रॉस-साइलो कोल्ड बैकअप रेप्लिकेशन, WAF, मोबाइल क्लाइंट पर SSL पिनिंग। चरण 3: समर्पित GCC साइलो, SOC 2 Type II, मजबूत मल्टी-रीजन KMS।
ईमानदार दावे
हर मार्केटिंग दावे की जाँच की गई है। आज क्या सच है, क्या योजना बनाई गई है, क्या नहीं बनाया गया है, और हम क्या इस्तेमाल नहीं करते।
| दावा | स्थिति | व्यावहारिक सच्चाई |
|---|---|---|
| कर्मचारियों का कोई रूटीन एक्सेस नहीं | सही | vault की सामग्री तक कर्मचारियों का कोई रूटीन एक्सेस नहीं; प्रोडक्शन एक्सेस सीमित है और लॉग किया जाता है। मृत्यु के दावे की समीक्षा करते समय, समीक्षकों की एक छोटी allowlist किसी अकाउंट के दस्तावेज़ खोल सकती है, और हर एक्सेस लॉग होता है। Advanced Password Keeper पासवर्ड्स को छोड़कर, यह एक एक्सेस कंट्रोल है, तकनीकी असंभवता नहीं। |
| भारत में डेटा रेज़िडेंसी | सही | सारा vault डेटा भारत में, AWS मुंबई में स्टोर होता है। कुछ ऑपरेशनल डेटा (साइन-इन कोड, भुगतान, एनालिटिक्स, क्रैश रिपोर्ट) ऐसे प्रोवाइडर्स संभालते हैं जो उसे भारत के बाहर प्रोसेस कर सकते हैं। |
| ISO 27001 और ISO 9001 सर्टिफ़िकेशन | प्रक्रिया में | ISO 27001 के अनुरूप सुरक्षा प्रोग्राम। ISO 9001 के अनुरूप गुणवत्ता प्रबंधन। दोनों के लिए मान्यता-प्राप्त सर्टिफ़िकेशन प्रक्रिया में है। |
| AES-256 एन्क्रिप्शन | सही | सारा vault डेटा स्टोर होने पर AES-256 से एन्क्रिप्टेड रहता है, और संवेदनशील फ़ील्ड्स को AWS KMS की एक अतिरिक्त परत मिलती है। |
| Password Keeper — स्टैंडर्ड | सही | डिफ़ॉल्ट। पासवर्ड हमारे सर्वर पर AWS KMS से एन्क्रिप्ट होता है, ताकि उसे रिकवर करके आपके Executors को सौंपा जा सके। |
| Password Keeper — एडवांस्ड | लाइव | जुलाई 2026 से लाइव (ऑप्ट-इन)। किसी Password Keeper एंट्री के लिए Advanced चालू करें, और उसका पासवर्ड आपके फ़ोन पर एक ऐसी key से एन्क्रिप्ट होता है जो सिर्फ़ आपके जानने वाले vault पासवर्ड से बनती है, इसलिए Soult उसे डिक्रिप्ट नहीं कर सकता। एंट्री का बाकी विवरण (शीर्षक, यूज़रनेम, वेबसाइट, नोट्स, सुरक्षा प्रश्न और उत्तर) Standard protection का उपयोग करता है। अगर आपका vault पासवर्ड और आपका 12-शब्दों वाला रिकवरी फ़्रेज़ दोनों खो जाएँ, तो वह पासवर्ड रिकवर नहीं किया जा सकता। |
| एक-क्लिक vault एक्सपोर्ट | योजना में है | आज नहीं बनाया गया है। यूज़र मैन्युअल बैकअप लेते हैं। वन-क्लिक एक्सपोर्ट हमारे रोडमैप पर है। |
| आइटम-वाइज़ शेयरिंग | अभी नहीं बना | आज कोई शेयरिंग या कोलैबोरेशन नहीं है। Executor फ्लो ही एक्सेस का एकमात्र तरीका है। |
| क्रॉस-साइलो बैकअप | रोडमैप में है | दूसरे रीजन में बैकअप रेप्लिकेशन हमारे रोडमैप पर है और US/SEA साइलो डिप्लॉय होने के साथ आएगा। |
| क्रॉस-रीजन डिज़ास्टर रिकवरी | रोडमैप में है | आज आपका डेटा एक AWS रीजन (मुंबई) में रहता है, जो वहाँ के कई डेटा सेंटर्स में स्टोर है। दूसरे रीजन में स्टैंडबाय हमारे रोडमैप पर है; तब तक, पूरे रीजन के खो जाने से बचाव के लिए आपका अपना बैकअप सबसे मज़बूत सुरक्षा है। |
| लाइव सिस्टम्स से डिलीशन | तुरंत | 10 सेकंड की पुष्टि और आपका MPIN, फिर आपका लॉगिन, रिकॉर्ड्स और फ़ाइलें लाइव सिस्टम्स से हटा दी जाती हैं। हर यूज़र की अलग key नहीं है, इसलिए बैकअप, फ़ाइलों के पुराने वर्ज़न और लॉग crypto-shred नहीं होते और तुरंत नहीं मिटते। |
| यूज़र डेटा पर AI ट्रेनिंग | कभी नहीं | वॉल्ट का कंटेंट AI मॉडल ट्रेनिंग के लिए कभी इस्तेमाल नहीं होता, भले ही AI फीचर्स सेशन में इस्तेमाल किए जाएं। |
| ब्लॉकचेन | इस्तेमाल नहीं होता | एक प्राइवेट वॉल्ट के लिए यह गलत टूल है। हम इसकी जगह ऑडिट लॉग्स का इस्तेमाल करते हैं। |
| ज़ीरो-नॉलेज एन्क्रिप्शन | आंशिक रूप से लाइव | आज आंशिक रूप से लाइव। Advanced Password Keeper की एंट्रीज़ सच में क्लाइंट-साइड एन्क्रिप्टेड हैं — एक ऐसे vault पासवर्ड से बनी key से सील की गई जो हम तक कभी नहीं पहुँचता, इसलिए हम उन्हें डिक्रिप्ट नहीं कर सकते (देखें क्लाइंट-साइड एन्क्रिप्शन)। बाकी vault हमारे सर्वर पर एन्क्रिप्ट होता है, और संवेदनशील फ़ील्ड्स AWS KMS के तहत रहते हैं। यह मज़बूत है, लेकिन ज़ीरो-नॉलेज नहीं — जानबूझकर, ताकि आपका परिवार कभी लॉक आउट न हो। व्यापक ऑप्ट-इन ज़ीरो-नॉलेज विकल्प हमारे रोडमैप पर बने हुए हैं। |
अक्सर पूछे जाने वाले सवाल
मैं अपना डेटा कैसे डिलीट करूँ?
10 सेकंड के कन्फ़र्मेशन पॉज़ और आपके MPIN के बाद, आपका साइन-इन और vault रिकॉर्ड्स हमारे डेटाबेस से डिलीट कर दिए जाते हैं और आपकी फ़ाइलें एक्टिव स्टोरेज से तुरंत हटा दी जाती हैं। इसे न आप पलट सकते हैं, न हमारी सपोर्ट टीम। बैकअप, फ़ाइलों के पुराने वर्ज़न और सिस्टम लॉग में मौजूद कॉपीज़ तुरंत नहीं मिटतीं, और भुगतान का एक रिकॉर्ड आपकी व्यक्तिगत जानकारी हटाकर रखा जाता है। जो कुछ भी आप रखना चाहते हैं, उसे पहले डाउनलोड कर लें। वन-क्लिक एक्सपोर्ट हमारे रोडमैप पर है।
अगर Soult बंद हो जाए तो क्या होगा?
अगर Soult को कभी बंद करना पड़े, तो हम आपको पहले से बताएँगे और आपके vault की कॉपी पाने में आपकी मदद करेंगे। वन-क्लिक एक्सपोर्ट हमारे रोडमैप पर है। हम आपका डेटा नहीं बेचेंगे और आपकी सहमति के बिना आपके vault को किसी खरीदार को ट्रांसफर नहीं करेंगे।
सब्सक्रिप्शन की बिलिंग कैसे होती है?
Soult वेबसाइट पर Razorpay के ज़रिए मैनेज किया जाता है। कोई इन-ऐप परचेज़ नहीं। इससे बिलिंग आपके वॉल्ट डिवाइस से अलग रहती है।
डेटा हटाने के प्रोटोकॉल की जानकारी?
पुष्टि होने पर, यूज़र का Cognito साइन-इन डिलीट कर दिया जाता है, DynamoDB की vault टेबल्स से उनकी rows हटा दी जाती हैं और उनकी S3 फ़ाइलें एक्टिव स्टोरेज से हटा दी जाती हैं, साथ में एक asynchronous दूसरा क्लीन-अप पास चलता है। भुगतान रिकॉर्ड्स व्यक्तिगत विवरण हटाकर रखे जाते हैं। हर यूज़र की अलग key नहीं है, इसलिए कोई crypto-shredding नहीं; बैकअप, फ़ाइलों के पुराने वर्ज़न और लॉग तुरंत नहीं मिटते।
Soult ब्लॉकचेन का इस्तेमाल क्यों नहीं करता?
ब्लॉकचेन पब्लिक वेरिफिकेशन के लिए बनाया गया है, जहाँ साझा लेजर पर पार्टियाँ एक-दूसरे पर भरोसा नहीं करतीं — जैसे क्रिप्टोकरेंसी, प्रतिद्वंद्वियों के बीच सप्लाई चेन, पब्लिक लैंड रिकॉर्ड। इसकी ताकत दुनिया को छेड़छाड़ दिखानी है।
Soult वॉल्ट पब्लिक के ठीक उलट हैं — वे डिज़ाइन से ही प्राइवेट हैं। डेटा में केवल यूज़र का ही हित होता है। छेड़छाड़ की संभावना कम है: यह यूज़र का अपना डेटा है, जो यूज़र के अपने परिवार के लिए रखा गया है।
बदलावों को ट्रैक करने के लिए, हम ऑडिट लॉग्स का इस्तेमाल करते हैं (सेक्शन 14 देखें) — हर क्रिएट, अपडेट, डिलीट को टाइमस्टैम्प और एक्टर के साथ रिकॉर्ड किया जाता है। ब्लॉकचेन लागत, जटिलता बढ़ाएगा और पब्लिक लेजर पर पैटर्न उजागर करके प्राइवेसी कम करेगा — बिना किसी यूज़र समस्या को हल किए।
अगर और जब वेरिफाइड-पब्लिक अटेस्टेशन एक वास्तविक यूज़र की ज़रूरत बन जाता है, तो इस पर फिर से विचार किया जाएगा।
Soult क्या कर सकता है और क्या नहीं, इस बारे में ज़्यादा जानने के लिए — लीगल वैलिडिटी पेज पढ़ें। Executor प्रोटोकॉल की विस्तृत जानकारी के लिए, Executor और हैंडओवर फ्लो देखें।
मुफ़्त में शुरू करें →