Google Chrome
От няколко месеца Google обяви намеренията си да премахне блокерите на реклами от своя уеб браузър Chrome., това с насоката, че блокерите ще имат проблеми при промените, въведени в Manifest V3.
Въпреки че Google също така твърди, че някои доставчици на услуги онлайн имат вградени технологии, които може да компрометира основните характеристики на дигиталната реклама на трети страни.
Разработчиците на Chrome се опитаха да оправдаят прекратяването на поддръжката за режим на блокиране от API на webRequest, което ви позволява да променяте полученото съдържание в движение и се използва активно в приставки за блокиране на реклами, защита срещу злонамерен софтуер, фишинг, шпиониране на потребители, родителски контрол и поверителност.
Режимът на блокиране на webRequest API води до голямо потребление на ресурси.
Когато използвате този API, браузърът първо изпраща всички данни, съдържащи се в мрежовата заявка, на приставката, приставката я анализира и връща модифицирана версия за по-нататъшна обработка в браузъра или проблеми с инструкциите за блокиране.
В този случай основните закъснения възникват не на етапа на обработка на трафика с приставка, а поради режийни разходи за координиране на изпълнението на приставката.
По-специално, такива манипулации изискват стартиране за допълване на отделен процес, както и използването на IPC за взаимодействие с този процес и механизми за сериализация на данни.
Добавката напълно контролира целия трафик на ниско ниво, което отваря широки възможности за злоупотреби и нарушения на поверителността.
Google все още подкрепя премахването на API
Според статистиката на Google, в Използвани са 42% от всички злонамерени плъгини, API на webRequest.
За съжаление, кръпката не позволява прихващане на нито един от всички злонамерени плъгини, За да се подобри защитата, беше решено да се ограничат приставките на ниво API.
Основната идея е да се осигурят плъгини с ограничен достъп до целия трафик, ако не само към данните, които са необходими за изпълнението на замислената функционалност.
По-специално, за да блокирате съдържание, не е необходимо да предоставяте на приставката пълен достъп до всички поверителни потребителски данни.
Предложеният декларатив, който да замени API-то на deklarativeNetRequest, се грижи за цялата работа високоефективна система за филтриране на съдържание и изисква само изтегляне на приставки за правила за филтриране. Освен това добавката не може да попречи на трафика и личните данни на потребителя остават неприкосновени.
Google взе предвид много от коментарите относно липсата на функционалност на API, deklarativeNetRequest и разшири ограничението за броя на правилата за филтриране от 30,000 150,000 първоначално предложени за всяко разширение до глобален максимум XNUMX XNUMX и също така добави възможността за динамично модифициране и добавяне на правила, премахване и замяна на HTTP заглавки (Referer, Cookie, Set-Cookie) и параметри на заявката.
Разработчиците не са напълно убедени
Тестването от разработчици на плъгини показва, че ефективността на блокиращите реклами плъгини е незначителна в сравнение с общия фон (при тестване, сравняване на производителността на различни плъгини, но без да се вземат предвид режийните разходи за допълнителен процес, който координира изпълнението на манипулаторите в режимът на блокиране на webRequest API).
Не е практично напълно да спрете да поддържате API, активно се използва в приставки. Вместо да го премахват, разработчиците твърдят, че може да се добави отделна резолюция и да се контролира плътно за адекватността на използването й в допълнения, което би спестило на авторите на много популярни приставки от пълна обработка на техните продукти и ще предотврати намаляване на функционалността.
Предложената алтернатива на declarativeNetRequest не покрива всички нужди на разработчиците на приставки за блокиране на реклами и гарантиране на сигурност / поверителност, тъй като не осигурява пълен контрол върху мрежовите заявки, не позволява използването на собствени алгоритми за филтриране и не позволява използването на сложни правила, които се припокриват взаимно в зависимост от условията.
Fuente: https://security.googleblog.com/