Предстоящият манифест V3 за Google Chrome Extensions ще промени начина, по който рекламните блокери работят в Chrome. Това ли е правилният път напред за рекламните блокери и Google?
Google Chrome е най-популярният междуплатформен уеб браузър, наличен на пазара в момента, претендирайки за 62,7% от глобалния дял на използване на браузъра до май 2019 г., като Safari на Apple е на второ място с 15,89%, а Firefox на Mozilla с 5,07%. Поради своя лъвски дял, най-малките промени, които Google Chrome предприема за своята платформа, в крайна сметка засягат милиони потребители по целия свят. Така че, когато Google обяви следващата версия на манифеста на разширенията под формата на Manifest V3 за Google Chrome Extensions, знаехме, че ги очакваха големи промени, особено когато стана ясно, че Google изгражда API за блокиране на съдържание в Chrome себе си.
Какво е Manifest V3?
Ако сте активен потребител на Chrome, несъмнено използвате няколко разширения. Разширенията са малки софтуерни програми, които персонализират изживяването при сърфиране с помощта на
От края на миналата година, Google работи върху „Манифест V3“, набор от предложени промени в платформата за разширения на Chrome, които могат да бъдат класифицирани като „разрушителни промени“. Като документ за обществено обсъждане за манифест V3 състояния, версията на манифеста на разширението е механизъм за ограничаване на определени възможности до определен клас разширения. Тези ограничения могат да бъдат под формата на минимална версия или максимална версия. Ограничаването до минимална версия позволява по-новите API или възможности да бъдат достъпни само за по-нови разширения докато ограничаването до максимална версия на манифеста позволява постепенно по-стари API или възможности отхвърлено.
С по-прости думи, нова версия на манифест позволява на Chrome да ограничи API и функции до тази нова версия на манифеста, в за да принуди разработчиците на разширения да мигрират от определени по-стари API поради отрицателното им въздействие върху потребителя опит. Внедряването на разширение в Manifest V3 теоретично трябва да осигури по-силни гаранции от гледна точка на сигурност, поверителност и производителност.
Въпреки че има широк набор от промени, очертани в Manifest V3, най-спорната промяна е свързана с решението на Google да ограничи възможностите за блокиране, налични в съществуващия chrome.webRequest API (и фокусирайте API върху наблюдението, вместо върху блокирането) и след това представете тези блокиращи способности чрез нов chrome.declarativeNetRequest API. Тази конкретна промяна има разпалиха общността тъй като в крайна сметка се насочва към механизма за блокиране на реклами на известното разширение за блокиране на реклами, Произход на uBlock, и пряко засяга неговите 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 42% от злонамерените разширения са използвали API за уеб заявки от януари 2018 г. 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.
С Declarative Net Request Chrome не трябва да изпраща цялата информация за заявка до разширението за слушане. Вместо това разширението регистрира правила с Chrome, които предварително казват на браузъра какво да прави, ако бъдат видени определени типове заявки.
Разширението уточнява своите правила предварително. След това заявката на потребителите се съпоставя с това правило от браузъра (а не от разширението), като действието също се предприема от браузъра и страницата впоследствие се изобразява. Google споменава, че това им позволява да гарантират ефективност, тъй като могат да упражняват контрол върху алгоритъма, определящ резултата, и могат да предотвратят или деактивират неефективни правила. Той също така предоставя по-добри гаранции за поверителност на крайния потребител, тъй като детайлите на мрежовата заявка не са изложени на разширението. Тъй като постоянните и продължителни процеси вече не са необходими (тъй като правилата са регистрирани предварително), Google твърди, че този подход също така носи подобрения в производителността, които ще направят разширенията значително по-жизнеспособни при ограничени ресурси платформи.
Декларативната нетна заявка ще бъде достъпна както за Manifest V2 (текущ), така и за Manifest V3, но това ще бъде основният начин, по който Google ще позволи мрежовите заявки да бъдат модифицирани в Manifest V3.
Противоречието
Изглежда, че промените на Google имат смисъл, докато не чуете другата страна на историята, главно тази на рекламните блокери. Тази конкретна миграция на API се разглежда като начин на Google да унищожи рекламните блокери, тъй като фундаментално променя начина, по който работи един от най-популярните рекламни блокери. Това е свързано с „теорията“, че Google е мотивиран към тази промяна повече от бизнес гледна точка, отколкото от гледна точка на сигурността на потребителите. В края на краищата Google разчита в голяма степен на рекламата за приходите си и рекламните блокери се възприемат като пряка заплаха за клиентите на Google на този фронт, както беше разкрито чрез Формуляр 10-K на Alphabet за 2018 г. SEC (чрез Регистърът):
Нови и съществуващи технологии могат да повлияят на способността ни да персонализираме реклами и/или да блокираме реклами онлайн, което би навредило на бизнеса ни.
Бяха разработени технологии, за да направят персонализираните реклами по-трудни или да блокират напълно показването на реклами и някои доставчици от онлайн услугите имат интегрирани технологии, които потенциално биха могли да навредят на основната функционалност на цифровите услуги на трети страни реклама. По-голямата част от приходите ни от Google произтичат от такси, плащани ни във връзка с показването на реклами онлайн. В резултат на това такива технологии и инструменти могат да повлияят неблагоприятно на нашите оперативни резултати.
Google трябваше публикувайте изявление за да отговори на това, повтаряйки позицията си, че промяната е в интерес на поверителността на потребителите, а не директна атака срещу рекламни блокери:
Ние не предотвратяваме разработването на рекламни блокери или спираме потребителите да блокират реклами. Вместо това искаме да помогнем на разработчиците, включително програмите за блокиране на съдържание, да пишат разширения по начин, който защитава поверителността на потребителите.
Трябва да се направи справка с два от най-популярните рекламни блокери, налични в Google Chrome: Произход на uBlock и Adblock Plus, като и двете използват различни подходи за постигане на същия резултат от блокиране на съдържание. uBlock Origin разчита до голяма степен на API за уеб заявки и общността е предпочела това разширение през годините. Adblock Plus и други разширения за блокиране на съдържание също разчитат на блокиращата част на Web Request, така че промените в този API в крайна сметка ще засегнат повечето блокери на съдържание поне в някакъв капацитет.
Стремежът на Google да отмени Web Request по същество ще убие uBlock Origin в текущия му формат, нещо, което наистина ще засегне много потребители. Въпреки че потребителите без лоялност (и без намерение да се занимават с това как се постига рекламният блок) ще намерят алтернативни решения, които идват със собствените си недостатъци, това ще стане невъзможно за лоялисти и ентусиасти да измислят нови дизайни на филтриращи машини, за да заобиколят различните техники, които уеб сайтовете в крайна сметка ще измислят, за да се борят с рекламните блокери на този специфичен API.
Беше предложено също така, че Declarative Net Request е доста ограничен двигател за филтриране, какъвто беше първоначално планирано да има ограничение от 30 000 правила за статични филтриращи правила за разширение (правила, които се декларират по време на инсталацията); и ограничение от 5000 правила за правила за динамичен филтър за всяко разширение (правила, които могат да се добавят след инсталиране). Всички излишни правила ще бъдат игнорирани, което е малко проблем, тъй като самият EasyList за Adblock Plus има 70 000 правила, докато uBlock Origin може да бъде конфигуриран да работи с над 100 000 правила. След първоначалната реакция от страна на общността, Google отговори като обещава да промени лимита на статичните правила от 30 000 правила за разширение до глобален максимум от 150 000 правила. След това това има страничен ефект, като не позволява на потребителите да използват други скриптове, натоварени с правила, заедно с рекламен блокер, така че потребителите ще трябва да жонглират с предпочитанията си.
Освен ограниченото ограничение за филтриране, Декларативна нетна заявка може да пренасочва само към статични URL адреси, така че няма включена поддръжка за съвпадение на шаблони. uBlock Origin силно разчита на съвпадение на шаблони и разработчика на разширението заяви, че не е възможно да се преоборудва алгоритъм за съвпадение на неговото разширение, за да отговори на изискването за API. API също ще изисква пълна актуализация на разширението, за да актуализира просто списъка с филтри, което би било твърде честа дейност, като се има предвид честотата, с която тези списъци с филтри се актуализират. Разбира се, тези актуализации също ще зависят от критериите и процесите за преглед на разширенията на Google.
От друга страна, Google винаги е поддържал позицията си, че намерението му да се оттегли от Web Request е от 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 също имат тежест - уеб заявката е твърде мощна и нейните правомощия трябва да бъдат ограничени в по-големия интерес на потребителската общност (която се състои от средни потребители заедно с ентусиасти).
Преминаването към декларативна мрежова заявка също можеше да бъде положителен PR ход - в крайна сметка Google добавя вграден API за блокиране на съдържание към Chrome! Но тъй като новият API идва със собствени тежки ограничения, общността с право вижда това като подрязване на крилата. В един идеален свят Google трябваше да е проучил работата на рекламни блокери като uBlock Origin, преди да прокара новия API. Както е сега, новият API може да използва допълнителни облекчения на ограниченията на правилата си, за да приспособи сценарии, при които потребителите биха искали да използват две разширения с голям филтър.
Според Регистърът, първите компилации с промени в Manifest V3 ще бъдат налични от юли 2019 г. нататък. Надяваме се, че Google ще съобрази обратната връзка, получена от общността на разработчиците на разширения, с тези компилации.
Специални благодарности на главния редактор на XDA Мишал Рахман за неговия принос и помощ!
Редактиране: Статията неправилно приравнява работата на Adblock Plus с тази на Declarative Net Request API. Статията е съответно изменена. Adblock Plus също ще бъде засегнат от премахването на възможностите за блокиране на Web Request API.