Google Chrome एक्सटेंशन के लिए आगामी मेनिफेस्ट V3 क्रोम पर विज्ञापन अवरोधकों के काम करने के तरीके को बदल देगा। क्या यह विज्ञापन अवरोधकों और Google के लिए आगे बढ़ने का सही तरीका है?
गूगल क्रोम इस समय बाज़ार में उपलब्ध सबसे लोकप्रिय क्रॉस-प्लेटफ़ॉर्म वेब ब्राउज़र है, वैश्विक ब्राउज़र उपयोग हिस्सेदारी में 62.7% का दावा मई 2019 तक, Apple की Safari 15.89% के साथ दूसरे स्थान पर रही और मोज़िला का फ़ायरफ़ॉक्स 5.07% का दावा करता रहा। अपने बड़े हिस्से के कारण, Google Chrome अपने प्लेटफ़ॉर्म के लिए जो छोटे-छोटे बदलाव करता है, वे दुनिया भर के लाखों उपयोगकर्ताओं को प्रभावित करते हैं। इसलिए जब Google ने Google Chrome एक्सटेंशन के लिए मेनिफेस्ट V3 के रूप में अगले एक्सटेंशन मैनिफ़ेस्ट संस्करण की घोषणा की, तो हमें पता चल गया था कुछ बड़े बदलाव होने वाले थे, खासकर जब यह पता चला कि Google क्रोम के भीतर एक सामग्री अवरोधक एपीआई का निर्माण कर रहा था अपने आप।
मेनिफेस्ट V3 क्या है?
यदि आप एक सक्रिय क्रोम उपयोगकर्ता हैं, तो आप निस्संदेह कुछ एक्सटेंशन का उपयोग करते हैं। एक्सटेंशन छोटे सॉफ़्टवेयर प्रोग्राम होते हैं जो ब्राउज़िंग अनुभव को अनुकूलित करते हैं
तब से पिछले साल के अंत में, Google "मैनिफ़ेस्ट V3" पर काम कर रहा है, जो क्रोम एक्सटेंशन प्लेटफ़ॉर्म में प्रस्तावित परिवर्तनों का एक सेट है जिसे "ब्रेकिंग परिवर्तन" के रूप में वर्गीकृत किया जा सकता है। के रूप में मेनिफेस्ट V3 के लिए सार्वजनिक चर्चा दस्तावेज़ बताता है, एक्सटेंशन मेनिफेस्ट संस्करण कुछ क्षमताओं को एक्सटेंशन के एक निश्चित वर्ग तक सीमित करने के लिए एक तंत्र है। ये प्रतिबंध न्यूनतम संस्करण या अधिकतम संस्करण के रूप में हो सकते हैं। न्यूनतम संस्करण तक सीमित करने से नए एपीआई या क्षमताएं केवल नए एक्सटेंशन के लिए ही उपलब्ध हो पाती हैं जबकि अधिकतम प्रकट संस्करण तक सीमित होने से पुराने एपीआई या क्षमताओं को धीरे-धीरे अनुमति मिलती है बहिष्कृत
सरल शब्दों में, एक नया मेनिफेस्ट संस्करण क्रोम को इस नए मेनिफेस्ट संस्करण में एपीआई और सुविधाओं को प्रतिबंधित करने की अनुमति देता है उपयोगकर्ता पर उनके नकारात्मक प्रभाव के कारण एक्सटेंशन डेवलपर्स को कुछ पुराने एपीआई से दूर जाने के लिए मजबूर करने का आदेश दिया गया है अनुभव। मेनिफेस्ट V3 में एक्सटेंशन लागू करने से सैद्धांतिक रूप से सुरक्षा, गोपनीयता और प्रदर्शन के दृष्टिकोण से मजबूत गारंटी मिलनी चाहिए।
जबकि मेनिफेस्ट V3 में परिवर्तनों की एक विस्तृत श्रृंखला उल्लिखित है, सबसे विवादास्पद परिवर्तन मौजूदा में मौजूद अवरोधन क्षमताओं को सीमित करने के Google के निर्णय से संबंधित है। chrome.webRequest एपीआई (और एपीआई को ब्लॉक करने के बजाय अवलोकन पर केंद्रित करें) और फिर इन ब्लॉकिंग क्षमताओं को एक नए के माध्यम से प्रस्तुत करें chrome.declarativeNetRequest एपीआई. यह विशेष परिवर्तन हुआ है समुदाय को भड़काया चूँकि यह प्रसिद्ध विज्ञापन-अवरोधक एक्सटेंशन के विज्ञापन-अवरोधक तंत्र को लक्षित करता है, यूब्लॉक उत्पत्ति, और सीधे तौर पर इसके 10 मिलियन+ उपयोगकर्ताओं को प्रभावित करता है।
इससे पहले कि हम इस मुद्दे पर विचार करें, आइए एक नजर डालते हैं कि कैसे वेब अनुरोध एपीआई की तुलना की जाती है घोषणात्मकनेट अनुरोध एपीआई.
वेब अनुरोध एपीआई और घोषणात्मक नेट अनुरोध एपीआई
वर्तमान
वेब रिक्वेस्ट का आधिकारिक विवरण एपीआई का वर्णन इस प्रकार करता है:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
वेब अनुरोध के साथ, Chrome भेजता है सभी किसी नेटवर्क में डेटा उसे सुनने वाले एक्सटेंशन के लिए अनुरोध करता है। इसके बाद एक्सटेंशन के पास अनुरोध का मूल्यांकन करने और क्रोम को निर्देश देने का मौका होता है कि अनुरोध के साथ क्या करना है: इसे अनुमति दें, इसे ब्लॉक करें, या इसे कुछ संशोधनों के साथ भेजें।
यह समझने के लिए कि जब एक्सटेंशन वेब अनुरोध एपीआई का उपयोग करते हैं तो क्या हो रहा है, घटनाओं के अनुक्रम का अनुसरण करें। जब वेब रिक्वेस्ट एक्सटेंशन वाला कोई उपयोगकर्ता किसी लिंक पर क्लिक करता है, तो क्रोम एक्सटेंशन को सूचित करता है कि अनुरोध सर्वर तक पहुंचने से पहले डेटा अनुरोध किया गया है। एक्सटेंशन इस चरण में अनुरोध को संशोधित करना चुन सकता है। सर्वर तब प्रतिक्रिया देता है, लेकिन प्रतिक्रिया एक बार फिर एक्सटेंशन के माध्यम से जाती है, और एक्सटेंशन यह तय कर सकता है कि प्रतिक्रिया को संशोधित करने की आवश्यकता है या नहीं। क्रोम अंततः पेज को प्रस्तुत करता है और उपयोगकर्ता अपनी क्लिक कार्रवाई का परिणाम देख पाता है।
जैसे ही क्रोम सौंपता है नेटवर्क अनुरोध में सभी डेटा, वेब अनुरोध एपीआई का उपयोग करने वाले एक्सटेंशन के पास उपयोगकर्ता द्वारा वेब पर किए जाने वाले सभी कार्यों को पढ़ने और संशोधित करने की पहुंच होती है। इसलिए जबकि यूब्लॉक ओरिजिन जैसे सामग्री अवरोधक इस एपीआई की क्षमता का बुद्धिमानी से उपयोग करते हैं, Google ऐसा दावा करता है दुर्भावनापूर्ण इरादों वाले अन्य एक्सटेंशन ने उपयोगकर्ताओं की व्यक्तिगत पहुंच हासिल करने के लिए इसका दुरुपयोग किया है जानकारी। Google के अनुसार, जनवरी 2018 से 42% दुर्भावनापूर्ण एक्सटेंशन ने वेब रिक्वेस्ट एपीआई का उपयोग किया है। Google का यह भी दावा है कि अवरोधक संस्करण के रूप में एपीआई के साथ "महत्वपूर्ण प्रदर्शन लागत" शामिल हैं इसके लिए लगातार और अक्सर लंबे समय तक चलने वाली प्रक्रिया की आवश्यकता होती है जो मूल रूप से 'आलसी' के साथ असंगत है प्रक्रियाएँ।
मेनिफेस्ट V3 के साथ, Google इस API को इसके ब्लॉकिंग फॉर्म में सीमित करने का प्रस्ताव कर रहा है। एक विकल्प के रूप में, Google डिक्लेरेटिव नेट रिक्वेस्ट एपीआई प्रदान कर रहा है।
भविष्य
डिक्लेरेटिव नेट रिक्वेस्ट का आधिकारिक विवरण एपीआई का वर्णन इस प्रकार करता है:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
डिक्लेरेटिव नेट रिक्वेस्ट के साथ, क्रोम को लिसनिंग एक्सटेंशन को अनुरोध के बारे में सारी जानकारी भेजने की आवश्यकता नहीं है। इसके बजाय, एक्सटेंशन क्रोम के साथ नियमों को पंजीकृत करता है जो ब्राउज़र को पहले से बताता है कि यदि कुछ प्रकार के अनुरोध दिखाई देते हैं तो क्या करना है।
एक्सटेंशन अपने नियमों को पहले से निर्दिष्ट करता है। फिर उपयोगकर्ताओं के अनुरोध को ब्राउज़र द्वारा इस नियम के विरुद्ध मिलान किया जाता है (और एक्सटेंशन नहीं), और कार्रवाई भी ब्राउज़र द्वारा की जाती है, और पृष्ठ को बाद में प्रस्तुत किया जाता है। Google का उल्लेख है कि यह उन्हें दक्षता सुनिश्चित करने की अनुमति देता है क्योंकि वे परिणाम निर्धारित करने वाले एल्गोरिदम पर नियंत्रण रख सकते हैं और अक्षम नियमों को रोक या अक्षम कर सकते हैं। यह अंतिम उपयोगकर्ता को बेहतर गोपनीयता गारंटी भी प्रदान करता है क्योंकि नेटवर्क अनुरोध का विवरण एक्सटेंशन के संपर्क में नहीं आता है। चूंकि लगातार और लंबे समय तक चलने वाली प्रक्रियाएं अब आवश्यक नहीं हैं (क्योंकि नियम पहले से पंजीकृत हैं), Google ऐसा दावा करता है यह दृष्टिकोण प्रदर्शन में सुधार भी लाता है जो संसाधन-बाधित होने पर एक्सटेंशन को काफी अधिक व्यवहार्य बना देगा प्लेटफार्म.
घोषणात्मक नेट अनुरोध मेनिफेस्ट V2 (वर्तमान) और मेनिफेस्ट V3 दोनों के लिए उपलब्ध होगा, लेकिन यह प्राथमिक तरीका होगा जिससे Google नेटवर्क अनुरोधों को मेनिफेस्ट V3 में संशोधित करने की अनुमति देगा।
विवाद
Google के परिवर्तन तब तक समझ में आते हैं जब तक आप कहानी का दूसरा पक्ष नहीं सुनते, मुख्य रूप से विज्ञापन अवरोधकों का। इस विशेष एपीआई माइग्रेशन को विज्ञापन अवरोधकों को ख़त्म करने के Google के तरीके के रूप में देखा जा रहा है क्योंकि यह सबसे लोकप्रिय विज्ञापन अवरोधकों में से एक के काम करने के तरीके को मौलिक रूप से बदल देता है। यह इस "सिद्धांत" से जुड़ा है कि Google इस परिवर्तन के लिए उपयोगकर्ता सुरक्षा के दृष्टिकोण से अधिक व्यावसायिक दृष्टिकोण से प्रेरित है। आख़िरकार, Google अपने राजस्व के लिए विज्ञापन पर बहुत अधिक निर्भर है, और विज्ञापन अवरोधकों को इस मोर्चे पर Google के ग्राहकों के लिए सीधा ख़तरा माना जाता है, जैसा कि इसके माध्यम से पता चला था अल्फाबेट की 2018 एसईसी फॉर्म 10-के फाइलिंग (के जरिए रजिस्टर):
नई और मौजूदा प्रौद्योगिकियां विज्ञापनों को अनुकूलित करने की हमारी क्षमता को प्रभावित कर सकती हैं और/या विज्ञापनों को ऑनलाइन ब्लॉक कर सकती हैं, जिससे हमारे व्यवसाय को नुकसान होगा।
अनुकूलन योग्य विज्ञापनों को अधिक कठिन बनाने या विज्ञापनों के प्रदर्शन को पूरी तरह से और कुछ प्रदाताओं को अवरुद्ध करने के लिए तकनीकें विकसित की गई हैं ऑनलाइन सेवाओं में एकीकृत प्रौद्योगिकियाँ हैं जो संभावित रूप से तृतीय-पक्ष डिजिटल की मुख्य कार्यक्षमता को ख़राब कर सकती हैं विज्ञापन देना। हमारा अधिकांश Google राजस्व ऑनलाइन विज्ञापनों के प्रदर्शन के संबंध में हमें भुगतान की गई फीस से प्राप्त होता है। परिणामस्वरूप, ऐसी प्रौद्योगिकियाँ और उपकरण हमारे परिचालन परिणामों पर प्रतिकूल प्रभाव डाल सकते हैं।
गूगल को करना पड़ा एक बयान जारी करें इसे संबोधित करने के लिए, अपने रुख को दोहराते हुए कि परिवर्तन उपयोगकर्ता की गोपनीयता के हित में है और विज्ञापन अवरोधकों के खिलाफ सीधा हमला नहीं है:
हम विज्ञापन अवरोधकों के विकास को नहीं रोक रहे हैं या उपयोगकर्ताओं को विज्ञापनों को अवरुद्ध करने से नहीं रोक रहे हैं। इसके बजाय, हम कंटेंट ब्लॉकर्स सहित डेवलपर्स को इस तरह से एक्सटेंशन लिखने में मदद करना चाहते हैं जो उपयोगकर्ताओं की गोपनीयता की रक्षा करे।
Google Chrome पर उपलब्ध दो सबसे लोकप्रिय विज्ञापन-अवरोधकों का संदर्भ देना आवश्यक है: यूब्लॉक उत्पत्ति और ऐडब्लॉक प्लस, दोनों ही सामग्री अवरोधन के समान परिणाम प्राप्त करने के लिए अलग-अलग दृष्टिकोण अपनाते हैं। यूब्लॉक ओरिजिन वेब रिक्वेस्ट एपीआई पर बहुत अधिक निर्भर करता है, और समुदाय ने वर्षों से इस एक्सटेंशन को प्राथमिकता दी है। एडब्लॉक प्लस और अन्य कंटेंट ब्लॉकिंग एक्सटेंशन भी वेब रिक्वेस्ट के ब्लॉकिंग हिस्से पर निर्भर करते हैं, इसलिए इस एपीआई में बदलाव से कम से कम कुछ क्षमता में अधिकांश कंटेंट ब्लॉकर्स प्रभावित होंगे।
वेब अनुरोध को अस्वीकार करने के लिए Google का दबाव अनिवार्य रूप से यूब्लॉक ओरिजिन को उसके वर्तमान प्रारूप में समाप्त कर देगा, कुछ ऐसा जो वास्तव में बहुत सारे उपयोगकर्ताओं को प्रभावित करेगा। जबकि जिन उपयोगकर्ताओं के पास कोई निष्ठा नहीं है (और विज्ञापन ब्लॉक कैसे प्राप्त किया जाता है इसके बारे में खुद को परेशान करने का कोई इरादा नहीं है) वे वैकल्पिक समाधान ढूंढेंगे जो उनकी अपनी कमियों के साथ आते हैं, यह असंभव हो जाएगा वफादारों और उत्साही लोगों के लिए विभिन्न तकनीकों को दरकिनार करने के लिए नए फ़िल्टरिंग इंजन डिज़ाइन के साथ आना, जो वेब साइटें अंततः इस विशिष्ट एपीआई पर विज्ञापन अवरोधकों से निपटने के लिए लेकर आएंगी।
डिक्लेरेटिव नेट रिक्वेस्ट को एक सीमित फ़िल्टरिंग इंजन के रूप में भी प्रस्तावित किया गया था, जैसा कि यह था प्रारंभ में योजना बनाई गई प्रति-एक्सटेंशन स्थिर फ़िल्टर नियमों (स्थापना के दौरान घोषित किए गए नियम) पर 30,000 नियम सीमा रखना; और प्रति-एक्सटेंशन डायनेमिक फ़िल्टर नियमों पर 5,000 नियम सीमा (ऐसे नियम जिन्हें इंस्टॉलेशन के बाद जोड़ा जा सकता है)। किसी भी अतिरिक्त नियम को नजरअंदाज कर दिया जाएगा, जो थोड़ी समस्या है क्योंकि एडब्लॉक प्लस के लिए ईज़ीलिस्ट में स्वयं 70,000 नियम हैं, जबकि यूब्लॉक ओरिजिन को 100,000 से अधिक नियमों के साथ चलाने के लिए कॉन्फ़िगर किया जा सकता है। समुदाय के शुरुआती विरोध के बाद, गूगल ने जवाब दिया स्थिर नियम सीमा को 30,000 नियम प्रति-एक्सटेंशन से बदलकर वैश्विक अधिकतम 150,000 नियम करने का वादा करके। इसके बाद उपयोगकर्ताओं को विज्ञापन अवरोधक के साथ अन्य नियम-भारी स्क्रिप्ट का उपयोग करने से रोकने का दुष्प्रभाव होता है, इसलिए उपयोगकर्ताओं को अपनी प्राथमिकताओं के साथ इधर-उधर घूमना होगा।
सीमित फ़िल्टरिंग सीमा के अलावा, घोषणात्मक नेट अनुरोध केवल स्थिर यूआरएल पर रीडायरेक्ट कर सकते हैं, इसलिए पैटर्न मिलान के लिए कोई समर्थन शामिल नहीं है। यूब्लॉक ओरिजिन काफी हद तक पैटर्न मिलान और एक्सटेंशन डेवलपर पर निर्भर करता है कहा कि दोबारा लगाना संभव नहीं है एपीआई आवश्यकता को पूरा करने के लिए उसके एक्सटेंशन का मिलान एल्गोरिदम। एपीआई को केवल फ़िल्टर सूची को अपडेट करने के लिए एक पूर्ण एक्सटेंशन अपडेट की भी आवश्यकता होगी, जिसे देखते हुए यह बहुत अधिक बार होने वाली गतिविधि होगी वह आवृत्ति जिसके साथ ये फ़िल्टर सूचियाँ अद्यतन की जाती हैं. बेशक, ये अपडेट Google के विस्तार समीक्षा मानदंडों और प्रक्रियाओं पर भी निर्भर होंगे।
दूसरी ओर, Google ने हमेशा अपना रुख बनाए रखा है कि वेब अनुरोध से दूर जाने का उसका इरादा है सुरक्षा परिप्रेक्ष्य, क्योंकि वेब अनुरोध एपीआई अपने वर्तमान स्वरूप में बहुत शक्तिशाली है और इसके लिए बहुत विस्तृत जगह छोड़ता है दुर्व्यवहार करना। यह दुरुपयोग केवल सैद्धांतिक नहीं है, क्योंकि Google ने उल्लेख किया है कि 42% दुर्भावनापूर्ण एक्सटेंशन ने इस एपीआई का दुरुपयोग किया है। एप्पल सफारी सामग्री अवरोधक एपीआई समान कारणों से डिक्लेरेटिव नेट रिक्वेस्ट की तरह डिज़ाइन किया गया था, क्योंकि इसमें दुष्ट डेवलपर के शोषण के लिए कम जगह होती है। कमज़ोर वेब अनुरोध पर, नेटवर्क अनुरोध अभी भी देखे जा सकेंगे, लेकिन उन्हें संबंधित होस्ट पर अनुमति की आवश्यकता होगी। मेनिफेस्ट V3 के साथ, होस्ट अनुमतियाँ भी महत्वपूर्ण रूप से बदल रही हैं और उन्हें अब इंस्टॉल समय पर व्यापक तरीके से प्रदान नहीं किया जा सकता है।
Google ने स्विच के लिए प्रेरक के रूप में प्रदर्शन ओवरहेड्स का भी उपयोग किया है। नेटवर्क अनुरोधों का मूल्यांकन एक्सटेंशन के जावास्क्रिप्ट थ्रेड में होता है, जो प्रदर्शन पर महंगा हो सकता है। खंडन के रूप में, यूब्लॉक ओरिजिन के डेवलपर ने अपने एक्सटेंशन का उल्लेख किया है कोई महत्वपूर्ण प्रदर्शन जुर्माना नहीं लगता है लागू करने के लिए 140,000 से अधिक स्थिर फ़िल्टर होने पर भी। दावा किया जाता है कि खर्च की गई लागत उन संसाधनों द्वारा आसानी से वसूल की जाती है जिन्हें दूरस्थ सर्वर से डाउनलोड होने से रोका जाता है और इस प्रकार ब्राउज़र द्वारा संसाधित नहीं किया जाता है।
भले ही Google इस तर्क का उपयोग नहीं करता है, वेब अनुरोध के विरुद्ध एक तर्क विज्ञापन अवरोधन की दक्षता के लिए भी दिया जा सकता है। वेब अनुरोध के साथ, यदि कोई एक्सटेंशन समय पर प्रतिक्रिया नहीं देता है (अंतराल या क्रैश के कारण), तो नेटवर्क हैंडलिंग अनुरोध को स्पष्ट रूप से अनुमति दी जाती है, जो विज्ञापनों को विज्ञापन अवरोधक के माध्यम से फिसलने देता है। दूसरी ओर, घोषणात्मक नेट अनुरोध इस कमी से ग्रस्त नहीं होगा। इसके बजाय, यदि विज्ञापन स्थिर नियमों के दायरे में नहीं आते हैं तो वे पारित हो जाएंगे, और ऐसा अक्सर होगा।
निष्कर्ष
उपरोक्त स्पष्टीकरण से, यह स्पष्ट है कि डिक्लेरेटिव नेट रिक्वेस्ट ब्लॉकिंग के लिए 1:1 कार्यक्षमता क्लोन नहीं है वेब रिक्वेस्ट एपीआई की क्षमताओं और एक्सटेंशन डेवलपर्स का नाराज होना लाजिमी है जब उनकी मेहनत खराब हो जाएगी ऐसे परिवर्तन. लेकिन Google के तर्क में भी वजन है - वेब अनुरोध बहुत शक्तिशाली है, और इसकी शक्तियों की आवश्यकता है उपयोगकर्ता समुदाय (जिसमें औसत उपयोगकर्ता भी शामिल हैं) के व्यापक हित में कटौती की गई है उत्साही)।
डिक्लेरेटिव नेट रिक्वेस्ट की ओर कदम एक सकारात्मक पीआर कदम भी हो सकता था - आखिरकार, Google क्रोम में एक अंतर्निहित सामग्री अवरोधक एपीआई जोड़ रहा है! लेकिन चूंकि नया एपीआई अपने स्वयं के भारी प्रतिबंधों के साथ आता है, समुदाय इसे अपने पंखों की कतरन के रूप में देखता है। एक आदर्श दुनिया में, Google को नए एपीआई को आगे बढ़ाने से पहले यूब्लॉक ओरिजिन जैसे विज्ञापन अवरोधकों की कार्यप्रणाली का पता लगाना चाहिए था। जैसा कि अभी है, नया एपीआई उन परिदृश्यों को समायोजित करने के लिए अपनी नियम सीमाओं पर और छूट का उपयोग कर सकता है जहां उपयोगकर्ता दो फ़िल्टर-भारी एक्सटेंशन का उपयोग करना चाहेंगे।
के अनुसार रजिस्टर, मेनिफेस्ट V3 परिवर्तनों के साथ पहला बिल्ड जुलाई 2019 से उपलब्ध होगा। हमें उम्मीद है कि Google इन बिल्डों के साथ एक्सटेंशन डेवलपर समुदाय से प्राप्त फीडबैक को समायोजित करेगा।
XDA के प्रधान संपादक मिशाल रहमान को उनके इनपुट और सहायता के लिए विशेष धन्यवाद!
संपादित करें: लेख में गलत तरीके से एडब्लॉक प्लस की कार्यप्रणाली को डिक्लेरेटिव नेट रिक्वेस्ट एपीआई के बराबर बताया गया है। लेख को तदनुसार संशोधित किया गया है। वेब रिक्वेस्ट एपीआई की ब्लॉकिंग क्षमताओं को हटाने से एडब्लॉक प्लस भी प्रभावित होगा।