Remio का सुरक्षा आर्किटेक्चर, सीधे शब्दों में।

§01 · कार्यकारी सारांश

Remio एक रिमोट डेस्कटॉप ऐप्लिकेशन है जो ज़ीरो-नॉलेज, पीयर-टू-पीयर आर्किटेक्चर पर बना है। स्क्रीन की सामग्री, इनपुट डेटा और ऑडियो स्ट्रीम, उद्योग-मानक DTLS-SRTP से डिवाइस के बीच एंड-टू-एंड एन्क्रिप्टेड हैं — वही सुरक्षा मॉडल जिस पर हर WebRTC-आधारित प्रोडक्ट निर्भर करता है। केंद्रीकृत समाधानों के उलट, Remio का सिग्नलिंग सर्वर सिर्फ़ शुरुआती कनेक्शन बनाने में मदद करता है — वह सेशन डेटा को कभी देखता, प्रोसेस करता या स्टोर नहीं करता।

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

§02 · खतरा मॉडल

Remio का सुरक्षा आर्किटेक्चर एंटरप्राइज़ और निजी, दोनों संदर्भों में रिमोट डेस्कटॉप के इस्तेमाल से जुड़े खतरों के एक समूह के विरुद्ध डिज़ाइन किया गया है। हम साफ़ बताते हैं कि हम किससे बचाते हैं, और भरोसे की सीमाएँ कहाँ हैं।

वे खतरे जिनसे हम बचाते हैं

• छिपकर सुनना। सभी मीडिया (वीडियो, ऑडियो) और डेटा चैनल (इनपुट, कीबोर्ड, कर्सर) क्रमशः SRTP और DTLS से एन्क्रिप्टेड हैं। नेटवर्क पर नज़र रखने वाला सिर्फ़ एन्क्रिप्टेड पैकेट देखता है और सेशन की सामग्री दोबारा बनाने में असमर्थ रहता है।
• बीच में घुसपैठ (MITM)। सर्टिफ़िकेट फ़िंगरप्रिंट सत्यापन के साथ DTLS हैंडशेक अवरोधन को रोकता है। सिग्नलिंग चैनल Perfect Forward Secrecy के साथ TLS 1.3 इस्तेमाल करता है।
• सर्वर में सेंध। हमारे सिग्नलिंग सर्वर के पूरी तरह समझौता होने पर भी, हमलावरों को सिर्फ़ कनेक्शन मेटाडेटा (IP पते, टाइमस्टैंप) मिलता है। सेशन की सामग्री कभी हमारे सर्वरों से होकर नहीं जाती, न वहाँ स्टोर होती है।
• अनधिकृत पहुँच। PIN-आधारित पेयरिंग के लिए भौतिक निकटता या दिखाए गए PIN का ज्ञान चाहिए। हमला करने को कोई दूर से पहुँच-योग्य क्रेडेंशियल डेटाबेस मौजूद नहीं है।
• क्रेडेंशियल की चोरी। कोई पासवर्ड नहीं, कोई अकाउंट नहीं, कोई केंद्रीय क्रेडेंशियल स्टोर नहीं। डिवाइस पर भरोसा PIN पेयरिंग से बनता है; सेशन टोकन (JWT) अल्पकालिक और डिवाइस से बँधे हैं।
• सेशन रीप्ले। SRTP की अंतर्निहित रीप्ले सुरक्षा और DTLS सीक्वेंस नंबर पकड़े गए पैकेट को दोबारा चलाए जाने से रोकते हैं।
• सप्लाई चेन हमले। Remio की सभी बाइनरी कोड-साइन की हुई हैं। macOS बिल्ड Apple द्वारा notarized हैं। iOS बिल्ड सिर्फ़ App Store से बँटते हैं।

भरोसे की सीमाएँ

हमारा खतरा मॉडल साफ़ तौर पर तीन भरोसे की सीमाएँ तय करता है:

1. डिवाइस की सीमा। हर डिवाइस पर भरोसा सिर्फ़ PIN सत्यापन के बाद किया जाता है। OS-स्तर की सुरक्षाएँ (सैंडबॉक्सिंग, Keychain, Secure Enclave) डिवाइस पर मौजूद डेटा की रक्षा करती हैं।
2. नेटवर्क की सीमा। ट्रांज़िट में सारा डेटा एन्क्रिप्टेड है। हम मानते हैं कि नेटवर्क शत्रुतापूर्ण है।
3. सर्वर की सीमा। हमारे अपने सर्वरों को अविश्वसनीय रिले माना जाता है। वे कनेक्शन करवाते हैं पर सामग्री की जाँच नहीं कर सकते।

§03 · आर्किटेक्चर का अवलोकन

Remio सिग्नलिंग प्लेन (कनेक्शन सेटअप) को डेटा प्लेन (स्ट्रीमिंग) से अलग रखता है। यह अलगाव हमारे ज़ीरो-नॉलेज डिज़ाइन की बुनियाद है — जो सर्वर आपको जुड़ने में मदद करता है, वह आपके आदान-प्रदान किए डेटा को कभी नहीं छूता।

सिग्नलिंग बनाम डेटा प्लेन

सिग्नलिंग सर्वर की एकमात्र ज़िम्मेदारी कनेक्शन सेटअप के दौरान डिवाइस के बीच SDP offer/answer और ICE कैंडिडेट रिले करना है। P2P कनेक्शन स्थापित होते ही, सिग्नलिंग सर्वर की कोई भूमिका नहीं रहती।

सर्वर रिले की गई सामग्री को पार्स नहीं कर सकता — वह एक एन्क्रिप्टेड बाइनरी ब्लॉब है जिसे सिर्फ़ लक्ष्य डिवाइस समझ सकता है। बाइनरी प्रोटोकॉल एक अतिरिक्त संरचना की परत जोड़ता है जो JSON-आधारित सिग्नलिंग की तुलना में इंजेक्शन हमलों को ज़्यादा मुश्किल बनाती है।

§04 · एन्क्रिप्शन की परतें

Remio बहु-परत एन्क्रिप्शन रणनीति अपनाता है जिसमें हर संचार चैनल अपनी ज़रूरतों के सबसे अनुकूल क्रिप्टोग्राफ़िक प्रोटोकॉल का उपयोग करता है।

Perfect forward secrecy

हर Remio सेशन ECDHE कुंजी विनिमय के ज़रिए अस्थायी एन्क्रिप्शन कुंजियों का एक अनूठा सेट बनाता है।

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

सिफ़र सूट

# सिग्नलिंग — TLS 1.3 सिफ़र सूट (प्राथमिकता के क्रम में)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# मीडिया — SRTP सुरक्षा प्रोफ़ाइल (WebRTC उद्योग डिफ़ॉल्ट)
SRTP_AES128_CM_SHA1_80   # AES-128 काउंटर मोड, HMAC-SHA1-80 ऑथ

# DTLS सर्टिफ़िकेट
Self-signed ECDSA (P-256), SDP फ़िंगरप्रिंट से आउट-ऑफ़-बैंड सत्यापित

कुंजी रोटेशन

कुंजियाँ निम्न सीमाओं पर अपने आप रोटेट होती हैं:

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

§05 · प्रमाणीकरण और पेयरिंग

Remio जान-बूझकर पारंपरिक यूज़रनेम/पासवर्ड प्रमाणीकरण से बचता है। इसके बजाय हम एक PIN-आधारित डिवाइस पेयरिंग मॉडल इस्तेमाल करते हैं जो रिमोट डेस्कटॉप सॉफ़्टवेयर के सबसे आम हमले-रास्तों को मिटा देता है।

PIN-आधारित पेयरिंग

जब कोई क्लाइंट पहली बार किसी होस्ट से जुड़ना चाहता है, तो प्रक्रिया इस तरह चलती है:

1. होस्ट अपनी स्क्रीन पर (या QR कोड के रूप में) एक छोटा संख्यात्मक PIN दिखाता है।
2. क्लाइंट PIN दर्ज करता है, जो सिग्नलिंग चैनल से होस्ट को भेजा जाता है।
3. होस्ट PIN को सत्यापित करता है और पेयरिंग की पुष्टि करता या उसे अस्वीकार करता है।
4. सफल होने पर, एक डिवाइस भरोसा संबंध स्थापित होता है।
5. उसी डिवाइस से बाद के कनेक्शन को दोबारा पेयर करने की ज़रूरत नहीं।

डिवाइस भरोसा मॉडल

एक बार पेयर होने के बाद, हर डिवाइस एक अनूठे डिवाइस ID से पहचाना जाता है। होस्ट भरोसेमंद डिवाइस की एक लोकल सूची रखता है। यह भरोसा संबंध है:

• लोकल रूप से स्टोर सिर्फ़ होस्ट डिवाइस पर, OS Keychain में।
• कभी प्रसारित नहीं — सर्वर को कोई जानकारी नहीं कि कौन-से डिवाइस भरोसेमंद हैं।
• रद्द किया जा सकता है — होस्ट किसी भी समय किसी भरोसेमंद डिवाइस को हटा सकता है।

सेशन टोकन (JWT)

पेयरिंग के बाद, सिग्नलिंग सर्वर के प्रमाणीकरण के लिए अल्पकालिक हस्ताक्षरित टोकन (24 घंटे की समाप्ति) इस्तेमाल होते हैं।

ये टोकन रूम बनाने और संदेश रिले के लिए किसी डिवाइस को सिग्नलिंग सर्वर के सामने प्रमाणित करते हैं। ये सेशन की सामग्री तक पहुँच नहीं देते, जो एक अलग DTLS हैंडशेक से सुरक्षित है।

AI एजेंट की पहुँच (Remio MCP Server)

Remio इसी भरोसा मॉडल को AI एजेंट तक बढ़ा रहा है। Claude Code, Codex या Claude ऐप जैसे टूल Remio MCP Server के ज़रिए आपकी मशीनें दूर से चला सकते हैं — और सुरक्षा सीमा वही है जो कोई इंसानी क्लाइंट पार करता है:

• सब कुछ आपके साइन-इन से बँधा है। कोई एजेंट सिर्फ़ उन होस्ट तक पहुँच सकता है जो ऑनलाइन हैं और उस अकाउंट से पेयर हैं जिससे आपने प्रमाणित किया (Google या Apple साइन-इन, OAuth के ज़रिए)। कोई प्रमाणित अकाउंट नहीं, तो कोई टूल नहीं।
• Remio एक ब्रोकर है, ऑपरेटर नहीं। MCP सर्वर का एकमात्र काम आपके प्रमाणित अकाउंट तक सीमित टूलों का एक समूह सामने रखना और उन्हें उस AI टूल को सौंपना है जिसे आपने जोड़ने के लिए चुना। Remio अपने आप आपकी मशीन के साथ सेशन शुरू नहीं कर सकता — होस्ट सिर्फ़ वही कनेक्शन स्वीकार करता है जो आपके अकाउंट की अनुमति का प्रमाण पेश करें, ठीक ऊपर के डिवाइस भरोसा मॉडल की तरह।
• वही एन्क्रिप्टेड ट्रांसपोर्ट। एजेंट सेशन §04 में बताए उन्हीं एंड-टू-एंड एन्क्रिप्टेड चैनलों पर चलते हैं। हमारे सर्वर अब भी सिर्फ़ एन्क्रिप्टेड ब्लॉब देखते हैं — §06 के ज़ीरो-नॉलेज गुण बिना बदले लागू रहते हैं।
• दिखता हुआ, रोके जाने योग्य, ऑडिट किया हुआ। एजेंट सेशन चलने के दौरान होस्ट पर दिखता है, किल स्विच से तुरंत समाप्त किया जा सकता है, और एक लोकल ऑडिट लॉग में दर्ज होता है।

§06 · ज़ीरो-नॉलेज डिज़ाइन

Remio में ज़ीरो-नॉलेज कोई मार्केटिंग शब्द नहीं है — यह एक आर्किटेक्चरल बाध्यता है। हमारे सिस्टम इस तरह डिज़ाइन किए गए हैं कि सेशन की सामग्री Remio, उसके कर्मचारियों या किसी तीसरे पक्ष के लिए संरचनात्मक रूप से अगम्य है।

हमारे सर्वर क्या देख सकते हैं

• जुड़ने वाले डिवाइस के IP पते (नेटवर्किंग के लिए ज़रूरी)।
• कनेक्शन टाइमस्टैंप।
• डिवाइस ID (अपारदर्शी पहचानकर्ता, व्यक्तिगत जानकारी से जुड़े नहीं)।
• सिग्नलिंग मेटाडेटा: SDP offer/answer का आदान-प्रदान, ICE कैंडिडेट।

हमारे सर्वर क्या नहीं देख सकते

• स्क्रीन की सामग्री — वीडियो फ़्रेम एंड-टू-एंड SRTP-एन्क्रिप्टेड हैं।
• ऑडियो — वीडियो जैसा ही SRTP एन्क्रिप्शन।
• इनपुट इवेंट — माउस, कीबोर्ड, टच DTLS-एन्क्रिप्टेड हैं।
• कर्सर की स्थिति — एन्क्रिप्टेड डेटा चैनल से प्रसारित।
• फ़ाइल की सामग्री — कोई भी फ़ाइल ट्रांसफ़र एन्क्रिप्टेड चैनल पर होता है।
• क्लिपबोर्ड डेटा — एन्क्रिप्टेड डेटा चैनल।
• ऐप्लिकेशन की स्थिति — आप कौन-से ऐप चला रहे हैं, आप किस पर काम कर रहे हैं।

डेटा प्रतिधारण नीति

हमारे P2P आर्किटेक्चर की वजह से, प्रतिधारण करने को व्यावहारिक रूप से कुछ नहीं है:

• सेशन की सामग्री। कभी स्टोर नहीं होती। सिर्फ़ रियल-टाइम स्ट्रीम।
• सिग्नलिंग लॉग। कनेक्शन मेटाडेटा डीबगिंग के लिए 30 दिन तक रखा जाता है, फिर मिटा दिया जाता है। इसमें सेशन की कोई सामग्री नहीं होती।
• यूज़र अकाउंट। कोई अकाउंट ज़रूरी नहीं। वैकल्पिक Firebase Auth डेटा Google के इंफ़्रास्ट्रक्चर द्वारा प्रबंधित है और यूज़र द्वारा मिटाया जा सकता है।
• डिवाइस की जानकारी। हर डिवाइस पर लोकल रूप से स्टोर होती है। अगर आप साइन इन करना चुनते हैं, तो आपकी डिवाइस सूची आपके अकाउंट में सिंक होती है (देखें निजता नीति)।

P2P-पहले डेटा प्रवाह

ज़्यादातर कनेक्शन में (जहाँ NAT ट्रैवर्सल सफल होता है), डेटा किसी भी सर्वर को छुए बिना सीधे डिवाइस के बीच बहता है:

# सबसे अच्छी स्थिति: सीधा P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ सर्वर की कोई भूमिका नहीं

# फ़ॉलबैक: TURN रिले
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ फिर भी E2E एन्क्रिप्टेड
                            ↑ सर्वर सिर्फ़ एन्क्रिप्टेड ब्लॉब देखता है

TURN रिले फ़ॉलबैक की स्थिति में भी, रिले सर्वर सिर्फ़ एन्क्रिप्टेड पैकेट संभालता है। वह एक गूँगे पाइप की तरह काम करता है — वह डेटा को डिक्रिप्ट, जाँच या संशोधित नहीं कर सकता।

§07 · नेटवर्क सुरक्षा

P2P कनेक्शन की स्थापना

Remio डिवाइस के बीच सबसे अच्छा संभव कनेक्शन रास्ता खोजने के लिए ICE (Interactive Connectivity Establishment) प्रोटोकॉल इस्तेमाल करता है:

1. होस्ट कैंडिडेट — उसी नेटवर्क पर सीधा LAN कनेक्शन।
2. सर्वर-रिफ़्लेक्सिव कैंडिडेट (STUN) — सार्वजनिक IP खोजने के लिए STUN सर्वर के ज़रिए NAT ट्रैवर्सल।
3. रिले कैंडिडेट (TURN) — सीधा कनेक्शन न बन पाने पर एन्क्रिप्टेड रिले।

ICE एजेंट सभी कैंडिडेट जोड़ियों को एक साथ परखता है और सबसे कम-लेटेंसी, सबसे भरोसेमंद रास्ता चुनता है। सीधा P2P हमेशा पसंदीदा है।

कॉन्फ़िगर करने योग्य ट्रांसपोर्ट नीतियाँ

कनेक्शन डिफ़ॉल्ट रूप से सीधे P2P को तरजीह देते हैं और एन्क्रिप्टेड रिले पर अपने आप लौट आते हैं। ज़्यादा सख़्त नीतियाँ — सारा ट्रैफ़िक रिले से भेजना, या LAN डिस्कवरी पूरी तरह छोड़ देना — बंद किए गए नेटवर्क माहौल के लिए उपलब्ध हैं।

दर सीमा

सिग्नलिंग सर्वर दुरुपयोग रोकने के लिए सख़्त दर सीमा लागू करता है:

समाप्त हो चुके रेट लिमिटर 5 मिनट के अंतराल पर और 10 मिनट के TTL के साथ अपने आप साफ़ किए जाते हैं, जो वितरित हमलों से मेमोरी खत्म होने को रोकता है।

DDoS सुरक्षा

हमारा सिग्नलिंग इंफ़्रास्ट्रक्चर Cloudflare द्वारा सुरक्षित है, जो देता है:

• वैश्विक एज नेटवर्क के साथ Anycast DNS।
• Layer 3, 4 और 7 DDoS न्यूनीकरण।
• Web Application Firewall (WAF)।
• ट्रैफ़िक के ओरिजिन तक पहुँचने से पहले एज पर दर सीमा।
• बॉट पहचान और चैलेंज पेज।

§08 · क्लाइंट सुरक्षा

Remio लोकल डेटा की रक्षा करने और ऐप्लिकेशन की अखंडता पक्की करने के लिए हर ऑपरेटिंग सिस्टम का पूरा सुरक्षा स्टैक इस्तेमाल करता है।

macOS

• Keychain इंटीग्रेशन। सारा संवेदनशील डेटा (डिवाइस भरोसा टोकन, JWT) macOS Keychain में स्टोर होता है, जो यूज़र के लॉगिन क्रेडेंशियल और हार्डवेयर एन्क्रिप्शन से सुरक्षित है।
• App Sandbox। Remio न्यूनतम अनुमतियों के साथ एक सैंडबॉक्स वाले माहौल में चलता है। स्क्रीन कैप्चर और एक्सेसिबिलिटी के लिए यूज़र की स्पष्ट मंज़ूरी चाहिए।
• कोड साइनिंग। सभी बिल्ड Apple Developer सर्टिफ़िकेट से साइन किए जाते हैं।
• Notarization। macOS बिल्ड Apple द्वारा notarized हैं, जो पुष्टि करता है कि वे ज्ञात मैलवेयर से मुक्त हैं।
• Hardened runtime। प्रोडक्शन बिल्ड में कोड इंजेक्शन, लाइब्रेरी हाइजैकिंग और डीबगिंग को रोकता है।

iOS

• App Transport Security (ATS)। सभी नेटवर्क कनेक्शन HTTPS/TLS इस्तेमाल करने चाहिए। कोई अपवाद कॉन्फ़िगर नहीं।
• Secure Enclave। जहाँ उपलब्ध हो, क्रिप्टोग्राफ़िक कुंजियाँ Secure Enclave हार्डवेयर में बनती और स्टोर होती हैं।
• Keychain Services। डिवाइस क्रेडेंशियल iOS Keychain में kSecAttrAccessibleWhenUnlockedThisDeviceOnly सुरक्षा श्रेणी के साथ स्टोर होते हैं।
• App Store समीक्षा। सभी iOS बिल्ड Apple की सुरक्षा समीक्षा प्रक्रिया से गुज़रते हैं।
• बैकग्राउंड में कोई डेटा नहीं। ऐप बैकग्राउंड में होने पर डेटा इकट्ठा या प्रसारित नहीं करता।

कोड साइनिंग & सत्यापन

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · घटना प्रतिक्रिया

सुरक्षा का रिकॉर्ड

फ़रवरी 2026 तक, Remio का सुरक्षा सेंध या घटनाओं का कोई इतिहास नहीं है। हमारा ज़ीरो-नॉलेज आर्किटेक्चर हमला-सतह को काफ़ी घटाता है — निशाना बनाने को क्रेडेंशियल या सेशन डेटा का कोई केंद्रीय डेटाबेस नहीं है।

कमज़ोरी की रिपोर्टिंग

हम सुरक्षा शोधकर्ताओं से ज़िम्मेदार खुलासे को प्रोत्साहित करते हैं। अगर आपको कोई संभावित कमज़ोरी मिले:

1. विस्तृत विवरण के साथ [email protected] पर ईमेल करें।
2. अगर लागू हो, तो दोहराने के चरण शामिल करें।
3. हम 48 घंटे के भीतर प्राप्ति की पुष्टि करते हैं।
4. हम पुष्ट कमज़ोरियों को 30 दिनों के भीतर हल करने का लक्ष्य रखते हैं।
5. रिपोर्ट करने वालों को हमारे सुरक्षा चेंजलॉग में श्रेय दिया जाता है, जब तक वे गुमनामी न चाहें।

ज़िम्मेदार खुलासे की नीति

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

घटना प्रतिक्रिया प्रक्रिया

किसी पुष्ट सुरक्षा समस्या की स्थिति में:

1. रोकथाम। प्रभावित सिस्टम को 1 घंटे के भीतर अलग करें।
2. आकलन। 24 घंटे के भीतर दायरा और असर तय करें।
3. संचार। प्रभावित यूज़र को 72 घंटे के भीतर सूचित करें (GDPR-अनुरूप)।
4. उपचार। ऑटो-अपडेट इंफ़्रास्ट्रक्चर से पैच तैनात करें।
5. पोस्ट-मॉर्टम। एक पारदर्शिता रिपोर्ट प्रकाशित करें।

§10 · अनुपालन

GDPR की तैयारी

Remio का ज़ीरो-नॉलेज आर्किटेक्चर स्वाभाविक रूप से GDPR-अनुकूल है क्योंकि हम डेटा संग्रह को पूर्ण तकनीकी न्यूनतम तक घटाते हैं:

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

SOC 2 रोडमैप

नियोजित अनुपालन मील के पत्थर

• स्वतंत्र सुरक्षा ऑडिट — पेशेवर पेनिट्रेशन टेस्टिंग और कोड समीक्षा, 2026 के लिए नियोजित।
• SOC 2 Type I — शुरुआती संगठनात्मक नियंत्रणों का आकलन।
• SOC 2 Type II — निरंतर अनुपालन सत्यापन।
• बग बाउंटी कार्यक्रम — औपचारिक ज़िम्मेदार-खुलासा पुरस्कार।

डेटा निवास

क्योंकि Remio P2P-पहले है, सेशन डेटा वहीं रहता है जहाँ आपके डिवाइस हैं। आपका डेटा आपके डिवाइस के बीच सीधे कनेक्शन से कभी बाहर नहीं जाता। सिग्नलिंग सर्वर (Cloudflare और DigitalOcean के साथ होस्ट किया गया) सिर्फ़ कनेक्शन मेटाडेटा प्रोसेस करता है — और यह मेटाडेटा किसी व्यक्तिगत जानकारी से जुड़ा नहीं है।

§11 · विकल्पों से तुलना

रिमोट डेस्कटॉप उद्योग चर्चित सुरक्षा सेंध से जूझता रहा है। यहाँ बताया है कि Remio का आर्किटेक्चर केंद्रीकृत विकल्पों से बुनियादी तौर पर कैसे अलग है।

केंद्रीकृत आर्किटेक्चर क्यों विफल होते हैं

केंद्रीकृत रिमोट डेस्कटॉप सेवाओं की बुनियादी समस्या यह है कि एक अकेली सेंध सभी यूज़र से समझौता कर सकती है। जब फ़रवरी 2024 में AnyDesk के प्रोडक्शन सर्वरों में सेंध लगी, तो हमलावरों ने कोड साइनिंग सर्टिफ़िकेट चुरा लिए, जिससे वे संभावित रूप से वैध AnyDesk सॉफ़्टवेयर के भेस में मैलवेयर बाँट सकते थे। सभी यूज़र पासवर्ड रीसेट करने पड़े।

जब जून 2024 में APT29 (रूसी सरकार-प्रायोजित समूह) ने TeamViewer के कॉर्पोरेट नेटवर्क में सेंध लगाई, तो इसने प्रोडक्ट की अखंडता पर ही सवाल उठाए — क्योंकि केंद्रीकृत आर्किटेक्चर का मतलब है कि वेंडर के पास सेशन तक पहुँचने की तकनीकी क्षमता है।

Remio इस श्रेणी के हमले को पूरी तरह मिटा देता है। हमारे सिग्नलिंग सर्वर में सेंध सिर्फ़ कनेक्शन मेटाडेटा देती है। चुराने को कोई क्रेडेंशियल नहीं, पहुँचने को कोई सेशन नहीं, ऐसा कोई सर्टिफ़िकेट नहीं जिससे हमारे यूज़र के डिवाइस को निशाना बनाने वाला दुर्भावनापूर्ण सॉफ़्टवेयर साइन किया जा सके।

§12 · निष्कर्ष

Remio की सुरक्षा किसी प्रोडक्ट में बाद में जोड़े गए फ़ीचर का समूह नहीं है — यह पहले दिन से लिए गए आर्किटेक्चरल फ़ैसलों का नतीजा है। केंद्रीकृत के बजाय P2P, पासवर्ड के बजाय PIN पेयरिंग, और डेटा संग्रह के बजाय ज़ीरो-नॉलेज चुनकर, हमने ऐसा रिमोट डेस्कटॉप बनाया है जहाँ सुरक्षा डिफ़ॉल्ट स्थिति है, कोई वैकल्पिक अपग्रेड नहीं।

हम मानते हैं कि निजता वैकल्पिक नहीं है, और भरोसा पारदर्शिता से कमाया जाना चाहिए, सेवा की शर्तों से माँगा नहीं जाना चाहिए। यह व्हाइटपेपर उसी प्रतिबद्धता का हिस्सा है।

सवालों, एंटरप्राइज़ सुरक्षा समीक्षाओं, या कमज़ोरी की रिपोर्ट करने के लिए:

• सुरक्षा संबंधी पूछताछ: [email protected]
• एंटरप्राइज़ सेल्स: [email protected]
• सामान्य: [email protected]