Реймонд Хілл (Raymond Hill), автор систем блокування небажаного контенту uBlock Origin і uMatrix, попередив про неможливість використання в браузері Chrome доповнення uBlock Origin в разі затвердження третьої версії маніфесту Chrome.
Маніфест визначає перелік можливостей та ресурсів, що надаються доповненням Chrome. У поточному чорновому варіанті третьої версії маніфесту припинена підтримка обробки API webRequest в блокуючему режимі і в якості заміни запропоновано використовувати істотно більш обмежений API declarativeNetRequest. На думку Реймонда Хілла запропонованого API недостатньо для забезпечення повноцінного блокування реклами і в разі затвердження маніфесту доповнення uBlock Origin та uMatrix не зможуть випускатися для Chrome.
При цьому зміна не вплине на роботу блокувальника Adblock Plus, побудованого на базі API declarativeNetRequest. Реймонд зазначає, що за допомогою декларативного API declarativeNetRequest неможливо створювати ефективні рушії для блокування небажаного контенту, так як даний API є вже готовою сильно обмеженою реалізацією одного специфічного рушія і не дає самостійно контролювати контент, що надходить на низькому рівні. З думкою Реймонда також погодилися розробники блокувальника AdGuard, який також зачіпають зміни, що вводяться.
З недоліків API declarativeNetRequest називається жорстке обмеження максимального числа фільтрів, що підключаються - список правил фільтрації обмежується 30 тисячами записів, що недостатньо з урахуванням того, що тільки в одному списку EasyList присутні більше 42 тисяч блокувань. Крім того, запропонований API не дає використовувати власні алгоритми фільтрації і не дозволяє створювати складні правила, що перекривають один одного в залежності від умов. За допомогою API declarativeNetRequest також неможливо організувати блокування великих мультимедійних елементів, зупинити виконання JavaScript через підстановку директив CSP та видалити заголовки з Cookie.
В якості причини припинення підтримки API webRequest називається бажання захистити користувачів від неконтрольованого доступу доповнень до контенту. На думку Google користувачі повинні мати можливість визначити, яка інформація доступна доповненню, а яка ні. API declarativeNetRequest не дає доповненню прямого доступу до мережевих запитів, а лише дозволяє задавати правила блокування, але обробляє їх самостійно.
Відзначається також, що використання webRequest призводить до уповільнення відображення контенту, так як даний API працює в блокуючему режимі та перед виведенням сторінки браузер очікує повного завершення обробки даних доповненням. Відповідно до плану Google, частково підтримка API webRequest буде збережена, але обмежена неблокуючим режимом, відповідним тільки для читання запитів та аналізу трафіку, а можливості, що працюють в блокуючему режимі, такі як перехоплення, перенаправлення та модифікація вмісту, будуть відключені.
На думку Реймонда Хілла припинення підтримки вже 7 років існуючого API з посиланнями на захист приватності користувачів є дивним кроком, так як логічніше було додати окремий дозвіл, що дозволяє користувачеві вибірково надавати доступ обраним доповненням до webRequest, а не повністю видаляти даний API. Викликає питання і те, що робота з видалення webRequest почалася в передчутті повсюдного введення в дію власного блокувальника Google, в якому реалізація declarativeNetRequest близька до рушія блокувальника Adblock Plus, яка уклала угоду про розміщення рекламних мереж Google, Amazon і Microsoft у білий перелік.
Додаток 1: Розробники Adblock Plus повідомили, що зміна торкнеться і їх продукту, так як API declarativeNetRequest покриває лише обмежену частина можливостей, які використовуються в даному блокувальнику реклами. Adblock Plus також використовує список блокування EasyList, тому на нього вплине і обмеження на кількість записів.
Додаток 2: Автор проекту NoScript згадав, що припинення підтримки засобів для зміни контенту через API webRequest ставить хрест на розробці порту NoScript для Chromium, який розвивається вже близько року і вже майже доведений до готовності.
Додаток 3: Розробники проекту AdGuard, який також потрапляє під удар у разі обмеження API webRequest, звернули увагу на іншу зміну у маніфесті - нову систему доступу на рівні хостів (припинення підтримки повноваження "all_urls"), яка вимагатиме від користувача підтвердження активації доповнення для кожного сайту. Тобто навіть якщо API webRequest буде збережений, користувачам буде виводитися діалог з підтвердженням надання повноважень для кожного вперше відкриваємого сайту.
Додаток 4: Представники компаній F-Secure, Blockade.io і Ermes Cyber Security заявили, що з проблемами зіштовхнуться не тільки розробники додатків для блокування реклами, але і виробники доповнень для захисту від шкідливого ПО, фішингу та активності, що шпигує за користувачами, а також доповнень для батьківського контролю. Відзначається, що API declarativeNetRequest та заявлених лімітів недостатньо для реалізації подібних доповнень (бази блокування фішингу можуть включати мільйони записів, а список Blockade містить 250 тисяч записів, що ніяк не узгоджується з лімітом в 30 тисяч правил). Компанія Amnesty International підтвердила, що функціональності, яка залишається, недостатньо для роботи доповнень, що розробляються для блокування атак.
Джерело: opennet.ru
Коментарі
Дописати коментар