Prihajajoči Manifest V3 za razširitve za Google Chrome bo spremenil delovanje zaviralcev oglasov v Chromu. Je to prava pot naprej za zaviralce oglasov in Google?
Google Chrome je najbolj priljubljen spletni brskalnik za več platform, ki je trenutno na voljo na trgu, zahteva 62,7 % svetovnega deleža uporabe brskalnika do maja 2019, pri čemer je Applov Safari na drugem mestu s 15,89 % in Mozillin Firefox s 5,07 %. Zaradi njegovega levjega deleža že najmanjše spremembe, ki jih Google Chrome naredi za svojo platformo, na koncu prizadenejo milijone uporabnikov po vsem svetu. Ko je Google napovedal naslednjo različico manifesta razširitev v obliki Manifesta V3 za razširitve Google Chrome, smo vedeli, da čakalo nekaj velikih sprememb, zlasti ko se je izvedelo, da Google v Chromu vgrajuje API za blokiranje vsebine sama.
Kaj je Manifest V3?
Če ste aktivni uporabnik Chroma, nedvomno uporabljate nekaj razširitev. Razširitve so majhni programi, ki prilagodijo izkušnjo brskanja z uporabo API-ji, ki jih ponuja brskalnik
, kar uporabnikom omogoča, da prilagodijo funkcionalnost in vedenje svojim individualnim potrebam in željam. Te razširitve se distribuirajo predvsem prek Spletna trgovina Chrome, kjer je več kot 180.000 razširitev.Od konec lanskega leta, je Google delal na »Manifestu V3«, naboru predlaganih sprememb platforme razširitev za Chrome, ki jih lahko označimo kot »odlomne spremembe«. Kot je dokument javne razprave za Manifest V3 stanja je različica manifesta razširitve mehanizem za omejevanje določenih zmogljivosti na določen razred razširitev. Te omejitve so lahko v obliki najnižje ali največje različice. Omejitev na najnižjo različico omogoča, da so novejši API-ji ali zmogljivosti na voljo samo novejšim razširitvam medtem ko omejitev na najvišjo različico manifesta omogoča postopno uničenje starejših API-jev ali zmogljivosti zastarel.
Preprosteje rečeno, nova različica manifesta omogoča Chromu, da omeji API-je in funkcije na to novo različico manifesta v da bi razvijalce razširitev prisilili k selitvi z nekaterih starejših API-jev zaradi njihovega negativnega vpliva na uporabnika izkušnje. Implementacija razširitve v Manifest V3 bi morala teoretično zagotoviti močnejša jamstva z vidika varnosti, zasebnosti in zmogljivosti.
Medtem ko je v Manifestu V3 predstavljen širok razpon sprememb, se najbolj kontroverzna sprememba nanaša na Googlovo odločitev, da omeji zmožnosti blokiranja, ki so prisotne v obstoječem chrome.webRequest API (in osredotočite API na opazovanje namesto na blokiranje) in nato predstavite te zmožnosti blokiranja prek novega chrome.declarativeNetRequest API. Ta posebna sprememba ima podžgala skupnost ker na koncu cilja na mehanizem za blokiranje oglasov znane razširitve za blokiranje oglasov, uBlock Izvor, in neposredno vpliva na njegovih 10 milijonov+ uporabnikov.
Preden se lotimo tega vprašanja, si poglejmo, kako webRequest API primerja z deklarativnaNetRequest API.
API za spletne zahteve in API za deklarativne mrežne zahteve
Prisoten
Uradni opis spletne zahteve opisuje API na naslednji način:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
S spletno zahtevo Chrome pošlje vse podatki v omrežni zahtevi razširitvi, ki jih posluša. Razširitev ima nato možnost oceniti zahtevo in Chromu dati navodila, kaj naj naredi z zahtevo: dovoli, blokira ali pošlje z nekaj spremembami.
Sledite zaporedju dogodkov, da razumete, kaj se dogaja, ko razširitve uporabljajo API za spletne zahteve. Ko uporabnik z nameščeno razširitvijo spletne zahteve klikne povezavo, Chrome obvesti razširitev, da je bila podana zahteva za podatke, preden zahteva doseže strežnik. Razširitev se lahko na tej stopnji odloči za spremembo zahteve. Strežnik se nato odzove, vendar gre odgovor še enkrat skozi razširitev in razširitev lahko narekuje, ali je treba odziv spremeniti. Chrome nato končno upodobi stran in uporabnik si lahko ogleda rezultat svojega klika.
Ko Chrome preda vse podatke v omrežni zahtevi, imajo razširitve, ki uporabljajo API za spletne zahteve, dostop do branja in spreminjanja vsega, kar uporabnik počne v spletu. Medtem ko blokatorji vsebine, kot je uBlock Origin, modro izkoriščajo potencial tega API-ja, Google trdi, da druge razširitve z zlonamernimi nameni so jih zlorabile za dostop do osebnih podatkov uporabnikov informacije. Po podatkih Googla je 42 % zlonamernih razširitev od januarja 2018 uporabljalo API za spletne zahteve. Google prav tako trdi, da so z API-jem kot različico za blokiranje povezani "znatni stroški delovanja". za to je potreben vztrajen in pogosto dolgotrajen proces, ki je načeloma nezdružljiv z "lenim" procesov.
Z Manifestom V3 Google predlaga omejitev tega API-ja v obliki blokiranja. Kot alternativo Google ponuja API za deklarativne mrežne zahteve.
Prihodnost
Uradni opis Declarative Net Request opisuje API na naslednji način:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Z deklarativno mrežno zahtevo Chromu ni treba poslati vseh informacij o zahtevi razširitvi za poslušanje. Namesto tega razširitev registrira pravila v Chromu, ki brskalniku vnaprej povedo, kaj naj stori, če opazi določene vrste zahtev.
Razširitev vnaprej določa svoja pravila. Zahtevo uporabnikov nato brskalnik (in ne razširitev) primerja s tem pravilom, brskalnik prav tako izvede dejanje in stran se nato upodobi. Google omenja, da jim to omogoča zagotavljanje učinkovitosti, saj lahko izvajajo nadzor nad algoritmom, ki določa rezultat, in lahko preprečijo ali onemogočijo neučinkovita pravila. Končnemu uporabniku nudi tudi boljše jamstvo za zasebnost, saj podrobnosti omrežne zahteve niso izpostavljene razširitvi. Ker vztrajni in dolgotrajni procesi niso več potrebni (ker so pravila registrirana vnaprej), Google trdi, da ta pristop prinaša tudi izboljšave zmogljivosti, zaradi katerih bodo razširitve znatno bolj izvedljive pri omejenih virih platforme.
Deklarativna mrežna zahteva bo na voljo za Manifest V2 (trenutni) in Manifest V3, vendar bo to primarni način, na katerega bo Google dovolil spreminjanje omrežnih zahtev v Manifestu V3.
Polemika
Googlove spremembe se zdijo smiselne, dokler ne slišite druge strani zgodbe, predvsem tiste o zaviralcih oglasov. Na to posebno selitev API-ja se gleda kot na Googlov način za odpravo blokatorjev oglasov, saj bistveno spremeni način delovanja enega najbolj priljubljenih blokatorjev oglasov. To je povezano s "teorijo", da je Google bolj motiviran za to spremembo s poslovnega vidika kot z vidika varnosti uporabnikov. Konec koncev je Google za svoje prihodke močno odvisen od oglaševanja, zaviralci oglasov pa se na tem področju dojemajo kot neposredna grožnja za Googlove stranke, kot je bilo razkrito v Alphabetov obrazec SEC 2018 10-K (prek Register):
Nove in obstoječe tehnologije bi lahko vplivale na našo zmožnost prilagajanja oglasov in/ali blokirale spletne oglase, kar bi škodilo našemu poslovanju.
Razvite so bile tehnologije, ki otežujejo prikazovanje oglasov po meri ali popolnoma blokirajo prikazovanje oglasov in nekateri ponudniki spletnih storitev ima vgrajene tehnologije, ki bi lahko škodile osnovni funkciji digitalnih storitev tretjih oseb oglaševanje. Večino naših prihodkov Google izhaja iz pristojbin, ki nam jih plačate v zvezi s prikazovanjem oglasov na spletu. Posledično lahko takšne tehnologije in orodja negativno vplivajo na naše poslovne rezultate.
Google je moral objavi izjavo za obravnavo tega, pri čemer ponavlja svoje stališče, da je sprememba v interesu zasebnosti uporabnikov in ne neposredni napad na zaviralce oglasov:
Ne preprečujemo razvoja blokatorjev oglasov ali preprečujemo uporabnikom blokiranja oglasov. Namesto tega želimo pomagati razvijalcem, vključno z blokatorji vsebine, pri pisanju razširitev na način, ki ščiti zasebnost uporabnikov.
Omeniti je treba dva izmed najbolj priljubljenih zaviralcev oglasov, ki sta na voljo v Google Chromu: uBlock Izvor in Adblock Plus, pri čemer oba uporabljata različne pristope, da dosežeta enak rezultat blokiranja vsebine. uBlock Origin se v veliki meri opira na Web Request API in skupnost je v preteklih letih dala prednost tej razširitvi. Adblock Plus in druge razširitve za blokiranje vsebine se prav tako zanašajo na blokirni del spletne zahteve, zato bodo spremembe tega API-ja vsaj v določeni meri vplivale na večino blokatorjev vsebine.
Googlovo prizadevanje za opustitev spletne zahteve bo v bistvu uničilo uBlock Origin v njegovi trenutni obliki, nekaj, kar bo dejansko vplivalo na veliko uporabnikov. Medtem ko bodo uporabniki brez zvestobe (in brez namena, da bi se obremenjevali s tem, kako se doseže blokada oglasov) našli alternativne rešitve, ki imajo lastne pomanjkljivosti, bo postalo nemogoče za zveste in navdušence, da pripravijo nove zasnove filtrirnih mehanizmov, da bi se izognili različnim tehnikam, ki jih bodo spletna mesta sčasoma pripravila za boj proti blokatorjem oglasov na tem specifičnem API-ju.
Predlagano je bilo tudi, da bo Declarative Net Request precej omejen mehanizem za filtriranje, kot je bil sprva načrtovano imeti omejitev 30.000 pravil za pravila statičnega filtra na razširitev (pravila, ki so deklarirana med namestitvijo); in omejitev 5000 pravil za pravila dinamičnega filtra na razširitev (pravila, ki jih je mogoče dodati po namestitvi). Vsa presežna pravila bodo prezrta, kar je nekoliko težava, saj ima EasyList za Adblock Plus 70.000 pravil, medtem ko je uBlock Origin mogoče konfigurirati za delovanje z več kot 100.000 pravili. Po začetnem odzivu skupnosti, Google se je odzval z obljubo, da bo spremenil omejitev statičnih pravil s 30.000 pravil na razširitev na globalno največ 150.000 pravil. To ima potem stranski učinek, da uporabnikom onemogoči uporabo drugih skriptov, ki vsebujejo težka pravila, skupaj z zaviralcem oglasov, tako da bodo morali uporabniki žonglirati s svojimi nastavitvami.
Razen omejene omejitve filtriranja, Deklarativna mrežna zahteva lahko samo preusmeri na statične URL-je, zato ni vključene podpore za ujemanje vzorcev. uBlock Origin se močno opira na ujemanje vzorcev in razvijalca razširitve izjavil, da ni možna naknadna vgradnja algoritem ujemanja njegove razširitve za izpolnjevanje zahtev API-jev. API bi zahteval tudi popolno posodobitev razširitve, da bi preprosto posodobil seznam filtrov, kar bi bila glede na pogostost posodabljanja teh seznamov filtrov. Seveda bi bile te posodobitve odvisne tudi od Googlovih meril in postopkov pregleda razširitev.
Po drugi strani pa je Google vedno vztrajal pri svojem stališču, da je njegov namen, da se odmakne od spletne zahteve, od a varnostnega vidika, saj je API spletne zahteve v svoji trenutni obliki preveč zmogljiv in pušča zelo širok prostor za zloraba. Ta zloraba ni samo teoretična, saj je Google omenil, da je 42 % zlonamernih razširitev zlorabilo ta API. Apple Safari API za blokiranje vsebine je bil zasnovan kot Declarative Net Request iz podobnih razlogov, saj je manj prostora za izkoriščanje lažnega razvijalca. Na nerfed Web Request bi bilo omrežne zahteve še vedno mogoče opazovati, vendar bi potrebovale dovoljenja za ustrezne gostitelje. Z Manifestom V3 se tudi dovoljenja gostitelja bistveno spremenijo in jih ni več mogoče dodeliti na splošni način med namestitvijo.
Google je kot motivator za prehod uporabil tudi režijske stroške delovanja. Vrednotenje omrežnih zahtev poteka v niti JavaScript razširitve, kar je lahko drago za delovanje. Kot zavrnitev razvijalec uBlock Origin omenja, da njegova razširitev ne povzroči nobene pomembne kazni za uspešnost tudi če je treba uveljaviti kar 140.000 statičnih filtrov. Nastali stroški naj bi se zlahka povrnili z viri, ki jim je preprečen prenos z oddaljenih strežnikov in jih brskalnik zato ne obdeluje.
Čeprav Google ne uporablja tega sklepanja, je en argument proti spletni zahtevi mogoče navesti tudi za učinkovitost pri blokiranju oglasov. Če se pri spletni zahtevi razširitev ne odzove pravočasno (zaradi zakasnitve ali zrušitve), je zahteva za omrežno obravnavanje očitno dovoljena, kar omogoča, da oglasi zdrsnejo skozi zaviralec oglasov. Po drugi strani Declarative Net Request ne bi imela te pomanjkljivosti. Namesto tega bodo oglasi šli skozi, če se ne ujamejo v statična pravila, in to se bo zgodilo pogosteje kot ne.
Zaključek
Iz zgornjih razlag je jasno, da Declarative Net Request ni funkcionalni klon 1:1 za blokiranje zmožnosti vmesnika Web Request API, razvijalci razširitev pa bodo zagotovo jezni, ko bo njihovo trdo delo ovirano takšne spremembe. Vendar ima tudi Googlova utemeljitev težo – spletna zahteva je premočna, njena pooblastila pa morajo biti omejeno v večjem interesu skupnosti uporabnikov (ki jo sestavljajo povprečni uporabniki skupaj z navdušenci).
Premik k Declarative Net Request bi lahko bil tudi pozitivna PR poteza – navsezadnje Google Chromu dodaja vgrajen API za blokiranje vsebine! Ker pa ima novi API svoje stroge omejitve, skupnost to upravičeno vidi kot pristriženo krilo. V idealnem svetu bi moral Google raziskati delovanje zaviralcev oglasov, kot je uBlock Origin, preden je uvedel nov API. Kot je zdaj, bi novi API lahko uporabil dodatne sprostitve svojih omejitev pravil, da bi se prilagodil scenarijem, kjer bi uporabniki želeli uporabiti dve razširitvi, ki sta zahtevni za filtriranje.
Po navedbah Register, bodo prve različice s spremembami Manifesta V3 na voljo od julija 2019 naprej. Upamo, da bo Google s temi različicami upošteval povratne informacije, ki jih je prejela od skupnosti razvijalcev razširitev.
Posebna zahvala glavnemu uredniku XDA Mishaalu Rahmanu za njegove prispevke in pomoč!
Urejanje: članek je napačno enačil delovanje Adblock Plus z API-jem Declarative Net Request. Člen je bil ustrezno spremenjen. Na Adblock Plus bo vplivala tudi odstranitev zmožnosti blokiranja Web Request API.