गुगलले विज्ञापन ब्लकरहरूमा आवश्यक एपीआई सीमित गर्न जोड दिन जारी राख्छ

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

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

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

म्यानिफेस्टको तेस्रो संस्करणको प्रारम्भिक संस्करण, जसले Chrome एड-अनहरूमा उपलब्ध गराइने क्षमता र स्रोतहरूको सूची परिभाषित गर्दछ, आगामी महिनाहरूमा क्रोम क्यानरीको प्रयोगात्मक निर्माणहरूमा परीक्षणको लागि प्रयोग गर्ने योजना छ।

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

दोस्रो तर्क, प्रयोगकर्ताहरूलाई सामग्रीमा एड-अनहरूको अनियन्त्रित पहुँचबाट जोगाउने इच्छासँग सम्बन्धित, पनि विश्वस्त देखिँदैन, किनकि वैध एड-अनहरूमा लामो-स्थापित र व्यापक कार्यक्षमता हटाउनुको सट्टा, नयाँ थप्न सम्भव थियो। अधिकारको प्रकार र प्रयोगकर्तालाई नेटवर्क अनुरोधहरूमा पूर्ण पहुँचको साथ एड-अन स्थापना गर्ने अन्तिम विकल्प प्रदान गर्नुहोस् वा नगर्नुहोस्। थप रूपमा, Google ले कम-स्तर हस्तक्षेप बिना पूर्ण ट्राफिक अनुगमनलाई अनुमति दिँदै, पढ्ने-मात्र मोडमा webRequest API प्रयोग गर्नको लागि समर्थन छोडेको छ।
एड-अनहरूले अन्य API मार्फत लोड गरिएका वेब पृष्ठहरूको सामग्रीहरू परिवर्तन गर्न सक्छन् (उदाहरणका लागि, खराब एड-अनहरूले अझै पनि तिनीहरूको विज्ञापनहरू डेलिभर गर्न सक्छन्, खानीहरू सुरु गर्न सक्छन् र इनपुट फारमहरूको सामग्रीहरू विश्लेषण गर्न सक्छन्)।

अवांछित सामग्री ब्लक गर्नका लागि uBlock Origin र uMatrix प्रणालीका लेखक रेमन्ड हिल एकदमै कडा छन्। मा टिप्पणी गर्नुभयो गुगल प्रतिनिधिबाट प्रतिक्रिया र डेमागोगुरी र पर्दा पछाडिका खेलहरूमा संकेत गरिएको छ जसमा गुगलले राम्रो अवसरको आडमा, इन्टरनेट विज्ञापनको क्षेत्रमा आफ्नो व्यापारिक चासोलाई अगाडि बढाउने प्रयास गरिरहेको छ, यसको फिल्टरिङ मेकानिजमको नियन्त्रण प्राप्त गर्न र औचित्य साबित गर्न। आम जनताको नजरमा यी कार्यहरू।

एड-अन विकासकर्ताहरू बीच व्यापक र लोकप्रिय एपीआई रोक्नको आवश्यकताको लागि उसले कहिल्यै विश्वसनीय तर्कहरू प्राप्त गरेन। रेमन्डका अनुसार, कार्यसम्पादनमा गिरावट कुनै तर्क होइन, किनकि पृष्ठहरू तिनीहरूको ब्लोटको कारणले बिस्तारै लोड हुन्छन्, र सही रूपमा लागू गरिएको एड-अनहरूमा webRequest अवरुद्ध मोडको प्रयोगको कारणले होइन। यदि गुगलले साँच्चै प्रदर्शनको बारेमा ख्याल राख्छ भने, तिनीहरूले मेकानिज्मको आधारमा webRequest पुन: डिजाइन गर्ने थिए प्रतिज्ञा, संग समानता द्वारा कार्यान्वयन Firefox मा webRequest।

रेमण्डका अनुसार गुगलको रणनीति भनेको क्रोमको प्रयोगकर्ता आधार विस्तार गर्ने र सामग्री ब्लकरहरूको प्रयोगबाट हुने व्यापारिक क्षतिको बीचमा इष्टतम सन्तुलन निर्धारण गर्ने हो। क्रोम विस्तारको पहिलो चरणमा, Google लाई प्रयोगकर्ताहरू बीचको सबैभन्दा लोकप्रिय एड-अनहरू मध्ये एकको रूपमा विज्ञापन ब्लकरहरू राख्न बाध्य पारियो। तर क्रोमले प्रभुत्व प्राप्त गरेपछि, कम्पनीले ब्यालेन्सलाई आफ्नो पक्षमा टिप्न र प्रवर्द्धन गरेर ब्लकिङमा नियन्त्रण प्राप्त गर्न खोज्यो। पहल क्रोममा अनुपयुक्त विज्ञापन अवरुद्ध कार्यक्षमता एकीकृत गर्न। WebRequest API ले यस उद्देश्यलाई पराजित गर्छ किनभने सामग्री अवरुद्ध गर्ने नियन्त्रण हाल तेस्रो-पक्ष विज्ञापन अवरोधक विकासकर्ताहरूको हातमा छ।

स्रोत: opennet.ru