प्रांप्ट और उपयुक्त संदर्भ
एक्सटेंशन केवल स्पष्ट टूलबार क्लिक के बाद ही वर्तमान पेज को प्रोसेस करता है, फिर फ़िल्टर किए गए फ़ील्ड को एक नियंत्रित बैकएंड पर भेजता है। इसे प्रत्येक टैब के बैकग्राउंड स्कैनिंग या मनमाने साइट कुकीज़ तक पहुंच की आवश्यकता नहीं है। Manifest V3 अनुमति विभाजन, रनटाइम प्रवाह, ग्रेसफुल डिग्रेडेशन और रिलीज़ सत्यापन योजना का प्रस्ताव दें।
यह प्रश्न ब्राउज़र-एक्सटेंशन अनुमति सीमाओं और उत्पाद सुरक्षा का परीक्षण करता है। बैकएंड अभी भी प्रमाणीकरण (authentication), डेटा न्यूनीकरण (data minimization) और ऑडिट नियंत्रणों का स्वामी है; एक्सटेंशन अनुमतियां उनका स्थान नहीं लेती हैं।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
साक्षात्कारकर्ता यह देखना चाहता है कि API क्षमता, पहुंच योग्य होस्ट और उपयोगकर्ता की सहमति को अलग-अलग निर्णयों के रूप में माना गया है या नहीं। Chrome API अनुमतियों, होस्ट अनुमतियों, वैकल्पिक अनुमतियों और activeTab को अलग से दस्तावेज़ित करता है; वे उपलब्ध API, URL पहुंच, इंस्टाल चेतावनियों और अपडेट व्यवहार को प्रभावित करते हैं।
एक मजबूत उत्तर सबसे छोटी क्षमता से शुरू होता है, यह बताता है कि वर्तमान पेज पर एक बार की कार्रवाई (one-shot action) के लिए <all_urls> का अनुरोध क्यों नहीं करना चाहिए, और अस्वीकृति, निरस्तीकरण, अपग्रेड और टेलीमेट्री को कवर करता है। केवल "अनुमतियां जोड़ें" कहना एक सुरक्षित जीवनचक्र प्रदर्शित नहीं करता है।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- क्या "वर्तमान पेज" में विशेष पेज, क्रॉस-ओरिजिन फ़्रेम, file URL या गुप्त (incognito) विंडो शामिल हैं?
- क्या API को पूरे दस्तावेज़ की आवश्यकता है या केवल उपयोगकर्ता द्वारा चयनित फ़ील्ड की?
- क्या एक्सटेंशन को पेज परिवर्तनों को तब भी देखना चाहिए जब उपयोगकर्ता ने उस पर क्लिक नहीं किया हो?
- किन WebExtensions कार्यान्वयनों का समर्थन किया जाना चाहिए?
- क्या एंटरप्राइज़ नीति अनुमतियों को पूर्व-कॉन्फ़िगर कर सकती है, और ऑडिट फ़ील्ड को कब तक बनाए रखा जा सकता है?
30-सेकंड उत्तर रूपरेखा
"मैं क्षमता को वर्तमान-पेज रीडिंग, बैकएंड संचार और स्टोरेज में विभाजित करूँगा। एक बार की कार्रवाई के लिए मैं व्यापक होस्ट पहुंच के बजाय activeTab का उपयोग करूँगा। केवल एक वास्तविक क्रॉस-पेज बैकग्राउंड सुविधा ही सटीक optional_host_permissions को उचित ठहराएगी, जिसका अनुरोध तब किया जाएगा जब उपयोगकर्ता उस सुविधा को ट्रिगर करेगा। मैं केवल आवश्यक API अनुमतियों की घोषणा करूँगा, अस्वीकृति या निरस्तीकरण पर रुकूँगा, और एक मैनुअल-कॉपी फ़ॉलबैक प्रदान करूँगा। अपग्रेड से पहले मैं अनुमतियों के अंतर (diff) की जांच करूँगा और नई पहुंच और डेटा प्रवाह की निगरानी करूँगा; रोलबैक नई क्षमता को हटा देगा।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: व्यवहार को अनुमतियों से मैप करना
storage और scripting जैसी API अनुमतियां एक्सटेंशन API क्षमताएं प्रदान करती हैं; होस्ट अनुमतियां उस URL श्रेणी को परिभाषित करती हैं जिसके साथ इंटरैक्ट किया जा सकता है। मैनिफ़ेस्ट को प्रत्येक डेटा प्रवाह से प्राप्त किया जाना चाहिए, न कि उन सुविधाओं से जिनकी बाद में आवश्यकता हो सकती है।
केवल उस टैब को प्रोसेस करने के लिए जहां उपयोगकर्ता ने क्लिक किया है, एक प्रारंभिक बिंदु है:
{
"manifest_version": 3,
"permissions": ["activeTab", "scripting", "storage"],
"optional_host_permissions": ["https://app.example.com/*"]
}जब एक स्क्रिप्ट केवल वर्तमान पेज में इंजेक्ट की जाती है, तो activeTab उपयोगकर्ता की कार्रवाई के बाद अस्थायी पहुंच प्रदान करता है; टैब को बंद करना या नेविगेट करना इसे समाप्त कर देता है। यदि उत्पाद को वास्तव में app.example.com के लिए बैकग्राउंड प्रोसेसिंग की आवश्यकता है, तो डिफ़ॉल्ट रूप से *://*/* करने के बजाय एक सटीक वैकल्पिक होस्ट अनुमति का मूल्यांकन करें।
चरण 2: प्रगतिशील सहमति डिज़ाइन करना
इंस्टॉल के समय केवल मुख्य, कम जोखिम वाली क्षमताओं का अनुरोध करें। जब उपयोगकर्ता "इस पेज का विश्लेषण करें" पर क्लिक करता है, तो अनुमत सेट के विरुद्ध URL की जांच करें। यदि किसी अतिरिक्त होस्ट की आवश्यकता है, तो chrome.permissions.request() को कॉल करें और उद्देश्य, दायरा और सुविधा से बाहर निकलने का तरीका बताएं।
const granted = await chrome.permissions.request({
origins: ["https://app.example.com/*"]
});
if (!granted) {
showManualCopyFallback();
return;
}सफलता का अर्थ है कि ब्राउज़र क्षमता उपलब्ध है; यह बैकएंड प्रमाणीकरण को बायपास नहीं करता है। यदि अनुरोध विफल हो जाता है, उपयोगकर्ता बाद में इसे रद्द कर देता है, या नीति इसे अक्षम कर देती है, तो बार-बार संकेत दिए बिना बिना अनुमति वाली स्थिति पर वापस आ जाएं।
चरण 3: सक्रिय, स्वीकृत और प्रतिसंहरणीय (revocable) स्थिति में अंतर करना
Chromium वर्तमान में सक्रिय अनुमतियों को ऐतिहासिक रूप से दी गई अनुमतियों से अलग करता है। chrome.permissions.remove() वर्तमान क्षमता को कम करता है, जबकि ऐतिहासिक अनुदान सेट अभी भी अनुमति को रिकॉर्ड कर सकता है; बाद का अनुरोध फिर से वही संकेत नहीं दिखा सकता है। रनटाइम निर्णयों में उसका उपयोग होना चाहिए जो वर्तमान में उपलब्ध है, और सेटिंग्स में एक स्पष्ट निरस्तीकरण कार्रवाई प्रदर्शित होनी चाहिए।
प्रत्येक कार्य से पहले, वास्तविक अनुमति के लिए chrome.permissions.contains() को कॉल करें। कार्य के दौरान, permissions.onRemoved को सुनें; पढ़ना और अपलोड करना बंद करें, आउटबाउंड कतार को साफ़ करें, और एक ऑडिट योग्य अनुमति-परिवर्तन ईवेंट रिकॉर्ड करें।
चरण 4: अस्वीकृति, अपग्रेड और रोलबैक को संभालना
अस्वीकृति पर, एक गैर-तकनीकी अगला कदम प्रस्तुत करें जैसे कि मैनुअल चयन, कॉपी और पेस्ट, या बाहर निकलना। अस्वीकृति को नेटवर्क त्रुटि के रूप में वर्गीकृत न करें या बैकग्राउंड में अनुमति अनुरोधों का पुनः प्रयास न करें।
एक रिलीज़ से पहले, नए API, होस्ट पैटर्न, कंटेंट-स्क्रिप्ट मिलान और डेटा फ़ील्ड को कवर करते हुए एक अनुमति अंतर (diff) तैयार करें। जब कोई अपडेट विशेषाधिकार बढ़ाता है तो Chrome एक्सटेंशन को अक्षम कर सकता है और नवीनीकृत सहमति की प्रतीक्षा कर सकता है। किसी अनुमति को हटाने से ऐतिहासिक अनुदान भी आवश्यक रूप से नहीं मिटते हैं, इसलिए रोलबैक परीक्षणों में उन उपयोगकर्ताओं को शामिल किया जाना चाहिए जिन्होंने पहले इसे प्रदान किया था और वे उपयोगकर्ता जिन्होंने इसे कभी नहीं दिया था।
चरण 5: अनुमतियों को एक परीक्षण योग्य सुरक्षा सीमा बनाना
कंटेंट स्क्रिप्ट पेज-नियंत्रित इनपुट को प्रोसेस करती हैं, इसलिए संदेश हैंडलर को प्रेषक, संदेश प्रकार और आकार को मान्य करना चाहिए। बैकएंड को एक्सटेंशन पहचान, उपयोगकर्ता पहचान, लक्षित संसाधन और फ़ील्ड अनुमति सूची (allowlist) को पुन: अधिकृत करना चाहिए। होस्ट अनुमतियां ब्राउज़र क्षमता को सीमित करती हैं; वे किसी पेज को भरोसेमंद नहीं बनाती हैं और न ही किसी एक्सटेंशन को पढ़े गए डेटा को गलत बैकएंड पर भेजने से रोकती हैं।
लॉन्च से पहले, इंस्टॉल, अनुमति देने, अस्वीकार करने, रद्द करने, नेविगेशन के बाद activeTab समाप्ति, वैकल्पिक-होस्ट अनुरोध, अनुमति-बढ़ाने वाले अपडेट, रोलबैक, एंटरप्राइज़ नीति अक्षमता, असमर्थित ब्राउज़र और ऑफ़लाइन मोड के लिए एक मैट्रिक्स बनाएं। टेलीमेट्री को अनुमति कुंजी, होस्ट पैटर्न, परिणाम और संस्करण रिकॉर्ड करना चाहिए, कभी भी पेज टेक्स्ट नहीं।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं क्षमता और डेटा-प्रवाह मानचित्र के साथ शुरुआत करूँगा। चूंकि टूलबार कार्रवाई केवल वर्तमान पेज को प्रोसेस करती है, मुख्य डिज़ाइन सभी साइटों तक पहुंच के बिना activeTab, scripting और आवश्यक storage का उपयोग करता है। app.example.com के लिए केवल एक बैकग्राउंड सुविधा एक सटीक वैकल्पिक होस्ट अनुमति का उपयोग करेगी, जिसका अनुरोध तब किया जाएगा जब उपयोगकर्ता इसे ट्रिगर करेगा। मैं अनुरोध से पहले उद्देश्य और दायरे की व्याख्या करूँगा, अस्वीकृति के बाद मैनुअल चयन की पेशकश करूँगा, और प्रॉम्प्ट लूप से बचूँगा।
प्रत्येक कार्य से पहले मैं वर्तमान अनुमतियों की जांच करूँगा और निरस्तीकरण को सुनूँगा। यदि पहुंच समाप्त हो जाती है, तो पढ़ना बंद करें, आउटबाउंड कतार साफ़ करें, और बैकएंड से पहचान और संसाधन को फिर से अधिकृत करवाएं। एक अपडेट से पहले, API, होस्ट और कंटेंट-स्क्रिप्ट परिवर्तनों का अंतर निकालें, फिर अक्षमता, नवीनीकृत सहमति और रोलबैक का परीक्षण करें। अंत में, यह सत्यापित करने के लिए एक अनुमति मैट्रिक्स और अज्ञात टेलीमेट्री का उपयोग करें कि कोई बैकग्राउंड स्कैन नहीं है, कोई क्रॉस-होस्ट इंजेक्शन नहीं है, लॉग में कोई पेज टेक्स्ट नहीं है, और अस्वीकृति और निरस्तीकरण के लिए सुरक्षित डिग्रेडेशन है।"
सामान्य गलतियाँ
- डिफ़ॉल्ट रूप से
<all_urls>का अनुरोध करना → पढ़ने और इंजेक्शन के जोखिम को बढ़ाता है और चेतावनियों को बढ़ाता है →activeTabसे शुरू करें, फिर निरंतर सुविधाओं के लिए सटीक होस्ट का आकलन करें। optional_host_permissionsको स्वचालित सहमति मानना → घोषणा उपयोगकर्ता की स्वीकृति नहीं है → सुविधा के समय अनुरोध करें और अस्वीकृति को संभालें।- केवल इंस्टॉल के समय अनुमतियों की जांच करना → उपयोगकर्ता उन्हें बाद में रद्द कर सकते हैं → काम करने से पहले जांचें और हटाने की निगरानी करें।
- अपग्रेड पर केवल कोड परिवर्तनों की समीक्षा करना → नई अनुमतियां एक्सटेंशन को अक्षम कर सकती हैं → अनुमति सेट का अंतर (diff) निकालें और पिछले अनुदानों का परीक्षण करें।
- ब्राउज़र अनुमति को बैकएंड प्राधिकरण मानना → डेटा अभी भी गलत खाते में जा सकता है → सर्वर-साइड पहचान, संसाधन और फ़ील्ड को पुन: अधिकृत करें।
- सहमति कॉपी को API नामों से भरना → उपयोगकर्ता एक उपयोगी जोखिम मॉडल नहीं बना सकते हैं → उद्देश्य, दायरा और बाहर निकलने का तरीका बताएं।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: सीधे <all_urls> का अनुरोध क्यों नहीं करते?
एक बार की वर्तमान-पेज कार्रवाई के लिए प्रत्येक साइट पर बैकग्राउंड पहुंच की आवश्यकता नहीं होती है। activeTab उपयोगकर्ता कार्रवाई के बाद अस्थायी क्षमता प्रदान करता है और लंबे समय तक रहने वाले जोखिम को कम करता है; केवल एक स्पष्ट निरंतर क्रॉस-पेज आवश्यकता ही सटीक होस्ट पहुंच को सही ठहराती है।
फॉलो-अप 2: जब उपयोगकर्ता पहुंच रद्द कर देता है, तो पहले से अपलोड किए गए डेटा का क्या होगा?
निरस्तीकरण बाद में ब्राउज़र पहुंच को रोकता है लेकिन उस डेटा को वापस नहीं ला सकता जो डिवाइस को पहले ही छोड़ चुका है। बैकएंड पर न्यूनतम फ़ील्ड, संक्षिप्त अवधारण (short retention) और विलोपन नियंत्रणों का उपयोग करें; स्थानीय आउटबाउंड कतार साफ़ करें और उपयोगकर्ता को बताएं कि पहले से क्या प्रोसेसिंग हो चुकी है।
फॉलो-अप 3: वैकल्पिक अनुमति सफल होने के बाद बैकएंड पर पुन: अधिकृत क्यों करें?
ब्राउज़र अनुमति कहती है कि एक्सटेंशन एक पेज पढ़ सकता है, न कि यह कि उपयोगकर्ता व्यावसायिक संसाधन तक पहुंच सकता है। बैकएंड को सत्र, एक्सटेंशन संस्करण, लक्षित संसाधन और फ़ील्ड अनुमति सूची को मान्य करना चाहिए और पुराने या असामान्य अनुरोधों को अस्वीकार करना चाहिए।
फॉलो-अप 4: क्या Chrome और Firefox अनुमति व्यवहार को समान माना जा सकता है?
नहीं। वे WebExtensions अवधारणाओं को साझा करते हैं, लेकिन प्रॉम्प्ट, मैच पैटर्न और रनटाइम सीमाएं भिन्न हो सकती हैं। प्रत्येक लक्षित ब्राउज़र पर इंस्टॉल, अनुरोध, निरस्तीकरण, नेविगेशन और अपग्रेड का परीक्षण करें और अंतरों को एक अनुकूलता (compatibility) मैट्रिक्स में रखें।