Google upravičuje omejitev API-ja webRequest, ki ga uporabljajo blokatorji oglasov

Razvijalci brskalnika Chrome poskusil utemeljiti ukinitev podpore za blokiranje načina delovanja webRequest API, ki omogoča sprotno spreminjanje prejete vsebine in se aktivno uporablja v dodatkih za blokiranje oglaševanja,
zaščita pred zlonamerno programsko opremo, lažnim predstavljanjem, vohunjenjem za dejavnostjo uporabnikov, starševskim nadzorom in zasebnostjo.

Googlovi motivi:

• Način blokiranja API-ja webRequest vodi do velike porabe virov.
  Pri uporabi tega API-ja brskalnik najprej pošlje dodatku vse podatke, ki jih vsebuje omrežna zahteva, dodatek jih analizira in vrne spremenjeno različico za nadaljnjo obdelavo v brskalniku ali izda navodila za blokiranje. V tem primeru glavne zamude ne nastanejo v fazi obdelave prometa s strani dodatka, temveč zaradi režijskih stroškov usklajevanja izvajanja dodatka. Zlasti takšne manipulacije zahtevajo zagon ločenega procesa za dopolnitev, kot tudi uporabo IPC za interakcijo s tem procesom in mehanizmi za serializacijo podatkov;

• Dodatek popolnoma nadzira ves promet na nizki ravni, kar odpira ogromno možnosti za zlorabe in kršitve zasebnosti. Po Googlovi statistiki je 42 % vseh odkritih zlonamernih dodatkov uporabljalo webRequest API. Opozoriti je treba, da je vsak mesec v katalogu spletne trgovine Chrome blokiranih poskusov umestitve povprečno 1800 zlonamernih dodatkov. Na žalost nam pregled ne omogoča, da bi ujeli vse zlonamerne dodatke brez izjeme, zato je bilo za izboljšanje zaščite odločeno omejiti dodatke na ravni API-ja. Glavna ideja je omogočiti dodatkom dostop ne do celotnega prometa, temveč le do podatkov, ki so potrebni za izvajanje predvidene funkcionalnosti. Zlasti za blokiranje vsebine dodatku ni treba dati popolnega dostopa do vseh zaupnih uporabniških podatkov;
• Predlagani nadomestni deklarativni API deklarativnaNetRequest poskrbi za vse delo visokozmogljivega filtriranja vsebine in zahteva samo dodatke za nalaganje pravil filtriranja. Dodatek ne more ovirati prometa in zasebni podatki uporabnika ostanejo nedotakljivi;
• Google je upošteval številne pripombe v zvezi s pomanjkanjem funkcionalnosti API-ja declarativeNetRequest in razširil omejitev števila pravil filtriranja s prvotno predlaganih 30 tisoč na razširitev na globalni maksimum 150 tisoč, dodal pa je tudi možnost dinamičnega spreminjanje in dodajanje pravil, odstranjevanje in zamenjava glav HTTP (Referer, Cookie, Set-Cookie) in parametrov zahteve;
• Za podjetja je možna uporaba blokirajočega načina delovanja webRequest API, saj politiko uporabe dodatkov določi skrbnik, ki razume značilnosti infrastrukture in se zaveda tveganj. Navedeni API se lahko na primer uporablja v podjetjih za beleženje tokov prometa zaposlenih in integracijo z notranjimi sistemi;
• Googlov cilj ni spodkopati ali zatreti dodatkov za blokiranje oglasov, temveč omogočiti ustvarjanje varnejših in močnejših blokatorjev oglasov;
• Nepripravljenost, da bi zapustili način delovanja webRequest API skupaj z novim deklarativnimNetRequest, je razložen z željo po omejitvi dostopa dodatkov do zaupnih podatkov. Če pustite API webRequest tak, kot je, večina dodatkov ne bo uporabljala varnejšega deklarativnegaNetRequesta, saj pri izbiri med varnostjo in funkcionalnostjo večina razvijalcev običajno izbere funkcionalnost.

Ugovori razvijalci dodatki:

• Izvajajo razvijalci dodatkov testi kažejo nepomemben splošni vpliv na delovanje dodatkov za blokiranje oglasov (med testiranjem je bilo primerjano delovanje različnih dodatkov, vendar brez upoštevanja dodatnih stroškov dodatnega procesa, ki usklajuje izvajanje obdelovalcev v načinu blokiranja API webRequest);
• Ni praktično popolnoma prenehati podpirati API-ja, ki se aktivno uporablja v dodatkih. Namesto da ga odstranite, lahko dodate ločeno dovoljenje in strogo nadzirate ustreznost njegove uporabe v dodatkih, s čimer bi avtorjem številnih priljubljenih dodatkov prihranili popolno predelavo svojih izdelkov in se izognili krčenju funkcionalnosti;
• Če želite zmanjšati režijske stroške, API-ja ne morete izbrisati, ampak ga predelate na podlagi mehanizma Promise, podobno implementaciji webRequest v Firefoxu;
• Predlagana alternativa, declarativeNetRequest, ne pokriva vseh potreb razvijalcev dodatkov po blokiranju oglasov in varnosti/zasebnosti, saj ne zagotavlja popolnega nadzora nad omrežnimi zahtevami, ne dovoljuje uporabe algoritmov filtriranja po meri in ne omogoča uporaba kompleksnih pravil, ki se med seboj prekrivajo glede na pogoje;
• S trenutnim stanjem API-ja declarativeNetRequest je nemogoče znova ustvariti nespremenjeno obstoječo funkcionalnost dodatkov uBlock Origin in uMatrix, poleg tega pa je nadaljnji razvoj vrat NoScript za Chrome nesmiseln;
• Pomisleki glede zasebnosti so odveč, saj je način API-ja webRequest, ki je samo za branje in ne blokira, ostal nespremenjen in še vedno dovoljuje zlonamernim dodatkom, da nadzorujejo ves promet, vendar ne omogoča poseganja vanj na fly (spremenite vsebino, postavite svoje oglase, zaženite rudarje in analizirajte vsebino vnosnih obrazcev lahko uporabite, ko se stran konča z nalaganjem);
• Razvijalci brskalnikov Brave, deluje и Vivaldi, zgrajen na motorju Chromium, nameravajo v svojih izdelkih pustiti podporo za način blokiranja webRequest.

Vir: opennet.ru