A közelgő Manifest V3 for Google Chrome Extensions megváltoztatja a hirdetésblokkolók működését a Chrome-ban. Ez a helyes út a hirdetésblokkolók és a Google számára?
Google Chrome jelenleg a piacon elérhető legnépszerűbb többplatformos webböngésző, a globális böngészőhasználati részesedés 62,7%-át birtokolja 2019 májusáig, az Apple Safari 15,89%-kal, a Mozilla Firefox pedig 5,07%-kal a második helyen végzett. Oroszlánrészének köszönhetően a Google Chrome által a platformon végrehajtott legkisebb változtatások felhasználók millióit érintik szerte a világon. Tehát amikor a Google bejelentette a bővítmények következő manifest verzióját a Manifest V3 for Google Chrome Extensions formájában, tudtuk, hogy nagy változások előtt álltak, különösen amikor kiderült, hogy a Google egy tartalomblokkoló API-t épít be a Chrome-ban maga.
Mi az a Manifest V3?
Ha Ön aktív Chrome-felhasználó, kétségtelenül használ néhány bővítményt. A bővítmények olyan kis szoftverprogramok, amelyek testreszabják a böngészési élményt a
A böngésző által biztosított API-k, amely lehetővé teszi a felhasználók számára, hogy a funkcionalitást és a viselkedést egyéni igényeiknek és preferenciáiknak megfelelően alakítsák. Ezeket a bővítményeket elsősorban a Chrome Internetes áruház, amely több mint 180 000 bővítménynek ad otthont.Mivel tavaly év végén, a Google a „Manifest V3”-on dolgozik, amely a Chrome Extensions platformon javasolt változtatások sorozata, amelyek „törő változásoknak” minősíthetők. Ahogy a nyilvános vitairat a Manifest V3-hoz kimondja, a kiterjesztés jegyzékváltozata egy olyan mechanizmus, amely bizonyos képességeket a kiterjesztések egy bizonyos osztályára korlátoz. Ezek a korlátozások lehetnek minimális verzió vagy maximális verzió formájában. A minimális verzióra való korlátozás lehetővé teszi, hogy az újabb API-k vagy képességek csak az újabb bővítmények számára legyenek elérhetők míg a maximális jegyzékverzióra való korlátozás lehetővé teszi a régebbi API-k vagy képességek fokozatos használatát elavult.
Egyszerűbben fogalmazva: egy új jegyzékverzió lehetővé teszi a Chrome számára, hogy az API-kat és a funkciókat erre az új jegyzékverzióra korlátozza annak érdekében, hogy a bővítményfejlesztőket arra kényszerítsék, hogy eltérjenek bizonyos régebbi API-któl, mivel azok negatív hatással vannak a felhasználóra tapasztalat. A Manifest V3 kiterjesztésének megvalósítása elméletileg erősebb garanciákat nyújthat a biztonság, az adatvédelem és a teljesítmény szempontjából.
Noha a Manifest V3 számos változtatást vázol fel, a legellentmondásosabb változás a Google azon döntésével kapcsolatos, hogy korlátozza a meglévő blokkolási képességeket. chrome.webRequest API (és az API-t a megfigyelésre összpontosítsa a blokkolás helyett), majd mutassa be ezeket a blokkoló képességeket egy újon keresztül chrome.declarativeNetRequest API. Ez a különleges változás fellázította a közösséget mivel végül a híres hirdetésblokkoló bővítmény hirdetésblokkoló mechanizmusát célozza meg, uBlock eredet, és közvetlenül érinti több mint 10 millió felhasználóját.
Mielőtt ezzel a kérdéssel foglalkoznánk, nézzük meg, hogyan a webRequest API-hoz képest deklaratívNetRequest API.
Web Request API és Declarative Net Request API
Jelen
A Web Request hivatalos leírása a következőképpen írja le az API-t:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
A webes kéréssel a Chrome küld minden a hálózati kérés adatait az azt figyelő melléknek. A bővítmény ezután kiértékeli a kérést, és utasítja a Chrome-ot, hogy mit tegyen a kéréssel: engedélyezze, blokkolja vagy elküldi bizonyos módosításokkal.
Kövesse az események sorrendjét, hogy megértse, mi történik, amikor a bővítmények a Web Request API-t használják. Amikor egy felhasználó, aki telepített Web Request bővítményt, rákattint egy hivatkozásra, a Chrome tájékoztatja a bővítményt, hogy adatkérés történt, mielőtt a kérés elérné a szervert. A kiterjesztés ebben a szakaszban módosíthatja a kérést. A szerver ezután válaszol, de a válasz ismét átmegy a kiterjesztésen, és a kiterjesztés megszabhatja, hogy módosítani kell-e a választ. A Chrome végül megjeleníti az oldalt, és a felhasználó megtekintheti kattintási műveletének eredményét.
Ahogy a Chrome átadja a hálózati kérés összes adata, a Web Request API-t használó bővítmények hozzáférhetnek ahhoz, hogy elolvassák és módosítsák mindazt, amit a felhasználó az interneten tesz. Tehát míg a tartalomblokkolók, például az uBlock Origin bölcsen kihasználják az API-ban rejlő lehetőségeket, a Google azt állítja, hogy más bővítmények rosszindulatú szándékkal visszaéltek ugyanezzel, hogy hozzáférjenek a felhasználók személyes adataihoz információ. A Google szerint 2018 januárja óta a rosszindulatú bővítmények 42%-a használta a Web Request API-t. A Google azt is állítja, hogy az API-nak mint blokkoló verziónak "jelentős teljesítményköltségei" vannak kitartó és gyakran hosszan tartó folyamatot igényel, ami alapvetően összeegyeztethetetlen a „lustával” folyamatokat.
A Manifest V3-mal a Google azt javasolja, hogy korlátozza ezt az API-t a blokkoló formájában. Alternatív megoldásként a Google biztosítja a Declarative Net Request API-t.
A jövő
A Declarative Net Request hivatalos leírása a következőképpen írja le az API-t:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
A Declarative Net Request használatával a Chrome-nak nem kell a kéréssel kapcsolatos összes információt elküldenie a figyelő bővítménynek. Ehelyett a bővítmény szabályokat regisztrál a Chrome-ban, amelyek előre megmondják a böngészőnek, hogy mit kell tennie, ha bizonyos típusú kéréseket lát.
A kiterjesztés előre meghatározza a szabályait. A felhasználók kérelmét ezután a böngésző (és nem a kiterjesztés) egyezik ezzel a szabállyal, és a műveletet a böngésző is végrehajtja, majd az oldalt ezután rendereli. A Google megemlíti, hogy ez lehetővé teszi számukra a hatékonyság biztosítását, mivel irányíthatják az eredményt meghatározó algoritmust, és megakadályozhatják vagy letilthatják a nem hatékony szabályokat. Ezenkívül jobb adatvédelmi garanciákat nyújt a végfelhasználó számára, mivel a hálózati kérés részletei nem kerülnek kiterjesztésre. Mivel a kitartó és hosszan tartó folyamatokra már nincs szükség (mivel a szabályokat előzetesen regisztrálták), a Google azt állítja, hogy ez a megközelítés teljesítményjavulásokat is hoz, amelyek jelentősen életképessé teszik a bővítményeket korlátozott erőforrások mellett platformok.
A deklaratív hálózati kérés a Manifest V2 (jelenlegi) és a Manifest V3 számára is elérhető lesz, de ez lesz az elsődleges módja annak, hogy a Google engedélyezze a hálózati kérelmek módosítását a Manifest V3-ban.
A vita
A Google változtatásai logikusnak tűnnek mindaddig, amíg meg nem halljuk a történet másik oldalát, főleg a hirdetésblokkolókat. Erre a bizonyos API-migrációra úgy tekintenek, mint a Google által a hirdetésblokkolók megölésére, mivel alapvetően megváltoztatja az egyik legnépszerűbb hirdetésblokkoló működését. Ez kapcsolódik ahhoz az "elmélethez", hogy a Google-t inkább üzleti, mintsem felhasználói biztonság motiválja ez a változás. Végtére is, a Google bevételei nagymértékben a hirdetésekre támaszkodnak, és a hirdetésblokkolókat ezen a területen közvetlen fenyegetésnek tekintik a Google ügyfelei számára, amint az kiderült Az Alphabet 2018. évi SEC 10-K űrlapja (keresztül A regisztráció):
Az új és a meglévő technológiák befolyásolhatják a hirdetések testreszabásának képességét, és/vagy blokkolhatják a hirdetéseket az interneten, ami árthat vállalkozásunknak.
Technológiákat fejlesztettek ki a személyre szabható hirdetések megnehezítésére vagy a hirdetések megjelenítésének teljes blokkolására, valamint egyes szolgáltatók Az online szolgáltatások olyan integrált technológiákkal rendelkeznek, amelyek potenciálisan ronthatják a harmadik felek digitális szolgáltatásának alapvető funkcióit hirdető. Google-bevételeink nagy része a hirdetések online megjelenítésével kapcsolatban nekünk fizetett díjakból származik. Ennek eredményeként az ilyen technológiák és eszközök hátrányosan befolyásolhatják működési eredményeinket.
A Google-nek kellett nyilatkozatot adni ennek megoldására, megismételve álláspontját, miszerint a változtatás a felhasználók adatainak védelmét szolgálja, nem pedig a hirdetésblokkolók elleni közvetlen támadás:
Nem akadályozzuk meg a hirdetésblokkolók fejlesztését, és nem akadályozzuk meg a felhasználókat abban, hogy blokkolják a hirdetéseket. Ehelyett szeretnénk segíteni a fejlesztőknek, beleértve a tartalomblokkolókat is, hogy a bővítményeket úgy írhassák meg, hogy védjék a felhasználók adatait.
Hivatkozni kell a Google Chrome-ban elérhető két legnépszerűbb hirdetésblokkolóra: uBlock eredet és Adblock Plus, mindkettő eltérő megközelítést alkalmaz a tartalomletiltás azonos eredményének elérése érdekében. Az uBlock Origin nagymértékben támaszkodik a Web Request API-ra, és a közösség az évek során ezt a bővítményt részesítette előnyben. Az Adblock Plus és más tartalomblokkoló bővítmények is a Web Request blokkoló részére támaszkodnak, így az API módosításai végül a legtöbb tartalomblokkolót érintik legalább bizonyos mértékben.
A Google azon törekvése, hogy leállítsa a Web Request alkalmazást, lényegében megöli az uBlock Origint jelenlegi formátumában, ami valóban sok felhasználót érint majd. Míg a lojalitás nélküli felhasználók (és nem szándékoznak foglalkozni azzal, hogyan valósulnak meg a hirdetésblokk) alternatív megoldásokat találnak, amelyeknek saját hátrányai vannak, ez lehetetlenné válik a hűségesek és a rajongók számára, hogy új szűrőmotor-terveket dolgozzanak ki, hogy megkerüljék azokat a különféle technikákat, amelyeket a webhelyek végül kidolgoznak, hogy leküzdjék a hirdetésblokkolókat ezen az API-n.
A Declarative Net Request is javasolták, hogy egy meglehetősen korlátozott szűrőmotor legyen, ahogy volt kezdetben tervezett 30 000-es szabálykorlátozás a bővítményenkénti statikus szűrőszabályokra (a telepítés során deklarált szabályok); és 5000 szabálykorlát a bővítményenkénti dinamikus szűrőszabályokra (a telepítés után hozzáadható szabályok). A felesleges szabályokat figyelmen kívül kell hagyni, ami egy kis probléma, mivel maga az EasyList for Adblock Plus 70 000 szabályt tartalmaz, míg az uBlock Origin több mint 100 000 szabállyal futtatható. A közösség kezdeti visszahatása után A Google válaszolt azzal az ígérettel, hogy a statikus szabálykorlátot bővítményenként 30 000 szabályról a globális maximum 150 000 szabályra módosítják. Ennek az a mellékhatása van, hogy kizárja a felhasználókat, hogy más, szigorú szabályokat tartalmazó szkripteket használjanak egy hirdetésblokkolóval együtt, így a felhasználóknak zsonglőrködniük kell a preferenciáikkal.
A korlátozott szűrési korláton kívül, deklaratív hálózati kérés csak statikus URL-ekre irányíthat át, így a mintaillesztéshez nem tartozik támogatás. Az uBlock Origin nagymértékben támaszkodik a mintaillesztésre és a bővítményfejlesztőre kijelentette, hogy nem lehet utólag beszerelni bővítményének megfelelő algoritmusa, hogy megfeleljen az API-kra vonatkozó követelménynek. Az API teljes bővítményfrissítést is igényelne a szűrőlista egyszerű frissítéséhez, ami túlságosan gyakori tevékenység lenne, figyelembe véve a a szűrőlisták frissítésének gyakorisága. Természetesen ezek a frissítések a Google bővítmény-ellenőrzési kritériumaitól és folyamataitól is függnek.
Másrészt a Google mindig is fenntartotta azt az álláspontját, hogy szándéka eltávolodni a Web Requesttől egy biztonsági szempontból, mivel a Web Request API jelenlegi formájában túl erős, és nagyon széles teret hagy visszaélés. Ez a visszaélés nem csupán elméleti jellegű, mivel a Google megemlítette, hogy a rosszindulatú bővítmények 42%-a visszaélt ezzel az API-val. Apple Safari Content Blocker API Hasonló okokból készült, mint a Declarative Net Request, mivel egy gazember fejlesztő számára kevesebb lehetőség van kihasználni. A nerfed Web Request esetén a hálózati kérések továbbra is megfigyelhetők lennének, de engedélyekre van szükségük a megfelelő gazdagépeken. A Manifest V3-mal a gazdagép-engedélyek is jelentősen megváltoznak, és a telepítéskor már nem adhatók általános módon.
A Google a teljesítmény rezsiköltségeit is felhasználta a váltás motivációjaként. A hálózati kérések kiértékelése a bővítmény JavaScript-szálában történik, ami költséges lehet a teljesítmény szempontjából. Cáfolatként az uBlock Origin fejlesztője megemlíti, hogy a kiterjesztése nem jár jelentős teljesítési bírsággal még akkor is, ha akár 140 000 statikus szűrőt kell kikényszeríteni. A felmerült költségeket állítólag könnyen megtérítik azok az erőforrások, amelyeket nem lehet letölteni távoli szerverekről, és így nem dolgozza fel a böngésző.
Bár a Google nem használja ezt az érvelést, a Web Request ellen is fel lehet hozni egy érvet a hirdetésblokkolással kapcsolatos hatékonyság érdekében. A Web Request használatával, ha egy bővítmény nem válaszol időben (késés vagy összeomlás miatt), a hálózatkezelési kérés egyértelműen engedélyezett, ami lehetővé teszi, hogy a hirdetések átcsúszjanak a hirdetésblokkolón. A Declarative Net Request viszont nem szenvedne ettől a hátránytól. Ehelyett a hirdetések átmennek, ha nem ragadják meg őket a statikus szabályokon, és ez gyakrabban fog megtörténni.
Következtetés
A fenti magyarázatokból egyértelmű, hogy a Declarative Net Request nem egy 1:1 funkcionalitás klón a blokkoláshoz. a Web Request API képességei, és a bővítmények fejlesztői biztosan zavarba jönnek, ha kemény munkájukat akadályozza ilyen változások. De a Google érvelésének is súlya van – a Web Request túlságosan erős, és annak kell lennie a felhasználói közösség (amelyben az átlagos felhasználók és a rajongók).
A Declarative Net Request felé való elmozdulás egy pozitív PR lépés is lehetett volna – elvégre a Google beépített tartalomblokkoló API-t ad a Chrome-hoz! De mivel az új API-nak megvannak a maga szigorú korlátozásai, a közösség jogosan tekinti ezt a szárnyak levágásának. Egy ideális világban a Google-nak meg kellett volna vizsgálnia az olyan hirdetésblokkolók működését, mint az uBlock Origin, mielőtt elindítaná az új API-t. Jelenlegi állapotában az új API további lazításokat alkalmazhat a szabálykorlátokon, hogy megfeleljen az olyan forgatókönyveknek, amikor a felhasználók két szűrőigényes bővítményt szeretnének használni.
Alapján A regisztráció, az első buildek a Manifest V3 változtatásokkal 2019 júliusától lesznek elérhetők. Reméljük, hogy a Google figyelembe veszi a bővítményfejlesztői közösségtől kapott visszajelzéseket ezekkel a buildekkel.
Külön köszönet az XDA főszerkesztőjének, Mishaal Rahmannak a közreműködéséért és segítségéért!
Szerkesztés: A cikk helytelenül egyenlővé tette az Adblock Plus működését a Declarative Net Request API működésével. A cikk ennek megfelelően módosult. Az Adblock Plus-ra a Web Request API blokkoló képességeinek eltávolítása is hatással lesz.