Google odôvodňuje obmedzenie rozhrania webRequest API používaného blokovačmi reklám

Vývojári prehliadača Chrome vyskúšal ospravedlniť ukončenie podpory blokovacieho režimu prevádzky webRequest API, ktoré vám umožňuje meniť prijímaný obsah za chodu a aktívne sa používa v doplnkoch na blokovanie reklamy,
ochrana pred malvérom, phishingom, špehovaním aktivity používateľov, rodičovskou kontrolou a ochranou súkromia.

Motívy Google:

• Režim blokovania API webRequest vedie k vysokej spotrebe zdrojov.
  Pri použití tohto API prehliadač najskôr odošle doplnku všetky údaje obsiahnuté v sieťovej požiadavke, doplnok ich analyzuje a vráti upravenú verziu na ďalšie spracovanie v prehliadači alebo vydá pokyny na blokovanie. V tomto prípade hlavné oneskorenia nevznikajú vo fáze spracovania prevádzky doplnkom, ale z dôvodu režijných nákladov na koordináciu vykonávania doplnku. Takéto manipulácie vyžadujú najmä spustenie samostatného procesu na doplnenie, ako aj použitie IPC na interakciu s týmto procesom a mechanizmov serializácie údajov;

• Doplnok úplne riadi všetku premávku na nízkej úrovni, čo otvára obrovské príležitosti na zneužívanie a porušovanie súkromia. Podľa štatistík Google 42 % všetkých zistených škodlivých doplnkov využívalo webRequest API. Je potrebné poznamenať, že každý mesiac sú v katalógu Internetového obchodu Chrome zablokované pokusy o umiestnenie v priemere 1800 XNUMX škodlivých doplnkov. Žiaľ, kontrola nám neumožňuje zachytiť všetky škodlivé doplnky bez výnimky, preto sa v záujme zvýšenia ochrany rozhodlo obmedziť doplnky na úrovni API. Hlavnou myšlienkou je poskytnúť doplnkom prístup nie k celej prevádzke, ale iba k údajom, ktoré sú potrebné na implementáciu zamýšľanej funkcionality. Najmä na blokovanie obsahu nie je potrebné poskytnúť doplnku úplný prístup ku všetkým dôverným údajom používateľa;
• Navrhované náhradné deklaratívne API deklarativeNetRequest stará sa o všetku prácu vysokovýkonného filtrovania obsahu a vyžaduje iba doplnky na načítanie pravidiel filtrovania. Doplnok nemôže zasahovať do premávky a súkromné ​​údaje používateľa zostávajú nedotknuteľné;
• Google zohľadnil mnohé pripomienky týkajúce sa nedostatočnej funkčnosti deklaratívneho NetRequest API a rozšíril limit počtu pravidiel filtrovania z pôvodne navrhovaných 30 tisíc na rozšírenie na globálne maximum 150 tisíc a pridal aj možnosť dynamicky meniť a pridávať pravidlá, odstraňovať a nahrádzať HTTP hlavičky (Referer, Cookie, Set-Cookie) a požadovať parametre;
• Pre podniky je možné použiť blokovací režim prevádzky webRequest API, keďže politiku používania doplnkov určuje administrátor, ktorý rozumie vlastnostiam infraštruktúry a je si vedomý rizík. Napríklad špecifikované API možno použiť v podnikoch na zaznamenávanie tokov zamestnancov a integráciu s internými systémami;
• Cieľom spoločnosti Google nie je podkopať alebo potlačiť doplnky na blokovanie reklám, ale umožniť vytváranie bezpečnejších a výkonnejších blokátorov reklám;
• Neochota opustiť blokovací režim fungovania webRequest API spolu s novým deklarativeNetRequest sa vysvetľuje snahou obmedziť prístup doplnkov k dôverným údajom. Ak necháte rozhranie webRequest API tak, ako je, väčšina doplnkov nebude používať bezpečnejšie deklaratívneNetRequest, pretože pri výbere medzi bezpečnosťou a funkčnosťou si väčšina vývojárov zvyčajne vyberie funkčnosť.

Námietky vývojárov prílohy:

• Vykonávajú vývojári doplnkov skúšky vykazujú nevýznamný celkový vplyv na výkonnosť doplnkov na blokovanie reklám (počas testovania sa porovnávala výkonnosť rôznych doplnkov, ale bez zohľadnenia réžie dodatočného procesu, ktorý koordinuje spúšťanie obslužných nástrojov v režime blokovania rozhranie webRequest API);
• Nie je praktické úplne prestať podporovať API, ktoré sa aktívne používa v doplnkoch. Namiesto odstránenia môžete pridať samostatné povolenie a prísne kontrolovať primeranosť jeho použitia v doplnkoch, čo by ušetrilo autorov mnohých populárnych doplnkov od úplného prepracovania svojich produktov a vyhli sa orezávaniu funkčnosti;
• Ak chcete znížiť režijné náklady, nemôžete API odstrániť, ale prerobiť ho na základe mechanizmu Promise, podobne ako implementácia webRequest vo Firefoxe;
• Navrhovaná alternatíva, declarativeNetRequest, nepokrýva všetky potreby vývojárov doplnkov pre blokovanie reklám a bezpečnosť/súkromie, pretože neposkytuje úplnú kontrolu nad sieťovými požiadavkami, neumožňuje použitie vlastných filtrovacích algoritmov a neumožňuje používanie zložitých pravidiel, ktoré sa navzájom prekrývajú v závislosti od podmienok;
• Pri súčasnom stave deklaratívneho rozhrania API NetRequest nie je možné obnoviť existujúcu funkčnosť doplnkov uBlock Origin a uMatrix bez zmeny a ďalší vývoj portu NoScript pre Chrome je tiež zbytočný;
• Obavy o súkromie sú pritiahnuté za vlasy, pretože neblokujúci režim rozhrania webRequest API len na čítanie je ponechaný na svojom mieste a stále umožňuje škodlivým doplnkom kontrolovať všetku premávku, ale neposkytuje možnosť zasahovať do lietať (zmeniť obsah, umiestniť svoje reklamy, spustiť baníkov a analyzovať obsah vstupných formulárov možno použiť po dokončení načítania stránky);
• Vývojári prehliadačov statočný, Opera и Vivaldi, postavený na motore Chromium, majú v úmysle ponechať vo svojich produktoch podporu pre režim blokovania webRequest.

Zdroj: opennet.ru