Google justifica a restrizione di l'API webRequest utilizata da i blocchi di publicità

Sviluppatori di u navigatore Chrome pruvatu ghjustificà a cessazione di u supportu per u modu di bloccu di u funziunamentu di l'API webRequest, chì vi permette di cambià u cuntenutu ricevutu nantu à a mosca è hè attivamente utilizatu in add-ons per bluccà a publicità,
prutezzione contra malware, phishing, spia nantu à l'attività di l'utilizatori, cuntrolli parentali è privacy.

I mutivi di Google:

• Modu di bloccu API WebRequest porta à un altu cunsumu di risorse.
  Quandu si usa questa API, u navigatore manda prima l'add-on tutte e dati cuntenuti in a dumanda di a rete, l'add-on l'analizeghja è torna una versione mudificata per un ulteriore prucessu in u navigatore o emette struzzioni di bloccu. In questu casu, i ritardi principali ùn sò micca in u stadiu di trasfurmazioni di u trafficu da l'add-on, ma per via di i costi di sopra di a coordinazione di l'esekzione di l'add-on. In particulare, tali manipulazioni necessitanu u lanciamentu di un prucessu separatu per cumplementari, è ancu l'usu di l'IPC per interagisce cù stu prucessu è i miccanismi di serializazione di dati;

• L'add-on cuntrolla cumplettamente tuttu u trafficu à un livellu bassu, chì apre vaste opportunità per abusi è violazioni di privacy. Sicondu statistiche di Google, 42% di tutti l'add-ons maliziusi rilevati anu utilizatu l'API webRequest. Hè nutatu chì ogni mese, i tentativi di mette una media di 1800 add-ons maliziusi sò bluccati in u catalogu di Chrome Web Store. Sfortunatamente, a rivisione ùn ci permette micca di catturà tutti i add-ons maliziusi senza eccezzioni, cusì per rinfurzà a prutezzione, hè statu decisu di limità add-ons à u livellu API. L'idea principale hè di furnisce add-ons cù accessu micca à tuttu u trafficu, ma solu à e dati chì hè necessariu per implementà a funziunalità prevista. In particulare, per bluccà u cuntenutu, ùn hè micca necessariu di dà l'accessu cumpletu à tutti i dati cunfidenziale di l'utilizatori;
• API dichiarativa di rimpiazzamentu pruposta dichiarativeNetRequest cura di tuttu u travagliu di filtrazione di cuntenutu d'altu rendiment è solu bisognu di add-ons per carricà e regule di filtrazione. L'add-on ùn pò micca interferiscenu cù u trafficu è i dati privati ​​​​di l'utilizatori restanu inviolabili;
• Google hà pigliatu in contu parechji di i cumenti in quantu à a mancanza di funziunalità di l'API declarativeNetRequest è hà allargatu u limitu di u numeru di reguli di filtrazione da i primi pruposti 30 mila per estensione à un massimu globale di 150 mila, è hà ancu aghjustatu a capacità di dinamicamente. cambià è aghjunghje regule, sguassate è rimpiazzà l'intestazione HTTP (Referer, Cookie, Set-Cookie) è dumandate parametri;
• Per l'imprese, hè pussibule aduprà u modu di bloccu di u funziunamentu di l'API webRequest, postu chì a pulitica per l'usu di add-ons hè determinata da un amministratore chì capisce e caratteristiche di l'infrastruttura è hè cunuscenza di i risichi. Per esempiu, l'API specificata pò esse aduprata in l'imprese per registrà i flussi di trafficu di l'impiegati è integrà cù sistemi internu;
• L'obiettivu di Google ùn hè micca di minà o suppressione add-ons di bloccu di l'annunzii, ma per attivà a creazione di blocchi di publicità più sicuri è più putenti;
• A riluttanza di abbandunà u modu di bloccu di l'operazione di l'API webRequest cù a nova declarativeNetRequest hè spiegata da u desideriu di limità l'accessu di add-ons à e dati cunfidenziale. Se lasciate l'API webRequest cum'è, a maiò parte di l'addons ùn anu micca aduprà a più sicura declarativeNetRequest, postu chì quandu sceglite trà a sicurità è a funziunalità, a maiò parte di i sviluppatori di solitu sceglienu funziunalità.

Obiezioni sviluppatori aghjunte:

• Conduttu da sviluppatori add-on testi mostranu un impattu generale insignificante nantu à u rendiment di l'add-ons di bloccu di publicità (durante a prova, u rendiment di diversi add-ons hè statu paragunatu, ma senza piglià in contu l'overhead di un prucessu supplementu chì coordina l'esekzione di i gestori in u modu di bloccu di l'API webRequest);
• Ùn hè micca praticu di piantà cumplettamente di sustene una API chì hè attivamente utilizata in add-ons. Invece di sguassate, pudete aghjunghje un permessu separatu è cuntrollà strettamente l'adeguatezza di u so usu in add-ons, chì salvaria l'autori di parechji add-ons populari da a rielaborazione cumpleta di i so prudutti è evitendu a funziunalità di taglià;
• Per riduce i costi generali, ùn pudete micca eliminà l'API, ma rinfriscà nantu à u mecanismu Promise, simili à l'implementazione di webRequest in Firefox;
• L'alternativa pruposta, declarativeNetRequest, ùn copre micca tutti i bisogni di i sviluppatori add-on per u bloccu di l'annunzii è a sicurità / a privacy, postu chì ùn furnisce micca un cuntrollu tutale di e dumande di rete, ùn permette micca l'usu di algoritmi di filtrazione persunalizati, è ùn permettenu micca. l'usu di reguli cumplessi chì si sovrapponenu l'un l'altru secondu e cundizioni;
• Cù u statu attuale di l'API declarativeNetRequest, hè impussibile di ricreà a funziunalità esistenti di l'uBlock Origin è l'add-ons uMatrix senza cambià, è ancu rende più sviluppu di un portu NoScript per Chrome inutile;
• E preoccupazioni nantu à a privacy sò fora, postu chì u modu di sola lettura, senza bloccu di l'API webRequest hè lasciatu in u locu è permette ancu add-ons maliziusi per cuntrullà tuttu u trafficu, ma ùn furnisce micca a capacità di interferiscenu cù questu nantu à u fly (cambià u cuntenutu, postu i vostri publicità, eseguite minatori è analizà u cuntenutu di e forme di input pò esse usatu dopu chì a pagina hà finitu di carica);
• Sviluppatori di navigatori Brave, Opera и Vivaldi, custruitu nantu à u mutore Chromium, intendenu lascià u supportu per u modu di bloccu webRequest in i so prudutti.

Source: opennet.ru