Chystaný Manifest V3 pro rozšíření Google Chrome změní fungování blokátorů reklam v prohlížeči Chrome. Je toto správná cesta vpřed pro blokátory reklam a Google?
Google Chrome je nejpopulárnější multiplatformní webový prohlížeč dostupný na trhu právě teď, nárokuje si 62,7 % podílu na celosvětovém používání prohlížečů až do května 2019, přičemž Safari od Applu se umístilo na druhém místě s 15,89 % a Firefox od Mozilly si připsal 5,07 %. Díky svému lvímu podílu se i ty nejmenší změny, které Google Chrome pro svou platformu provádí, dotknou milionů uživatelů po celém světě. Když tedy Google oznámil další verzi manifestu rozšíření ve formě Manifest V3 pro rozšíření Google Chrome, věděli jsme, že došlo k velkým změnám, zejména když vyšlo najevo, že Google zabudoval do Chromu API pro blokování obsahu sám.
Co je Manifest V3?
Pokud jste aktivním uživatelem Chrome, nepochybně používáte několik rozšíření. Rozšíření jsou malé softwarové programy, které přizpůsobují procházení webu pomocí API, které prohlížeč poskytuje
, což uživatelům umožňuje přizpůsobit funkčnost a chování tak, aby vyhovovaly jejich individuálním potřebám a preferencím. Tato rozšíření jsou distribuována především prostřednictvím Internetový obchod Chrome, která je domovem více než 180 000 rozšíření.Od té doby koncem minulého rokuGoogle pracuje na „Manifest V3“, souboru navrhovaných změn platformy Chrome Extensions, které lze klasifikovat jako „přelomové změny“. Jako dokument veřejné diskuse pro Manifest V3 stavů, verze manifestu rozšíření je mechanismus pro omezení určitých schopností na určitou třídu rozšíření. Tato omezení mohou mít podobu buď minimální verze, nebo maximální verze. Omezení na minimální verzi umožňuje, aby byly novější API nebo funkce dostupné pouze pro novější rozšíření zatímco omezení na maximální verzi manifestu umožňuje postupné přidávání starších API nebo schopností zastaralé.
Jednodušeji řečeno, nová verze manifestu umožňuje Chromu omezit rozhraní API a funkce na tuto novou verzi manifestu s cílem donutit vývojáře rozšíření k migraci z určitých starších rozhraní API kvůli jejich negativnímu dopadu na uživatele Zkušenosti. Implementace rozšíření v Manifest V3 by teoreticky měla poskytnout silnější záruky z hlediska bezpečnosti, soukromí a výkonu.
I když je v Manifestu V3 naznačena široká škála změn, nejkontroverznější změna se týká rozhodnutí společnosti Google omezit blokovací schopnosti existujících chrome.webRequest API (a zaměřit API na pozorování místo na blokování) a poté tyto blokovací schopnosti prezentovat prostřednictvím nového chrome.declarativeNetRequest API. Tato konkrétní změna má roznítil komunitu jak to skončí zacílením na mechanismus blokování reklam známého rozšíření pro blokování reklam, uBlock Origina přímo ovlivňuje více než 10 milionů uživatelů.
Než se budeme zabývat tímto problémem, podívejme se, jak to webRequest API srovnává s deklarativníNetRequest API.
Web Request API a Declarative Net Request API
Přítomnost
Oficiální popis Web Request popisuje API následovně:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Pomocí webového požadavku Chrome odesílá Všechno data v síťovém požadavku na pobočku, která na ně naslouchá. Rozšíření pak má šanci vyhodnotit požadavek a instruovat Chrome, co má s požadavkem udělat: povolit, zablokovat nebo odeslat s určitými úpravami.
Postupujte podle sekvence událostí, abyste pochopili, co se děje, když rozšíření používají rozhraní Web Request API. Když uživatel s nainstalovaným rozšířením Web Request klikne na odkaz, Chrome informuje rozšíření o tom, že byl podán požadavek na data, než požadavek dorazí na server. Rozšíření se může rozhodnout v této fázi požadavek upravit. Server poté odpoví, ale odpověď znovu prochází rozšířením a rozšíření může diktovat, zda je třeba odpověď upravit. Chrome poté stránku konečně vykreslí a uživatel si může prohlédnout výsledek své akce kliknutí.
Jak Chrome předává všechna data v síťovém požadavku, rozšíření, která používají rozhraní Web Request API, mají přístup ke čtení a úpravě všeho, co uživatel na webu dělá. Takže zatímco blokátory obsahu jako uBlock Origin moudře využívají potenciál tohoto API, Google to tvrdí jiná rozšíření se zlými úmysly totéž zneužili k získání přístupu k osobním údajům uživatelů informace. Podle společnosti Google od ledna 2018 používá rozhraní Web Request API 42 % škodlivých rozšíření. Google také tvrdí, že s API jako blokující verzí jsou spojeny „významné náklady na výkon“. vyžaduje trvalý a často dlouhotrvající proces, který je zásadně neslučitelný s „líným“ procesy.
S Manifestem V3 Google navrhuje omezit toto API v jeho blokovací podobě. Jako alternativu Google poskytuje rozhraní Declarative Net Request API.
Budoucnost
Oficiální popis Declarative Net Request popisuje API následovně:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Díky Declarative Net Request nemusí Chrome odesílat všechny informace o požadavku do naslouchacího rozšíření. Místo toho rozšíření registruje pravidla v prohlížeči Chrome, která prohlížeči předem sdělují, co má dělat, když jsou vidět určité typy požadavků.
Rozšíření předem specifikuje svá pravidla. Požadavek uživatelů je pak porovnán s tímto pravidlem prohlížečem (a nikoli rozšířením) a akci také provede prohlížeč a stránka je následně vykreslena. Google uvádí, že jim to umožňuje zajistit efektivitu, protože mohou vykonávat kontrolu nad algoritmem určujícím výsledek a mohou zabránit nebo deaktivovat neefektivní pravidla. Poskytuje také lepší záruky ochrany soukromí pro koncového uživatele, protože podrobnosti o síťovém požadavku nejsou vystaveny rozšíření. Vzhledem k tomu, že přetrvávající a dlouhotrvající procesy již nejsou nutné (protože pravidla jsou registrována předem), Google to tvrdí tento přístup také přináší vylepšení výkonu, díky kterým budou rozšíření výrazně životaschopnější s omezenými zdroji platformy.
Declarative Net Request bude k dispozici pro Manifest V2 (aktuální) i Manifest V3, ale bude to primární způsob, jak Google umožní úpravy síťových požadavků v Manifestu V3.
Kontroverze
Zdá se, že změny Google dávají smysl, dokud neuslyšíte druhou stranu příběhu, zejména blokování reklam. Tato konkrétní migrace rozhraní API je považována za způsob, jakým Google odstraňuje blokátory reklam, protože zásadně mění způsob, jakým funguje jeden z nejpopulárnějších blokátorů reklam. To souvisí s „teorií“, že Google je k této změně motivován spíše z obchodního hlediska než z hlediska bezpečnosti uživatelů. Koneckonců, Google je ve svých příjmech silně závislý na reklamě a blokátory reklam jsou na této frontě vnímány jako přímá hrozba pro klienty Google, jak bylo odhaleno prostřednictvím Formulář 10-K společnosti Alphabet pro rok 2018 (přes Registrace):
Nové a stávající technologie by mohly ovlivnit naši schopnost přizpůsobovat reklamy a/nebo by mohly blokovat reklamy online, což by poškodilo naše podnikání.
Byly vyvinuty technologie, které znesnadňují přizpůsobitelné reklamy nebo zcela blokují zobrazování reklam a někteří poskytovatelé online služeb mají integrované technologie, které by mohly potenciálně narušit základní funkce digitálních služeb třetích stran reklamní. Většina našich příjmů Google pochází z poplatků, které nám platíme v souvislosti se zobrazováním reklam online. V důsledku toho by takové technologie a nástroje mohly nepříznivě ovlivnit naše provozní výsledky.
Google musel vydat prohlášení aby to vyřešil tím, že opakuje svůj postoj, že změna je v zájmu soukromí uživatelů a ne přímým útokem proti blokátorům reklam:
Nebráníme vývoji blokovačů reklam ani nebráníme uživatelům v blokování reklam. Místo toho chceme vývojářům, včetně blokátorů obsahu, pomoci psát rozšíření způsobem, který chrání soukromí uživatelů.
Je třeba zmínit dva z nejpopulárnějších blokátorů reklam dostupných v prohlížeči Google Chrome: uBlock Origin a Adblock Plus, které oba používají různé přístupy k dosažení stejného výsledku blokování obsahu. uBlock Origin silně spoléhá na Web Request API a komunita toto rozšíření v průběhu let preferovala. Adblock Plus a další rozšíření pro blokování obsahu také spoléhají na blokovací část Web Request, takže změny tohoto API nakonec ovlivní většinu blokátorů obsahu alespoň do určité míry.
Snaha společnosti Google zavrhnout Web Request v podstatě zabije uBlock Origin v jeho současném formátu, což skutečně ovlivní mnoho uživatelů. Zatímco uživatelé bez loajality (a bez úmyslu obtěžovat se tím, jak je blokování reklam dosaženo) najdou alternativní řešení, která mají své vlastní nevýhody, bude nemožné pro loajalisty a nadšence, aby přišli s novými návrhy filtrovacích enginů, aby obešli různé techniky, se kterými webové stránky nakonec přijdou v boji proti blokátorům reklam na tomto specifickém API.
Declarative Net Request byl také navržen jako poněkud omezený filtrovací engine, jak tomu bylo původně plánované mít limit 30 000 pravidel pro pravidla statického filtru na rozšíření (pravidla, která jsou deklarována během instalace); a limit 5 000 pravidel pro pravidla dynamického filtru na rozšíření (pravidla, která lze přidat po instalaci). Všechna přebytečná pravidla budou ignorována, což je trochu problém, protože samotný EasyList pro Adblock Plus má 70 000 pravidel, zatímco uBlock Origin lze nakonfigurovat tak, aby běžel s více než 100 000 pravidly. Po počátečním odporu ze strany komunity, Google odpověděl slibem změnit limit statických pravidel z 30 000 pravidel na rozšíření na globální maximum 150 000 pravidel. To pak má vedlejší účinek, že uživatelům brání v používání jiných skriptů náročných na pravidla ve spojení s blokovačem reklam, takže uživatelé budou muset žonglovat se svými preferencemi.
Kromě omezeného limitu filtrování, Declarative Net Request může přesměrovat pouze na statické adresy URL, takže není zahrnuta žádná podpora pro porovnávání vzorů. uBlock Origin silně spoléhá na shodu vzorů a vývojáře rozšíření uvedl, že není možné provést dodatečnou montáž algoritmus porovnávání jeho rozšíření, aby splnil požadavek na rozhraní API. Rozhraní API by také vyžadovalo úplnou aktualizaci rozšíření, aby se jednoduše aktualizoval seznam filtrů, což by byla příliš častá aktivita vzhledem k frekvenci, s jakou jsou tyto seznamy filtrů aktualizovány. Tyto aktualizace by samozřejmě také závisely na kritériích a procesech kontroly rozšíření společnosti Google.
Na druhou stranu Google vždy zastával svůj postoj, že jeho záměr odklonit se od Web Request je z a bezpečnostní perspektivu, protože rozhraní Web Request API je ve své současné podobě příliš výkonné a ponechává pro něj velmi široký prostor zneužívání. Toto zneužití není jen teoretické, protože Google uvedl, že 42 % škodlivých rozšíření toto API zneužilo. Apple Safari Content Blocker API byl navržen jako Declarative Net Request z podobných důvodů, protože je zde menší prostor pro zneužití pro nepoctivého vývojáře. Na nerfovaném webovém požadavku by síťové požadavky byly stále pozorovatelné, ale potřebovaly by oprávnění na příslušných hostitelích. S Manifestem V3 se výrazně mění také oprávnění hostitele a nelze je již při instalaci udělovat plošně.
Google také jako motivaci k přechodu použil režii výkonu. Vyhodnocení síťových požadavků probíhá ve vláknu JavaScript rozšíření, což může být nákladné na výkon. Jako vyvrácení zmiňuje vývojář uBlock Origin, že jeho rozšíření nezpůsobuje žádnou významnou výkonnostní penalizaci i když je potřeba vynutit až 140 000 statických filtrů. Uvádí se, že vzniklé náklady mohou být snadno pokryty prostředky, které nemohou být staženy ze vzdálených serverů, a proto je prohlížeč nezpracuje.
I když Google toto zdůvodnění nepoužívá, jeden argument proti Web Request může být také použit pro efektivitu s blokováním reklam. Pokud rozšíření nereaguje včas (kvůli prodlevě nebo havárii), u webového požadavku je požadavek na zpracování sítě jasně povolen, což umožňuje reklamám proklouznout blokováním reklam. Na druhou stranu deklarativní Net Request by touto nevýhodou netrpěl. Místo toho reklamy projdou, pokud nebudou zachyceny v rámci statických pravidel, a to se stane častěji než ne.
Závěr
Z výše uvedených vysvětlení je jasné, že Declarative Net Request není funkční klon 1:1 pro blokování funkcemi rozhraní Web Request API a vývojáři rozšíření budou nutně zklamáni, když bude jejich tvrdá práce znevýhodněna takové změny. Úvahy společnosti Google však mají také váhu – Web Request je příliš výkonný a jeho pravomoci musí být omezena ve větším zájmu uživatelské komunity (která se skládá z průměrných uživatelů spolu s nadšenci).
Posun směrem k Declarative Net Request mohl být také pozitivním PR krokem – koneckonců Google přidává do Chromu vestavěné API pro blokování obsahu! Ale protože nové API přichází s vlastními těžkými omezeními, komunita to oprávněně považuje za přistřižení křídel. V ideálním světě by měl Google prozkoumat fungování blokátorů reklam, jako je uBlock Origin, než prosadí nové API. V současné podobě by nové API mohlo využít další zmírnění limitů pravidel, aby vyhovovalo scénářům, kdy by uživatelé chtěli používat dvě rozšíření s vysokým obsahem filtrů.
Podle Registrace, první sestavení se změnami Manifest V3 budou k dispozici od července 2019. Doufáme, že Google vyhoví zpětné vazbě od komunity vývojářů rozšíření s těmito sestaveními.
Zvláštní poděkování patří šéfredaktorovi XDA Mishaalu Rahmanovi za jeho příspěvky a pomoc!
Edit: Článek nesprávně přirovnal práci Adblock Plus k práci rozhraní Declarative Net Request API. Článek byl odpovídajícím způsobem upraven. Adblock Plus bude také ovlivněn odstraněním blokovacích schopností Web Request API.