परिदृश्य (Scenario)
आप एक मल्टी-साइट वेब प्लेटफॉर्म के ओनर हैं। सुरक्षा टीम केंद्रीकृत CSP, Permissions-Policy, डेप्रिकेशन और इंटरवेंशन रिपोर्ट्स चाहती है ताकि घटनाएं यूजर के स्क्रीनशॉट पर निर्भर न रहें। इंजीनियरिंग टीम Reporting API का प्रस्ताव करती है: Reporting-Endpoints के साथ एंडपॉइंट्स घोषित करें, application/reports+json प्राप्त करें, और वैकल्पिक रूप से ReportingObserver के साथ इन-पेज रिपोर्ट्स देखें। इसे अपनाने के निर्णय, चरणबद्ध लॉन्च और सफलता के मेट्रिक्स को समझाएं।
इंटरव्यूअर क्या मूल्यांकन करता है
- ब्राउज़र की समस्याओं का पहले पता लगाने की क्षमता को मापने योग्य उपयोगकर्ता और व्यावसायिक परिणामों में बदलना।
- यह समझना कि Reporting API बेस्ट-एफर्ट (सर्वोत्तम प्रयास) पर काम करती है, यह एक विश्वसनीय मैसेजिंग चैनल नहीं है।
- ब्राउज़र सपोर्ट, एंडपॉइंट सुरक्षा, गोपनीयता और डेटा गवर्नेंस को संभालना।
- प्रोग्रेसिव रोलआउट, डिडुप्लिकेश़न (deduplication) और रोलबैक गेट्स डिज़ाइन करना।
स्पष्टीकरण वाले प्रश्न (Clarifying questions)
रिपोर्ट के प्रकार, लक्षित ब्राउज़र, साइटों की संख्या, वर्तमान CSP/डेप्रिकेशन बेसलाइन, डेटा रखने (retention) की आवश्यकताएं और अलर्ट संभालने की क्षमता की पुष्टि करें। पूछें कि क्या एंडपॉइंट में पहले से प्रमाणीकरण (authentication) है, क्या URL फ़्रैगमेंट भेजे जा सकते हैं, और क्या लक्ष्य कम घटनाएं, सुधार में कम समय (lower time to repair), या अनुपालन (compliance) का प्रमाण है।
30-सेकंड का उत्तर
मैं इसे एक कम लागत वाले, गैर-महत्वपूर्ण डायग्नोस्टिक सिग्नल के रूप में अपनाऊंगा। रिपोर्ट-ओनली मोड और एक छोटे साइट सैंपल के साथ शुरुआत करें; केवल स्वीकृत रिपोर्ट प्रकार स्वीकार करें और मौजूदा लॉग बनाए रखते हुए रेट लिमिट, डिडुप्लिकेश़न और रिडक्शन (redaction) जोड़ें। एक्शन लेने योग्य रिपोर्ट दर, पहली रिपोर्ट से समाधान तक का समय, फॉल्स-पॉजिटिव दर, एंडपॉइंट लागत और पुराने ब्राउज़र कवरेज को मापें। डेटा-क्वालिटी और गोपनीयता समीक्षा के बाद ही विस्तार करें। कोई भी सुरक्षा निर्णय गारंटीड डिलीवरी पर निर्भर नहीं होना चाहिए।
चरण-दर-चरण तर्क (Step-by-step reasoning)
1. समस्या और विकल्पों को फ्रेम करें
Reporting API CSP, Permissions-Policy, COEP, Integrity, डेप्रिकेशन, क्रैश और इंटरवेंशन रिपोर्ट्स ले जा सकती है। वृद्धिशील (incremental) कवरेज, क्लाइंट लागत, डेटा संवेदनशीलता और संचालन के आधार पर मौजूदा RUM SDKs, सर्वर लॉग्स और ब्राउज़र कंसोल के साथ इसकी तुलना करें।
2. मिनिमम वायबल सिग्नल (MVS) को परिभाषित करें
प्रत्येक प्रकार के लिए एक लॉजिकल कतार का उपयोग करते हुए, csp-violation और deprecation के साथ शुरुआत करें। सर्वर-साइड पर Content-Type: application/reports+json को मान्य करें; पेलोड आकार, स्रोत और फ़ील्ड्स को सीमित करें; साइट, वर्शन और फ़िंगरप्रिंट द्वारा डिडुप्लिकेट करें। एंडपॉइंट आउटेज के कारण केवल डायग्नोस्टिक्स का नुकसान होना चाहिए, पेज अनुरोधों का कभी नहीं।
3. विश्वसनीयता और अनुकूलता को संभालें
विनिर्देश (specification) कहता है कि डिलीवरी की गारंटी नहीं है; नेटवर्क या पॉलिसी स्थितियों के कारण यूजर एजेंट रिपोर्ट्स को छोड़ (drop) सकते हैं। MDN नोट करता है कि नए ब्राउज़रों पर सपोर्ट सबसे मजबूत है और पुराने उपकरणों पर अनुपस्थित हो सकता है। ब्राउज़र वर्शन के अनुसार कवरेज को विभाजित करें और सर्वर लॉग के साथ ReportingObserver को पूरक के रूप में बनाए रखें। शून्य प्राप्त रिपोर्ट कभी भी शून्य उल्लंघनों को साबित नहीं करती हैं।
4. गोपनीयता, सुरक्षा और लॉन्च गेट्स सेट करें
रिपोर्ट्स में URLs, यूजर एजेंट और पॉलिसी विवरण शामिल हो सकते हैं। HTTPS, प्रमाणीकरण या अप्रत्याशित (unguessable) पाथ, क्वेरी-पैरामीटर फ़िल्टरिंग, सीमित अवधारण (bounded retention) और एक्सेस ऑडिट का उपयोग करें। आंतरिक साइटों और 1% ट्रैफ़िक पर रिपोर्ट-ओनली से शुरुआत करें; एंडपॉइंट लोड, संवेदनशील फ़ील्ड और कार्रवाई योग्य दर की निगरानी करें। यदि PII लीक होता है, लागत में वृद्धि होती है, या अलर्ट का तूफ़ान आता है, तो एंडपॉइंट कॉन्फ़िगरेशन को अक्षम कर दें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं इसे एक नए लॉगिंग सिस्टम के बजाय ब्राउज़र पॉलिसी और डेप्रिकेशन के लिए एक प्रारंभिक-डायग्नोस्टिक्स लेयर के रूप में रखूंगा। इस निर्णय में तीन गेट्स हैं। पहला, मूल्य (value): रिपोर्ट-ओनली मोड में 10 प्रतिनिधि साइटों का सैंपल लें, सत्यापित करें कि रिपोर्ट मौजूदा टिकटों का पता लगाती हैं, और पता लगाने के औसत समय (mean time to detection) का बेसलाइन बनाएं। दूसरा, जोखिम (risk): एंडपॉइंट फ़ील्ड, अवधारण, क्रॉस-साइट आइसोलेशन और एक्सेस कंट्रोल की सुरक्षा और गोपनीयता समीक्षा। तीसरा, संचालन (operations): रिपोर्ट बर्स्ट पर लोड-टेस्ट करें और प्रति-स्रोत कोटा, डिडुप्लिकेश़न कुंजी और ड्रॉप-रेट मॉनिटरिंग सेट करें। क्योंकि डिलीवरी बेस्ट-एफर्ट है, RUM, सर्वर लॉग और एक मैन्युअल फ़ॉलबैक बनाए रखें। लॉन्च के बाद, ब्राउज़र परिवार द्वारा कवरेज दिखाएं और एक्शन लेने योग्य दर, MTTR, फॉल्स-पॉजिटिव, प्रति मिलियन पेज रिपोर्ट्स और रिपोर्ट प्रकार के अनुसार लागत को ट्रैक करें। यदि किसी ब्राउज़र में कमजोर कवरेज है, तो निष्कर्षों को कवर किए गए ट्रैफ़िक तक सीमित रखें। यदि एंडपॉइंट गलत व्यवहार करता है, तो मुख्य पेज अनुरोधों को बदले बिना रोलबैक करने के लिए Reporting-Endpoints रिस्पॉन्स हेडर हटा दें।
सामान्य गलतियाँ
- Reporting API को एक विश्वसनीय कतार या अनुपालन ऑडिट रिकॉर्ड के रूप में मानना।
- ब्राउज़र कवरेज को सही किए बिना कम रिपोर्ट मिलने को सफलता घोषित करना।
- रॉ URLs, क्वेरी पैरामीटर और यूजर एजेंट को अनिश्चित काल तक स्टोर करना।
- एंडपॉइंट रेट लिमिट, डिडुप्लिकेश़न, लागत या ओनरशिप के बिना SDK इंटीग्रेशन पर चर्चा करना।
- रिपोर्ट-ओनली, सैंपलिंग या रोलबैक मानदंडों के बिना सभी साइटों को एक साथ सक्षम करना।
फॉलो-अप प्रश्न और उत्तर
“ReportingObserver का उपयोग क्यों न करें?”
यह इन-पेज प्रयोगों और कस्टम हैंडलिंग के लिए आसान है, लेकिन एक क्रैश हुआ पेज निगरानी जारी नहीं रख सकता है। एक रिमोट एंडपॉइंट पेज के लाइफटाइम से स्वतंत्र रूप से रिपोर्ट प्राप्त कर सकता है। वे एक-दूसरे के पूरक हो सकते हैं, लेकिन कोई भी डिलीवरी की गारंटी नहीं देता है।
“आप कैसे साबित करेंगे कि प्रोडक्ट काम कर रहा है?”
ब्राउज़र कवरेज द्वारा विभाजित, पुष्टि की गई समस्याओं के लिए पता लगाने के समय, मरम्मत के समय, कार्रवाई योग्य दर और फॉल्स-पॉजिटिव की पहले/बाद की तुलना का उपयोग करें। साथ ही एंडपॉइंट लागत और गोपनीयता की घटनाओं की निगरानी करें।
“असमर्थित ब्राउज़रों के बारे में क्या?”
सपोर्ट मैट्रिक्स को एक प्रोडक्ट बाधा (constraint) के रूप में मानें, सर्वर लॉग और RUM को बनाए रखें, और निष्कर्षों को कवर किए गए ट्रैफ़िक तक सीमित रखें। केवल कवरेज को एकसमान दिखाने के लिए एक महंगा पॉलीफ़िल इंजेक्ट न करें।