Google põhjendab reklaamiblokeerijate kasutatava webRequest API piiramist

Chrome'i brauseri arendajad proovis õigustada webRequest API-i blokeerimisrežiimi toetamise katkestamine, mis võimaldab teil vastuvõetud sisu lennult muuta ja mida kasutatakse aktiivselt reklaamide blokeerimise lisandmoodulites,
kaitse pahavara, andmepüügi, kasutajategevuse järele luuramise, vanemliku kontrolli ja privaatsuse eest.

Google'i motiivid:

• API blokeerimisrežiim webRequest toob kaasa suure ressursikulu.
  Selle API kasutamisel saadab brauser esmalt lisandmoodulile kõik võrgupäringus sisalduvad andmed, lisandmoodul analüüsib neid ja tagastab muudetud versiooni edasiseks töötlemiseks brauseris või väljastab blokeerimisjuhised. Sel juhul tekivad peamised viivitused mitte lisandmooduli liikluse töötlemise etapis, vaid lisandmooduli täitmise koordineerimise üldkulude tõttu. Eelkõige nõuavad sellised manipulatsioonid täiendava täiendava protsessi käivitamist, samuti IPC kasutamist selle protsessi ja andmete serialiseerimismehhanismidega suhtlemiseks;

• Lisandmoodul kontrollib täielikult kogu liiklust madalal tasemel, mis avab tohutud võimalused kuritarvitamiseks ja privaatsuse rikkumiseks. Google'i statistika kohaselt kasutas 42% kõigist tuvastatud pahatahtlikest lisandmoodulitest webRequest API-t. Märgitakse, et Chrome'i veebipoe kataloogis blokeeritakse iga kuu katsed paigutada keskmiselt 1800 pahatahtlikku lisandmoodulit. Kahjuks ei võimalda ülevaatamine meil tabada eranditult kõiki pahatahtlikke lisandmooduleid, mistõttu otsustati kaitse tõhustamiseks piirata lisandmooduleid API tasemel. Põhiidee on pakkuda lisandmoodulitele juurdepääsu mitte kogu liiklusele, vaid ainult andmetele, mis on vajalikud kavandatud funktsioonide rakendamiseks. Eelkõige ei ole sisu blokeerimiseks vaja anda lisandmoodulile täielikku juurdepääsu kõigile konfidentsiaalsetele kasutajaandmetele;
• Pakutud asendus deklaratiivne API deklaratiivneNetRequest hoolitseb kogu suure jõudlusega sisu filtreerimise töö eest ja nõuab ainult lisandmooduleid filtreerimisreeglite laadimiseks. Lisandmoodul ei saa liiklust segada ja kasutaja privaatsed andmed jäävad puutumatuks;
• Google võttis arvesse paljusid kommentaare deklaratiivse NetRequest API funktsionaalsuse puudumise kohta ja laiendas filtreerimisreeglite arvu piirangut algselt pakutud 30 tuhandelt laienduse kohta globaalse maksimumini 150 tuhandeni ning lisas ka võimaluse dünaamiliselt muuta ja lisada reegleid, eemaldada ja asendada HTTP päised ( Referer, Cookie, Set-Cookie) ja taotleda parameetreid;
• Ettevõtete jaoks on võimalik kasutada webRequest API-i blokeerimisrežiimi, kuna lisandmoodulite kasutamise poliitika määrab administraator, kes mõistab infrastruktuuri funktsioone ja on teadlik riskidest. Näiteks saab määratud API-d ettevõtetes kasutada töötajate liiklusvoogude registreerimiseks ja sisemiste süsteemidega integreerimiseks;
• Google'i eesmärk ei ole õõnestada või alla suruda reklaamide blokeerimise lisandmooduleid, vaid võimaldada turvalisemate ja võimsamate reklaamiblokeerijate loomist;
• Soovimatust lahkuda webRequest API blokeerimisrežiimist koos uue deklaratiivse NetRequestiga seletatakse sooviga piirata lisandmoodulite juurdepääsu konfidentsiaalsetele andmetele. Kui jätate webRequesti API praeguseks, ei kasuta enamik lisandmooduleid turvalisemat deklaratiivset NetRequesti, kuna turvalisuse ja funktsionaalsuse vahel valides valib enamik arendajaid tavaliselt funktsionaalsuse.

Vastuväited arendajad täiendused:

• Viivad läbi lisandmoodulite arendajad testid näitavad ebaolulist üldist mõju reklaamide blokeerimise lisandmoodulite toimivusele (testimise ajal võrreldi erinevate lisandmoodulite toimivust, kuid võtmata arvesse lisaprotsessi, mis koordineerib töötlejate täitmist blokeerimisrežiimis. webRequest API);
• Lisandmoodulites aktiivselt kasutatava API toetamist ei ole otstarbekas täielikult lõpetada. Eemaldamise asemel saate lisada eraldi loa ja rangelt kontrollida selle lisandmoodulites kasutamise adekvaatsust, mis säästaks paljude populaarsete lisandmoodulite autoreid oma toodete täielikust ümbertöötamisest ja väldiks funktsionaalsuse kärpimist;
• Üldkulude vähendamiseks ei saa te API-d kustutada, vaid luua selle uuesti lubaduse mehhanismi alusel, sarnaselt WebRequesti rakendamisega Firefoxis;
• Pakutud alternatiiv, deklaratiivne NetRequest, ei kata kõiki lisandmoodulite arendajate vajadusi reklaamide blokeerimise ja turvalisuse/privaatsuse osas, kuna see ei anna täielikku kontrolli võrgupäringute üle, ei võimalda kasutada kohandatud filtreerimisalgoritme ega võimalda keeruliste reeglite kasutamine, mis olenevalt tingimustest kattuvad;
• DeclarativeNetRequest API praeguse olekuga on võimatu uBlock Origin ja uMatrixi lisandmoodulite olemasolevaid funktsioone muutmata kujul uuesti luua ning see muudab Chrome'i jaoks mõeldud NoScripti pordi edasise arendamise mõttetuks;
• Mure privaatsuse pärast on kaugel, kuna webRequest API kirjutuskaitstud, mitteblokeeriv režiim jäetakse paigale ja lubab endiselt pahatahtlikel lisandmoodulitel kogu liiklust juhtida, kuid ei võimalda seda võrgus segada. lennata (sisu muutmine, reklaamide paigutamine, kaevurite käivitamine ja sisestusvormide sisu analüüsimine saab kasutada pärast lehe laadimise lõppu);
• Brauseri arendajad Vapper, Opera и Vivaldi, mis on üles ehitatud Chromiumi mootorile, kavatsevad jätta oma toodetesse webRequesti blokeerimisrežiimi toe.

Allikas: opennet.ru