Як Google пояснює обмеження API і що відповідають автори розширень

Розробники Chrome спробували пояснити, чому припиниться підтримка режиму блокування API webRequest. Саме завдяки цьому механізму працюють розширення, зокрема блокувальники реклами, інструменти батьківського контролю та захисту від фішингу. Нагадаємо, нововведення Google дуже критикувались спільнотою, однак компанія наполягає на своєму рішенні.

На чому ґрунтується позиція Google:

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

Що кажуть автори розширень:

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

Браузери Opera, Brave і Vivaldi теж побудовані на Chromium, однак нововведень Chrome щодо API вони не підтримують.