Būsimas „Google Chrome“ plėtinių manifestas V3 pakeis skelbimų blokatorių veikimą „Chrome“. Ar tai tinkamas kelias skelbimų blokatoriams ir „Google“?
Google Chrome yra populiariausia kelių platformų žiniatinklio naršyklė šiuo metu rinkoje, užima 62,7% pasaulinės naršyklės naudojimo dalies iki 2019 m. gegužės mėn. Apple Safari užėmė antrąją vietą – 15,89 %, o Mozilla Firefox – 5,07 %. Dėl savo liūto dalies mažiausi pakeitimai, kuriuos „Google Chrome“ atlieka savo platformoje, paveiks milijonus vartotojų visame pasaulyje. Taigi, kai „Google“ paskelbė apie kitą plėtinių manifesto versiją „Google Chrome“ plėtiniams skirto V3 manifesto pavidalu, žinojome, kad buvo didelių pokyčių, ypač kai paaiškėjo, kad „Google“ naršyklėje „Chrome“ kuria turinio blokavimo API pats.
Kas yra manifestas V3?
Jei esate aktyvus „Chrome“ naudotojas, neabejotinai naudojate kelis plėtinius. Plėtiniai yra nedidelės programinės įrangos programos, kurios tinkina naršymo patirtį naudojant API, kurias teikia naršyklė, leidžianti vartotojams pritaikyti funkcionalumą ir elgesį pagal jų individualius poreikius ir pageidavimus. Šie plėtiniai daugiausia platinami per
Nuo praėjusių metų pabaigoje, „Google“ dirbo su „Manifest V3“ – siūlomų „Chrome“ plėtinių platformos pakeitimų rinkiniu, kurį galima klasifikuoti kaip „nesulaužančius pakeitimus“. Kaip ir Manifesto V3 viešo aptarimo dokumentas teigia, kad plėtinio aprašo versija yra mechanizmas, apribojantis tam tikras galimybes tam tikrai plėtinių klasei. Šie apribojimai gali būti minimalios arba maksimalios versijos forma. Apribojus iki minimalios versijos, naujesnės API arba galimybės bus pasiekiamos tik naujesniems plėtiniams o apribojus iki didžiausios aprašo versijos, senesnės API arba galimybės gali būti palaipsniui pasenęs.
Paprasčiau tariant, nauja aprašo versija leidžia „Chrome“ apriboti API ir funkcijas iki šios naujos aprašo versijos siekiant priversti plėtinių kūrėjus pereiti nuo tam tikrų senesnių API dėl jų neigiamo poveikio vartotojui patirtį. Išplėtimo įgyvendinimas „Manifest V3“ teoriškai turėtų suteikti didesnes garantijas saugumo, privatumo ir našumo požiūriu.
Nors manifeste V3 aprašyta daugybė pakeitimų, labiausiai ginčytinas pakeitimas yra susijęs su „Google“ sprendimu apriboti esamų blokavimo galimybių. chrome.webRequest API (ir sutelkite API į stebėjimą, o ne blokavimą) ir pateikite šiuos blokavimo gebėjimus naudodami naują chrome.declarativeNetRequest API. Šis konkretus pokytis turi pakurstė bendruomenę nes jis nukreipiamas į garsiojo skelbimų blokavimo plėtinio skelbimų blokavimo mechanizmą, „uBlock“ kilmėir tiesiogiai veikia daugiau nei 10 milijonų vartotojų.
Prieš spręsdami šią problemą, pažiūrėkime, kaip WebRequest API lyginama su deklaratyvusNetRequest API.
Web Request API ir Declarative Net Request API
Dabartis
Oficialus žiniatinklio užklausos aprašymas API aprašo taip:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Naudodama žiniatinklio užklausą „Chrome“ siunčia visi duomenis, esančius tinklo užklausoje, skirtą jų klausančiam plėtiniui. Tada plėtinys turi galimybę įvertinti užklausą ir nurodyti „Chrome“, ką daryti su užklausa: leisti, blokuoti ar išsiųsti su kai kuriais pakeitimais.
Sekite įvykių seką, kad suprastumėte, kas vyksta, kai plėtiniai naudoja Web Request API. Kai naudotojas, turintis įdiegtą žiniatinklio užklausos plėtinį, spusteli nuorodą, „Chrome“ informuoja plėtinį, kad duomenų užklausa buvo pateikta prieš užklausai pasiekiant serverį. Šiame etape plėtinys gali pakeisti užklausą. Tada serveris atsako, tačiau atsakymas vėl siunčiamas per plėtinį, o plėtinys gali nurodyti, ar atsakymą reikia keisti. Tada „Chrome“ pagaliau pateikia puslapį ir vartotojas gali peržiūrėti savo paspaudimo rezultatą.
Kaip Chrome perduoda visi tinklo užklausos duomenys, plėtiniai, naudojantys žiniatinklio užklausos API, gali skaityti ir keisti viską, ką vartotojas daro žiniatinklyje. Taigi, nors turinio blokatoriai, tokie kaip „uBlock Origin“, išmintingai išnaudoja šios API potencialą, „Google“ teigia, kad kiti plėtiniai, turintys piktų kėslų, tuo pačiu piktnaudžiauja, kad gautų prieigą prie asmeninių naudotojų informacija. „Google“ duomenimis, nuo 2018 m. sausio mėn. 42 % kenkėjiškų plėtinių naudojo Web Request API. „Google“ taip pat teigia, kad su API kaip blokuojančia versija yra susijusios „didelės našumo išlaidos“. tam reikalingas nuolatinis ir dažnai ilgai trunkantis procesas, kuris iš esmės nesuderinamas su „tinginiu“ procesus.
Naudodama „Manifest V3“, „Google“ siūlo apriboti šią API blokavimo formą. Kaip alternatyvą „Google“ teikia Declarative Net Request API.
Ateitis
Oficialus deklaratyvaus tinklo užklausos aprašymas API aprašo taip:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Naudojant deklaratyviąją tinklo užklausą, „Chrome“ nereikia siųsti visos informacijos apie užklausą klausymo plėtiniui. Vietoj to, plėtinys užregistruoja „Chrome“ taisykles, kurios iš anksto nurodo naršyklei, ką daryti, jei matomos tam tikros rūšies užklausos.
Pratęsimo taisyklės nustatomos iš anksto. Tada naršyklė (o ne plėtinys) suderina naudotojų užklausą su šia taisykle, o veiksmą taip pat atlieka naršyklė, o puslapis vėliau pateikiamas. „Google“ nurodo, kad tai leidžia jiems užtikrinti efektyvumą, nes jie gali kontroliuoti rezultatą nustatantį algoritmą ir užkirsti kelią neveiksmingoms taisyklėms arba jų išjungti. Tai taip pat suteikia geresnes privatumo garantijas galutiniam vartotojui, nes tinklo užklausos informacija nepateikiama plėtiniui. Kadangi nuolatiniai ir ilgai trunkantys procesai nebėra būtini (kadangi taisyklės užregistruotos iš anksto), „Google“ tvirtina, kad Šis metodas taip pat pagerina našumą, todėl plėtiniai bus žymiai perspektyvesni, kai ištekliai yra riboti platformos.
Deklaratyvioji tinklo užklausa bus pasiekiama ir manifeste V2 (dabartinis), ir manifeste V3, tačiau tai bus pagrindinis būdas, kuriuo „Google“ leis keisti tinklo užklausas V3 manifeste.
Ginčas
„Google“ pakeitimai atrodo prasmingi, kol išgirsite kitą istorijos pusę, daugiausia apie skelbimų blokatorius. Šis konkretus API perkėlimas yra vertinamas kaip „Google“ būdas sunaikinti skelbimų blokatorius, nes tai iš esmės pakeičia vieno populiariausių skelbimų blokatorių veikimo būdą. Tai siejama su „teorija“, kad „Google“ yra motyvuota siekti šio pokyčio labiau verslo, o ne vartotojų saugumo požiūriu. Galų gale, „Google“ labai priklauso nuo reklamos, kad gautų savo pajamas, o skelbimų blokatoriai šiuo atžvilgiu suvokiami kaip tiesioginė grėsmė „Google“ klientams, kaip buvo atskleista Abėcėlės 2018 m. SEC 10-K formos padavimas (per Registras):
Naujos ir esamos technologijos gali turėti įtakos mūsų galimybėms tinkinti skelbimus ir (arba) blokuoti skelbimus internete, o tai pakenktų mūsų verslui.
Buvo sukurtos technologijos, kurios apsunkina tinkinamus skelbimus arba visiškai blokuoja skelbimų rodymą ir kai kuriuos teikėjus internetinių paslaugų turi integruotas technologijas, kurios gali pakenkti pagrindiniam trečiųjų šalių skaitmeninio funkcionalumui reklama. Didžioji dalis mūsų „Google“ pajamų gaunama iš mokesčių, sumokėtų už skelbimų rodymą internete. Dėl to tokios technologijos ir įrankiai gali neigiamai paveikti mūsų veiklos rezultatus.
Google turėjo paskelbti pareiškimą Norėdami tai išspręsti, pakartodami savo poziciją, kad pakeitimu siekiama apsaugoti naudotojų privatumą, o ne tiesioginė ataka prieš skelbimų blokatorius:
Mes netrukdome kurti skelbimų blokavimo priemones ir netrukdome vartotojams blokuoti skelbimų. Vietoj to norime padėti kūrėjams, įskaitant turinio blokatorius, rašyti plėtinius taip, kad būtų apsaugotas naudotojų privatumas.
Reikia nurodyti du populiariausius „Google Chrome“ skelbimų blokatorius: „uBlock“ kilmė ir Adblock Plus, kurios abi taiko skirtingus metodus, kad pasiektų tą patį turinio blokavimo rezultatą. „uBlock Origin“ labai priklauso nuo „Web Request“ API, o bendruomenė daugelį metų pirmenybę teikė šiam plėtiniui. „Adblock Plus“ ir kiti turinį blokuojantys plėtiniai taip pat priklauso nuo „Web Request“ blokuojamosios dalies, todėl šios API pakeitimai bent kiek paveiks daugumą turinio blokatorių.
„Google“ pastangos atsisakyti „Web Request“ iš esmės nužudys „uBlock Origin“ dabartiniu formatu, o tai iš tikrųjų turės įtakos daugeliui vartotojų. Nors vartotojai, neturintys lojalumo (ir neketinantys jaudintis dėl to, kaip pasiekiamas skelbimų blokavimas), ras alternatyvių sprendimų, turinčių savų trūkumų, tai taps neįmanoma. lojalistams ir entuziastams, kad jie pasiūlytų naujų filtravimo variklio dizainų, kad būtų išvengta įvairių metodų, kuriuos interneto svetainės galiausiai sukurs kovodamos su skelbimų blokatoriais šioje konkrečioje API.
Declarative Net Request taip pat buvo pasiūlyta kaip gana ribotas filtravimo variklis, koks buvo iš pradžių planuota turėti 30 000 taisyklių limitą kiekvienam plėtiniui statinio filtro taisyklėms (taisyklėms, kurios deklaruojamos diegiant); ir 5 000 taisyklių apribojimas, taikomas kiekvienam plėtiniui dinaminio filtro taisyklėms (taisyklės, kurias galima pridėti įdiegus). Bet kokios perteklinės taisyklės bus ignoruojamos, o tai yra šiek tiek problema, nes „EasyList for Adblock Plus“ turi 70 000 taisyklių, o „uBlock Origin“ galima sukonfigūruoti taip, kad ji veiktų su daugiau nei 100 000 taisyklių. Po pradinio bendruomenės atsako Google atsakė pažadėdamas pakeisti statinių taisyklių ribą nuo 30 000 taisyklių vienam plėtiniui iki 150 000 taisyklių visame pasaulyje. Tada tai turi šalutinį poveikį, nes vartotojai negali naudoti kitų griežtų taisyklių scenarijų kartu su skelbimų blokavimo priemone, todėl vartotojai turės žongliruoti su savo nuostatomis.
Išskyrus ribotą filtravimo limitą, deklaratyviojo tinklo užklausa gali peradresuoti tik į statinius URL, todėl modelio derinimo palaikymas neįtrauktas. „uBlock Origin“ labai priklauso nuo šablonų atitikimo ir plėtinio kūrėjo nurodė, kad modifikuoti negalima jo plėtinio atitikimo algoritmas, kad atitiktų API reikalavimą. API taip pat reikės viso plėtinio atnaujinimo, kad būtų tiesiog atnaujintas filtrų sąrašas, o tai būtų pernelyg dažna veikla, atsižvelgiant į dažnumas, kuriuo šie filtrų sąrašai atnaujinami. Žinoma, šie atnaujinimai taip pat priklausys nuo „Google“ plėtinių peržiūros kriterijų ir procesų.
Kita vertus, „Google“ visada laikėsi pozicijos, kad jos ketinimas atsisakyti „Web Request“ yra saugumo perspektyvos, nes Web Request API yra per galinga dabartine forma ir palieka labai plačią erdvę piktnaudžiavimas. Šis piktnaudžiavimas nėra tik teorinis, nes „Google“ paminėjo, kad 42 % kenkėjiškų plėtinių piktnaudžiauja šia API. Apple Safari Turinio blokavimo API buvo sukurta kaip Declarative Net Request dėl panašių priežasčių, nes nesąžiningam kūrėjui yra mažiau galimybių išnaudoti. Naudojant „nerfed“ žiniatinklio užklausą, tinklo užklausos vis tiek būtų stebimos, tačiau joms reikės atitinkamų prieglobų leidimų. Naudojant „Manifest V3“, pagrindinio kompiuterio leidimai taip pat labai keičiasi ir jų nebegalima suteikti bendrai diegiant.
„Google“ taip pat naudojo pridėtines našumo išlaidas kaip motyvaciją pakeisti. Tinklo užklausos įvertinamos plėtinio „JavaScript“ gijoje, o tai gali brangiai kainuoti dėl našumo. Kaip paneigimą „uBlock Origin“ kūrėjas mini, kad jo plėtinys netaikoma reikšminga bauda net kai turi net 140 000 statinių filtrų. Teigiama, kad patirtas išlaidas nesunkiai susigrąžins ištekliai, kurių negalima atsisiųsti iš nuotolinių serverių ir todėl naršyklė neapdoroja.
Nors „Google“ nesinaudoja šiais argumentais, vienas argumentas prieš „Web Request“ taip pat gali būti pateiktas dėl efektyvumo naudojant skelbimų blokavimą. Naudojant žiniatinklio užklausą, jei plėtinys neatsako laiku (dėl vėlavimo ar gedimo), tinklo tvarkymo užklausa yra aiškiai leidžiama, todėl skelbimai gali praslysti per skelbimų blokatorių. Kita vertus, deklaratyvioji tinklo užklausa nepatirtų šio trūkumo. Vietoj to, skelbimai bus rodomi, jei jie nepaisys statinių taisyklių, ir tai įvyks dažniau.
Išvada
Iš aukščiau pateiktų paaiškinimų aišku, kad Declarative Net Request nėra 1:1 funkcionalumo klonas blokavimui. žiniatinklio užklausos API galimybes, o plėtinių kūrėjai bus sutrikę, kai jų sunkus darbas trukdys tokių pokyčių. Tačiau „Google“ samprotavimai taip pat turi svarų – žiniatinklio užklausa yra per galinga ir jos galios turi būti tokios sumažintas siekiant didesnio vartotojų bendruomenės (kurią sudaro vidutiniai vartotojai ir entuziastai).
Perėjimas prie deklaratyvaus tinklo užklausos taip pat galėjo būti teigiamas PR žingsnis – juk „Google“ į „Chrome“ prideda integruotą turinio blokavimo API! Tačiau kadangi naujoji API yra su griežtais apribojimais, bendruomenė pagrįstai tai vertina kaip savo sparnų nukirpimą. Idealiame pasaulyje „Google“ turėjo ištirti skelbimų blokatorių, tokių kaip „uBlock Origin“, veikimą, prieš pradėdama naudoti naują API. Dabartinė naujoji API gali dar labiau sušvelninti savo taisyklių ribas, kad atitiktų scenarijus, kai vartotojai norėtų naudoti du daug filtrų turinčius plėtinius.
Pagal Registras, pirmosios versijos su Manifest V3 pakeitimais bus pasiekiamos nuo 2019 m. liepos mėn. Tikimės, kad „Google“ atsižvelgs į atsiliepimus, gautus iš plėtinių kūrėjų bendruomenės dėl šių versijų.
Ypatingas ačiū XDA vyriausiajam redaktoriui Mishaalui Rahmanui už indėlį ir pagalbą!
Redaguoti: Straipsnyje neteisingai prilygintas „Adblock Plus“ veikimas su Declarative Net Request API veikimu. Straipsnis atitinkamai pakeistas. „Adblock Plus“ taip pat turės įtakos pašalinus „Web Request“ API blokavimo galimybes.