Google продължава да настоява за ограничаване на API, изискван от рекламните блокери

Симеон Винсент, защитник на разработчиците на разширения за Chrome, ръководител на екипа на Chrome, коментира Текущата позиция на Google относно третата ревизия на манифеста на Chrome, нарушаващи работа много добавки за блокиране на неподходящо съдържание и гарантиране на сигурност. Компанията не възнамерява да се откаже от първоначалния план за спиране на поддръжката на блокиращия режим на работа на webRequest API, който ви позволява да променяте приетото съдържание в движение. Изключение ще бъде направено само за корпоративното издание на Chrome (Chrome за предприятия), което ще запази поддръжката на API на webRequest непокътната.

За редовни потребители на API на Chrome webRequest ще бъде ограничен до режим само за четене. Беше предложен декларативен API, който да замени API на webRequest за филтриране на съдържание declarativeNetRequest, който обхваща само ограничена част от функциите, използвани в съвременните рекламни блокери. Всъщност, вместо собствени манипулатори, които имат пълен достъп до мрежовите заявки, се предлага готов универсален вграден филтърен двигател, който сам обработва правилата за блокиране. Например declarativeNetRequest API не ви позволява да използвате свои собствени алгоритми за филтриране и не ви позволява да създавате сложни правила, които се припокриват едно с друго в зависимост от условията.

Разработчиците на добавки за блокиране на реклами са подготвили съвместно списък със забележки, който изброява недостатъците на declarativeNetRequest API. Google се съгласи с много от коментарите и добави declarativeNetRequest API. По-специално, добавена е поддръжка за динамична промяна и добавяне на правила и е възможно да се премахнат HTTP заглавките, но само тези в белия списък (Referer, Cookie, Set-Cookie). Има планове за внедряване на поддръжка за добавяне и замяна на HTTP заглавки (например за заместване на директиви Set-Cookie и CSP) и възможност за премахване и замяна на параметри на заявка.

Черновата на третата версия на манифеста, която определя списъка с функции и ресурси, предоставени от добавките на Chrome, се планира да се използва за тестване в експериментални компилации на Chrome Canary през следващите месеци.

В същото време мотивацията за забрана на промени в приетото съдържание чрез webRequest API остава не съвсем ясна. Твърденията, че режимът на блокиране на API на webRequest има отрицателно въздействие върху производителността, тъй като браузърът изчаква завършването на манипулатора за завършване, преди страницата да бъде изобразена, не издържат на проверка. Преди това се проведе Тестове Ефективността на добавките за блокиране на реклами показа, че въведената от тях латентност е незначителна. Средно използването на блокер забавя изпълнението на заявка само с част от милисекунди, което е незначително на общия фон.

Вторият аргумент, свързан с желанието да се защитят потребителите от неконтролиран достъп до добавки за съдържание, също не изглежда убедителен, тъй като вместо да премахнете отдавна установената и обща функционалност в легитимните добавки, можете да добавите нов тип разрешение и дайте на потребителя окончателния избор, инсталирайте добавка, която има пълен достъп до мрежовите заявки или не. В допълнение, Google остави поддръжката за използване на webRequest API в режим само за четене, което позволява пълен мониторинг на трафика, но не и намеса на ниско ниво в него.
Добавките могат да променят съдържанието на изтеглените уеб страници чрез други API (например злонамерените добавки все още могат да доставят своите реклами, да изпълняват копачи и да анализират съдържанието на формулярите за въвеждане).

Реймънд Хил, автор на системите за блокиране на нежелано съдържание uBlock Origin и uMatrix, е достатъчно твърд коментира отговорът на представител на Google и намекна за демагогия и задкулисни игри, в които Google, под прикритието на добра възможност, се опитва да прокара своите бизнес интереси в областта на онлайн рекламата, да получи контрол над своите филтриращи механизми и оправдават тези действия в очите на широката общественост.

Той така и не получи убедителни аргументи за необходимостта от спиране на широко използваното и популярно API сред разработчиците на добавки. Според Реймънд влошаването на производителността не е аргумент, тъй като страниците се зареждат бавно поради тяхното раздуване, а не поради използването на блокиращ режим на webRequest в правилно внедрени добавки. Ако Google наистина се интересуваше от производителността, те щяха да преработят webRequest въз основа на Promise, по аналогия с изпълнение webRequest във Firefox.

Според Реймънд стратегията на Google е да намери правилния баланс между разширяването на потребителската база на Chrome и бизнес щетите, причинени от използването на блокери за съдържание. На първия етап от разширяването на Chrome Google трябваше да се примири с рекламните блокери като една от най-популярните добавки сред потребителите. Но след като Chrome придоби господство, компанията се опита да наклони баланса в своя полза и да придобие контрол върху блокирането чрез популяризиране инициатива за вграждане на неподходящо блокиране на реклами в Chrome. WebRequest API проваля тази цел, тъй като контролът върху блокирането на съдържание вече е в ръцете на разработчици на трети страни за блокиране на реклами.

Източник: opennet.ru