पिछले साल से, हम MV3 एक्सटेंशन प्लैटफ़ॉर्म को बेहतर बनाने के तरीकों पर, कॉन्टेंट ब्लॉक करने वाले कई एक्सटेंशन से जुड़े वेंडर के साथ बातचीत में सक्रिय रूप से शामिल रहे हैं. इन चर्चाओं के आधार पर, हमने अन्य ब्राउज़र के साथ Webएक्सटेंशन कम्यूनिटी ग्रुप (WECG) में काम किया. इस आधार पर, हम काफ़ी सुधार कर पाए हैं.
ज़्यादा स्टैटिक रूलसेट
आम तौर पर, फ़िल्टर के नियमों के सेट को सूचियों में शामिल किया जाता है. उदाहरण के लिए, हो सकता है कि ज़्यादा सामान्य सूची में सभी उपयोगकर्ताओं पर लागू होने वाले नियम हों, जबकि किसी खास सूची में, जगह के हिसाब से वह कॉन्टेंट छिपाया जा सकता है जिसे सिर्फ़ कुछ ही उपयोगकर्ता ब्लॉक करना चाहते हैं. हाल तक, हमने हर एक्सटेंशन को उपयोगकर्ताओं को 50 सूचियां (या “स्टैटिक नियम सेट”) चुनने का विकल्प दिया था और इनमें से 10 सूचियां एक साथ चालू की जा सकती थीं. कम्यूनिटी के साथ बातचीत के दौरान, एक्सटेंशन डेवलपर ने इस बात का ठोस सबूत दिया कि इस्तेमाल के कुछ मामलों में यह संख्या बहुत कम थी. इन चर्चाओं को ध्यान में रखते हुए, Chrome में एपीआई की परफ़ॉर्मेंस को देखने के बाद, अब हम एक साथ 50 एपीआई को चालू करने की अनुमति दे रहे हैं. (खास तौर पर, यह WECG में अनुरोध की गई 20 की सीमा से काफ़ी ज़्यादा है.) हम कुल 100 रूलसेट की भी अनुमति देते हैं. इसकी शिपिंग Chrome 120 में की जा रही है और इसकी सीमा बढ़ाने के लिए Firefox और Safari, दोनों ही इस प्रस्ताव पर शुरुआती जानकारी देंगे.
ज़्यादा डायनैमिक नियम
ज़्यादातर नियम "स्टैटिक" होते हैं और हर अपडेट के साथ एक्सटेंशन में भेजा जाता है. हालांकि, बार-बार होने वाले अपडेट और उपयोगकर्ता के तय किए गए नियमों को लागू करने के लिए, एक्सटेंशन डाइनैमिक तौर पर भी नियमों को जोड़ सकते हैं. इसके लिए, डेवलपर को 'Chrome वेब स्टोर' पर एक्सटेंशन का नया वर्शन अपलोड करने की ज़रूरत नहीं होती.
जब कोई एक्सटेंशन, अनुरोधों में डाइनैमिक तौर पर उन तरीकों से बदलाव कर सकता है जिनकी जांच Chrome Web Store की समीक्षा के दौरान नहीं किया गया था, तो इससे उपयोगकर्ताओं को फ़िशिंग या डेटा की चोरी के जोखिम का खतरा रहता है. उदाहरण के लिए, किसी रीडायरेक्ट नियम का गलत इस्तेमाल, बिना सहमति के अफ़िलिएट लिंक इंजेक्ट करने के लिए किया जा सकता है.
इसलिए, हमने सिर्फ़ एक्सटेंशन को ज़्यादा से ज़्यादा 5,000 नियमों को जोड़ने की अनुमति दी. इन नियमों ने इस सुविधा के इस्तेमाल को सीमित तौर पर बढ़ावा दिया और गलत इस्तेमाल का पता लगाना आसान बना दिया.
हालांकि, AdGuard और Adblock Plus जैसे एक्सटेंशन के डेवलपर ने अपना विश्लेषण किया और डेटा शेयर किया. इसकी सीमा ज़्यादा होने पर, ज़्यादा अप-टू-डेट नियम और ज़्यादा कस्टम सूचियों वाले उपयोगकर्ताओं को मेनिफ़ेस्ट V3 पर माइग्रेट किया जा सकता है. असल में, AdGuard ने रिपोर्ट किया कि हर हफ़्ते लोकप्रिय सूचियों में 2600 से ज़्यादा बदलाव किए जाते हैं और कस्टम फ़िल्टर सूचियों का इस्तेमाल करने वाले पांच प्रतिशत उपयोगकर्ताओं में से, इन चार उपयोगकर्ताओं में से एक के पास कुल 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 व्यूअर एक्सटेंशन से अनुरोध किया जाता है. सभी मामलों में, हम लोगों को अपने काम के बारे में बताते रहेंगे. साथ ही, नियमित तौर पर वेब एक्सटेंशन कम्यूनिटी ग्रुप का इस्तेमाल करके, अलग-अलग आइडिया पर चर्चा करेंगे और तय करेंगे कि आगे हमें किन विषयों पर ध्यान देना है.