Google risponde ai problemi di blocco degli annunci di Chromium

A gennaio abbiamo scritto di un crescente furore dovuto a I piani di Google per deprecare l'API webRequest e sostituiscilo con una nuova API dichiarativaNetRequest che è molto meno potente e che limita il numero di regole che gli sviluppatori possono utilizzare per filtrare gli annunci.

All'epoca lo sviluppatore di una delle migliori app adbock, uBlock Origin, ha dichiarato su bugs.chromium.org:

Se questa API dichiarativaNetRequest (abbastanza limitata) finisce per essere l'unico modo in cui i bloccanti dei contenuti possono svolgere il loro dovere, ciò significa essenzialmente che due bloccanti dei contenuti che ho mantenuto per anni, uBlock Origin ("uBO") e uMatrix, non possono più esistere.

Ora a L'ingegnere di Google che lavora su Chromium ha risposto alle preoccupazioni e ha accettato alcune concessioni, anche se non è chiaro se queste vadano abbastanza lontano.

Google è rimasto determinato a sbarazzarsi dell'AP webRequest, affermando che è una fonte di abusi crescenti, ma ha accettato di migliorare l'API dichiarativaNetRequest nel modo seguente:

• Supporto per le regole dinamiche: Siamo d'accordo sul fatto che ciò sia prezioso nella creazione di sofisticate estensioni di blocco dei contenuti e verrà aggiunto il supporto per le regole dichiarative che possono essere aggiunte o rimosse in fase di esecuzione all'API dichiarativaNetRequest.
• Dimensioni del set di regole aumentate: Aumenteremo il limite della regola dal valore della bozza di 30. Tuttavia, è ancora necessario un limite superiore per garantire le prestazioni agli utenti. Gli elenchi di blocco tendono ad essere "solo push", in cui vengono aggiunte nuove regole ma le regole obsolete vengono raramente, se non mai, rimosse (ricerca esterna ha dimostrato che il 90% delle regole di blocco EasyList non ha fornito alcun vantaggio negli scenari di blocco comuni). Avere questo elenco che continua a crescere senza limiti è problematico.
• Azioni e condizioni aggiuntive: Abbiamo in programma di aggiungere il supporto per la corrispondenza in base a più condizioni, come la dimensione delle risorse, e forniremo azioni per modificare parti di una richiesta invece di bloccarla semplicemente, come lo stripping dei cookie. Stiamo anche esaminando altre condizioni e azioni che potrebbe avere senso aggiungere, come la corrispondenza basata sul dominio di primo livello. (Una nota aggiuntiva: mentre stiamo esaminando l'aggiunta del supporto per le modifiche CSP, l'aggiunta di un'intestazione CSP per disabilitare JavaScript è stata spesso menzionata come caso d'uso; questo è già possibile tramite il le impostazioni del contenuto API. Se questo è insufficiente, fateci sapere perché.)

Google ha affermato che avrebbe continuato a lavorare con gli sviluppatori e non avrebbe rimosso l'API webRequest prima che la sostituzione fosse pronta e matura, dicendo:

Ancora una volta, ci impegniamo a supportare le estensioni in Chrome. Continueremo a lavorare con gli sviluppatori. Non lanceremo Manifest V3 finché non sarà pronto e ci sarà un periodo di migrazione in cui potremo continuare ad affrontare feedback e problemi. Non rimuoveremo il supporto per Manifest V2 finché non avremo fiducia nella piattaforma.

Molti rimangono scettici, tuttavia il vero obiettivo di Google è controllare più strettamente l'esperienza dell'utente per consentire il monitoraggio e la pubblicazione di annunci dei loro miliardi di utenti.

I nostri lettori pensano che Google utilizzerà il suo crescente controllo sui motori di rendering web del mondo tramite Chromium per aumentare ulteriormente la loro attività pubblicitaria o c'è abbastanza concorrenza tra i browser per mantenerli onesti? Facci sapere di seguito.

via Il registro