Google विज्ञापन अवरोधकों में आवश्यक एपीआई को सीमित करने पर जोर देता रहता है

शिमोन विंसेंट, जो क्रोम टीम में एक्सटेंशन डेवलपर्स के साथ बातचीत के लिए जिम्मेदार हैं (एक्सटेंशन डेवलपर एडवोकेट का पद संभालते हैं), टिप्पणी Chrome घोषणापत्र के तीसरे संस्करण के संबंध में Google की वर्तमान स्थिति, उल्लंघन करने काम अनुचित सामग्री को रोकने और सुरक्षा सुनिश्चित करने के लिए कई ऐड-ऑन। कंपनी का वेबरिक्वेस्ट एपीआई के ब्लॉकिंग मोड का समर्थन बंद करने की अपनी मूल योजना को छोड़ने का इरादा नहीं है, जो आपको तुरंत प्राप्त सामग्री को बदलने की अनुमति देता है। अपवाद केवल Chrome के एंटरप्राइज़ संस्करण के लिए बनाया जाएगा (एंटरप्राइज़ के लिए क्रोम), जिसमें webRequest API के लिए समर्थन पहले की तरह बरकरार रखा जाएगा।

नियमित Chrome API उपयोगकर्ताओं के लिए वेब अनुरोध केवल पढ़ने योग्य मोड तक सीमित रहेगा। सामग्री फ़िल्टरिंग के लिए webRequest API को बदलने के लिए एक घोषणात्मक API प्रस्तावित किया गया है declarativeNetRequest, जो आधुनिक विज्ञापन अवरोधकों में उपयोग की जाने वाली क्षमताओं का केवल एक सीमित हिस्सा ही कवर करता है। अनिवार्य रूप से, मालिकाना हैंडलर के बजाय जिनके पास नेटवर्क अनुरोधों तक पूर्ण पहुंच है, एक तैयार-निर्मित सार्वभौमिक अंतर्निहित फ़िल्टरिंग इंजन की पेशकश की जाती है जो नियमों को स्वयं अवरुद्ध करने की प्रक्रिया करता है। उदाहरण के लिए, declarativeNetRequest API आपको अपने स्वयं के फ़िल्टरिंग एल्गोरिदम का उपयोग करने की अनुमति नहीं देता है और आपको जटिल नियम बनाने की अनुमति नहीं देता है जो शर्तों के आधार पर एक दूसरे को ओवरलैप करते हैं।

विज्ञापन अवरोधक ऐड-ऑन के डेवलपर्स ने संयुक्त रूप से तैयारी की है टिप्पणियों की सूची, जिसने डिक्लेरेटिवनेटरेक्वेस्ट एपीआई की कमियों को सूचीबद्ध किया। Google कई टिप्पणियों से सहमत हुआ और घोषणात्मकNetRequest API में जोड़ा गया। विशेष रूप से, नियमों को गतिशील रूप से बदलने और जोड़ने के लिए समर्थन जोड़ा गया है, और HTTP हेडर को हटाना संभव है, लेकिन केवल श्वेत सूची (रेफ़रर, कुकी, सेट-कुकी) में मौजूद हेडर को हटाना संभव है। हम HTTP हेडर जोड़ने और बदलने के लिए समर्थन लागू करने की योजना बना रहे हैं (उदाहरण के लिए, सेट-कुकी प्रतिस्थापन और सीएसपी निर्देशों के लिए) और अनुरोध पैरामीटर को हटाने और बदलने की क्षमता।

मेनिफेस्ट के तीसरे संस्करण का प्रारंभिक संस्करण, जो क्रोम ऐड-ऑन को प्रदान की गई क्षमताओं और संसाधनों की सूची को परिभाषित करता है, का उपयोग आने वाले महीनों में क्रोम कैनरी के प्रायोगिक बिल्ड में परीक्षण के लिए किए जाने की योजना है।

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

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

अवांछित सामग्री को रोकने के लिए यूब्लॉक ओरिजिन और यूमैट्रिक्स सिस्टम के लेखक रेमंड हिल काफी सख्त हैं टिप्पणी एक Google प्रतिनिधि की प्रतिक्रिया और डेमोगुगरी और पर्दे के पीछे के खेलों का संकेत दिया गया जिसमें Google, एक अच्छे अवसर की आड़ में, इंटरनेट विज्ञापन के क्षेत्र में अपने व्यावसायिक हितों को आगे बढ़ाने, अपने फ़िल्टरिंग तंत्र पर नियंत्रण हासिल करने और औचित्य साबित करने की कोशिश कर रहा है। ये कार्य आम जनता की नज़र में हैं।

ऐड-ऑन डेवलपर्स के बीच व्यापक और लोकप्रिय एपीआई को रोकने की आवश्यकता के लिए उन्हें कभी भी ठोस तर्क नहीं मिले। रेमंड के अनुसार, प्रदर्शन में गिरावट कोई तर्क नहीं है, क्योंकि पेज अपने ब्लोट के कारण धीरे-धीरे लोड होते हैं, न कि सही ढंग से कार्यान्वित ऐड-ऑन में वेबरेक्वेस्ट ब्लॉकिंग मोड के उपयोग के कारण। यदि Google को वास्तव में प्रदर्शन की परवाह होती, तो उन्होंने तंत्र के आधार पर webRequest को फिर से डिज़ाइन किया होता वादा, के साथ सादृश्य द्वारा कार्यान्वयन फ़ायरफ़ॉक्स में webRequest।

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

स्रोत: opennet.ru