Майбутній маніфест V3 для розширень Google Chrome змінить роботу блокувальників реклами в Chrome. Чи це правильний шлях для блокувальників реклами та Google?
Гугл хром є найпопулярнішим кросплатформним веб-браузером, доступним на ринку прямо зараз, претендуючи на 62,7% глобальної частки використання браузера до травня 2019 року, причому Safari від Apple займає друге місце з 15,89%, а Firefox від Mozilla — 5,07%. Через його левову частку найменші зміни, які Google Chrome здійснює для своєї платформи, зрештою впливають на мільйони користувачів у всьому світі. Тому, коли Google анонсувала наступну версію маніфесту розширень у формі маніфесту V3 для розширень Google Chrome, ми знали, що чекали великі зміни, особливо коли стало відомо, що Google створює API блокувальника вмісту в Chrome себе.
Що таке Manifest V3?
Якщо ви активний користувач Chrome, ви, безсумнівно, використовуєте кілька розширень. Розширення – це невеликі програмні програми, які налаштовують роботу веб-переглядача за допомогою
API, які надає браузер, дозволяючи користувачам адаптувати функціональність і поведінку відповідно до своїх індивідуальних потреб і вподобань. Ці розширення поширюються в основному через Веб-магазин Chrome, який містить понад 180 000 розширень.Оскільки наприкінці минулого року, Google працює над «Маніфестом V3», набором запропонованих змін до платформи розширень Chrome, які можна класифікувати як «критичні зміни». Як документ публічного обговорення для Manifest V3 станів версія маніфесту розширення — це механізм для обмеження певних можливостей певним класом розширень. Ці обмеження можуть мати форму мінімальної або максимальної версії. Обмеження до мінімальної версії дозволяє новішим API або можливостям бути доступними лише для нових розширень в той час як обмеження максимальною версією маніфесту дозволяє поступово відновлювати старі API або можливості застарілий.
Простіше кажучи, нова версія маніфесту дозволяє Chrome обмежити API і функції цією новою версією маніфесту в щоб змусити розробників розширень перейти з певних старіших API через їхній негативний вплив на користувача досвід. Впровадження розширення в Manifest V3 теоретично повинно забезпечити більш сильні гарантії з точки зору безпеки, конфіденційності та продуктивності.
Незважаючи на те, що в Manifest V3 описано широкий спектр змін, найбільш суперечлива зміна стосується рішення Google обмежити можливості блокування, наявні в існуючому chrome.webRequest API (і зосередити API на спостереженні, а не на блокуванні), а потім представити ці можливості блокування через новий chrome.declarativeNetRequest API. Ця конкретна зміна має розпалили громаду оскільки він націлений на механізм блокування реклами відомого розширення для блокування реклами, uBlock Origin, і безпосередньо впливає на понад 10 мільйонів користувачів.
Перш ніж розглянути цю проблему, давайте подивимося, як webRequest API порівнюється з declarativeNetRequest API.
API веб-запиту та API декларативного мережевого запиту
сьогодення
Офіційний опис Web Request описує API таким чином:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
За допомогою веб-запиту Chrome надсилає все дані в мережевому запиті до розширення, яке їх прослуховує. Тоді розширення має можливість оцінити запит і вказати Chrome, що робити із запитом: дозволити, заблокувати або надіслати з деякими змінами.
Слідкуйте за послідовністю подій, щоб зрозуміти, що відбувається, коли розширення використовують API веб-запитів. Коли користувач із встановленим розширенням Web Request клацає посилання, Chrome повідомляє розширення, що запит даних було зроблено до того, як запит досягне сервера. Розширення може змінити запит на цьому етапі. Потім сервер відповідає, але відповідь знову проходить через розширення, а розширення може вказати, чи потрібно змінити відповідь. Потім Chrome нарешті відтворює сторінку, і користувач може переглянути результат свого клацання.
Як Chrome передає усі дані в мережевому запиті, розширення, які використовують API веб-запитів, мають доступ для читання та змінення всього, що робить користувач в Інтернеті. Тож хоча блокувальники вмісту, такі як uBlock Origin, розумно використовують потенціал цього API, Google стверджує, що інші розширення зі зловмисними намірами зловживали тим самим, щоб отримати доступ до особистих даних користувачів інформації. За даними Google, із січня 2018 року 42% шкідливих розширень використовували API веб-запитів. Google також стверджує, що використання API як блокуючої версії пов’язане з «значними витратами на продуктивність». для цього потрібен наполегливий і часто тривалий процес, який принципово несумісний із «лінивим» процеси.
З Manifest V3 Google пропонує обмежити цей API у формі блокування. Як альтернативу Google надає API декларативного мережевого запиту.
Майбутнє
Офіційний опис Declarative Net Request описує API таким чином:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
За допомогою декларативного мережевого запиту Chrome не потрібно надсилати всю інформацію про запит до розширення прослуховування. Натомість розширення реєструє в Chrome правила, які заздалегідь повідомляють браузеру, що робити, якщо помічаються певні типи запитів.
Розширення визначає свої правила заздалегідь. Запит користувача потім порівнюється з цим правилом браузером (а не розширенням), і дія також виконується браузером, а сторінка згодом відображається. Google зазначає, що це дозволяє їм забезпечити ефективність, оскільки вони можуть здійснювати контроль над алгоритмом визначення результату та можуть запобігати або вимикати неефективні правила. Це також надає кращі гарантії конфіденційності для кінцевого користувача, оскільки деталі мережевого запиту не піддаються розширенню. Оскільки постійні та тривалі процеси більше не потрібні (оскільки правила реєструються заздалегідь), Google стверджує, що цей підхід також забезпечує покращення продуктивності, що зробить розширення значно більш життєздатними за обмежених ресурсів платформи.
Декларативний мережевий запит буде доступний як для Manifest V2 (поточний), так і для Manifest V3, але це буде основний спосіб, за допомогою якого Google дозволить змінювати мережеві запити в Manifest V3.
Суперечка
Зміни, внесені Google, мабуть, матимуть сенс, поки ви не почуєте іншу сторону історії, головним чином блокувальників реклами. Цю конкретну міграцію API розглядають як спосіб Google знищити блокувальники реклами, оскільки він докорінно змінює спосіб роботи одного з найпопулярніших блокувальників реклами. Це пов’язано з «теорією», згідно з якою Google мотивується до цих змін більше з точки зору бізнесу, ніж з точки зору безпеки користувачів. Зрештою, Google значною мірою залежить від реклами для отримання прибутку, а блокувальники реклами сприймаються як пряма загроза для клієнтів Google на цьому фронті, як було виявлено в Форма 10-K від Alphabet SEC за 2018 рік (через Реєстр):
Нові та існуючі технології можуть вплинути на нашу здатність налаштовувати рекламу та/або блокувати рекламу в Інтернеті, що зашкодить нашому бізнесу.
Було розроблено технології, щоб ускладнити настроювані оголошення або взагалі заблокувати показ оголошень, а деякі постачальники онлайн-сервісів мають інтегровані технології, які потенційно можуть погіршити основні функції сторонніх цифрових служб реклама. Більшу частину наших доходів Google отримує від комісій, сплачених нам у зв’язку з показом реклами в Інтернеті. У результаті такі технології та інструменти можуть негативно вплинути на наші операційні результати.
Google повинен був випустити заяву щоб вирішити це питання, повторюючи свою позицію, що зміна в інтересах конфіденційності користувачів, а не пряма атака на блокувальники реклами:
Ми не перешкоджаємо розробці блокувальників реклами чи забороняємо користувачам блокувати рекламу. Натомість ми хочемо допомогти розробникам, зокрема блокувальникам вмісту, писати розширення таким чином, щоб захистити конфіденційність користувачів.
Слід згадати два найпопулярніші блокувальники реклами, доступні в Google Chrome: uBlock Origin і Adblock Plus, обидва використовують різні підходи для досягнення однакового результату блокування вмісту. uBlock Origin значною мірою покладається на API веб-запитів, і протягом багатьох років спільнота віддала перевагу цьому розширенню. Adblock Plus та інші розширення блокування вмісту також покладаються на частину веб-запиту, що блокує, тому зміни в цьому API принаймні певною мірою вплинуть на більшість засобів блокування вмісту.
Поштовх Google припинити використання Web Request фактично знищить uBlock Origin у його поточному форматі, що справді вплине на багатьох користувачів. У той час як користувачі, які не є лояльними (і не мають наміру турбуватися про те, як досягається блокування реклами), знайдуть альтернативні рішення, які мають свої недоліки, це стане неможливим лоялісти та ентузіасти можуть розробити нові механізми фільтрації, щоб обійти різні методи, які веб-сайти зрештою придумають для боротьби з блокувальниками реклами на цьому конкретному API.
Декларативний мережевий запит також був запропонований як досить обмежений механізм фільтрації, як це було спочатку заплановано мати обмеження на 30 000 правил для статичних правил фільтрації для кожного розширення (правила, які оголошуються під час встановлення); і обмеження на 5000 правил для правил динамічного фільтрування для кожного розширення (правила, які можна додати після встановлення). Будь-які зайві правила ігноруватимуться, що є певною проблемою, оскільки сам EasyList для Adblock Plus має 70 000 правил, тоді як uBlock Origin можна налаштувати для роботи з понад 100 000 правил. Після початкової негативної реакції з боку спільноти, Google відповів пообіцявши змінити ліміт статичних правил з 30 000 правил на розширення до глобального максимуму 150 000 правил. Побічним ефектом цього є те, що користувачі не можуть використовувати інші сценарії, пов’язані з правилами, у поєднанні з блокувальником реклами, тому користувачам доведеться жонглювати зі своїми уподобаннями.
За винятком обмеженого обмеження фільтрації, декларативний мережевий запит може перенаправляти лише на статичні URL-адреси, тому немає підтримки для зіставлення шаблонів. uBlock Origin значною мірою покладається на зіставлення шаблонів і розробника розширення заявив, що дообладнати не можна алгоритм відповідності його розширення відповідно до вимог API. API також вимагатиме повного оновлення розширення, щоб просто оновити список фільтрів, що було б надто частою діяльністю, враховуючи частота оновлення цих списків фільтрів. Звичайно, ці оновлення також залежатимуть від критеріїв і процесів перевірки розширень Google.
З іншого боку, Google завжди дотримувався своєї позиції, що її намір відмовитися від веб-запиту пов’язаний з a з точки зору безпеки, оскільки API веб-запитів надто потужний у своїй поточній формі та залишає відкритим дуже широкий простір для зловживання. Це зловживання не лише теоретичним, оскільки Google зазначив, що 42% шкідливих розширень зловживали цим API. Apple Safari API блокувальника вмісту був розроблений як Declarative Net Request з подібних причин, оскільки нечесний розробник має менше можливостей для використання. На nerfed Web Request мережеві запити все одно будуть доступні для спостереження, але їм знадобляться дозволи на відповідні хости. З Manifest V3 дозволи хоста також суттєво змінюються, і їх більше не можна надавати загальним способом під час встановлення.
Google також використовував накладні витрати на продуктивність як стимул для переходу. Оцінка мережевих запитів відбувається в потоці JavaScript розширення, що може бути дорогим для продуктивності. Як спростування розробник uBlock Origin згадує, що його розширення не тягне за собою жодного значного погіршення продуктивності навіть якщо потрібно застосувати до 140 000 статичних фільтрів. Стверджується, що понесені витрати легко відшкодовуються ресурсами, які не можуть бути завантажені з віддалених серверів і тому не обробляються браузером.
Незважаючи на те, що Google не використовує це міркування, можна навести один аргумент проти веб-запиту щодо ефективності блокування реклами. За допомогою веб-запиту, якщо розширення не відповідає вчасно (через затримку або збій), мережева обробка запиту явно дозволена, що дозволяє рекламі прослизати через блокувальник реклами. Декларативний мережевий запит, з іншого боку, не страждатиме від цього недоліку. Натомість реклама пропускатиметься, якщо не потрапить у рамки статичних правил, і це траплятиметься частіше, ніж ні.
Висновок
З наведених вище пояснень стає зрозуміло, що Declarative Net Request не є функціональним клоном 1:1 для блокування можливості API веб-запитів, і розробники розширень неодмінно будуть засмучені, коли їх наполегливу роботу заважатиме такі зміни. Але міркування Google також мають вагу – веб-запит надто потужний, і його повноваження повинні бути такими обмежується через більший інтерес спільноти користувачів (яка складається з середніх користувачів разом із ентузіастів).
Перехід до декларативного мережевого запиту також міг бути позитивним піар-ходом — зрештою, Google додає вбудований API блокувальника вмісту в Chrome! Але оскільки новий API має свої суворі обмеження, спільнота справедливо сприймає це як підрізування крил. В ідеальному світі Google мав би вивчити роботу блокувальників реклами, таких як uBlock Origin, перш ніж просувати новий API. У поточному стані новий API може використовувати подальші послаблення обмежень правил, щоб адаптувати сценарії, коли користувачі бажають використовувати два розширення з великими фільтрами.
Відповідно до Реєстр, перші збірки зі змінами Manifest V3 будуть доступні з липня 2019 року. Ми сподіваємося, що Google врахує відгуки, отримані від спільноти розробників розширень, у цих збірках.
Особлива подяка головному редактору XDA Мішалу Рахману за його внески та допомогу!
Редагувати: у статті неправильно прирівняно роботу Adblock Plus до API декларативного мережевого запиту. До статті внесено відповідні зміни. На Adblock Plus також вплине видалення можливостей блокування Web Request API.