सुरक्षा और डेटा
डेटा कहाँ रहता है, कैसे जाता है, उस तक कौन पहुँचता है और क्या लॉग होता है।
आपके बनाए सिस्टम में डेटा किसका होता है?
आपका। हम उसे सिर्फ़ उसी सेवा को चलाने के लिए संसाधित करते हैं जिसका आपने काम दिया है, और किसी काम के लिए नहीं। उसे किसी दूसरे ग्राहक के डेटा के साथ मिलाया नहीं जाता, बेचा नहीं जाता, और आपके उपयोगकर्ताओं को विज्ञापन दिखाने में इस्तेमाल नहीं होता। रिश्ता खत्म हो तो डेटा आपके साथ जाता है।
रास्ते में डेटा की सुरक्षा कैसे होती है?
कनेक्शन HTTP/3 पर चलते हैं और डोमेन ब्राउज़रों की पहले से लोड HSTS सूची में है — यानी ब्राउज़र पहली ही विज़िट पर बिना एन्क्रिप्शन बात करने से मना कर देता है, इससे पहले कि किसी रीडायरेक्ट को बीच में पकड़ा जा सके। कुंजी विनिमय पोस्ट-क्वांटम है: X25519 के साथ ML-KEM-768। इसे इसलिए चुना गया है कि आज पकड़ा गया ट्रैफ़िक तब भी टिका रहे, जब क्वांटम कंप्यूटर उस पर हमला करने लायक हो जाएँ।
पासवर्ड, कुंजियाँ और API क्रेडेंशियल कैसे संग्रहित होते हैं?
सोर्स कोड में कभी नहीं — और यह अनुशासन नहीं, बिल्ड लागू करता है: जिस कोड में कोई सीक्रेट सीधे लिखा हो, वह मर्ज होने से पहले ही अस्वीकार हो जाता है। सीक्रेट एक सेटिंग्स स्टोर में एन्क्रिप्टेड रहते हैं और रनटाइम पर सिर्फ़ वहीं डिक्रिप्ट होते हैं जहाँ सचमुच ज़रूरत है। इसलिए कुंजी बदलना एक जगह एक बदलाव है, पूरे कोडबेस में खोज नहीं।
क्या-क्या लॉग होता है, और क्या पता चलता है कि किसने बदला?
हाँ। एप्लिकेशन की घटनाएँ, त्रुटियाँ और प्रशासनिक कार्य सर्वरों पर बिखरी टेक्स्ट फ़ाइलों के बजाय डेटाबेस में लिखे जाते हैं, इसलिए उनमें सचमुच खोजा जा सकता है। प्रशासनिक बदलाव यह दर्ज करते हैं कि किसने किया, क्या बदला और कब। "पिछले महीने यह कीमत किसने बदली" का जवाब होता है, अंदाज़ा नहीं।
कुकीज़ और सहमति को आप कैसे संभालते हैं?
ग़ैर-ज़रूरी कुकीज़ तभी सेट होती हैं जब विज़िटर सहमति देता है, यह चुनाव दर्ज होता है, और हमारी बनाई हर साइट पर एक जगह होती है जहाँ बाद में उसे बदला या वापस लिया जा सके। मना करना एक क्लिक है, सेटिंग्स मेन्यू में खोजबीन नहीं — और मना करने वाले को भी पूरी तरह काम करती साइट मिलती है।