Google оправдава ограничението на webRequest API, използвано от рекламни блокери

Разработчици на браузър Chrome опитах се да оправдавам преустановяване на поддръжката за блокиращ режим на работа на webRequest API, който ви позволява да променяте полученото съдържание в движение и се използва активно в добавки за блокиране на реклама,
защита срещу зловреден софтуер, фишинг, шпиониране на потребителската активност, родителски контрол и поверителност.

Мотивите на Google:

• Режим на блокиране на API webRequest води до висока консумация на ресурси.
  Когато използва този API, браузърът първо изпраща на добавката всички данни, съдържащи се в мрежовата заявка, добавката ги анализира и връща модифицирана версия за допълнителна обработка в браузъра или издава инструкции за блокиране. В този случай основните забавяния възникват не на етапа на обработка на трафика от добавката, а поради режийните разходи за координиране на изпълнението на добавката. По-специално, такива манипулации изискват стартирането на отделен процес за допълване, както и използването на IPC за взаимодействие с този процес и механизми за сериализиране на данни;

• Добавката напълно контролира целия трафик на ниско ниво, което отваря огромни възможности за злоупотреби и нарушения на поверителността. Според статистиката на Google 42% от всички открити злонамерени добавки са използвали webRequest API. Отбелязва се, че всеки месец опитите за поставяне на средно 1800 злонамерени добавки са блокирани в каталога на уеб магазина на Chrome. За съжаление, прегледът не ни позволява да уловим всички злонамерени добавки без изключение, така че за подобряване на защитата беше решено да ограничим добавките на ниво API. Основната идея е да се предоставят добавки с достъп не до целия трафик, а само до данните, които са необходими за реализиране на планираната функционалност. По-специално, за да блокирате съдържание, не е необходимо да давате на добавката пълен достъп до всички поверителни потребителски данни;
• Предложен заместващ декларативен API declarativeNetRequest се грижи за цялата работа по високоефективното филтриране на съдържание и изисква само добавки за зареждане на правила за филтриране. Добавката не може да пречи на трафика и личните данни на потребителя остават неприкосновени;
• Google взе предвид много от коментарите относно липсата на функционалност на declarativeNetRequest API и разшири ограничението за броя на правилата за филтриране от първоначално предложените 30 хиляди на разширение до глобален максимум от 150 хиляди, а също така добави възможност за динамично промяна и добавяне на правила, премахване и замяна на HTTP хедъри (Referer, Cookie, Set-Cookie) и параметри на заявка;
• За предприятията е възможно да се използва блокиращ режим на работа на webRequest API, тъй като политиката за използване на добавки се определя от администратор, който разбира характеристиките на инфраструктурата и е наясно с рисковете. Например посоченият API може да се използва в предприятията за записване на потоците от трафик на служителите и интегриране с вътрешни системи;
• Целта на Google не е да подкопава или потиска добавките за блокиране на реклами, а да позволи създаването на по-безопасни и по-мощни рекламни блокери;
• Нежеланието да се напусне блокиращият режим на работа на webRequest API заедно с новия declarativeNetRequest се обяснява с желанието да се ограничи достъпът на добавките до поверителни данни. Ако оставите API на webRequest така, както е, повечето добавки няма да използват по-сигурния declarativeNetRequest, тъй като когато избират между сигурност и функционалност, повечето разработчици обикновено ще изберат функционалност.

Възражения разработчици допълнения:

• Провежда се от разработчици на добавки Тестове показват незначително цялостно въздействие върху производителността на добавките за блокиране на реклами (по време на тестването производителността на различни добавки беше сравнена, но без да се вземат предвид режийните разходи на допълнителен процес, който координира изпълнението на манипулатори в режим на блокиране на API на webRequest);
• Не е практично напълно да спрете да поддържате API, който се използва активно в добавки. Вместо да го премахвате, можете да добавите отделно разрешение и стриктно да контролирате адекватността на използването му в добавките, което би спестило авторите на много популярни добавки от пълно преработване на техните продукти и избягване на намаляване на функционалността;
• За да намалите режийните разходи, не можете да изтриете API, а да го преправите въз основа на механизма Promise, подобно на внедряването на webRequest във Firefox;
• Предложената алтернатива, declarativeNetRequest, не покрива всички нужди на разработчиците на добавки за блокиране на реклами и сигурност/поверителност, тъй като не осигурява пълен контрол върху мрежовите заявки, не позволява използването на персонализирани алгоритми за филтриране и не позволява използването на сложни правила, които се припокриват едно с друго в зависимост от условията;
• С текущото състояние на declarativeNetRequest API е невъзможно да се пресъздаде съществуващата функционалност на добавките uBlock Origin и uMatrix непроменени и също така прави по-нататъшното развитие на NoScript порт за Chrome безсмислено;
• Притесненията относно поверителността са пресилени, тъй като режимът само за четене, без блокиране на API на webRequest е оставен на място и все още позволява на злонамерени добавки да контролират целия трафик, но не предоставя възможност за намеса в него на fly (променете съдържанието, поставете вашите реклами, стартирайте миньори и анализирайте съдържанието на формулярите за въвеждане може да се използва, след като страницата приключи зареждането);
• Разработчици на браузъри Смел, Opera и Vivaldi, изграден на базата на двигателя Chromium, възнамеряват да оставят поддръжка за режима на блокиране на webRequest в своите продукти.

Източник: opennet.ru