qub पर सुरक्षा

प्रभावी तिथि: 23 सितंबर 2026 संस्करण: 1.1 — कार्यान्वयन-सटीकता समीक्षा

शोधकर्ताओं के लिए — त्वरित संदर्भ:

• रिपोर्ट कहाँ भेजें: support@qub.social विषय उपसर्ग [SECURITY] के साथ।
• क्या शामिल करें: भेद्यता, प्रजनन के चरण, और कोई प्रूफ़-ऑफ़-कॉन्सेप्ट।
• हमारी प्रतिक्रिया: हम 3 कार्य दिवसों के भीतर प्राप्ति की पुष्टि करते हैं और 90 दिनों के भीतर एक फ़िक्स शिप करने का लक्ष्य रखते हैं।
• Safe Harbor: हम सद्भावनापूर्ण अनुसंधान के विरुद्ध कानूनी कार्रवाई नहीं करेंगे जो §12 में नियमों का पालन करता है (ऐसे डेटा तक पहुँच नहीं जो आपका नहीं है, कोई सेवा गिरावट नहीं, मुद्दे का प्रदर्शन करने के लिए आवश्यक से अधिक प्राप्त डेटा का संरक्षण नहीं, हमें उचित प्रकटीकरण खिड़की दें)।

पूरा विवरण §12 (समन्वित प्रकटीकरण) में है।

हम कौन हैं

qub.social का संचालन VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia द्वारा किया जाता है। "qub", "हम", "हमें", और "हमारा" के संदर्भ उसी इकाई को इंगित करते हैं।

सुरक्षा संपर्क: support@qub.social विषय उपसर्ग [SECURITY] के साथ।

1. हमारा दृष्टिकोण

qub विश्वास का ढाँचा है। यदि यह सुरक्षित नहीं है तो उत्पाद बेकार है, इसलिए सुरक्षा एक सुविधा नहीं है — यह आधार है। यह पृष्ठ ठोस शर्तों में बताता है कि हम अपने स्टैक, आपके डेटा, और मुहरबंद सामग्री की अखंडता की सुरक्षा कैसे करते हैं।

जैसे-जैसे इंटरनेट का अधिक हिस्सा मशीन-निर्मित होता जाता है, एक सत्यापन योग्य अस्थायी प्रतिबद्धता का मूल्य बढ़ता है। सत्यापित संग्रहण लेन-देन या पारदर्शिता-लॉग एंकर यह स्थापित कर सकता है कि ciphertext अपने ब्लॉक समय से बाद में नहीं बना था; मुहरबंद आर्टफ़ैक्ट अलग से सामग्री की अखंडता, drand-राउंड बंधन और लेखकत्व के किसी भी हस्ताक्षर को सिद्ध करता है। इन दावों को अलग रखना ही इस पृष्ठ का मानक है।

हम आपसे हम पर भरोसा करने को नहीं कहते। हम इस तरह डिज़ाइन करते हैं कि हमसे आवश्यक विश्वास जितना संभव हो सके उतना छोटा हो, और जहाँ विश्वास आवश्यक है वहाँ हम ठीक से समझाते हैं कि क्या भरोसा किया जा रहा है और क्यों।

तीन सिद्धांत हर डिज़ाइन निर्णय को संचालित करते हैं:

• सर्वर क्या देख सकता है उसे न्यूनतम करें। डिफ़ॉल्ट ब्राउज़र संदेश फ़्लो में plaintext और wrapper कुंजी आपके डिवाइस पर रहते हैं। सर्वर-साइड Builder मुहरबंदी, संधि सह-हस्ताक्षर और स्पष्ट रूप से सक्षम रिकवरी की विश्वास सीमाएँ अलग हैं, जिनका वर्णन नीचे है। जहाँ हम मेटाडेटा रखते हैं, उसे चुनी गई सुविधा की आवश्यकता तक सीमित रखते हैं।
• समझौते को स्थानीय रूप से सीमित बनाएँ। किसी एक घटक का उल्लंघन (हमारा सर्वर, ईमेल प्रदाता, एक drand नोड) मुहरबंद सामग्री को प्रकट नहीं करना चाहिए जो अभी तक अपने प्रकट समय तक नहीं पहुँची है।
• प्रोटोकॉल को ऑडिट योग्य बनाएँ। मुहरबंद कलाकृति सार्वजनिक क्रिप्टोग्राफी के साथ end-to-end सत्यापन योग्य है। qub आर्टफ़ैक्ट को सत्यापित करने के लिए आपको qub सेवा पर भरोसा करने की आवश्यकता नहीं है।

2. खतरा मॉडल

2.1 हम किसके विरुद्ध सुरक्षा करते हैं

• एक हमलावर जो प्रकट समय से पहले हमारे संग्रहीत सर्वर-साइड डेटा तक पठन पहुँच प्राप्त करता है। डिफ़ॉल्ट निजी ब्राउज़र फ़्लो में उसे मेटाडेटा और अपारदर्शी रैप्ड बाइट्स मिलते हैं, plaintext या K नहीं। यह सुरक्षा रिकवरी के लिए स्पष्ट रूप से रखे गए K, उसके drand राउंड के बाद सार्वजनिक/बिना-wrapper डिलीवरी, या Builder /api/v1/seal और संधि वर्कफ़्लो को अस्थायी रूप से दिए गए plaintext पर लागू नहीं होती।
• एक हमलावर जो आपके ब्राउज़र और हमारे बुनियादी ढाँचे के बीच ट्रैफ़िक को इंटरसेप्ट करता है। TLS हमारे CDN edge पर समाप्त होता है; मुहरबंद पेलोड पारगमन से पहले ही एन्क्रिप्ट हो जाते हैं।
• एक हमलावर जो संग्रहीत पेलोड के साथ छेड़छाड़ करता है। बाहरी-wrapper प्रमाणीकरण (जहाँ मौजूद हो), canonical डिकोडिंग, बॉडी हैश, qub_id की पुनर्व्युत्पत्ति, राउंड बंधन और वैकल्पिक हस्ताक्षर छेड़छाड़ को सत्यापन में विफल कर देते हैं; दर्शक उसे रेंडर करने से मना कर देता है।
• एक हमलावर जो एक हस्ताक्षर कुंजी से एक जाली लेखक ईमेल बाँधने की कोशिश करता है। ईमेल सत्यापन के लिए निजी हस्ताक्षर कुंजी और ईमेल इनबॉक्स में दिए गए एक-बार-कोड दोनों के स्वामित्व की आवश्यकता होती है।
• एक समझौता किया हुआ drand बीकन ऑपरेटर। drand नेटवर्क कई स्वतंत्र ऑपरेटरों में थ्रेशोल्ड BLS हस्ताक्षरों का उपयोग करता है; एक अल्पसंख्यक प्रारंभिक-रिलीज़ हस्ताक्षरों को जाली नहीं कर सकता।

2.2 हम किसके विरुद्ध सुरक्षा नहीं कर सकते

हम अपनी सीमाओं के बारे में ईमानदार हैं। qub इन के विरुद्ध रक्षा नहीं कर सकता:

• मुहर लगाने से पहले आपके डिवाइस का समझौता। स्थानीय keyloggers, दुर्भावनापूर्ण ब्राउज़र एक्सटेंशन, या एक अनलॉक डिवाइस तक भौतिक पहुँच रचना के बिंदु पर प्लेनटेक्स्ट कैप्चर कर सकती है।
• drand थ्रेशोल्ड का पतन। कई स्वतंत्र संगठन इसे कठिन बनाने के लिए विशेष रूप से drand नेटवर्क चलाते हैं, लेकिन यह क्रिप्टोग्राफिक रूप से असंभव नहीं है: यदि पर्याप्त ऑपरेटर मिलीभगत करते हैं, तो वे timelock कुंजी जल्दी प्राप्त कर सकते हैं।
• वैध प्रति के रिलीज़ गुण। सार्वजनिक/बिना-wrapper qub अपने drand राउंड के बाद डिक्रिप्ट किया जा सकता है। निजी/रैप्ड qub को अतिरिक्त रूप से K चाहिए; संग्रहीत बाइट्स और K, दोनों पाने वाला कोई भी व्यक्ति राउंड के बाद उसे डिक्रिप्ट कर सकता है। स्थायी-संग्रहण और एंकर किए गए लॉग रिकॉर्ड केवल qub के उत्पाद सरफ़ेस से हटाकर वापस नहीं लिए जा सकते।
• एक वैश्विक प्रतिद्वंद्वी जो अंतर्निहित क्रिप्टोग्राफी तोड़ता है (AES-GCM, BLS12-381 युग्मन धारणाएँ, SHA3-256, ML-DSA-65)। यदि ये प्रिमिटिव गिरते हैं, तो बड़े पैमाने पर क्रिप्टोग्राफिक पारिस्थितिकी तंत्र में बड़ी समस्याएँ हैं।

3. क्लाइंट-साइड क्रिप्टोग्राफी

डिफ़ॉल्ट ब्राउज़र संदेश फ़्लो में सामग्री अपलोड अनुरोध से पहले एन्क्रिप्ट हो जाती है। दो स्पष्ट पथ अलग हैं: Builder /api/v1/seal जानबूझकर plaintext और कॉलर द्वारा जनरेट किया गया K इन-मेमोरी मुहरबंदी के लिए Worker को भेजता है, और संधि staging/सह-हस्ताक्षर हस्ताक्षरित संरचित संधि सेवा को भेजता है ताकि वह द्विपक्षीय आर्टफ़ैक्ट पूरा कर सके। किसी भी अपवाद को ब्राउज़र-पथ end-to-end एन्क्रिप्शन न समझें।

3.1 Timelock एन्क्रिप्शन

qub tlock का उपयोग करता है — एक भविष्य के drand बीकन राउंड के लिए कुंजी की पहचान-आधारित एन्क्रिप्शन। एन्क्रिप्शन drand नेटवर्क की सार्वजनिक कुंजी का उपयोग करके आपके ब्राउज़र में होता है; डिक्रिप्शन कुंजी drand नेटवर्क द्वारा सार्वजनिक रूप से तभी जारी की जाती है जब लक्ष्य राउंड तक पहुँच जाता है। कोई भी, हम सहित, समय से पहले डिक्रिप्शन कुंजी को पुनर्निर्माण नहीं कर सकता।

हम quicknet चेन को लक्षित करते हैं:

• 3-सेकंड राउंड अवधि
• अनचेन्ड मोड (हर राउंड स्वतंत्र है)
• BLS12-381 G1 हस्ताक्षर
• चेन हैश 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

quicknet चेन की सार्वजनिक कुंजी और उत्पत्ति समय क्लाइंट में संकलित हैं। हम रनटाइम पर चेन पैरामीटर नहीं लाते, इसलिए एक दुर्भावनापूर्ण नोड हमारे द्वारा नियंत्रित चेन को प्रतिस्थापित नहीं कर सकता।

3.2 सिमेट्रिक एन्क्रिप्शन

tlock योजना एक AES-256-GCM सामग्री कुंजी को लपेटती है। AES-GCM प्रमाणित एन्क्रिप्शन प्रदान करता है: सिफरटेक्स्ट में एक बिट पलटने से डिक्रिप्शन विफल हो जाता है, चुपचाप-दूषित प्लेनटेक्स्ट उत्पन्न करने के बजाय।

3.3 Canonical सीरियलाइज़ेशन

प्रोटोकॉल संरचनाएँ नियतात्मक CBOR (RFC 8949 §4.2 कोर नियतात्मक एन्कोडिंग) का उपयोग करके सीरियलाइज़ की जाती हैं। एक ही तार्किक संरचना को एन्कोड करने वाले दो कार्यान्वयन समान CBOR उत्पन्न करते हैं। पूर्ण मुहरबंद पेलोड नियतात्मक नहीं हैं: tlock और बाहरी-wrapper एन्क्रिप्शन नई यादृच्छिकता का उपयोग करते हैं। बॉडी हैश कच्चे बॉडी बाइट्स पर गणना की जाती है, जबकि canonical एन्कोडिंग आसपास की हस्ताक्षरित/wire संरचनाओं को असंदिग्ध बनाती है।

हमने अपने क्लाइंट और सर्वर दोनों कार्यान्वयनों के लिए CBOR एन्कोडर हाथ से लिखा है, न कि एक सामान्य सीरियलाइज़ेशन लाइब्रेरी पर निर्भर रहा — आवश्यकता सटीकता है, एर्गोनॉमिक्स नहीं, और दोनों कार्यान्वयनों में प्रॉपर्टी परीक्षण यह सत्यापित करने के लिए चलते हैं कि वे सहमत हैं।

एक प्रतिगमन परीक्षण दावा करता है कि canonical wire प्रारूप प्रोटोकॉल-प्रिमिटिव qub_id फ़ील्ड कुंजी के अलावा कोई qub-ब्रांड बाइट अनुक्रम नहीं रखता। wire प्रारूप जानबूझकर ब्रांड-अज्ञेय है — कोई भी अनुरूप दर्शक (हमारा या एक तीसरे पक्ष का) स्थायी संग्रहण से किसी भी qub को रेंडर कर सकता है, चाहे जिसने भी मुहरबंद किया हो। परीक्षण एक ट्रिपवायर है जो भविष्य के परिवर्तन को बाइट्स में अनजाने में एक ब्रांड संदर्भ बेक करने से रोकता है जो, एक बार स्थायी संग्रहण में होने के बाद, फिर से नहीं लिखे जा सकते।

3.4 बॉडी हैशिंग और पूर्व-प्रकट अखंडता

हर मुहरबंद पेलोड अपने कच्चे बॉडी बाइट्स का SHA3-256 हैश रखता है। हैश qub_id में और, लेखकत्व हस्ताक्षर सक्षम होने पर, V2 हस्ताक्षर इनपुट में बँधा है। दर्शक डिक्रिप्शन के बाद इसे पुनर्गणित करता है और मेल न खाने पर पेलोड अस्वीकार करता है।

32-बाइट सामग्री पहचानकर्ता qub_id एक 108-बाइट प्रीइमेज से प्राप्त होता है जो प्रोटोकॉल संस्करण, सामग्री प्रकार, निर्माण और अनलॉक टाइमस्टैम्प, वैकल्पिक outcome टाइमस्टैम्प (या उसका शून्य sentinel), लक्ष्य drand राउंड, बॉडी हैश और वैकल्पिक NFC-सामान्यीकृत शीर्षक के SHA3-256 को कवर करता है। कोई गेटवे या CDN किसी भी बँधे फ़ील्ड को संगत रूप से बदलकर भी पुनर्व्युत्पत्ति जाँच पास नहीं कर सकता। शीर्षक 100 NFC कोड बिंदुओं तक सीमित हैं और साझा hostile/control-codepoint वर्ग (bidi overrides, zero-width वर्ण, tag block, BOM, C0, C1 और DEL सहित) होने पर अस्वीकार कर दिए जाते हैं।

3.5 हस्ताक्षर (ML-DSA-65)

लेखकत्व हस्ताक्षर ML-DSA-65 (FIPS 204) का उपयोग करता है, एक NIST-मानकीकृत पोस्ट-क्वांटम हस्ताक्षर योजना। हमने जानबूझकर हस्ताक्षर के लिए एक पोस्ट-क्वांटम प्रिमिटिव चुना क्योंकि मुहरबंद सामग्री स्थायी है: एक हस्ताक्षर जो आज सत्यापित होता है, उसे दशकों बाद भी सत्यापित करना चाहिए, बड़े पैमाने पर क्वांटम कंप्यूटर व्यावहारिक होने के बाद सहित।

हस्ताक्षर कुंजियाँ ब्राउज़र में जनरेट होती हैं। स्थानीय गुप्त को IndexedDB में संग्रहण से पहले एक non-extractable WebCrypto कुंजी के अंतर्गत रैप किया जाता है। यदि account-scoped cross-device रिकवरी सुविधा का उपयोग किया जाता है, तो AEAD-एन्क्रिप्टेड पोर्टेबल कुंजी blob सर्वर-साइड संग्रहीत होता है; उसका गुप्त-कुंजी ciphertext अपरिवर्तनीय account id से बँधा है, और सेवा सार्वजनिक envelope को सत्यापित करती है लेकिन गुप्त सामग्री डिक्रिप्ट नहीं कर सकती। कच्चे निजी-कुंजी बाइट्स सर्वर को नहीं भेजे जाते। सार्वजनिक कुंजियाँ और प्रमाणन रिकॉर्ड सत्यापन तथा पहचान प्रदर्शन के लिए संग्रहीत किए जाते हैं।

वही इन-ब्राउज़र tlock डिक्रिप्शन qub embed के अंदर लागू होता है: जब एक मुहरबंद qub को एक तीसरे पक्ष के पृष्ठ पर <qub-embed> के माध्यम से रेंडर किया जाता है, तो डिक्रिप्शन अभी भी दर्शक के ब्राउज़र में embed iframe में होता है। embed विश्वास मॉडल को नहीं बदलता — प्लेनटेक्स्ट कभी qub सर्वर पर डिक्रिप्ट नहीं किया जाता।

3.6 सार्वजनिक श्रेय — ऑप्ट-इन

मुहरबंद qubs अपने रचयिता का कोई ऑन-चेन पॉइंटर नहीं रखते जब तक कि रचयिता स्पष्ट रूप से एक संलग्न करने का चयन नहीं करता। जब आप एक qub मुहरबंद करते हैं, संदर्भ ऐप एक Author संग्रहण टैग (आपकी हस्ताक्षर सार्वजनिक कुंजी का 64-वर्ण हेक्स फ़िंगरप्रिंट) तभी उत्सर्जित करता है जब "सार्वजनिक श्रेय" तिथि-चयनकर्ता चरण पर सक्षम होता है। टॉगल बंद होने पर — डिफ़ॉल्ट — कोई Author टैग नहीं लिखा जाता और qub स्थायी संग्रहण में अनश्रेय रहता है: संग्रहण में कुछ भी अपलोड को आपके हैंडल, आपके ईमेल, या आपके अन्य qubs से लिंक नहीं करता। टॉगल चालू होने पर, फ़िंगरप्रिंट §6.3 / §10 में सत्यापन श्रृंखला के माध्यम से आपके @handle के साथ हल हो जाता है और दर्शक काउंटडाउन प्रकट से पहले "@{handle} द्वारा मुहरबंद" दिखाता है।

यह हमेशा-चालू Author टैग द्वारा बनाए जाने वाले गणना जोखिम के विरुद्ध एक जानबूझकर रक्षक है: एक तीसरा पक्ष जो एक रचयिता का फ़िंगरप्रिंट सीखता है, अन्यथा टैग द्वारा स्थायी संग्रहण को खोज सकता है और उस रचयिता के पूर्ण ऐतिहासिक आउटपुट का पुनर्निर्माण कर सकता है। ऑप्ट-इन श्रेय उस चैनल को बंद करता है — केवल वे qubs जिन्हें रचयिता स्पष्ट रूप से श्रेय देने का चयन करता है स्थायी संग्रहण में एक फ़िंगरप्रिंट के तहत दिखाई देते हैं।

/u/{handle} प्रोफ़ाइल पृष्ठ एक सत्यापित-पहचान कार्ड है — हैंडल, वैकल्पिक प्रदर्शन नाम + URL, "सत्यापित ईमेल" पिल (कोई पता नहीं), और क्रिप्टोग्राफिक फ़िंगरप्रिंट का छोटा रूप। यह एक रचयिता के qubs को सूचीबद्ध नहीं करता। आगंतुक जो एक रचयिता से एक विशिष्ट qub देखना चाहते हैं, वे उस qub के डिलीवरी URL का सीधे अनुसरण करते हैं।

3.7 बाहरी एन्क्रिप्शन आवरण

timelock डिक्रिप्शन के गणितीय रूप से संभव होने के बाद भी—बँधे राउंड के लिए drand हस्ताक्षर प्रकाशित होने के बाद—अकेली canonical timelock परत किसी indexer को खोजे जा सकने वाले qubs बल्क-डिक्रिप्ट करने देगी। निजी डिलीवरी timelock-एन्क्रिप्टेड बाइट्स के चारों ओर एक अतिरिक्त सिमेट्रिक परत से उस चैनल को बंद करती है (प्रोटोकॉल §13)। सार्वजनिक डिलीवरी जानबूझकर wrapper हटाती है ताकि सूचना, embed और discovery लिंक किसी गुप्त फ़्रैगमेंट के बिना काम कर सकें।

आवरण AES-256-GCM का उपयोग करता है, एक NIST-मानकीकृत प्रमाणित सिफर, जो आपके ब्राउज़र के CSPRNG द्वारा प्रति qub उत्पन्न एक ताज़ा 256-बिट कुंजी K के साथ है। K, qub के qub_id के साथ प्रमाणित अतिरिक्त डेटा के रूप में बँधा है, इसलिए एक qub से एक कुंजी का दूसरे qub को डिक्रिप्ट करने के लिए पुन: उपयोग नहीं किया जा सकता।

डिफ़ॉल्ट निजी ब्राउज़र फ़्लो में K कभी हमारे सर्वर तक नहीं पहुँचता। यह शेयर लिंक के URL fragment (https://qub.social/c/<tx_id>#<base64url(K)>) में एन्कोड है। ब्राउज़र URL fragments को सर्वर तक प्रसारित नहीं करते—RFC 3986 fragment को अनुरोध के बाहर रखता है—इसलिए उस फ़्लो में qub.social, संग्रहण गेटवे, CDN और अनुरोध निगरानी K से अनभिज्ञ रहते हैं। संग्रहीत OuterWrapper पहचाने जा सकने वाला संरचित CBOR है, लेकिन उसका प्रमाणीकृत सिफरटेक्स्ट फ़ील्ड आंतरिक SealedQub संरचना को छिपाता है और K के बिना खोला नहीं जा सकता।

शुद्ध परिणाम:

• qub.social केवल संग्रहीत डेटा से डिफ़ॉल्ट निजी ब्राउज़र मुहरें डिक्रिप्ट नहीं कर सकता। डेटा-स्टोर समझौता K के बिना अपारदर्शी ciphertext तक पहुँचता है। सार्वजनिक qubs और रिकवरी-सक्षम qubs का exposure डिज़ाइन के अनुसार अलग है।
• ऑप्ट-इन रिकवरी चैनल के बिना Fragment हानि अप्राप्य है। यदि आप किसी निजी लिंक को fragment के बिना सहेजते हैं और रिकवरी सक्षम नहीं की थी, तो उस लिंक से qub अपठनीय हो जाता है। मुहर फ़्लो इसी कारण स्पष्ट "इस URL को सहेजें" प्रकटीकरण दिखाता है।
• ऑप्ट-इन रिकवरी। जब आप एक qub के लिए रचयिता जीवनचक्र ईमेल में ऑप्ट-इन करते हैं और ईमेल आपकी सत्यापित पहचान से मेल खाता है, हम अपलोड के साथ K को स्वीकार करते हैं, आपकी पहचान के मुहरबंद-इतिहास रिकॉर्ड पर पूर्ण डिलीवरी URL संग्रहीत करते हैं, और मुहर-पुष्टि ईमेल में इसका उपयोग लिंक के रूप में करते हैं। यह सौदा — कुछ end-to-end शुद्धता के बदले में एक सर्वर-साइड रिकवरी चैनल — केवल स्पष्ट ऑप्ट-इन पर और केवल उस qub के लिए लागू होता है। डिफ़ॉल्ट स्थिति क्रिप्टो-श्रेडिंग है।

Worker का सर्वर-साइड /api/v1/seal एंडपॉइंट (AI एजेंट्स और अन्य API कॉलर्स द्वारा उपयोग) कॉलर से अपेक्षा करता है कि वह K को एक CSPRNG के साथ उत्पन्न करे, उसे स्थानीय रूप से बनाए रखे, और उसे wrapper_key_b64url के रूप में आपूर्ति करे। इस स्पष्ट रूप से विश्वसनीय पथ पर Worker अनिवार्य रूप से plaintext और K दोनों को मेमोरी में देखता है, लेकिन किसी को भी संरक्षित नहीं करता। एक अनिवार्य Idempotency-Key एक खोई हुई प्रतिक्रिया को दूसरा बिल किया गया qub बनाने से रोकता है, जबकि कॉलर-द्वारा-बनाए-रखे गए K को रिप्ले किए गए फ़्रैगमेंट-रहित URL के साथ संयोजित किया जा सकता है। यह डिफ़ॉल्ट ब्राउज़र पथ से भिन्न है, जहाँ K कभी Worker तक नहीं पहुँचता जब तक कि रचयिता स्पष्ट रूप से रिकवरी सक्षम न करे।

4. परिवहन और Edge

4.1 TLS

qub के लिए ब्राउज़र ट्रैफ़िक Cloudflare edge पर HTTPS से परोसा जाता है। प्रतिक्रियाएँ HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload) सेट करती हैं। सटीक बातचीत किया गया TLS संस्करण और cipher suite सक्रिय edge कॉन्फ़िगरेशन द्वारा नियंत्रित होते हैं, एप्लिकेशन कोड द्वारा घोषित नहीं। हम अलग से पहुँच योग्य origin सर्वर उपलब्ध नहीं कराते।

4.2 सामग्री सुरक्षा

संकलित क्लाइंट सख्त सामग्री-प्रकार और कैश हेडर के साथ परोसा जाता है। SPA shell एक ही मूल है। हम एनालिटिक्स या विज्ञापन के लिए तीसरे-पक्ष की स्क्रिप्ट एम्बेड नहीं करते। उत्पाद में दो तीसरे-पक्ष स्पर्श बिंदु दोनों संकीर्ण रूप से दायरे में हैं: खरीद फ़्लो SPA को पूरी तरह से छोड़ देता है Stripe-होस्टेड चेकआउट (https://checkout.stripe.com/…) के लिए पूर्ण-पृष्ठ पुनर्निर्देश के साथ — Stripe का UI कभी हमारे मूल में निष्पादित नहीं होता और हम कभी कार्ड डेटा नहीं देखते — और मुहर फ़्लो Cloudflare का Turnstile विजेट लोड करता है, एक गोपनीयता-संरक्षित CAPTCHA विकल्प जिसे Cloudflare अपने स्वयं के sandboxed iframe में रेंडर करता है। कोई भी पक्ष पृष्ठ के बाकी हिस्से को नहीं पढ़ सकता।

qub embed iframe (qub.social/embed/{tx_id} से परोसा गया और embed.js द्वारा तीसरे-पक्ष की साइटों में लोड किया गया) अपनी Content-Security-Policy रखता है। उसकी connect-src अनुमति सूची 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh और https://drand.cloudflare.com है। iframe sandbox="allow-scripts allow-top-navigation-by-user-activation" (allow-same-origin नहीं) के साथ चलता है: होस्ट पृष्ठ उसका DOM नहीं पढ़ सकता, और वह उपयोगकर्ता की कार्रवाई के बाद ही होस्ट को नेविगेट कर सकता है।

4.3 CORS और Fetch क्षेत्र

ब्राउज़र क्लाइंट केवल इन को fetch अनुरोध करता है:

• हमारी अपनी API (api.qub.social और स्टेजिंग समकक्ष)
• संग्रहण गेटवे (केवल-पढ़ने के लिए, रैप किए गए निजी या बिना रैप किए सार्वजनिक बाइट्स की पुनर्प्राप्ति के लिए — §3.6)
• drand बीकन एंडपॉइंट्स (केवल-पढ़ने के लिए, प्रकट-समय राउंड हस्ताक्षरों के लिए)

embed के गंतव्य उसके CSP द्वारा लागू किए जाते हैं। मुख्य SPA के अभिप्रेत गंतव्य कोड और कॉन्फ़िगरेशन में निश्चित हैं तथा ब्राउज़र और एकीकरण जाँचों में परखे जाते हैं; Subresource Integrity नेटवर्क-गंतव्य नियंत्रण नहीं है।

embed अनुमति सूची में शामिल qub/संग्रहण origins से संग्रहीत बाइट्स प्राप्त करता है, अपने URL fragment के K से निजी पेलोड को ब्राउज़र में अनरैप करता है, और अनुमति सूची के दो drand origins से प्रकटीकरण-समय राउंड हस्ताक्षर लाता है। मुख्य SPA config/drand-endpoints.json में चार-एंडपॉइंट फ़ॉलबैक सेट (drand.cloudflare.com, api.drand.sh, api2.drand.sh और api3.drand.sh) का उपयोग करता है ताकि एक एंडपॉइंट की विफलता प्रकटीकरण न रोके। embed CSP अपनी स्पष्ट सूची से बाहर के कनेक्शन अस्वीकार करता है।

5. सर्वर-साइड बुनियादी ढाँचा

5.1 Serverless Edge

हमारा API पूरी तरह से edge पर एक प्रबंधित serverless रनटाइम पर चलता है। कोई VMs, कोई कंटेनर, और कोई स्थायी सर्वर प्रक्रिया नहीं है जिसे हम प्रबंधित करते हैं। यह नाटकीय रूप से उस आक्रमण सतह को कम करता है जिसके लिए हम ज़िम्मेदार हैं: हम एक OS, एक वेब सर्वर, या एक एप्लिकेशन रनटाइम नहीं चलाते जिसे हमें पैच करना चाहिए।

एक अलग सार्वजनिक-CORS मिडलवेयर लागू होता है Access-Control-Allow-Origin: * निम्नलिखित लागू किए गए पथ सेट के लिए: /embed.js, /embed/v1.js, सब कुछ के नीचे /embed/; /api/v1/telemetry; /api/v1/openapi.json; सब कुछ के नीचे /api/v1/qub/ (बाइट्स, मेटाडेटा, प्रूफ, एंगेजमेंट, नोटिफाई, और पुश सबरूट्स सहित); इसके तहत सब कुछ /api/v1/log/; सार्वजनिक हैंडल खोज के तहत /api/v1/handle/; और सार्वजनिक अवतार के नीचे पढ़ता है /api/v1/identity/avatar/. इसके प्रीफ्लाइट परमिट GET, POST, और OPTIONS के साथ Content-Type रिक्वेस्ट हेडर। यह प्रीफिक्स-आधारित सतह केवल वर्तमान में एम्बेड द्वारा किए जा रहे कॉल्स तक सीमित नहीं है, इसलिए उन प्रीफिक्स के नीचे हर हैंडलर को अपनी खुद की वैलिडेशन, प्रमाणीकरण, दर सीमा, और दुरुपयोग नियंत्रण लागू करना जारी रखना चाहिए। अन्य API पथ qub.social-सीमित CORS नीति बनाए रखते हैं।

5.2 भंडारण

• मेटाडेटा और समन्वय स्टोर पहचान तथा प्रमाणन रिकॉर्ड, अधिकार और बिलिंग संदर्भ, API-कुंजी रिकॉर्ड, denylist प्रविष्टियाँ, sessions, idempotency स्थिति, queues और rate-limit/concurrency स्थिति रखते हैं। अलग-अलग consistency आवश्यकताओं के लिए एक सार्वभौमिक स्टोर के बजाय KV, D1 और Durable Objects उपयोग किए जाते हैं।
• हमारा ऑब्जेक्ट स्टोर भी एक durability substrate है। यह अपलोड पर स्वीकार किए गए बिल्कुल वही रैप्ड या बिना-wrapper qub बाइट्स, पारदर्शिता-लॉग leaves तथा coordinate-keyed Merkle nodes, anchor सामग्री, संरचित event logs और response/metadata caches रखता है।
• स्थायी सार्वजनिक संग्रहण पारदर्शिता-लॉग anchors और, T3 पथ या deferred प्रकाशन के लिए, अलग qub transactions रखता है। हम उस नेटवर्क का संचालन नहीं करते। निजी ब्राउज़र पेलोड वहाँ अपारदर्शी रहते हैं जब तक धारक के पास K भी न हो; सार्वजनिक/बिना-wrapper पेलोड जानबूझकर वह अतिरिक्त link-capability परत नहीं रखते।

डिफ़ॉल्ट ब्राउज़र संदेश फ़्लो qub बुनियादी ढाँचे पर plaintext को बनाए नहीं रखता। Builder /api/v1/seal plaintext और K को मेमोरी में संभालता है लेकिन किसी को संरक्षित नहीं करता। संधि staging में हस्ताक्षरित संरचित संधि को उसके सह-हस्ताक्षरित, वापस लिए या समाप्त होने तक रखना आवश्यक है। ऑप्ट-इन रिकवरी डिलीवरी capability (पूरा fragment-युक्त लिंक) रखती है ताकि बाद में उसे पुनर्प्राप्त किया जा सके। इसलिए हम पूरे storage tier को “केवल-मेटाडेटा” नहीं कहते।

5.3 गुप्त

गुप्त (हस्ताक्षर वॉलेट, provider tokens और HMAC कुंजियाँ) source control के बजाय platform secret/environment bindings से दिए जाते हैं। Runtime components को केवल आवश्यक bindings मिलते हैं। Rotation और overlap प्रक्रियाएँ component-specific हैं; हम एक सार्वभौमिक automatic या audited rotation mechanism का दावा नहीं करते।

5.4 लॉगिंग और टेलीमेट्री

संरचित JSON लॉग हर API अनुरोध पर लिखे जाते हैं जिसमें एक correlation ID X-Request-Id प्रतिक्रिया हेडर में सामने आती है। क्लाइंट टेलीमेट्री अनाम है — कोई डिवाइस पहचानकर्ता नहीं, कोई IP पता नहीं, कोई सामग्री पूर्वावलोकन नहीं। ईवेंट मेमोरी में बफ़र होते हैं और सर्वोत्तम-प्रयास के आधार पर फ्लश होते हैं; एक विफल फ्लश को त्याग दिया जाता है, पुनः प्रयास नहीं किया जाता। टेलीमेट्री उत्पाद को प्रभावित किए बिना नेटवर्क परत पर अक्षम करने योग्य होने के लिए डिज़ाइन की गई है।

6. प्रमाणीकरण

6.1 Magic-Link साइन-इन

साइन-इन आपके ईमेल इनबॉक्स में भेजे गए एकल-उपयोग, HMAC-हस्ताक्षरित टोकन का उपयोग करता है। लिंक 15 मिनट तक वैध है और redemption पर atomically claim किया जाता है, जिससे concurrent या replayed उपयोग fail closed होता है। सफलता पर ब्राउज़र को Secure, HttpOnly, SameSite=Strict और Path=/ attributes वाली opaque __Host-qub_session cookie मिलती है।

Sessions की idle सीमा 30 दिन और absolute सीमा 90 दिन है, वे 24 घंटे के बाद rotate होते हैं, और केवल तुरंत पिछली generation को खोई हुई प्रतिक्रिया के लिए 120 सेकंड की grace अवधि में स्वीकार करते हैं। संवेदनशील account mutations के लिए पिछले 10 मिनट में प्रमाणीकरण आवश्यक है। HMAC signing secret एक platform binding है; केवल metadata read से वैध token नहीं बनाया जा सकता।

6.2 API कुंजी (डेवलपर टियर)

डेवलपर API कुंजी उपसर्ग qub_sk_ का उपयोग करती हैं ताकि वे आसानी से पहचानने और grep करने योग्य हों। प्रत्येक कुंजी:

• एक खाते, scopes और वैकल्पिक IP CIDR allowlist से बँधी है
• कच्चे रूप में एक बार दिखाई जाती है; स्थायी रिकॉर्ड bearer secret के बजाय उसका SHA-256 hash रखते हैं
• एक घंटे की grace mapping के साथ rotate की जा सकती है, जिसमें पुरानी कुंजी replacement को resolve करती है
• स्वतंत्र quota और rate-limit state रखती है
• कभी पूर्ण रूप से लॉग नहीं की जाती; लॉग केवल कुंजी पहचानकर्ता रिकॉर्ड करते हैं

व्यवस्थापक कुंजी-प्रबंधन एंडपॉइंट्स एक अलग व्यवस्थापक क्रेडेंशियल के पीछे गेट हैं।

6.3 ईमेल सत्यापन (लेखकत्व हस्ताक्षर)

एक हस्ताक्षर कुंजी के लिए एक ईमेल पते को बाँधने के लिए आवश्यक है:

1. निजी हस्ताक्षर कुंजी का स्वामित्व (आप एक चुनौती पर हस्ताक्षर करते हैं)
2. ईमेल इनबॉक्स का स्वामित्व (आप ईमेल द्वारा दिया गया 6-अंकीय कोड दर्ज करते हैं)

कोई भी अकेला अपर्याप्त है। निरस्तीकरण आपके स्वयं के खाते पर एक हस्ताक्षरित रिकॉर्ड है और तुरंत प्रभावी होता है; सत्यापन प्राप्त करने वाले दर्शक निरस्त स्थिति देखते हैं और तदनुसार प्रदर्शित करते हैं।

7. भुगतान

कार्ड प्रविष्टि और प्रसंस्करण Stripe-hosted checkout के भीतर होते हैं। हमें कार्ड नंबर, समाप्ति तिथियाँ या CVCs कभी नहीं मिलते। हम Stripe customer और subscription identifiers, subscription state तथा period data को entitlement/API-key रिकॉर्ड पर रखते हैं ताकि access, renewals, metering, cancellation और refunds का मिलान हो सके। भुगतान डेटा का Stripe द्वारा प्रबंधन उसके गोपनीयता और सुरक्षा कथनों के अधीन है।

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

8. दुरुपयोग प्रतिरोध

8.1 बॉट डिटेक्शन

मुहर फ़्लो एक गोपनीयता-संरक्षित CAPTCHA विकल्प द्वारा गेट किया गया है जो ट्रैकिंग के लिए कुकीज़ का उपयोग नहीं करता और विज्ञापन के लिए फ़िंगरप्रिंट नहीं करता। मुहर-साइड प्रसंस्करण होने से पहले हमारे edge Worker द्वारा एक विफल चुनौती अस्वीकार कर दी जाती है।

8.2 दर सीमा

दर सीमाएँ कई परतों पर लागू की जाती हैं:

• मुहर, पढ़ने, और auth एंडपॉइंट्स पर प्रति-IP और प्रति-कुंजी सीमाएँ
• मैजिक-लिंक अनुरोधों पर प्रति-ईमेल सीमाएँ (मेलबॉक्स बाढ़ रोकता है)
• संधि आमंत्रण ईमेल पर प्रति-प्रतिकार्य-पक्ष सीमाएँ (प्रति प्राप्तकर्ता पता प्रति UTC दिन दस, प्राथमिक स्पैम-रिले शमन; ईमानदार संधियाँ शायद ही कभी कैप तक पहुँचती हैं)
• टेलीमेट्री प्रस्तुति पर प्रति-IP सीमाएँ

Counters और atomic claims endpoint की consistency आवश्यकताओं के अनुसार KV, Durable Objects और platform rate-limit bindings में वितरित हैं। Rate-limited अनुरोध 429 लौटाते हैं; retry window गणना कर सकने वाले endpoints में Retry-After शामिल होता है।

8.3 सामग्री मॉडरेशन

डिफ़ॉल्ट ब्राउज़र-अपलोड रास्ता बॉडी को स्कैन नहीं कर सकता: यह केवल क्लाइंट-सिल किए गए आर्टिफैक्ट को प्राप्त करता है। बिल्डर /api/v1/seal रूट अस्थायी रूप से सादे पाठ को देखता है, और संधि स्टेजिंग संरचित शर्तों को अंतिम रूप देने तक रखता है, लेकिन वे भरोसेमंद अपवाद सामान्य बाइट-अंधे अपलोड पथ को कंटेंट स्कैनर में नहीं बदलते। संचालनात्मक मॉडरेशन एक है अस्वीकृत सूची दर्शक परत पर: एक अस्वीकार सूचीबद्ध क्यूब को हमारे दर्शक द्वारा अस्वीकार कर दिया जाता है चाहे संग्रहीत पेलोड पहुंच योग्य रहे या नहीं। अस्वीकार सूचीबद्ध करना पहले से प्रकाशित टिकाऊ बाइट्स, पारदर्शिता-लॉग प्रविष्टियों, या स्थायी-नेटवर्क डेटा को वापस नहीं लेता।

दुरुपयोग रिपोर्ट reporter के IP के एक-तरफ़ा हैश का उपयोग करके दर-सीमित हैं; हम इस उद्देश्य के लिए IPs को स्पष्ट में संग्रहीत नहीं करते।

9. आपूर्ति श्रृंखला और बिल्ड अखंडता

9.1 Toolchain पिनिंग

Compiler और runtime संस्करण repository configuration में pinned हैं और dependencies committed lockfiles के माध्यम से resolve होती हैं। CI generated-file freshness और reproducibility-sensitive invariants जाँचता है। हम यह अधिक मज़बूत दावा नहीं करते कि हर clean build सभी supported machines पर bit-for-bit समान है।

9.2 Lints और Static Analysis

कार्यक्षेत्र हमारे सख्ततम lint समूहों को deny स्तर पर सक्षम करता है। CI हर चेतावनी — दस्तावेज़ीकरण-लिंक चेतावनी सहित — को बिल्ड विफलता के रूप में मानता है। यह जानबूझकर है: हम सूक्ष्म प्रतिगमन के लिए lint सख्ती का उपयोग एक trip-wire के रूप में करते हैं।

9.3 CI Gates

CI workflow formatting और strict lints; Rust, WASM/browser, Worker, embed और API tests; type checking; code coverage; mutation/invariant checks; dependency और workflow static analysis; i18n keys, coverage, drift और hostile-codepoint checks; generated-doc/API/knowledge-base freshness; document inventory और internal-link checks; stylesheet तथा bundle budgets; और OpenAPI validation को कवर करता है। कुछ महँगे mutation jobs हर push पर चलने के बजाय scheduled हैं।

यदि कोई आवश्यक job विफल हो, तो एकल आवश्यक ci roll-up लाल रहता है। Protected-branch और deploy workflows एक छोटे security gate की नकल करने के बजाय उसी परिणाम का उपयोग करते हैं।

9.4 Mutation Testing

एक साप्ताहिक कार्य सुरक्षा-महत्वपूर्ण शुद्ध मॉड्यूल के विरुद्ध mutation परीक्षण चलाता है: hashing, canonical CBOR, seal, unlock, wire-format newtypes, प्रोटोकॉल प्रकार validators, और हैंडल namespace। Mutation परीक्षण "क्या हमारी परीक्षण सूट सूक्ष्म रूप से गलत कोड पकड़ता है?" का उत्तर देता है — यदि एक उत्परिवर्तित कार्यान्वयन अभी भी सभी परीक्षण पास करता है, तो हम जानते हैं कि हमारे पास एक परीक्षण-कवरेज अंतर है और इसे संबोधित करते हैं।

9.5 Git Hooks

स्थानीय hooks (pre-commit, pre-push) CI gates को प्रतिबिंबित करते हैं ताकि प्रतिगमन डेवलपर की मशीन छोड़ने से पहले पकड़े जाएँ। Hooks एक रेपो स्क्रिप्ट के माध्यम से स्थापित होते हैं; वे हमारे workflow में बायपास नहीं किए जाते और यदि उन्हें छोड़ा जाता है तो CI प्रामाणिक gate है।

10. परीक्षण

सुरक्षा-महत्वपूर्ण कोड तीन प्रकार के परीक्षण रखता है:

• इकाई परीक्षण ज्ञात इनपुट पर अपेक्षित व्यवहार सत्यापित करते हैं, प्रोटोकॉल विनिर्देश से प्राप्त परीक्षण वेक्टर सहित।
• प्रॉपर्टी परीक्षण हज़ारों मनमाने इनपुट उत्पन्न करते हैं और invariants पर ज़ोर देते हैं: canonical CBOR round-trips, हस्ताक्षर सत्यापन round-trips, ईमेल-बंधन predicates, संधि स्वीकृति determinism।
• क्रॉस-कार्यान्वयन परीक्षण सत्यापित करते हैं कि हमारे क्लाइंट और सर्वर कार्यान्वयन canonical encodings पर बाइट-दर-बाइट सहमत हैं। यह उत्पादन तक पहुँचने से पहले दो कार्यान्वयनों के बीच अंतर को पकड़ता है।

11. शाखा और रिलीज़ स्वच्छता

Feature branches केवल Gate 1 pull request से staging को आगे बढ़ाती हैं: आवश्यक ci हरा, कोई unresolved change request नहीं, कोई merge conflict नहीं, और साफ़ reviewed tree; merge squash-and-delete होता है। main केवल Gate 2 staging → main pull request से आगे बढ़ता है और merge commit के साथ ancestry बनाए रखता है। Direct branch pushes release workflow नहीं हैं।

Staging और production deploys CI के बाद क्रमशः protected staging और main branch states से trigger होते हैं। Pull-request code और fork credentials को deploy secrets नहीं मिलते।

Deploy workflows में उपयोग किए जाने वाले गुप्त हमारे CI प्लेटफ़ॉर्म द्वारा deploy वातावरण के दायरे में हैं। वे forks से pull-request workflows के लिए उपलब्ध नहीं हैं।

12. समन्वित प्रकटीकरण

यदि आपको लगता है कि आपने qub में एक सुरक्षा भेद्यता पाई है, हम जल्द से जल्द इसके बारे में सुनना चाहते हैं और हम रिपोर्ट को पेशेवर रूप से संभालने के लिए प्रतिबद्ध हैं।

• विषय उपसर्ग [SECURITY] के साथ support@qub.social पर ईमेल करें।
• भेद्यता, प्रजनन के चरण, और कोई प्रूफ़-ऑफ़-कॉन्सेप्ट का वर्णन करें।
• सार्वजनिक होने से पहले हमें एक उचित प्रकटीकरण खिड़की (आमतौर पर 90 दिन) दें।
• ऐसा डेटा एक्सेस न करें जो आपका नहीं है, अन्य उपयोगकर्ताओं के लिए सेवा को कम न करें, या मुद्दे का प्रदर्शन करने के लिए आवश्यक से अधिक अनुसंधान के दौरान प्राप्त डेटा को न रखें।

हम तीन कार्य दिवसों के भीतर प्राप्ति की पुष्टि करते हैं और जैसे-जैसे हम जाँच करते हैं आपको सूचित रखते हैं। आपकी सहमति से, हम release notes में reporters को क्रेडिट देते हैं।

12.1 Safe Harbor

यदि आपका अनुसंधान ऊपर के नियमों का पालन करता है (सद्भावनापूर्ण जाँच, अन्य उपयोगकर्ताओं या सेवा को कोई नुकसान नहीं, उचित प्रकटीकरण खिड़की), हम आप पर कानूनी कार्रवाई नहीं करेंगे, और हम कानून प्रवर्तन से ऐसा करने के लिए नहीं कहेंगे। हम आपके काम को अधिकृत परीक्षण के रूप में मानते हैं और हम चाहेंगे कि आप बग खोजें, कोई और नहीं।

यह Safe Harbor इन पर लागू होता है:

• live qub.social सेवा पर अनुसंधान (हम उस उद्देश्य के लिए जो परीक्षण फ़िक्स्चर प्रकाशित करते हैं उन पर नहीं)।
• हमारे प्रकाशित बायनरीज़ और open-source qub-core / qub-app crates की रिवर्स-इंजीनियरिंग।
• कोई भी भेद्यता वर्ग — प्रोटोकॉल, एप्लिकेशन, बुनियादी ढाँचा, आपूर्ति-श्रृंखला — जो qub को प्रभावित करता है।

यह qub टीम के सदस्यों की सामाजिक इंजीनियरिंग, denial-of-service परीक्षण, या मुद्दे का प्रदर्शन करने के लिए आवश्यक से अधिक अन्य उपयोगकर्ताओं के डेटा तक पहुँच पर लागू नहीं होता। यदि आप अनिश्चित हैं कि कुछ Safe Harbor के अंदर आता है या नहीं, तो पहले उसी [SECURITY] विषय उपसर्ग का उपयोग करके पूछें।

13. ईमानदार सीमाएँ

सुरक्षा एक अभ्यास है, स्थिति नहीं। कुछ सीमाओं को सीधे नाम देने योग्य है:

• हम एक छोटी टीम हैं। हमारी समीक्षा गहराई एक बड़े निगम के समर्पित एप्लिकेशन-सुरक्षा फ़ंक्शन से मेल नहीं खाती। हम सख्त स्वचालित gates और एक न्यूनतम आक्रमण सतह से क्षतिपूर्ति करते हैं, लेकिन हम अचूकता का दावा नहीं करते।
• हमारे संग्रहण बैकएंड की स्थायित्व एक एक-तरफ़ा दरवाज़ा है। यदि एक गलती के कारण मुहरबंद सामग्री इरादा से पहले डिक्रिप्ट करने योग्य हो जाती है, तो हम इसे पूर्ववत नहीं कर सकते। हम मुहर फ़्लो को समान देखभाल के साथ मानते हैं।
• drand नेटवर्क एक बाहरी निर्भरता है। drand की एक विनाशकारी विफलता हर qub के प्रकट व्यवहार को प्रभावित करेगी। हम drand स्वास्थ्य की निगरानी करते हैं और यदि आवश्यक हो तो चेन माइग्रेशन के लिए आकस्मिक प्रलेखन रखते हैं। 2 साल से अधिक अनलॉक तिथियों के लिए, मुहर-समय पुष्टि मोडल एक स्पष्ट प्रकटीकरण दिखाता है: लंबे-क्षितिज qubs drand चेन स्थायित्व पर निर्भर हैं, और एक भविष्य drand चेन माइग्रेशन को qub को अनलॉक करने के लिए पुनर्प्राप्ति चरणों की आवश्यकता हो सकती है। 5 साल से अधिक अनलॉक तिथियों के लिए, आपको मुहर आगे बढ़ने से पहले इस जोखिम को पढ़ने और स्वीकार करने की पुष्टि करने वाला एक अतिरिक्त बॉक्स चेक करना होगा।
• क्रिप्टोग्राफिक प्रिमिटिव जिन पर हम भरोसा करते हैं मानकीकृत हैं और व्यापक रूप से समीक्षा की जाती है, लेकिन क्रिप्टोग्राफी विकसित होती है। जहाँ हमारे पास विकल्प हैं (पोस्ट-क्वांटम हस्ताक्षर, प्रमाणित एन्क्रिप्शन), हम अधिक रूढ़िवादी विकल्प चुनते हैं।

14. इस पृष्ठ में परिवर्तन

भौतिक परिवर्तन शीर्ष पर प्रभावी तिथि अद्यतन करके नोट किए जाते हैं। जहाँ एक परिवर्तन एक ठोस सुरक्षा सुधार को दर्शाता है, हम सार्वजनिक changelog में इसे संक्षेप में वर्णित करते हैं। जहाँ एक परिवर्तन एक नीति स्पष्टीकरण को दर्शाता है, हम वर्णित करते हैं कि क्या बदला और क्यों।

इस पृष्ठ पर किसी भी चीज़ के बारे में प्रश्नों के लिए, विषय उपसर्ग [SECURITY] के साथ support@qub.social पर ईमेल करें।

15. परिवर्तन लॉग