Сімяон Вінцэнт (Simeon Vincent), які адказвае ў камандзе Chrome за ўзаемадзеянне з распрацоўшчыкамі дапаўненняў (займае пасаду Extensions Developer Advocate), бягучую пазіцыю Google у стаўленні трэцяй рэдакцыі маніфеста Chrome, многіх дапаўненняў для блакавання непажаданага кантэнту і забеспячэння бяспекі. Кампанія не мае намеру адмаўляцца ад першапачатковага плана па спыненні падтрымкі блакавальнага рэжыму працы API webRequest, які дазваляе змяняць прыманы кантэнт на лета. Выключэнне будзе зроблена толькі для рэдакцыі Chrome для прадпрыемстваў (), у якіх падтрымка API webRequest будзе захавана ў ранейшым выглядзе.
Для звычайных карыстальнікаў Chrome API будзе абмежаваны рэжымам толькі для чытання. На замену API webRequest для фільтрацыі кантэнту прапанаваны дэкларатыўны API , які пакрывае толькі абмежаваную частку магчымасцяў, якія выкарыстоўваюцца ў сучасных блакіроўшчыках рэкламы. Па сутнасці замест уласных апрацоўшчыкаў, якія маюць поўны доступ да сеткавых запытаў, прапануецца гатовы ўніверсальны ўбудаваны рухавічок для фільтрацыі, уласнымі сіламі які апрацоўвае правілы блакавання. Напрыклад, API declarativeNetRequest не дазваляе выкарыстоўваць уласныя алгарытмы фільтрацыі і не дае магчымасць ствараць складаныя правілы, якія перакрываюць адзін аднаго ў залежнасці ад умоў.
Распрацоўнікі дадаткаў для блакавання рэкламы сумесна падрыхтавалі , у якім пералічылі недахопы API declarativeNetRequest. Google пагадзіўся са шматлікімі заўвагамі і дапоўніў API declarativeNetRequest. У прыватнасці, дададзена падтрымка дынамічнай змены і даданні правіл, забяспечана магчымасць выдалення HTTP-загалоўкаў, але толькі змешчаных у белым спісе (Referer, Cookie, Set-Cookie). У планах рэалізацыя падтрымкі дадання і замены HTTP-загалоўкаў (напрыклад, для падстаноўкі Set-Cookie і дырэктыў CSP) і магчымасць выдалення і замены параметраў запытаў.
Папярэдні варыянт трэцяй версіі маніфесту, які вызначае пералік магчымасцяў і рэсурсаў, якія прадстаўляюцца дапаўненням Chrome, плануецца ў бліжэйшыя месяцы прымяніць для тэсціравання ў эксперыментальных зборках Chrome Canary.
Пры гэтым застаецца не зусім зразумелай матывацыя забароны змены прыманага кантэнту праз API webRequest. Заявы, што блакуючы рэжым API webRequest негатыўна адбіваецца на прадукцыйнасці, бо перад высновай старонкі браўзэр чакае поўнага завяршэння працы апрацоўшчыка дадатку, не вытрымоўваюць крытыкі. Раней праведзеныя прадукцыйнасці дадаткаў для блакавання рэкламы паказалі, што ўносіцца імі затрымка нікчэмная. У сярэднім ужыванне блакавальніка запавольвае выкананне запыту толькі на дзелі мілісекунд, што занядбана мала на агульным фоне.
Другі аргумент, злучаны з жаданнем абараніць карыстачоў ад некантралюемага доступу дадаткаў да кантэнту, таксама не выглядае пераканаўчым, бо замест выдалення даўно якая склалася і распаўсюджанай у легітымных дадатках функцыянальнасці можна было дадаць новы тып паўнамоцтваў і падаць карыстачу канчатковы выбар, усталёўваць дадатак, які мае поўны доступ да сеткавых запытаў ці не. Акрамя таго, Google пакінуў падтрымку выкарыстання API webRequest у рэжыме толькі для чытання, які дазваляе выконваць поўны маніторынг трафіку, але не ўмешвацца ў яго на нізкім узроўні.
Змяняць жа змесціва загружаных web-старонак дадаткі могуць праз іншыя API (напрыклад, шкоднасныя дадаткі па-ранейшаму могуць пастаўляць сваю рэкламу, запускаць майнеры і аналізаваць змесціва формаў уводу).
Рэйманд Хіл (Raymond Hill), аўтар сістэм блакавання непажаданага кантэнту uBlock Origin і uMatrix, дастаткова жорстка адказ прадстаўніка Google і намякнуў на дэмагогію і закулісныя гульні, у якіх Google пад выглядам добрай магчымасці спрабуе прасунуць свае бізнэс-інтарэсы ў вобласці інтэрнэт-рэкламы, атрымаць кантроль за механізмамі яе фільтрацыі і апраўдаць гэтыя дзеянні ў вачах шырокай публікі.
Пераканаўчых довадаў у неабходнасці спынення шырока распаўсюджанага і запатрабаванага сярод распрацоўнікаў дадаткаў API ён так і не атрымаў. На думку Рэйманд падзенне прадукцыйнасці не з'яўляецца довадам, так як старонкі загружаюцца павольна з-за сваёй разадзьмутасці, а не з-за выкарыстання блакіруючага рэжыму webRequest у карэктна рэалізаваных дапаўненнях. Калі б Google хвалявала сапраўды прадукцыйнасць, яны б перарабілі webRequest на аснове механізму , па аналогіі з webRequest у Firefox.
На думку Рэйманд стратэгія Google заключаецца ў вызначэнні аптымальнага балансу паміж пашырэннем карыстацкай базы Chrome і шкодай бізнэсу, які наносіцца з-за выкарыстання блакавальнікаў кантэнту. На першым этапе экспансіі Chrome кампанія Google змушаная была мірыцца з блакавальнікамі рэкламы, як аднымі з самых запатрабаваных сярод карыстачоў дадаткаў. Але пасля таго, як Chrome заняў дамінантныя пазіцыі, кампанія паспрабавала зрушыць баланс у сваю карысць і атрымаць кантроль над блакіроўкай, пачаўшы прасоўваць. па ўбудаванні ў Chrome функцыі блакавання непрымальнай рэкламы. API webRequest мяшае дадзенай мэты, бо цяпер кантроль над блакаваннем кантнента знаходзіцца ў руках распрацоўнікаў іншых блакавальнікаў рэкламы.
Крыніца: opennet.ru