Gaidāmais Google Chrome paplašinājumu manifests V3 mainīs reklāmu bloķētāju darbību pārlūkā Chrome. Vai tas ir pareizais ceļš uz priekšu reklāmu bloķētājiem un Google?
Google Chrome ir šobrīd tirgū pieejamākā starpplatformu tīmekļa pārlūkprogramma, pretendē uz 62,7% no globālās pārlūkprogrammas lietojuma daļas līdz 2019. gada maijam, Apple Safari ierindojoties otrajā vietā ar 15,89% un Mozilla Firefox pretendējot uz 5,07%. Tā kā tā ir lielākā daļa, mazākās izmaiņas, ko Google Chrome veic savā platformā, galu galā ietekmē miljoniem lietotāju visā pasaulē. Tātad, kad Google paziņoja par nākamo paplašinājumu manifesta versiju Manifest V3 formā Google Chrome paplašinājumiem, mēs zinājām, ka bija dažas lielas izmaiņas, it īpaši, kad atklājās, ka Google pārlūkā Chrome veido satura bloķētāja API pati par sevi.
Kas ir manifests V3?
Ja esat aktīvs Chrome lietotājs, jūs neapšaubāmi izmantojat dažus paplašinājumus. Paplašinājumi ir nelielas programmatūras programmas, kas pielāgo pārlūkošanas pieredzi, izmantojot
API, ko nodrošina pārlūkprogramma, ļaujot lietotājiem pielāgot funkcionalitāti un uzvedību atbilstoši savām individuālajām vajadzībām un vēlmēm. Šie paplašinājumi tiek izplatīti galvenokārt caur Chrome interneta veikals, kurā atrodas vairāk nekā 180 000 paplašinājumu.Kopš pagājušā gada beigās, Google ir strādājis pie "Manifest V3" — Chrome paplašinājumu platformas ierosināto izmaiņu kopas, ko var klasificēt kā "pārkāpuma izmaiņas". Kā Manifesta V3 sabiedriskās apspriešanas dokuments norāda, paplašinājuma manifesta versija ir mehānisms noteiktu iespēju ierobežošanai noteiktai paplašinājumu klasei. Šie ierobežojumi var būt minimālās vai maksimālās versijas veidā. Ierobežojot līdz minimālajai versijai, jaunākas API vai iespējas būs pieejamas tikai jaunākiem paplašinājumiem vienlaikus ierobežojot līdz maksimālajai manifesta versijai, vecākām API vai iespējām ir jābūt pakāpeniskiem novecojušas.
Vienkāršāk sakot, jaunā manifesta versija ļauj pārlūkam Chrome ierobežot API un funkcijas līdz šai jaunajai manifesta versijai lai piespiestu paplašinājumu izstrādātājus pāriet no noteiktām vecākām API, jo tās negatīvi ietekmē lietotāju pieredze. Paplašinājuma ieviešanai Manifest V3 teorētiski būtu jānodrošina stingrākas garantijas no drošības, privātuma un veiktspējas viedokļa.
Lai gan Manifest V3 ir izklāstīts plašs izmaiņu klāsts, vispretrunīgākās izmaiņas ir saistītas ar Google lēmumu ierobežot bloķēšanas iespējas, kas pastāv esošajās programmās. chrome.webRequest API (un koncentrējiet API uz novērošanu, nevis bloķēšanu) un pēc tam prezentējiet šīs bloķēšanas spējas, izmantojot jaunu chrome.declarativeNetRequest API. Šīs īpašās izmaiņas ir uzbudināja sabiedrību jo tas galu galā tiek mērķēts uz slavenā reklāmu bloķēšanas paplašinājuma reklāmu bloķēšanas mehānismu, uBlock izcelsme, un tiešā veidā ietekmē vairāk nekā 10 miljonus lietotāju.
Pirms šīs problēmas risināšanas apskatīsim, kā webRequest API salīdzina ar deklaratīvaisNetRequest API.
Web Request API un Declarative Net Request API
Tagadne
Web Request oficiālajā aprakstā API ir aprakstīta šādi:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Izmantojot Web Request, Chrome nosūta visi datus tīkla pieprasījumā paplašinājumam, kas tos klausās. Pēc tam paplašinājumam ir iespēja novērtēt pieprasījumu un norādīt pārlūkam Chrome, kā rīkoties ar pieprasījumu: atļaut to, bloķēt vai nosūtīt ar dažām izmaiņām.
Sekojiet līdzi notikumu secībai, lai saprastu, kas notiek, kad paplašinājumi izmanto Web Request API. Kad lietotājs, kuram ir instalēts tīmekļa pieprasījuma paplašinājums, noklikšķina uz saites, Chrome informē paplašinājumu, ka ir veikts datu pieprasījums, pirms pieprasījums sasniedz serveri. Paplašinājums šajā posmā var izvēlēties mainīt pieprasījumu. Pēc tam serveris atbild, bet atbilde atkal tiek nosūtīta caur paplašinājumu, un paplašinājums var noteikt, vai atbilde ir jāmaina. Pēc tam pārlūks Chrome beidzot atveido lapu, un lietotājs var skatīt savas klikšķa darbības rezultātu.
Kā Chrome nodod visus datus tīkla pieprasījumā, paplašinājumiem, kas izmanto Web Request API, ir piekļuve, lai lasītu un mainītu visu, ko lietotājs dara tīmeklī. Tātad, lai gan satura bloķētāji, piemēram, uBlock Origin, gudri izmanto šīs API potenciālu, Google apgalvo, ka citi paplašinājumi ar ļaunprātīgiem nodomiem ir ļaunprātīgi izmantojuši to pašu, lai iegūtu piekļuvi lietotāju personīgajiem datiem informāciju. Saskaņā ar Google datiem, 42% ļaunprātīgo paplašinājumu ir izmantojuši Web Request API kopš 2018. gada janvāra. Google arī apgalvo, ka ar API kā bloķējošo versiju ir saistītas "ievērojamas veiktspējas izmaksas". tas prasa pastāvīgu un bieži ilgstošu procesu, kas būtībā nav savienojams ar "slinkumu" procesi.
Izmantojot Manifest V3, Google ierosina ierobežot šo API bloķēšanas formā. Kā alternatīvu Google nodrošina Declarative Net Request API.
Nākotne
Deklaratīvais tīkla pieprasījums oficiālajā aprakstā API apraksta šādi:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Izmantojot deklaratīvo tīkla pieprasījumu, pārlūkam Chrome nav jānosūta visa informācija par pieprasījumu klausīšanās paplašinājumam. Tā vietā paplašinājums pārlūkā Chrome reģistrē noteikumus, kas pārlūkprogrammai iepriekš norāda, kā rīkoties, ja tiek parādīti noteikta veida pieprasījumi.
Pagarinājums iepriekš precizē savus noteikumus. Pēc tam pārlūkprogramma (nevis paplašinājums) saskaņo lietotāju pieprasījumu ar šo noteikumu, un darbību veic arī pārlūkprogramma, un pēc tam lapa tiek renderēta. Google norāda, ka tas viņiem ļauj nodrošināt efektivitāti, jo viņi var kontrolēt rezultātu noteikšanas algoritmu un novērst vai atspējot neefektīvus noteikumus. Tas arī sniedz labākas privātuma garantijas galalietotājam, jo informācija par tīkla pieprasījumu netiek pakļauta paplašinājumam. Tā kā pastāvīgi un ilgstoši procesi vairs nav nepieciešami (jo noteikumi ir reģistrēti iepriekš), Google apgalvo, ka šī pieeja nodrošina arī veiktspējas uzlabojumus, kas padarīs paplašinājumus ievērojami dzīvotspējīgākus, ja resursi ir ierobežoti platformas.
Deklaratīvais tīkla pieprasījums būs pieejams gan Manifest V2 (pašreizējais), gan Manifest V3, taču tas būs galvenais veids, kā Google ļaus mainīt tīkla pieprasījumus manifestā V3.
Strīdi
Šķiet, ka Google veiktajām izmaiņām ir jēga, kamēr nedzirdat stāsta otru pusi, galvenokārt par reklāmu bloķētājiem. Šī konkrētā API migrācija tiek uzskatīta par Google veidu, kā iznīcināt reklāmu bloķētājus, jo tā būtiski maina viena no populārākajiem reklāmu bloķētājiem darbības veidu. Tas ir saistīts ar "teoriju", ka Google ir motivēts uz šīm izmaiņām vairāk no biznesa, nevis lietotāju drošības viedokļa. Galu galā Google lielā mērā ir atkarīga no reklāmām, lai gūtu savus ieņēmumus, un reklāmu bloķētāji šajā jomā tiek uztverti kā tiešs drauds Google klientiem, kā tika atklāts Alfabēta 2018. gada SEC veidlapas 10-K iesniegšana (caur Reģistrs):
Jaunās un esošās tehnoloģijas var ietekmēt mūsu spēju pielāgot reklāmas un/vai bloķēt reklāmas tiešsaistē, kas kaitētu mūsu biznesam.
Ir izstrādātas tehnoloģijas, lai padarītu pielāgojamas reklāmas grūtākas vai vispār bloķētu reklāmu rādīšanu un dažus pakalpojumu sniedzējus. tiešsaistes pakalpojumu ir integrētas tehnoloģijas, kas potenciāli varētu pasliktināt trešo pušu digitālā satura pamatfunkcionalitāti reklāma. Lielāko daļu mūsu Google ieņēmumu gūst no maksām, kas mums tiek maksātas saistībā ar reklāmu rādīšanu tiešsaistē. Rezultātā šādas tehnoloģijas un rīki var negatīvi ietekmēt mūsu darbības rezultātus.
Google vajadzēja izdot paziņojumu lai to risinātu, atkārtoti paužot savu nostāju, ka izmaiņas ir lietotāju privātuma interesēs, nevis tiešs uzbrukums reklāmu bloķētājiem:
Mēs neliedzam reklāmu bloķētāju izstrādi un neliedzam lietotājiem bloķēt reklāmas. Tā vietā mēs vēlamies palīdzēt izstrādātājiem, tostarp satura bloķētājiem, rakstīt paplašinājumus tā, lai aizsargātu lietotāju privātumu.
Ir jāatsaucas uz diviem populārākajiem reklāmu bloķētājiem, kas pieejami pārlūkā Google Chrome: uBlock izcelsme un Adblock Plus, kas izmanto dažādas pieejas, lai sasniegtu vienu un to pašu satura bloķēšanas rezultātu. uBlock Origin lielā mērā paļaujas uz Web Request API, un sabiedrība gadu gaitā ir devusi priekšroku šim paplašinājumam. Adblock Plus un citi satura bloķēšanas paplašinājumi arī paļaujas uz Web Request bloķējošo daļu, tāpēc šīs API izmaiņas vismaz zināmā mērā ietekmēs lielāko daļu satura bloķētāju.
Google centieni pārtraukt Web Request izmantošanu būtībā nogalinās uBlock Origin tā pašreizējā formātā, kas patiešām ietekmēs daudzus lietotājus. Lai gan lietotāji bez lojalitātes (un bez nodoma sevi apgrūtināt ar to, kā tiek panākts reklāmu bloks) atradīs alternatīvus risinājumus, kuriem ir savi trūkumi, tas kļūs neiespējami. lojālistiem un entuziastiem izstrādāt jaunus filtrēšanas dzinēju dizainus, lai apietu dažādus paņēmienus, ko tīmekļa vietnes galu galā nāks klajā, lai apkarotu reklāmu bloķētājus šajā konkrētajā API.
Declarative Net Request arī tika ierosināts kā diezgan ierobežots filtrēšanas dzinējs, kā tas bija sākotnēji plānots 30 000 kārtulu ierobežojums statiskā filtra noteikumiem katram paplašinājumam (noteikumi, kas tiek deklarēti instalēšanas laikā); un 5000 kārtulu ierobežojums katram paplašinājumam dinamisko filtru kārtulām (kārtulas, kuras var pievienot pēc instalēšanas). Visi liekie noteikumi tiks ignorēti, kas ir neliela problēma, jo pašam EasyList for Adblock Plus ir 70 000 kārtulu, savukārt uBlock Origin var konfigurēt tā, lai tas darbotos ar vairāk nekā 100 000 kārtulu. Pēc sākotnējās sabiedrības atbildes reakcijas, Google atbildēja apsolot mainīt statisko noteikumu ierobežojumu no 30 000 kārtulām vienam paplašinājumam līdz globālajam maksimumam 150 000 kārtulu. Tam ir blakusefekts, kas liedz lietotājiem kopā ar reklāmu bloķētāju izmantot citus skriptus, kuros ir daudz noteikumu, tāpēc lietotājiem būs jāžonglē ar savām vēlmēm.
Izņemot ierobežoto filtrēšanas ierobežojumu, deklaratīvais tīkla pieprasījums var novirzīt tikai uz statiskiem URL, tāpēc nav iekļauts atbalsts paraugu saskaņošanai. uBlock Origin lielā mērā paļaujas uz modeļu saskaņošanu un paplašinājuma izstrādātāju norādīja, ka nav iespējams modernizēt viņa paplašinājuma atbilstības algoritmu, lai tas atbilstu API prasībām. API būtu nepieciešams arī pilnīgs paplašinājuma atjauninājums, lai vienkārši atjauninātu filtru sarakstu, kas būtu pārāk bieža darbība, ņemot vērā šo filtru sarakstu atjaunināšanas biežums. Protams, šie atjauninājumi būtu atkarīgi arī no Google paplašinājumu pārskatīšanas kritērijiem un procesiem.
No otras puses, Google vienmēr ir saglabājis savu nostāju, ka tā nolūks atteikties no Web Request ir saistīts ar drošības perspektīvas, jo Web Request API ir pārāk spēcīga pašreizējā formā un atstāj ļoti plašu telpu ļaunprātīga izmantošana. Šī ļaunprātīgā izmantošana nav tikai teorētiska, jo Google ir minējis, ka 42% ļaunprātīgo paplašinājumu ir ļaunprātīgi izmantojuši šo API. Apple Safari Satura bloķētāja API tika izstrādāts kā Deklaratīvais tīkla pieprasījums līdzīgu iemeslu dēļ, jo negodīgam izstrādātājam ir mazāk iespēju izmantot. Izmantojot nerfed Web Request, tīkla pieprasījumi joprojām būtu novērojami, taču tiem būs nepieciešamas atļaujas attiecīgajos saimniekdatoros. Izmantojot manifestu V3, resursdatora atļaujas arī ievērojami mainās, un tās vairs nevar piešķirt vispārēji instalēšanas laikā.
Google ir izmantojis arī veiktspējas pieskaitāmās izmaksas kā stimulu pārejai. Tīkla pieprasījumu novērtēšana notiek paplašinājuma JavaScript pavedienā, kas var dārgi izmaksāt veiktspējai. Kā atspēku uBlock Origin izstrādātājs min, ka viņa paplašinājums nerada nekādu būtisku sodu par izpildi pat tad, ja ir jāievieš 140 000 statisko filtru. Tiek apgalvots, ka radušās izmaksas var viegli atgūt no resursiem, kurus nevar lejupielādēt no attāliem serveriem un tādējādi pārlūkprogramma neapstrādā.
Lai gan Google neizmanto šo argumentāciju, viens arguments pret Web Request var tikt izvirzīts arī par reklāmu bloķēšanas efektivitāti. Izmantojot Web Request, ja paplašinājums nereaģē laikā (aizkavēšanās vai avārijas dēļ), tīkla apstrādes pieprasījums ir nepārprotami atļauts, kas ļauj reklāmām izslīdēt cauri reklāmu bloķētājam. No otras puses, deklaratīvais tīkla pieprasījums neciestu no šī trūkuma. Tā vietā reklāmas tiks rādītas, ja tās neatbilst statiskajiem noteikumiem, un tas notiks biežāk nekā nē.
Secinājums
No iepriekš minētajiem paskaidrojumiem ir skaidrs, ka deklaratīvais tīkla pieprasījums nav 1:1 funkcionalitātes klons bloķēšanai. Web Request API iespējas, un paplašinājumu izstrādātāji noteikti būs apmulsuši, ja viņu smago darbu apgrūtinās šādas izmaiņas. Taču Google argumentācijai ir arī nozīme — Web Request ir pārāk spēcīgs, un tā spējām ir jābūt ierobežota lietotāju kopienas (kurā ietilpst vidusmēra lietotāji un entuziasti).
Pāreja uz deklaratīvo tīkla pieprasījumu varēja būt arī pozitīvs PR solis — galu galā Google pārlūkam Chrome pievieno iebūvētu satura bloķētāja API! Taču, tā kā jaunajai API ir savi stingri ierobežojumi, sabiedrība to pamatoti uzskata par savu spārnu apgriešanu. Ideālā pasaulē pirms jaunās API ieviešanas Google būtu jāizpēta tādu reklāmu bloķētāju kā uBlock Origin darbība. Pašreizējā situācijā jaunais API varētu izmantot papildu noteikumu ierobežojumu atvieglojumus, lai pielāgotos scenārijiem, kuros lietotāji vēlas izmantot divus paplašinājumus, kuros ir daudz filtru.
Saskaņā ar Reģistrs, pirmās versijas ar Manifest V3 izmaiņām būs pieejamas no 2019. gada jūlija. Mēs ceram, ka Google ņems vērā atsauksmes, kas saņemtas no paplašinājumu izstrādātāju kopienas saistībā ar šīm versijām.
Īpašs paldies XDA galvenajam redaktoram Mishaal Rahman par ieguldījumu un palīdzību!
Rediģēt: rakstā Adblock Plus darbība ir nepareizi pielīdzināta Declarative Net Request API darbībai. Pants ir attiecīgi grozīts. Adblock Plus ietekmēs arī Web Request API bloķēšanas iespēju noņemšana.