„Google“ pateisina „webRequest“ API, kurią naudoja skelbimų blokatoriai, apribojimą

Chrome naršyklės kūrėjai bandė pateisinti nutraukus webRequest API blokavimo režimo palaikymą, leidžiantį keisti gautą turinį skrydžio metu ir aktyviai naudojamas reklamai blokuoti skirtuose prieduose,
apsauga nuo kenkėjiškų programų, sukčiavimo, naudotojų veiklos šnipinėjimo, tėvų kontrolės ir privatumo.

Google motyvai:

• API blokavimo režimas WebRequest lemia didelį išteklių suvartojimą.
  Naudodama šią API naršyklė pirmiausia siunčia priedui visus tinklo užklausoje esančius duomenis, priedas juos analizuoja ir grąžina modifikuotą versiją tolesniam apdorojimui naršyklėje arba pateikia blokavimo instrukcijas. Šiuo atveju pagrindiniai vėlavimai atsiranda ne priedo srauto apdorojimo etape, o dėl papildomų išlaidų, susijusių su priedo vykdymo koordinavimu. Visų pirma, norint atlikti tokias manipuliacijas, reikia pradėti atskirą papildymo procesą, taip pat naudoti IPC sąveikai su šiuo procesu ir duomenų nuoseklumo mechanizmais;

• Priedas visiškai kontroliuoja visą srautą žemu lygiu, o tai atveria daug galimybių piktnaudžiavimui ir privatumo pažeidimams. Remiantis „Google“ statistika, 42% visų aptiktų kenkėjiškų priedų naudojo „webRequest“ API. Pažymima, kad kiekvieną mėnesį „Chrome“ internetinės parduotuvės kataloge blokuojami bandymai įdėti vidutiniškai 1800 kenkėjiškų priedų. Deja, peržiūra neleidžia sugauti visų be išimties kenkėjiškų priedų, todėl siekiant sustiprinti apsaugą, buvo nuspręsta apriboti priedus API lygiu. Pagrindinė idėja – suteikti priedams prieigą ne prie viso srauto, o tik prie tų duomenų, kurie yra būtini numatytam funkcionalumui įgyvendinti. Visų pirma, norint blokuoti turinį, nebūtina suteikti priedui visiškos prieigos prie visų konfidencialių vartotojo duomenų;
• Siūloma pakeitimo deklaratyvi API deklaratyvusNetRequest rūpinasi visais didelio našumo turinio filtravimo darbais ir filtravimo taisyklėms įkelti reikia tik priedų. Priedas negali trukdyti srautui, o privatūs vartotojo duomenys lieka neliečiami;
• „Google“ atsižvelgė į daugelį pastabų dėl deklaratyvios NetRequest API funkcionalumo trūkumo ir išplėtė filtravimo taisyklių skaičiaus ribą nuo iš pradžių pasiūlytų 30 tūkst. vienam plėtiniui iki didžiausios 150 tūkst. visame pasaulyje, taip pat pridėjo galimybę keisti ir pridėti taisykles, pašalinti ir pakeisti HTTP antraštes (Referer, Cookie, Set-Cookie) ir užklausos parametrus;
• Įmonėms galima naudoti „webRequest“ API blokavimo režimą, nes priedų naudojimo politiką nustato administratorius, išmanantis infrastruktūros ypatybes ir žinantis riziką. Pavyzdžiui, nurodyta API gali būti naudojama įmonėse darbuotojų srautams fiksuoti ir integruoti su vidinėmis sistemomis;
• „Google“ tikslas yra ne pakenkti ar slopinti skelbimų blokavimo priedus, o sudaryti sąlygas kurti saugesnius ir galingesnius skelbimų blokatorius;
• Nenoras išeiti iš webRequest API blokavimo režimo kartu su naujuoju deklaratyviuoju NetRequest paaiškinamas noru apriboti priedų prieigą prie konfidencialių duomenų. Jei paliksite „webRequest“ API tokią, kokia yra, dauguma priedų nenaudos saugesnio deklaratyvaus „NetRequest“, nes rinkdamiesi tarp saugos ir funkcionalumo dauguma kūrėjų dažniausiai pasirenka funkcionalumą.

prieštaravimų kūrėjai papildymus:

• Vykdo priedų kūrėjai testai rodo nereikšmingą bendrą poveikį skelbimų blokavimo priedų našumui (bandymo metu buvo lyginamas įvairių priedų našumas, tačiau neatsižvelgiama į papildomo proceso, koordinuojančio tvarkyklių vykdymą blokavimo režimu, sąnaudas). webRequest API);
• Nepraktiška visiškai nustoti palaikyti API, kuri aktyviai naudojama prieduose. Užuot jį pašalinę, galite pridėti atskirą leidimą ir griežtai kontroliuoti jo panaudojimo prieduose adekvatumą, o tai sutaupytų daugelio populiarių priedų autorius nuo visiško gaminių perdirbimo ir išvengtumėte funkcionalumo apkarpymo;
• Norėdami sumažinti pridėtines išlaidas, negalite ištrinti API, bet perdaryti ją pagal pažado mechanizmą, panašiai kaip WebRequest įdiegimas Firefox;
• Siūloma alternatyva deklaratyvioji „NetRequest“ neapima visų priedų kūrėjų poreikių, susijusių su skelbimų blokavimu ir sauga/privatumu, nes neužtikrina visiškos tinklo užklausų kontrolės, neleidžia naudoti tinkintų filtravimo algoritmų ir neleidžia. sudėtingų taisyklių, kurios sutampa viena su kita priklausomai nuo sąlygų, naudojimas;
• Esant dabartinei „declarativeNetRequest“ API būsenai, neįmanoma atkurti esamų „uBlock Origin“ ir „uMatrix“ priedų funkcijų nepakeistų, be to, tolesnis „Chrome“ skirto „NoScript“ prievado kūrimas tampa beprasmis;
• Susirūpinimas dėl privatumo yra toli, nes tik skaitomas, neblokuojantis webRequest API režimas paliekamas vietoje ir vis tiek leidžia kenkėjiškiems priedams valdyti visą srautą, tačiau nesuteikia galimybės jam trukdyti skristi (keiskite turinį, talpinkite savo skelbimus, vykdykite minerius ir analizuokite įvesties formų turinį, galite naudoti baigus įkelti puslapį);
• Naršyklės kūrėjai Narsus, Opera и Vivaldi, sukurtas naudojant „Chromium“ variklį, ketina palikti „webRequest“ blokavimo režimo palaikymą savo produktuose.

Šaltinis: opennet.ru