Google विज्ञापन अवरोधकों द्वारा उपयोग किए जाने वाले WebRequest API के प्रतिबंध को उचित ठहराता है

क्रोम ब्राउज़र डेवलपर्स करने की कोशिश की औचित्य WebRequest API के संचालन के ब्लॉकिंग मोड के लिए समर्थन को बंद करना, जो आपको तुरंत प्राप्त सामग्री को बदलने की अनुमति देता है और विज्ञापनों को ब्लॉक करने के लिए ऐड-ऑन में सक्रिय रूप से उपयोग किया जाता है,
मैलवेयर, फ़िशिंग, उपयोगकर्ता गतिविधि पर जासूसी, माता-पिता के नियंत्रण और गोपनीयता से सुरक्षा।

Google का उद्देश्य:

• एपीआई ब्लॉकिंग मोड वेब अनुरोध उच्च संसाधन खपत की ओर ले जाता है।
  इस एपीआई का उपयोग करते समय, ब्राउज़र पहले नेटवर्क अनुरोध में निहित सभी डेटा को ऐड-ऑन भेजता है, ऐड-ऑन इसका विश्लेषण करता है और ब्राउज़र में आगे की प्रक्रिया के लिए एक संशोधित संस्करण लौटाता है या ब्लॉकिंग निर्देश जारी करता है। इस मामले में, मुख्य देरी ऐड-ऑन द्वारा ट्रैफ़िक को संसाधित करने के चरण में नहीं, बल्कि ऐड-ऑन के निष्पादन के समन्वय की ओवरहेड लागत के कारण उत्पन्न होती है। विशेष रूप से, इस तरह के हेरफेर के लिए पूरक के लिए एक अलग प्रक्रिया के लॉन्च की आवश्यकता होती है, साथ ही इस प्रक्रिया और डेटा क्रमांकन तंत्र के साथ बातचीत करने के लिए आईपीसी का उपयोग भी होता है;

• ऐड-ऑन निम्न स्तर पर सभी ट्रैफ़िक को पूरी तरह से नियंत्रित करता है, जो दुरुपयोग और गोपनीयता उल्लंघन के लिए व्यापक अवसर खोलता है। Google आंकड़ों के अनुसार, सभी पाए गए दुर्भावनापूर्ण ऐड-ऑन में से 42% ने webRequest API का उपयोग किया। यह ध्यान दिया गया है कि हर महीने, क्रोम वेब स्टोर कैटलॉग में औसतन 1800 दुर्भावनापूर्ण ऐड-ऑन रखने के प्रयासों को अवरुद्ध कर दिया जाता है। दुर्भाग्य से, समीक्षा करने से हमें बिना किसी अपवाद के सभी दुर्भावनापूर्ण ऐड-ऑन को पकड़ने की अनुमति नहीं मिलती है, इसलिए सुरक्षा बढ़ाने के लिए, एपीआई स्तर पर ऐड-ऑन को सीमित करने का निर्णय लिया गया। मुख्य विचार ऐड-ऑन को सभी ट्रैफ़िक तक पहुंच प्रदान करना नहीं है, बल्कि केवल उस डेटा तक पहुंच प्रदान करना है जो इच्छित कार्यक्षमता को लागू करने के लिए आवश्यक है। विशेष रूप से, सामग्री को ब्लॉक करने के लिए, ऐड-ऑन को सभी गोपनीय उपयोगकर्ता डेटा तक पूर्ण पहुंच देना आवश्यक नहीं है;
• प्रस्तावित प्रतिस्थापन घोषणात्मक एपीआई declarativeNetRequest उच्च-प्रदर्शन सामग्री फ़िल्टरिंग के सभी कार्यों का ध्यान रखता है और फ़िल्टरिंग नियमों को लोड करने के लिए केवल ऐड-ऑन की आवश्यकता होती है। ऐड-ऑन ट्रैफ़िक में हस्तक्षेप नहीं कर सकता है और उपयोगकर्ता का निजी डेटा अनुलंघनीय रहता है;
• Google ने घोषणात्मकNetRequest API की कार्यक्षमता की कमी के संबंध में कई टिप्पणियों को ध्यान में रखा और फ़िल्टरिंग नियमों की संख्या पर सीमा को शुरू में प्रस्तावित 30 हजार प्रति एक्सटेंशन से बढ़ाकर वैश्विक अधिकतम 150 हजार कर दिया, और गतिशील रूप से करने की क्षमता भी जोड़ी। नियम बदलें और जोड़ें, HTTP हेडर (रेफ़रर, कुकी, सेट-कुकी) हटाएं और बदलें और पैरामीटर का अनुरोध करें;
• उद्यमों के लिए, वेबरिक्वेस्ट एपीआई के संचालन के ब्लॉकिंग मोड का उपयोग करना संभव है, क्योंकि ऐड-ऑन का उपयोग करने की नीति एक प्रशासक द्वारा निर्धारित की जाती है जो बुनियादी ढांचे की विशेषताओं को समझता है और जोखिमों से अवगत है। उदाहरण के लिए, निर्दिष्ट एपीआई का उपयोग उद्यमों में कर्मचारी यातायात प्रवाह को रिकॉर्ड करने और आंतरिक प्रणालियों के साथ एकीकृत करने के लिए किया जा सकता है;
• Google का लक्ष्य विज्ञापन अवरोधक ऐड-ऑन को कमज़ोर करना या दबाना नहीं है, बल्कि सुरक्षित और अधिक शक्तिशाली विज्ञापन अवरोधकों के निर्माण को सक्षम करना है;
• नए डिक्लेरेटिव नेट रिक्वेस्ट के साथ वेब रिक्वेस्ट एपीआई के संचालन के ब्लॉकिंग मोड को छोड़ने की अनिच्छा को गोपनीय डेटा तक ऐड-ऑन की पहुंच को सीमित करने की इच्छा से समझाया गया है। यदि आप webRequest API को वैसे ही छोड़ देते हैं, तो अधिकांश ऐडऑन अधिक सुरक्षित डिक्लेरेटिवNetRequest का उपयोग नहीं करेंगे, क्योंकि सुरक्षा और कार्यक्षमता के बीच चयन करते समय, अधिकांश डेवलपर्स आमतौर पर कार्यक्षमता का चयन करेंगे।

आपत्तियां डेवलपर्स अतिरिक्त:

• ऐड-ऑन डेवलपर्स द्वारा संचालित परीक्षण विज्ञापन ब्लॉकिंग ऐड-ऑन के प्रदर्शन पर एक नगण्य समग्र प्रभाव दिखाएं (परीक्षण के दौरान, विभिन्न ऐड-ऑन के प्रदर्शन की तुलना की गई थी, लेकिन एक अतिरिक्त प्रक्रिया के ओवरहेड को ध्यान में रखे बिना जो ब्लॉकिंग मोड में हैंडलर के निष्पादन का समन्वय करता है) वेबरिक्वेस्ट एपीआई);
• ऐड-ऑन में सक्रिय रूप से उपयोग किए जाने वाले एपीआई का समर्थन पूरी तरह से बंद करना व्यावहारिक नहीं है। इसे हटाने के बजाय, आप एक अलग अनुमति जोड़ सकते हैं और ऐड-ऑन में इसके उपयोग की पर्याप्तता को सख्ती से नियंत्रित कर सकते हैं, जो कई लोकप्रिय ऐड-ऑन के लेखकों को अपने उत्पादों को पूरी तरह से दोबारा काम करने से बचाएगा और कार्यक्षमता में कटौती से बचाएगा;
• ओवरहेड लागत को कम करने के लिए, आप एपीआई को हटा नहीं सकते हैं, लेकिन फ़ायरफ़ॉक्स में वेबरेक्वेस्ट के कार्यान्वयन के समान, प्रॉमिस तंत्र के आधार पर इसे रीमेक कर सकते हैं;
• प्रस्तावित विकल्प, डिक्लेरेटिवनेटरिक्वेस्ट, विज्ञापन अवरोधन और सुरक्षा/गोपनीयता के लिए ऐड-ऑन डेवलपर्स की सभी जरूरतों को कवर नहीं करता है, क्योंकि यह नेटवर्क अनुरोधों पर पूर्ण नियंत्रण प्रदान नहीं करता है, कस्टम फ़िल्टरिंग एल्गोरिदम के उपयोग की अनुमति नहीं देता है, और अनुमति नहीं देता है जटिल नियमों का उपयोग जो स्थितियों के आधार पर एक दूसरे को ओवरलैप करते हैं;
• डिक्लेरेटिवनेटरिक्वेस्ट एपीआई की वर्तमान स्थिति के साथ, यूब्लॉक ओरिजिन और यूमैट्रिक्स ऐड-ऑन की मौजूदा कार्यक्षमता को अपरिवर्तित करना असंभव है, और क्रोम के लिए नोस्क्रिप्ट पोर्ट के आगे के विकास को भी व्यर्थ बनाता है;
• गोपनीयता के बारे में चिंताएं दूर की कौड़ी हैं, क्योंकि वेबरेक्वेस्ट एपीआई का रीड-ओनली, नॉन-ब्लॉकिंग मोड यथावत छोड़ दिया गया है और अभी भी दुर्भावनापूर्ण ऐड-ऑन को सभी ट्रैफ़िक को नियंत्रित करने की अनुमति देता है, लेकिन इसमें हस्तक्षेप करने की क्षमता प्रदान नहीं करता है उड़ना (सामग्री बदलें, अपने विज्ञापन लगाएं, खनिक चलाएं और इनपुट फॉर्म की सामग्री का विश्लेषण पृष्ठ लोड होने के बाद किया जा सकता है);
• ब्राउज़र डेवलपर्स बहादुर, Opera и विवाल्डीक्रोमियम इंजन पर निर्मित, अपने उत्पादों में वेबरिक्वेस्ट ब्लॉकिंग मोड के लिए समर्थन छोड़ने का इरादा रखता है।

स्रोत: opennet.ru