Google ले ad blockers द्वारा प्रयोग गरिएको webRequest API को प्रतिबन्धलाई उचित ठहराउँछ

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

गुगलको उद्देश्य:

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

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

आपत्तिहरू विकासकर्ताहरू थपहरू:

• एड-अन विकासकर्ताहरू द्वारा संचालित परीक्षण विज्ञापन अवरुद्ध एड-अनहरूको प्रदर्शनमा एक नगण्य समग्र प्रभाव देखाउनुहोस् (परीक्षणको क्रममा, विभिन्न एड-अनहरूको कार्यसम्पादन तुलना गरिएको थियो, तर ब्लकिङ मोडमा ह्यान्डलरहरूको कार्यान्वयन समन्वय गर्ने अतिरिक्त प्रक्रियाको ओभरहेडलाई ध्यानमा नदिई। webRequest API);
• एड-अनहरूमा सक्रिय रूपमा प्रयोग भएको API लाई पूर्ण रूपमा समर्थन गर्न बन्द गर्नु व्यावहारिक छैन। यसलाई हटाउनुको सट्टा, तपाईंले छुट्टै अनुमति थप्न सक्नुहुन्छ र एड-अनहरूमा यसको प्रयोगको पर्याप्ततालाई कडाइका साथ नियन्त्रण गर्न सक्नुहुन्छ, जसले धेरै लोकप्रिय एड-अनका लेखकहरूलाई तिनीहरूका उत्पादनहरू पूर्ण रूपमा पुन: काम गर्नबाट बचाउन र कार्यक्षमता कटौती गर्नबाट जोगिन सक्छ;
• ओभरहेड लागतहरू घटाउनको लागि, तपाईंले API लाई मेटाउन सक्नुहुन्न, तर Firefox मा webRequest को कार्यान्वयन जस्तै, Promise मेकानिज्मको आधारमा यसलाई पुन: बनाउन सक्नुहुन्छ;
• प्रस्तावित वैकल्पिक, declarativeNetRequest, विज्ञापन अवरुद्ध र सुरक्षा/गोपनीयता को लागी एड-अन विकासकर्ताहरु को सबै आवश्यकताहरु लाई कवर गर्दैन, किनकि यसले नेटवर्क अनुरोधहरु मा पूर्ण नियन्त्रण प्रदान गर्दैन, अनुकूलन फिल्टरिंग एल्गोरिदम को उपयोग को अनुमति दिदैन, र अनुमति दिदैन। सर्तहरूमा निर्भर गर्दै एक अर्कालाई ओभरल्याप गर्ने जटिल नियमहरूको प्रयोग;
• declarativeNetRequest API को हालको अवस्थाको साथ, uBlock Origin र uMatrix add-ons को अपरिवर्तित विद्यमान कार्यक्षमता पुन: सिर्जना गर्न असम्भव छ, र Chrome को लागि NoScript पोर्टको थप विकास पनि व्यर्थ छ;
• गोपनीयताको बारेमा चिन्ताहरू धेरै टाढा छन्, किनकि वेबRequest API को पढ्न-मात्र, गैर-ब्लकिङ मोडलाई ठाउँमा छोडिएको छ र अझै पनि सबै ट्राफिकलाई नियन्त्रण गर्न खराब एड-अनहरूलाई अनुमति दिन्छ, तर यसमा हस्तक्षेप गर्ने क्षमता प्रदान गर्दैन। फ्लाई (सामग्री परिवर्तन गर्नुहोस्, तपाइँको विज्ञापनहरू राख्नुहोस्, खानीहरू चलाउनुहोस् र पृष्ठ लोड समाप्त भएपछि इनपुट फारमहरूको सामग्रीहरू प्रयोग गर्न सकिन्छ) विश्लेषण गर्नुहोस्;
• ब्राउजर विकासकर्ताहरू बहादुर, ओपेरा и Vivaldi, क्रोमियम इन्जिनमा निर्मित, तिनीहरूका उत्पादनहरूमा webRequest अवरुद्ध मोडको लागि समर्थन छोड्न चाहन्छ।

स्रोत: opennet.ru