Google giustifica la limitazione dell'API webRequest utilizzata dagli ad blocker

Sviluppatori del browser Chrome ci ho provato convalidare interruzione del supporto per la modalità operativa di blocco dell'API webRequest, che consente di modificare al volo il contenuto ricevuto e viene utilizzata attivamente nei componenti aggiuntivi per bloccare la pubblicità,
protezione da malware, phishing, spionaggio dell'attività degli utenti, controllo genitori e privacy.

Le motivazioni di Google:

• Modalità di blocco dell'API webRichiesta porta ad un elevato consumo di risorse.
  Quando si utilizza questa API, il browser invia prima al componente aggiuntivo tutti i dati contenuti nella richiesta di rete, il componente aggiuntivo li analizza e restituisce una versione modificata per l'ulteriore elaborazione nel browser o emette istruzioni di blocco. In questo caso, i ritardi principali non si verificano nella fase di elaborazione del traffico da parte del componente aggiuntivo, ma a causa dei costi generali di coordinamento dell'esecuzione del componente aggiuntivo. In particolare, tali manipolazioni richiedono l'avvio di un processo separato da integrare, nonché l'uso di IPC per interagire con questo processo e meccanismi di serializzazione dei dati;

• Il componente aggiuntivo controlla completamente tutto il traffico a basso livello, il che apre vaste opportunità di abuso e violazione della privacy. Secondo le statistiche di Google, il 42% di tutti i componenti aggiuntivi dannosi rilevati utilizzava l'API webRequest. Ogni mese vengono bloccati nel catalogo del Chrome Web Store i tentativi di inserire in media 1800 componenti aggiuntivi dannosi. Sfortunatamente, la revisione non ci consente di individuare tutti i componenti aggiuntivi dannosi senza eccezioni, quindi per migliorare la protezione si è deciso di limitare i componenti aggiuntivi a livello API. L'idea principale è fornire componenti aggiuntivi con accesso non a tutto il traffico, ma solo ai dati necessari per implementare la funzionalità prevista. In particolare, per bloccare i contenuti, non è necessario dare al componente aggiuntivo pieno accesso a tutti i dati riservati dell'utente;
• API dichiarativa sostitutiva proposta dichiarativoNetRequest si occupa di tutto il lavoro di filtraggio dei contenuti ad alte prestazioni e richiede solo componenti aggiuntivi per caricare le regole di filtraggio. Il componente aggiuntivo non può interferire con il traffico e i dati privati ​​dell’utente rimangono inviolabili;
• Google ha preso in considerazione molti commenti riguardanti la mancanza di funzionalità dell'API dichiarativaNetRequest e ha ampliato il limite del numero di regole di filtraggio dalle 30mila proposte inizialmente per estensione a un massimo globale di 150mila, e ha anche aggiunto la possibilità di modificare dinamicamente modificare e aggiungere regole, rimuovere e sostituire intestazioni HTTP (Referer, Cookie, Set-Cookie) e parametri di richiesta;
• Per le aziende, è possibile utilizzare la modalità di funzionamento di blocco dell'API webRequest, poiché la politica per l'utilizzo dei componenti aggiuntivi è determinata da un amministratore che comprende le caratteristiche dell'infrastruttura ed è consapevole dei rischi. Ad esempio, l'API specificata può essere utilizzata nelle aziende per registrare i flussi di traffico dei dipendenti e integrarsi con i sistemi interni;
• L'obiettivo di Google non è indebolire o sopprimere i componenti aggiuntivi per il blocco degli annunci, ma consentire la creazione di blocchi degli annunci più sicuri e potenti;
• La riluttanza ad abbandonare la modalità operativa di blocco dell'API webRequest insieme alla nuova dichiarativaNetRequest è spiegata dal desiderio di limitare l'accesso dei componenti aggiuntivi ai dati riservati. Se lasci l'API webRequest così com'è, la maggior parte dei componenti aggiuntivi non utilizzerà il dichiarativo NetRequest più sicuro, poiché quando si sceglie tra sicurezza e funzionalità, la maggior parte degli sviluppatori di solito sceglie la funzionalità.

obiezioni sviluppatori aggiunte:

• Condotto da sviluppatori aggiuntivi test mostrano un impatto complessivo insignificante sulle prestazioni dei componenti aggiuntivi per il blocco degli annunci (durante il test, sono state confrontate le prestazioni di vari componenti aggiuntivi, ma senza tenere conto del sovraccarico di un processo aggiuntivo che coordina l'esecuzione dei gestori nella modalità di blocco di l'API webRequest);
• Non è pratico interrompere completamente il supporto di un'API utilizzata attivamente nei componenti aggiuntivi. Invece di rimuoverlo, puoi aggiungere un'autorizzazione separata e controllare rigorosamente l'adeguatezza del suo utilizzo nei componenti aggiuntivi, il che eviterebbe agli autori di molti componenti aggiuntivi popolari di rielaborare completamente i loro prodotti ed evitare di tagliare funzionalità;
• Per ridurre i costi generali, non è possibile eliminare l'API, ma rifarla in base al meccanismo Promise, simile all'implementazione di webRequest in Firefox;
• L'alternativa proposta, dichiarativaNetRequest, non copre tutte le esigenze degli sviluppatori di componenti aggiuntivi per il blocco degli annunci e la sicurezza/privacy, poiché non fornisce il controllo completo sulle richieste di rete, non consente l'uso di algoritmi di filtraggio personalizzati e non consente l'uso di regole complesse che si sovrappongono a seconda delle condizioni;
• Con lo stato attuale dell'API dichiarativaNetRequest, è impossibile ricreare invariate le funzionalità esistenti dei componenti aggiuntivi uBlock Origin e uMatrix e rende inoltre inutile l'ulteriore sviluppo di un port NoScript per Chrome;
• Le preoccupazioni sulla privacy sono inverosimili, dal momento che la modalità di sola lettura e non bloccante dell'API webRequest viene lasciata in vigore e consente comunque ai componenti aggiuntivi dannosi di controllare tutto il traffico, ma non fornisce la possibilità di interferire con esso sulla rete. fly (modifica contenuto, inserisci annunci, esegui minatori e analizza il contenuto dei moduli di input può essere utilizzato al termine del caricamento della pagina);
• Sviluppatori di browser Brave, Opera и Vivaldi, basati sul motore Chromium, intendono lasciare il supporto per la modalità di blocco webRequest nei loro prodotti.

Fonte: opennet.ru