Google обґрунтував обмеження API webRequest, використовуваного блокувальниками реклами

Розробники браузера Chrome спробували обґрунтувати припинення підтримки блокуючого режиму роботи API webRequest, що дозволяє міняти контент, що приймається, на льоту і активно застосовується в доповненнях для блокування реклами,
захисту від шкідливого ПЗ, фішингу, що шпигує за користувачами активності, батьківського контролю та забезпечення приватності.

Мотиви Google:

• Блокуючий режим роботи API веб-запит призводить до великого споживання ресурсів.
  При використанні даного API браузер спочатку надсилає доповненню всі дані, що містяться в мережевому запиті, додаток аналізує їх і повертає для подальшої обробки в браузері змінений варіант або видає інструкції з блокування. При цьому основні затримки виникають не на стадії обробки трафіку доповненням, а через накладні витрати на координацію виконання доповнення. Зокрема, подібні маніпуляції вимагають запуску для доповнення окремого процесу, а також застосування IPC для взаємодії з цим процесом та механізмів серіалізації даних;

• Доповнення повністю контролює весь трафік на низькому рівні, що відкриває великі можливості для зловживань та порушень приватності. За статистикою Google, у 42% всіх виявлених шкідливих доповнень застосовувався API webRequest. Зазначається, що щомісяця у каталозі Chrome Web Store блокуються спроби розміщення в середньому 1800 шкідливих доповнень. На жаль, рецензування не дозволяє відловлювати всі без винятку шкідливі доповнення, тому для посилення захисту було вирішено обмежити доповнення на рівні API. Основна ідея полягає в тому, щоб надавати доповненням доступ не до всього трафіку, а лише до тих даних, які необхідні для реалізації задуманої функціональності. Зокрема, для блокування контенту не обов'язково надавати доповненню повний доступ до всіх конфіденційних даних користувача;
• Запропонований на заміну декларативний API declarativeNetRequest бере на себе всю роботу з високопродуктивної фільтрації контенту і вимагає від доповнень завантаження правил фільтрації. Доповнення при цьому не може втручатися в трафік та приватні дані користувача залишаються недоторканними;
• Google врахував багато зауважень щодо недостатньої функціональності API declarativeNetRequest і розширив ліміт на кількість правил фільтрації з спочатку запропонованих 30 тисяч на кожне розширення до глобального максимуму в 150 тисяч, а також додав можливості для динамічної зміни та додавання правил, видалення та заміни HTTP-заголовків ( Referer, Cookie, Set-Cookie) та параметрів запитів;
• Для підприємств залишено можливість використання блокуючого режиму роботи API webRequest, оскільки політику застосування доповнень визначає адміністратор, який розуміє особливості інфраструктури та усвідомлює ризики. Наприклад, зазначений API може застосовуватись на підприємствах для обліку потоків трафіку співробітників та інтеграції з внутрішніми системами;
• Метою Google є не обмеження та придушення доповнень для блокування реклами, а надання можливості створення більш безпечних та продуктивних блокувальників реклами;
• Небажання залишити блокуючий режим роботи API webRequest поряд з новим declarativeNetRequest пояснюється бажанням обмежити доступ доповнень до конфіденційних даних. Якщо залишити API webRequest як є, то більшість доповнень не будуть використовувати більш безпечний declarativeNetRequest, тому що зазвичай при виборі між безпекою та функціональністю основна маса розробників вибере функціональність.

заперечення розробників доповнень:

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

Джерело: opennet.ru