Google opravdava ograničenje webRequest API-ja koji koriste programi za blokiranje oglasa

Programeri preglednika Chrome pokušao opravdati ukidanje podrške za blokirajući način rada webRequest API-ja koji omogućuje promjenu primljenog sadržaja u hodu i aktivno se koristi u dodacima za blokiranje oglašavanja,
zaštita od zlonamjernog softvera, krađe identiteta, špijuniranja aktivnosti korisnika, roditeljske kontrole i privatnosti.

Googleovi motivi:

  • Način blokiranja API-ja webZahtjev dovodi do velike potrošnje resursa.
    Kada koristite ovaj API, preglednik prvo šalje dodatku sve podatke sadržane u mrežnom zahtjevu, dodatak ih analizira i vraća modificiranu verziju za daljnju obradu u pregledniku ili izdaje upute za blokiranje. U ovom slučaju, glavna kašnjenja ne nastaju u fazi obrade prometa od strane dodatka, već zbog režijskih troškova koordinacije izvršenja dodatka. Konkretno, takve manipulacije zahtijevaju pokretanje zasebnog procesa za nadopunu, kao i korištenje IPC-a za interakciju s ovim procesom i mehanizmima serijalizacije podataka;

  • Dodatak u potpunosti kontrolira sav promet na niskoj razini, što otvara goleme mogućnosti za zlouporabu i kršenje privatnosti. Prema Google statistici, 42% svih otkrivenih zlonamjernih dodataka koristilo je webRequest API. Napominje se da se svaki mjesec pokušaji postavljanja prosječno 1800 zlonamjernih dodataka blokiraju u katalogu Chrome web trgovine. Nažalost, pregled nam ne dopušta da uhvatimo sve zlonamjerne dodatke bez iznimke, pa je za poboljšanje zaštite odlučeno ograničiti dodatke na razini API-ja. Glavna ideja je omogućiti dodacima pristup ne cjelokupnom prometu, već samo podacima koji su nužni za implementaciju predviđene funkcionalnosti. Konkretno, za blokiranje sadržaja nije potrebno dodatku dati puni pristup svim povjerljivim korisničkim podacima;
  • Predloženi zamjenski deklarativni API deklarativni NetZahtjev brine se za sav posao visokoučinkovitog filtriranja sadržaja i samo zahtijeva dodatke za učitavanje pravila filtriranja. Dodatak ne može ometati promet, a osobni podaci korisnika ostaju nepovredivi;
  • Google je uzeo u obzir mnoge komentare u vezi s nedostatkom funkcionalnosti declarativeNetRequest API-ja i proširio ograničenje broja pravila filtriranja s prvobitno predloženih 30 tisuća po ekstenziji na globalni maksimum od 150 tisuća, a također je dodao mogućnost dinamičkog mijenjati i dodavati pravila, uklanjati i mijenjati HTTP zaglavlja (Referer, Cookie, Set-Cookie) i parametre zahtjeva;
  • Za poduzeća je moguće koristiti blokirajući način rada webRequest API-ja, budući da politiku korištenja dodataka određuje administrator koji razumije značajke infrastrukture i svjestan je rizika. Na primjer, navedeni API može se koristiti u poduzećima za snimanje tokova prometa zaposlenika i integraciju s internim sustavima;
  • Googleov cilj nije potkopati ili potisnuti dodatke za blokiranje oglasa, već omogućiti stvaranje sigurnijih i moćnijih programa za blokiranje oglasa;
  • Nespremnost da se napusti blokirajući način rada webRequest API-ja zajedno s novim deklarativnimNetRequestom objašnjava se željom da se ograniči pristup dodataka povjerljivim podacima. Ako ostavite webRequest API kakav jest, većina dodataka neće koristiti sigurniji deklarativni NetRequest, budući da će pri odabiru između sigurnosti i funkcionalnosti većina programera obično odabrati funkcionalnost.

Prigovori programeri dodaci:

  • Provode programeri dodataka testovi pokazuju beznačajan ukupni utjecaj na izvedbu dodataka za blokiranje oglasa (tijekom testiranja uspoređivana je izvedba različitih dodataka, ali bez uzimanja u obzir opterećenja dodatnog procesa koji koordinira izvršavanje rukovatelja u načinu blokiranja webRequest API);
  • Nije praktično potpuno prestati podržavati API koji se aktivno koristi u dodacima. Umjesto da ga uklonite, možete dodati zasebno dopuštenje i strogo kontrolirati primjerenost njegove upotrebe u dodacima, što bi autore mnogih popularnih dodataka spasilo od potpune prerade svojih proizvoda i izbjeglo rezanje funkcionalnosti;
  • Kako biste smanjili režijske troškove, ne možete izbrisati API, već ga ponovno izraditi na temelju mehanizma Promise, slično implementaciji webRequesta u Firefoxu;
  • Predložena alternativa, declarativeNetRequest, ne pokriva sve potrebe programera dodataka za blokiranje oglasa i sigurnost/privatnost, budući da ne pruža potpunu kontrolu nad mrežnim zahtjevima, ne dopušta upotrebu prilagođenih algoritama za filtriranje i ne dopušta korištenje složenih pravila koja se međusobno preklapaju ovisno o uvjetima;
  • S trenutnim stanjem API-ja declarativeNetRequest, nemoguće je ponovno stvoriti nepromijenjenu postojeću funkcionalnost dodataka uBlock Origin i uMatrix, a također čini besmislenim daljnji razvoj NoScript priključka za Chrome;
  • Zabrinutost oko privatnosti je nategnuta, budući da je način rada samo za čitanje, bez blokiranja webRequest API-ja ostao na mjestu i još uvijek dopušta zlonamjernim dodacima da kontroliraju sav promet, ali ne pruža mogućnost ometanja toga na letjeti (mijenjajte sadržaj, postavljajte svoje oglase, pokrenite rudare i analizirajte sadržaj obrazaca za unos možete koristiti nakon što se stranica završi s učitavanjem);
  • Programeri preglednika Hrabar, Opera и Vivaldi, izgrađen na Chromium motoru, namjeravaju ostaviti podršku za način blokiranja webRequest u svojim proizvodima.

Izvor: opennet.ru

Dodajte komentar