Google Chrome'i laienduste eelseisev manifest V3 muudab reklaamiblokeerijate toimimist Chrome'is. Kas see on reklaamiblokeerijate ja Google'i jaoks õige tee?
Google Chrome on praegu turul kõige populaarsem platvormideülene veebibrauser, nõudes 62,7% ülemaailmsest brauseri kasutamisest kuni 2019. aasta maini, teisel kohal oli Apple'i Safari 15,89% ja Mozilla Firefox 5,07%. Lõviosa tõttu mõjutavad väikseimad muudatused, mida Google Chrome oma platvormil teeb, miljoneid kasutajaid üle maailma. Nii et kui Google teatas järgmisest laienduste manifesti versioonist Manifest V3 kujul Google Chrome'i laienduste jaoks, teadsime, et olid ees mõned suured muudatused, eriti kui tuli ilmsiks, et Google ehitas Chrome'is sisse sisublokeerija API ise.
Mis on manifest V3?
Kui olete aktiivne Chrome'i kasutaja, kasutate kahtlemata mõnda laiendust. Laiendused on väikesed tarkvaraprogrammid, mis kohandavad sirvimiskogemust kasutades API-d, mida brauser pakub, mis võimaldab kasutajatel kohandada funktsioone ja käitumist vastavalt nende individuaalsetele vajadustele ja eelistustele. Neid laiendusi levitatakse peamiselt veebisaidi kaudu
Chrome'i veebipood, mis on koduks enam kui 180 000 laiendusele.Alates eelmise aasta lõpus, Google on töötanud "Manifest V3" kallal, mis on Chrome'i laienduste platvormi kavandatud muudatuste kogum, mida saab liigitada "murdevmuudatusteks". Nagu Manifest V3 avaliku arutelu dokument väidab, et laienduse manifesti versioon on mehhanism teatud võimaluste piiramiseks teatud laiendusklassiga. Need piirangud võivad olla kas minimaalse või maksimaalse versiooni kujul. Minimaalse versiooniga piiramine võimaldab uuemad API-d või võimalused olla saadaval ainult uuematele laiendustele Maksimaalse manifesti versiooniga piiramine võimaldab vanematel API-del või võimalustel olla järk-järguline aegunud.
Lihtsamalt öeldes võimaldab uus manifesti versioon Chrome'il piirata API-sid ja funktsioone selle uue manifesti versiooniga et sundida laienduste arendajaid teatud vanematest API-dest eemalduma, kuna need mõjutavad kasutajat negatiivselt kogemusi. Laienduse rakendamine Manifest V3-s peaks teoreetiliselt andma tugevamad tagatised turvalisuse, privaatsuse ja jõudluse seisukohast.
Kuigi manifestis V3 on välja toodud suur hulk muudatusi, on kõige vastuolulisem muudatus seotud Google'i otsusega piirata olemasolevas versioonis olemasolevaid blokeerimisvõimalusi. chrome.webRequest API (ja keskenduge API-le blokeerimise asemel vaatlusele) ja seejärel esitage need blokeerimisvõimalused uue kaudu chrome.declarativeNetRequest API. See konkreetne muudatus on küttis kogukonda kuna see sihib kuulsa reklaamide blokeerimise laienduse reklaamide blokeerimismehhanismi, uBlocki päritoluja mõjutab otseselt selle 10 miljonit+ kasutajat.
Enne selle probleemi käsitlemist vaatame, kuidas webRequest API on võrreldav deklaratiivneNetRequest API.
Web Request API ja Declarative Net Request API
Praegu
Veebipäringu ametlik kirjeldus kirjeldab API-d järgmiselt.
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Web Requestiga saadab Chrome kõik võrgupäringus olevad andmed seda kuulavale laiendusele. Seejärel saab laiendus taotlust hinnata ja juhendada Chrome'i, mida päringuga teha: lubada, blokeerida või saata see mõne muudatusega.
Järgige sündmuste jada, et mõista, mis juhtub, kui laiendused kasutavad Web Request API-t. Kui kasutaja, kellel on installitud veebipäringu laiendus, klõpsab lingil, teavitab Chrome laiendust, et andmepäring on tehtud enne, kui päring jõuab serverisse. Laiendus võib selles etapis taotlust muuta. Seejärel server vastab, kuid vastus läheb veel kord laienduse kaudu ja laiendus võib dikteerida, kas vastust tuleb muuta. Seejärel renderdab Chrome lõpuks lehe ja kasutaja saab vaadata oma klõpsamise tulemust.
Kuna Chrome annab üle kõik võrgupäringu andmed, on Web Request API-d kasutavatel laiendustel juurdepääs, et lugeda ja muuta kõike, mida kasutaja veebis teeb. Ehkki sisu blokeerijad, nagu uBlock Origin, kasutavad targalt selle API potentsiaali, väidab Google, et teised pahatahtlike kavatsustega laiendused on seda kuritarvitanud, et saada juurdepääs kasutajate isiklikule teabele teavet. Google'i andmetel on 42% pahatahtlikest laiendustest alates 2018. aasta jaanuarist kasutanud Web Request API-t. Google väidab ka, et API kui blokeeriva versiooniga kaasnevad "olulised jõudluskulud". see nõuab püsivat ja sageli pikaajalist protsessi, mis on põhimõtteliselt kokkusobimatu "laiskusega" protsessid.
Manifesti V3 abil teeb Google ettepaneku piirata seda API-d selle blokeerimisvormis. Alternatiivina pakub Google Declarative Net Request API-t.
Tulevik
Deklaratiivse võrgutaotluse ametlik kirjeldus kirjeldab API-d järgmiselt.
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Deklaratiivse võrgupäringu korral ei pea Chrome saatma kogu päringu teavet kuulamislaiendile. Selle asemel registreerib laiendus Chrome'is reeglid, mis ütlevad brauserile eelnevalt, mida teha, kui nähakse teatud tüüpi päringuid.
Laiendus täpsustab oma reeglid eelnevalt. Seejärel seab brauser (ja mitte laiendus) kasutajate päringu selle reegliga vastavusse ning toimingu teeb ka brauser ning leht renderdatakse seejärel. Google mainib, et see võimaldab neil tagada tõhususe, kuna nad saavad kontrollida tulemust määravat algoritmi ning takistada või keelata ebatõhusaid reegleid. Samuti pakub see lõppkasutajale paremaid privaatsusgarantiid, kuna võrgupäringu üksikasju ei avaldata laiendusele. Kuna püsivad ja pikaajalised protsessid pole enam vajalikud (kuna reeglid on eelnevalt registreeritud), väidab Google, et see lähenemisviis toob kaasa ka jõudluse täiustused, mis muudavad laiendused oluliselt elujõulisemaks piiratud ressurssidega platvormid.
Deklaratiivne võrgutaotlus on saadaval nii manifesti V2 (praegune) kui ka manifesti V3 jaoks, kuid see on peamine viis, kuidas Google lubab Manifesti V3-s võrgutaotlusi muuta.
Vaidlus
Google'i muudatused tunduvad olevat mõistlikud, kuni kuulete loo teist poolt, peamiselt reklaamiblokeerijaid. Seda konkreetset API migratsiooni peetakse Google'i viisiks reklaamiblokeerijate hävitamiseks, kuna see muudab põhjalikult ühe populaarseima reklaamiblokeerija toimimist. See seostub "teooriaga", et Google on selle muudatuse poole motiveeritud rohkem äri- kui kasutajate turvalisuse vaatenurgast. Lõppude lõpuks sõltub Google oma tulude saamiseks suuresti reklaamist ja reklaamiblokeerijaid peetakse sellel rindel Google'i klientidele otseseks ohuks, nagu selgus Alphabeti 2018. aasta SEC-i vorm 10-K (via Register):
Uued ja olemasolevad tehnoloogiad võivad mõjutada meie võimet reklaame kohandada ja/või reklaame võrgus blokeerida, mis kahjustaks meie äri.
Välja on töötatud tehnoloogiad, mis muudavad kohandatavate reklaamide esitamise keerulisemaks või blokeerivad reklaamide kuvamise täielikult ja mõned pakkujad võrguteenustel on integreeritud tehnoloogiad, mis võivad kahjustada kolmandate osapoolte digitaalsete funktsioonide põhifunktsioone reklaam. Suurem osa meie Google'i tuludest pärineb tasudest, mida makstakse meile seoses reklaamide veebis kuvamisega. Selle tulemusena võivad sellised tehnoloogiad ja tööriistad meie tegevustulemusi negatiivselt mõjutada.
Google pidi avalda avaldus selle probleemi lahendamiseks korrates oma seisukohta, et muudatus on kasutaja privaatsuse huvides, mitte aga otsene rünnak reklaamiblokeerijate vastu:
Me ei takista reklaamiblokeerijate väljatöötamist ega takista kasutajatel reklaame blokeerimast. Selle asemel tahame aidata arendajatel, sealhulgas sisublokeerijatel, kirjutada laiendusi viisil, mis kaitseb kasutajate privaatsust.
Viidata tuleb kahele kõige populaarsemale Google Chrome'is saadaolevale reklaamiblokeerijale: uBlocki päritolu ja Adblock Plus, mis mõlemad kasutavad sisu blokeerimisel sama tulemuse saavutamiseks erinevaid lähenemisviise. uBlock Origin tugineb suuresti Web Request API-le ja kogukond on aastate jooksul seda laiendust eelistanud. Adblock Plus ja muud sisu blokeerivad laiendused tuginevad ka Web Requesti blokeerivale osale, nii et selle API muudatused mõjutavad lõppkokkuvõttes enamikku sisu blokeerijatest.
Google'i püüdlus Web Request tühistada tapab sisuliselt uBlock Origini praeguses vormingus, mis mõjutab tõepoolest paljusid kasutajaid. Kuigi kasutajad, kellel pole lojaalsust (ja ei kavatse end reklaamiblokeeringu saavutamisega vaeva näha), leiavad alternatiivseid lahendusi, millel on oma puudused, muutub see võimatuks lojalistidele ja entusiastidele, et tulla välja uute filtreerimismootorite kujundustega, et vältida erinevaid tehnikaid, mida veebisaidid lõpuks välja mõtlevad, et võidelda selle konkreetse API reklaamiblokeerijatega.
Declarative Net Request pakuti ka üsna piiratud filtreerimismootorina, nagu see oli algselt plaanitud 30 000 reegli piirang laienduse staatilise filtri reeglitele (reeglid, mis deklareeritakse paigaldamise ajal); ja 5000 reegli piirang laienduse dünaamilise filtri reeglitele (reeglid, mida saab lisada pärast installimist). Kõiki üleliigseid reegleid eiratakse, mis on natuke probleem, kuna EasyList for Adblock Plus ise sisaldab 70 000 reeglit, samas kui uBlock Origin saab seadistada töötama üle 100 000 reegliga. Pärast kogukonna esialgset vastureaktsiooni Google vastas lubades muuta staatilise reegli limiiti 30 000 reeglilt laienduse kohta ülemaailmselt maksimaalselt 150 000 reeglini. Selle kõrvalmõju on see, et kasutajad ei saa koos reklaamiblokeerijaga kasutada muid reeglipäraseid skripte, nii et kasutajad peavad oma eelistustega žongleerima.
Välja arvatud piiratud filtreerimislimiit, deklaratiivne võrgutaotlus saab suunata ainult staatilistele URL-idele, seega puudub mustri sobitamise tugi. uBlock Origin sõltub suuresti mustrite sobitamisest ja laienduse arendajast teatas, et seda ei ole võimalik tagantjärele paigaldada tema laienduse sobitusalgoritmi, et see vastaks API-de nõuetele. API vajaks ka täielikku laienduse värskendust, et lihtsalt filtriloendit värskendada, mis oleks liiga sagedane tegevus, arvestades sagedus, millega neid filtriloendeid värskendatakse. Loomulikult sõltuvad need värskendused ka Google'i laienduse ülevaatamise kriteeriumidest ja protsessidest.
Teisest küljest on Google alati säilitanud oma seisukoha, et tema kavatsus Web Requestist loobuda on turvalisuse seisukohast, kuna Web Request API on praegusel kujul liiga võimas ja jätab väga laia ruumi kuritarvitamine. See kuritarvitamine ei ole ainult teoreetiline, kuna Google on maininud, et 42% pahatahtlikest laiendustest on seda API-d kuritarvitanud. Apple Safari Sisu blokeerija API oli loodud nagu Declarative Net Request sarnastel põhjustel, kuna petturitel arendajatel on vähem ruumi. Nerfitud veebipäringu korral oleksid võrgupäringud endiselt jälgitavad, kuid neil on vaja vastavate hostide õigusi. Manifesti V3 puhul muutuvad oluliselt ka hostiõigused ja neid ei saa installimise ajal enam üldiselt anda.
Google on ülemineku motivaatorina kasutanud ka jõudluse üldkulusid. Võrgupäringute hindamine toimub laienduse JavaScripti lõimes, mis võib jõudlusele kulukaks osutuda. Vastulausena mainib uBlock Origini arendaja, et tema laiendus ei kaasne märkimisväärset sooritustrahvi isegi siis, kui jõustada on koguni 140 000 staatilist filtrit. Väidetavalt katavad kantud kulud kergesti ressursside abil, mida ei saa kaugserveritest alla laadida ja mida brauser seega ei töötle.
Kuigi Google seda arutluskäiku ei kasuta, saab ühe argumendi veebipäringu vastu esitada ka reklaamide blokeerimise tõhususe tagamiseks. Kui laiendus ei vasta õigeaegselt (viivituse või krahhi tõttu), on veebipäringu puhul võrgu käsitlemise päring selgelt lubatud, mis laseb reklaamidel reklaamiblokeerijast läbi libiseda. Declarative Net Request seevastu ei kannataks selle puuduse all. Selle asemel lähevad reklaamid läbi, kui need ei jää staatiliste reeglitega vahele, ja seda juhtub sagedamini.
Järeldus
Ülaltoodud selgitustest on selge, et Declarative Net Request ei ole 1:1 funktsioonide kloon blokeerimiseks. Web Request API võimalused ja laienduste arendajad on kindlasti ärritunud, kui nende raske töö takistab selliseid muudatusi. Kuid ka Google'i arutluskäik on kaalukas – Web Request on liiga võimas ja selle volitused peavad olema kärbitud kasutajate kogukonna (mis koosneb keskmistest kasutajatest ja entusiastid).
Liikumine deklaratiivse võrgutaotluse poole oleks võinud olla ka positiivne suhtekorraldus – lõppude lõpuks lisab Google Chrome'ile sisseehitatud sisublokeerija API! Kuid kuna uuel API-l on oma rasked piirangud, näeb kogukond seda õigustatult oma tiibade kärpimisena. Ideaalses maailmas oleks Google pidanud enne uue API kasutuselevõttu uurima reklaamiblokeerijate, nagu uBlock Origin, toimimist. Praegusel kujul võib uus API kasutada oma reeglite piirangute täiendavaid leevendusi, et kohandada stsenaariume, kus kasutajad soovivad kasutada kahte filtrirohket laiendust.
Vastavalt Register, on esimesed Manifest V3 muudatustega versioonid saadaval alates 2019. aasta juulist. Loodame, et Google võtab nende järgudega arvesse laienduste arendajate kogukonnalt saadud tagasisidet.
Eriline tänu XDA peatoimetajale Mishaal Rahmanile tema panuse ja abi eest!
Redigeerimine: artikkel võrdsustas Adblock Plusi töö valesti deklaratiivse võrgutaotluse API tööga. Artiklit on vastavalt muudetud. Adblock Plusi mõjutab ka Web Request API blokeerimisvõimaluste eemaldamine.