Google जाहिरात ब्लॉकर्सद्वारे वापरल्या जाणार्‍या webRequest API च्या निर्बंधाचे समर्थन करते

Chrome ब्राउझर विकसक प्रयत्न केला समर्थन करणे वेबरिक्वेस्ट API च्या ऑपरेशनच्या ब्लॉकिंग मोडसाठी समर्थन बंद करणे, जे तुम्हाला फ्लायवर प्राप्त सामग्री बदलण्याची परवानगी देते आणि जाहिरात ब्लॉक करण्यासाठी अॅड-ऑनमध्ये सक्रियपणे वापरले जाते,
मालवेअर, फिशिंग, वापरकर्त्याच्या क्रियाकलापांवर हेरगिरी, पालक नियंत्रणे आणि गोपनीयता यापासून संरक्षण.

Google चे हेतू:

• API ब्लॉकिंग मोड वेब विनंती उच्च संसाधन वापर ठरतो.
  हे API वापरताना, ब्राउझर प्रथम नेटवर्क विनंतीमध्ये समाविष्ट असलेला सर्व डेटा अॅड-ऑन पाठवतो, अॅड-ऑन त्याचे विश्लेषण करतो आणि ब्राउझरमध्ये पुढील प्रक्रियेसाठी सुधारित आवृत्ती परत करतो किंवा अवरोधित करण्याच्या सूचना जारी करतो. या प्रकरणात, मुख्य विलंब अॅड-ऑनद्वारे रहदारीवर प्रक्रिया करण्याच्या टप्प्यावर उद्भवत नाही, परंतु अॅड-ऑनच्या अंमलबजावणीचे समन्वय साधण्याच्या ओव्हरहेड खर्चामुळे उद्भवते. विशेषतः, अशा हाताळणींना पूरक होण्यासाठी स्वतंत्र प्रक्रिया सुरू करणे आवश्यक आहे, तसेच या प्रक्रियेशी आणि डेटा क्रमिकरण यंत्रणेशी संवाद साधण्यासाठी IPC चा वापर करणे आवश्यक आहे;

• अॅड-ऑन कमी स्तरावर सर्व रहदारी पूर्णपणे नियंत्रित करते, जे गैरवर्तन आणि गोपनीयतेच्या उल्लंघनासाठी मोठ्या संधी उघडते. Google आकडेवारीनुसार, आढळलेल्या सर्व दुर्भावनापूर्ण अॅड-ऑनपैकी 42% ने webRequest API वापरले. दर महिन्याला, Chrome वेब स्टोअर कॅटलॉगमध्ये सरासरी 1800 दुर्भावनापूर्ण अॅड-ऑन ठेवण्याचे प्रयत्न अवरोधित केले जातात. दुर्दैवाने, पुनरावलोकन केल्याने आम्हाला अपवादाशिवाय सर्व दुर्भावनापूर्ण अॅड-ऑन पकडण्याची परवानगी मिळत नाही, त्यामुळे संरक्षण वाढवण्यासाठी, API स्तरावर अॅड-ऑन मर्यादित करण्याचा निर्णय घेण्यात आला. मुख्य कल्पना म्हणजे ऍड-ऑन सर्व ट्रॅफिकमध्ये प्रवेशासह प्रदान करणे, परंतु केवळ इच्छित कार्यक्षमतेची अंमलबजावणी करण्यासाठी आवश्यक असलेल्या डेटासाठी. विशेषतः, सामग्री अवरोधित करण्यासाठी, अॅड-ऑनला सर्व गोपनीय वापरकर्ता डेटावर पूर्ण प्रवेश देणे आवश्यक नाही;
• प्रस्तावित बदली घोषणात्मक API declarativeNetRequest उच्च-कार्यक्षमता सामग्री फिल्टरिंगच्या सर्व कामांची काळजी घेते आणि फक्त फिल्टरिंग नियम लोड करण्यासाठी अॅड-ऑनची आवश्यकता असते. अॅड-ऑन रहदारीमध्ये व्यत्यय आणू शकत नाही आणि वापरकर्त्याचा खाजगी डेटा अभेद्य राहतो;
• Google ने declarativeNetRequest API च्या कार्यक्षमतेच्या कमतरतेबद्दलच्या अनेक टिप्पण्या विचारात घेतल्या आणि फिल्टरिंग नियमांच्या संख्येची मर्यादा सुरुवातीला प्रस्तावित 30 हजार प्रति विस्तार वरून जागतिक कमाल 150 हजारांपर्यंत वाढवली आणि गतिशीलतेची क्षमता देखील जोडली. नियम बदला आणि जोडा, HTTP शीर्षलेख काढा आणि पुनर्स्थित करा ( रेफरर, कुकी, सेट-कुकी) आणि मापदंडांची विनंती करा;
• एंटरप्राइझसाठी, वेबरिक्वेस्ट API च्या ऑपरेशनचा ब्लॉकिंग मोड वापरणे शक्य आहे, कारण अॅड-ऑन वापरण्याचे धोरण प्रशासकाद्वारे निर्धारित केले जाते ज्याला पायाभूत सुविधांची वैशिष्ट्ये समजतात आणि जोखमींची जाणीव असते. उदाहरणार्थ, निर्दिष्ट API एंटरप्राइजेसमध्ये कर्मचारी रहदारी प्रवाह रेकॉर्ड करण्यासाठी आणि अंतर्गत प्रणालींसह एकत्रित करण्यासाठी वापरले जाऊ शकते;
• Google चे उद्दिष्ट जाहिरात ब्लॉकिंग ऍड-ऑनला कमी करणे किंवा दडपून टाकणे नाही, परंतु अधिक सुरक्षित आणि अधिक शक्तिशाली जाहिरात ब्लॉकर तयार करणे सक्षम करणे आहे;
• नवीन declarativeNetRequest सोबत webRequest API च्या ऑपरेशनचा ब्लॉकिंग मोड सोडण्याची अनिच्छा गोपनीय डेटावर ऍड-ऑनचा प्रवेश मर्यादित करण्याच्या इच्छेद्वारे स्पष्ट केली आहे. तुम्ही webRequest API जसे आहे तसे सोडल्यास, बहुतेक ऍडऑन अधिक सुरक्षित declarativeNetRequest वापरणार नाहीत, कारण सुरक्षा आणि कार्यक्षमता यातील निवड करताना, बहुतेक विकासक सहसा कार्यक्षमता निवडतात.

आक्षेप विकसक जोडणे:

• अॅड-ऑन डेव्हलपर्सद्वारे आयोजित चाचण्या जाहिरात ब्लॉकिंग अॅड-ऑन्सच्या कार्यक्षमतेवर एक क्षुल्लक एकूण प्रभाव दर्शवा (चाचणी दरम्यान, विविध अॅड-ऑन्सच्या कार्यप्रदर्शनाची तुलना केली गेली, परंतु ब्लॉकिंग मोडमध्ये हँडलर्सच्या अंमलबजावणीचे समन्वय साधणाऱ्या अतिरिक्त प्रक्रियेच्या ओव्हरहेडचा विचार न करता webRequest API);
• ऍड-ऑनमध्ये सक्रियपणे वापरल्या जाणार्‍या API चे समर्थन करणे पूर्णपणे थांबवणे व्यावहारिक नाही. ते काढून टाकण्याऐवजी, तुम्ही वेगळी परवानगी जोडू शकता आणि अॅड-ऑन्समध्ये त्याच्या वापराच्या पर्याप्ततेवर काटेकोरपणे नियंत्रण ठेवू शकता, जे अनेक लोकप्रिय अॅड-ऑनच्या लेखकांना त्यांची उत्पादने पूर्णपणे पुन्हा काम करण्यापासून वाचवेल आणि कार्यक्षमता कमी करणे टाळेल;
• ओव्हरहेड खर्च कमी करण्यासाठी, तुम्ही API हटवू शकत नाही, परंतु फायरफॉक्समधील webRequest च्या अंमलबजावणीप्रमाणेच प्रॉमिस मेकॅनिझमवर आधारित ते रीमेक करू शकता;
• प्रस्तावित पर्याय, declarativeNetRequest, जाहिरात ब्लॉकिंग आणि सुरक्षितता/गोपनीयतेसाठी अॅड-ऑन विकासकांच्या सर्व गरजा पूर्ण करत नाही, कारण ते नेटवर्क विनंत्यांवर पूर्ण नियंत्रण प्रदान करत नाही, सानुकूल फिल्टरिंग अल्गोरिदम वापरण्याची परवानगी देत ​​​​नाही आणि परवानगी देत ​​​​नाही. जटिल नियमांचा वापर जे परिस्थितीनुसार एकमेकांना ओव्हरलॅप करतात;
• declarativeNetRequest API च्या सद्यस्थितीसह, uBlock Origin आणि uMatrix ऍड-ऑनची विद्यमान कार्यक्षमता अपरिवर्तित करून पुन्हा तयार करणे अशक्य आहे आणि Chrome साठी NoScript पोर्टचा पुढील विकास देखील निरर्थक करते;
• गोपनीयतेबद्दलची चिंता दूरची आहे, कारण webRequest API चा केवळ-वाचनीय, नॉन-ब्लॉकिंग मोड जागेवर सोडला आहे आणि तरीही सर्व रहदारी नियंत्रित करण्यासाठी दुर्भावनापूर्ण अॅड-ऑनला अनुमती देते, परंतु त्यात हस्तक्षेप करण्याची क्षमता प्रदान करत नाही. फ्लाय (सामग्री बदला, तुमच्या जाहिराती ठेवा, खाण कामगार चालवा आणि पृष्‍ठ लोडिंग पूर्ण झाल्यानंतर वापरता येऊ शकणार्‍या इनपुट फॉर्ममधील सामग्रीचे विश्लेषण करा);
• ब्राउझर विकसक शूर, ऑपेरा и विवाल्डी, Chromium इंजिनवर तयार केलेले, त्यांच्या उत्पादनांमध्ये webRequest ब्लॉकिंग मोडसाठी समर्थन सोडण्याचा मानस आहे.

स्त्रोत: opennet.ru