पिछले एक साल से, हम कॉन्टेंट ब्लॉक करने वाले कई एक्सटेंशन के वेंडर के साथ, MV3 एक्सटेंशन प्लैटफ़ॉर्म को बेहतर बनाने के तरीकों के बारे में लगातार बातचीत कर रहे हैं. इन बातचीत के आधार पर, हमने इस सुविधा में कई अहम सुधार किए हैं. इनमें से ज़्यादातर बातचीत, दूसरे ब्राउज़र के साथ मिलकर WebExtensions कम्यूनिटी ग्रुप (WECG) में हुई थीं.
ज़्यादा स्टैटिक नियम
फ़िल्टर नियमों के सेट को आम तौर पर सूचियों में बांटा जाता है. उदाहरण के लिए, सामान्य सूची में सभी उपयोगकर्ताओं पर लागू होने वाले नियम हो सकते हैं. वहीं, खास सूची में जगह के हिसाब से ऐसा कॉन्टेंट छिपाया जा सकता है जिसे सिर्फ़ कुछ उपयोगकर्ता ब्लॉक करना चाहते हैं. हाल ही तक, हमने हर एक्सटेंशन को उपयोगकर्ताओं को 50 सूचियां (या “स्टैटिक नियमों की सूचियां”) चुनने की अनुमति दी थी. साथ ही, इनमें से 10 सूचियों को एक साथ चालू करने की अनुमति दी थी. कम्यूनिटी के साथ हुई बातचीत में, एक्सटेंशन डेवलपर ने इस बात के पुख्ता सबूत दिए कि कुछ खास इस्तेमाल के उदाहरणों के लिए यह सीमा बहुत कम है. इन बातों को ध्यान में रखते हुए, Chrome में एपीआई की परफ़ॉर्मेंस की समीक्षा करने के बाद, हम अब एक साथ 50 एपीआई चालू करने की अनुमति दे रहे हैं. ध्यान दें, यह संख्या WECG में अनुरोध की गई 20 की सीमा से काफ़ी ज़्यादा है. हम कुल 100 नियमों की अनुमति भी देते हैं. यह सुविधा Chrome 120 में उपलब्ध है. साथ ही, Firefox और Safari, दोनों में सीमाएं बढ़ाने की सुविधा काम करती है. दोनों ने इस प्रस्ताव पर शुरुआती इनपुट दिया था.
ज़्यादा डाइनैमिक नियम
ज़्यादातर नियम “स्टैटिक” होते हैं और एक्सटेंशन के हर अपडेट के साथ शिप होते हैं. हालांकि, ज़्यादा बार अपडेट करने और उपयोगकर्ता के तय किए गए नियमों के साथ काम करने के लिए, एक्सटेंशन डाइनैमिक तौर पर भी नियम जोड़ सकते हैं. इसके लिए, डेवलपर को Chrome Web Store पर एक्सटेंशन का नया वर्शन अपलोड करने की ज़रूरत नहीं होती.
जब कोई एक्सटेंशन, अनुरोधों में डाइनैमिक तौर पर ऐसे बदलाव कर सकता है जिनकी जांच Chrome वेब स्टोर की समीक्षा के दौरान नहीं की गई थी, तो इससे उपयोगकर्ताओं को फ़िशिंग या डेटा चोरी के जोखिम का सामना करना पड़ सकता है. उदाहरण के लिए, रीडायरेक्ट करने के नियम का गलत इस्तेमाल करके, सहमति के बिना अफ़िलिएट लिंक इंजेक्ट किए जा सकते हैं.
इसलिए, हमने एक्सटेंशन को सिर्फ़ 5,000 नियम जोड़ने की अनुमति दी है. इससे, इस सुविधा का कम से कम इस्तेमाल करने के लिए बढ़ावा मिला और हमें गलत इस्तेमाल का पता लगाने में आसानी हुई.
हालांकि, AdGuard और Adblock Plus जैसे एक्सटेंशन के डेवलपर ने अपना विश्लेषण किया और डेटा शेयर किया. इससे पता चला कि ज़्यादा सीमाओं की मदद से, ज़्यादा अप-टू-डेट नियम बनाए जा सकते हैं. साथ ही, ज़्यादा कस्टम सूचियों वाले उपयोगकर्ता, मेनिफ़ेस्ट V3 पर माइग्रेट कर सकते हैं. असल में, AdGuard ने बताया कि हर हफ़्ते लोकप्रिय सूचियों में 2,600 से ज़्यादा बदलाव किए जाते हैं. साथ ही, कस्टम फ़िल्टर सूचियों का इस्तेमाल करने वाले पांच प्रतिशत उपयोगकर्ताओं में से, चार में से एक उपयोगकर्ता के पास कुल 5,000 से ज़्यादा डाइनैमिक नियम होते हैं (सोर्स). AdGuard ने अपने एक्सटेंशन को मेनिफ़ेस्ट V3 पर माइग्रेट करने के लिए, इसे एक बड़ी चुनौती के तौर पर बताया है. हमें कॉन्टेंट ब्लॉक करने वाले अन्य टूल से भी इसी तरह का सुझाव मिला है.
हमने पाया है कि कुछ फ़िल्टर नियम, जैसे कि block या allow की कार्रवाई वाले नियम, ज़्यादा सुरक्षित हैं और इनका गलत इस्तेमाल होने की संभावना कम है. विज्ञापन ब्लॉक करने वाले ज़्यादातर फ़िल्टर नियम भी इनसे ही बनते हैं. इस आधार पर, मैंने वेब एक्सटेंशन कम्यूनिटी ग्रुप में एक ड्राफ़्ट तैयार किया और एक प्रस्ताव शेयर किया. इसमें उन नियमों के बारे में बताया गया है जिनमें कम जोखिम होता है और जिन्हें 30,000 तक एक्सटेंशन के लिए अनुमति दी जा सकती है. हम परफ़ॉर्मेंस में गिरावट से बचने के लिए, अब भी एक तय सीमा से ज़्यादा विज्ञापन नहीं दिखाते.
वेब एक्सटेंशन कम्यूनिटी ग्रुप ने इस प्रस्ताव का समर्थन किया था. इसलिए, हमने इसे लागू कर दिया है. Chrome 121 से, 30,000 नियमों की ज़्यादा सीमा, सुरक्षित डीएनआर नियमों पर लागू होती है. हम इन नियमों को block, allow, allowAllRequests या upgradeScheme की कार्रवाई वाले नियमों के तौर पर परिभाषित कर रहे हैं.
AdGuard के शेयर किए गए डेटा के मुताबिक, उनके 98 से 99 प्रतिशत नियमों को इस ज़्यादा सीमा का फ़ायदा मिलेगा. बाकी बचे नियम अब भी काम करते हैं और उन्हें मौजूदा सीमा के अंदर जोड़ा जा सकता है.
यह Chrome में MAX_NUMBER_OF_DYNAMIC_RULES कॉन्स्टेंट के तौर पर उपलब्ध है. अन्य सभी डाइनैमिक नेट अनुरोध नियमों के लिए, नियम की सीमा 5,000 पर बनी रहेगी.
नियमों के सेट का साइज़ कम होना
Chrome 118 में, हमने समुदाय के सुझाव के आधार पर, isUrlFilterCaseSensitive फ़ील्ड की डिफ़ॉल्ट वैल्यू को false में बदल दिया है. यह फ़ील्ड यह कंट्रोल करता है कि यूआरएल के हिसाब से फ़िल्टर करने वाला नियम, केस-सेंसिटिव है या नहीं. हमें पता चला है कि ज़्यादातर डेवलपर के एक्सटेंशन में, डिफ़ॉल्ट तौर पर कोई दूसरा नियम सेट होता है. इस वजह से, वैल्यू को कई बार सेट करना पड़ता था. इस बदलाव से, डेवलपर अपने नियमों के सेट के साइज़ को काफ़ी कम कर पाते हैं.
आगे क्या होगा?
हम declarativeNetRequest API में लगातार काम करते रहेंगे, ताकि हम ज़्यादा से ज़्यादा इस्तेमाल के उदाहरणों के साथ काम कर सकें. साथ ही, हम कम्यूनिटी के साथ मिलकर काम करना जारी रखेंगे. खास तौर पर, हम WECG के सदस्यों का धन्यवाद करना चाहते हैं. इनमें AdGuard भी शामिल है, जिसने इस काम के लिए ज़रूरी डेटा शेयर किया. साथ ही, हम उन सभी ब्राउज़र वेंडर का भी धन्यवाद करना चाहते हैं जिन्होंने इस एपीआई को डिज़ाइन करने में अहम भूमिका निभाई है.
हम अपनी सीमाओं की समीक्षा करते रहेंगे, ताकि ज़रूरत पड़ने पर उनमें बदलाव किया जा सके. इस काम में मदद करने के लिए, हम आने वाले समय में इस प्रोसेस के दौरान इकट्ठा किया गया कुछ डेटा शेयर करेंगे. इसके अलावा, हम कुछ और सुविधाएं जोड़ने पर काम कर रहे हैं. जैसे, रिस्पॉन्स हेडर से मैच करने की सुविधा. PDF व्यूअर एक्सटेंशन से हमें अक्सर यह अनुरोध मिलता है. हम सभी मामलों में, अपने काम के बारे में बताते रहेंगे. साथ ही, वेब एक्सटेंशन कम्यूनिटी ग्रुप का नियमित तौर पर इस्तेमाल करेंगे. इस ग्रुप में, हम अपने आइडिया के बारे में चर्चा करेंगे और यह तय करेंगे कि हमें आगे क्या करना है.