शिमोन विंसन Chrome टीम के अनुरूप, Google के मेनिफेस्ट V3 के संबंध में Google की वर्तमान स्थिति पर टिप्पणी की ऐड ब्लॉकर्स को जोड़ने के लिए अतिरिक्त के रूप में।
Y ने कहा है कि कंपनी वेबरैपेस्ट एपीआई के ब्लॉकिंग मोड का समर्थन करने के लिए मूल योजना को छोड़ने का इरादा नहीं रखती है। यह आपको मक्खी पर प्राप्त सामग्री को बदलने की अनुमति देता है। केवल Chrome for Enterprises के लिए एक अपवाद बनाया जाएगा, जिसमें WebRequest API के लिए समर्थन पहले की तरह संरक्षित रहेगा।
Google विज्ञापन अवरोधकों को बाहर करना चाहता है
Chrome API के नियमित उपयोगकर्ताओं के लिए, webRequest केवल-पढ़ने के लिए मोड तक सीमित रहेगा। घोषणात्मक NetRequest API द्वारा दी जाने वाली सामग्री फ़िल्टरिंग के लिए WebRequest प्रतिस्थापन में, यह आधुनिक अवरोधक विज्ञापन में उपयोग की जाने वाली सुविधाओं का केवल एक सीमित हिस्सा शामिल करता है।
वास्तव में, नेटवर्क अनुरोधों के पूर्ण उपयोग के साथ स्वयं संचालकों के बजाय, एक तैयार और एकीकृत फ़िल्टरिंग इंजन है जो अपने स्वयं के संसाधनों के साथ अवरुद्ध नियमों को संसाधित करता है.
उदाहरण के लिए, घोषणात्मक नेटप्रिफ़स्ट एपीआई आपको अपने स्वयं के फ़िल्टरिंग एल्गोरिदम का उपयोग करने की अनुमति नहीं देता है और आपको जटिल नियम बनाने की अनुमति नहीं देता है जो शर्तों के आधार पर एक-दूसरे को ओवरलैप करते हैं।
डेवलपर्स ने संयुक्त रूप से टिप्पणियों की एक सूची तैयार की, जो एपीआई की घोषणात्मक खामियों को सूचीबद्ध करती है।
गूगल कई टिप्पणियों और के साथ सहमत हुए जोड़ा गया घोषणात्मक नेटप्रवेश एपीआई। विशेष रूप से, गतिशील परिवर्तनों और अतिरिक्त नियमों के लिए अतिरिक्त समर्थन, HTTP हेडर को हटाने की क्षमता प्रदान करता है, लेकिन केवल वे ही श्वेत (रेफर, कुकी, सेट-कुकी)।
योजनाओं में HTTP हेडर को जोड़ने और बदलने के लिए समर्थन शामिल है (उदाहरण के लिए, सेट-कुकी और सीएसपी निर्देशों को ओवरराइड करने के लिए) और अनुरोध मापदंडों को हटाने और बदलने की क्षमता।
मैनिफ़ेस्ट V3 के पूर्वावलोकन संस्करण को क्रोम प्लगइन्स द्वारा प्रदान की गई सुविधाओं और संसाधनों की सूची को परिभाषित करते हुए, आने वाले महीनों में क्रोम कैनरी के प्रयोगात्मक संस्करणों में उपयोग करने की योजना है।
Google अवरुद्ध करने के लिए ठोस तर्क नहीं देता है
रेमंड हिल, ओब्लॉक ओरिजिन और uMatrix के लेखक, कठोर उत्तर के साथ टिप्पणी की dई के एक प्रतिनिधि Google और संकेत दिया कि Google अपने व्यावसायिक हितों को बढ़ावा देने की कोशिश कर रहा है इंटरनेट विज्ञापन के क्षेत्र में और इस प्रकार इसके निस्पंदन के तंत्र पर नियंत्रण प्राप्त करते हैं और आम जनता के सामने इन कार्यों को उचित ठहराते हैं।
चूंकि आपको कभी कोई ठोस तर्क नहीं मिला विज्ञापन ब्लॉक प्लग इन के बीच लोकप्रिय डेवलपर्स को रोकने के लिए।
रेमंड के अनुसार, प्रदर्शन में गिरावट एक तर्क नहीं है, जैसे पृष्ठ अपने स्वयं के कोड के कारण धीरे-धीरे लोड होते हैं और ठीक से कार्यान्वित प्लगइन्स में वेबरेजेस्ट ब्लॉकिंग मोड के उपयोग के कारण नहीं।
यदि Google वास्तव में प्रदर्शन के बारे में चिंतित था, तो उन्होंने वादा तंत्र के आधार पर वेब अनुरोध को संशोधित किया होगा, फ़ायरफ़ॉक्स में वेब अनुरोध कार्यान्वयन के समान है।
रेमंड के अनुसार, Google की रणनीति विस्तार के बीच इष्टतम संतुलन निर्धारित करना है Chrome उपयोगकर्ता आधार और सामग्री अवरोधकों के उपयोग के कारण व्यावसायिक क्षति।
उसके लिए, Google विज्ञापन-संबंधी गतिविधियों को हर कीमत पर बाधित होने से रोकना चाहता है और अपने Chrome ब्राउज़र पर विज्ञापन अवरोधकों को अप्रभावी बनाने के बिंदु पर।
क्रोम के विस्तार के पहले चरण में, Google को उपयोगकर्ताओं के बीच सबसे लोकप्रिय प्लगइन्स में से कुछ के रूप में विज्ञापन अवरोधकों का समर्थन करने के लिए मजबूर किया गया था। लेकिन क्रोम के प्रभावी होने के बाद, कंपनी ने अपने पक्ष में संतुलन बदलने की कोशिश की।
WebRequest API इस लक्ष्य के साथ हस्तक्षेप करता है, क्योंकि सामग्री अवरोधन पर नियंत्रण अब तृतीय-पक्ष विज्ञापन अवरोधक डेवलपर्स के हाथों में है।
HTTP हेडर, कुकीज़ और अनुरोध पैरामीटर को बदलने की क्षमता का अभाव (उदाहरण के लिए, रेफर, _utm, और ट्रैकर पहचानकर्ताओं को काटने के लिए) का भी उल्लेख किया गया है, लेकिन Google ने पहले ही इन टिप्पणियों को हटाने का वादा किया है।
वे अपने अधिकारों के भीतर हैं। मुझे क्रोमियम का उपयोग बंद करने और फ़ायरफ़ॉक्स का उपयोग करने का भी अधिकार है। इसके अलावा, मुझे लगता है कि मैं एडब्लॉकर्स को ब्लॉक करने के लिए इंतजार नहीं करने जा रहा हूं और मैं फ़ायरफ़ॉक्स को एक कोशिश देने जा रहा हूं।
मैं फ़ायरफ़ॉक्स का उपयोग करता हूं, मैं भी होस्ट्स फ़ाइल से विज्ञापन ब्लॉक करता हूं, "ब्लॉकर्स" द्वारा नहीं।