L'imminente Manifest V3 per le estensioni di Google Chrome cambierà il modo in cui funzionano i blocchi degli annunci su Chrome. È questa la strada giusta da seguire per gli ad blocker e Google?
Google Chrome è il browser web multipiattaforma più popolare attualmente disponibile sul mercato, rivendicando il 62,7% della quota di utilizzo globale del browser fino a maggio 2019, con Safari di Apple al secondo posto con il 15,89% e Firefox di Mozilla con il 5,07%. A causa della sua parte da leone, il più piccolo dei cambiamenti che Google Chrome apporta alla sua piattaforma finisce per influenzare milioni di utenti in tutto il mondo. Quindi, quando Google ha annunciato la prossima versione manifest delle estensioni sotto forma di Manifest V3 per le estensioni di Google Chrome, lo sapevamo stavano per subire alcuni grandi cambiamenti, soprattutto quando è emerso che Google stava creando un'API di blocco dei contenuti all'interno di Chrome si.
Cos'è Manifest V3?
Se sei un utente Chrome attivo, utilizzi senza dubbio alcune estensioni. Le estensioni sono piccoli programmi software che personalizzano l'esperienza di navigazione utilizzando il file
Da alla fine dell'anno scorso, Google ha lavorato su "Manifest V3", una serie di modifiche proposte alla piattaforma Chrome Extensions che possono essere classificate come "modifiche di rilievo". Come il documento di discussione pubblica per Manifest V3 afferma, la versione manifest dell'estensione è un meccanismo per limitare determinate funzionalità a una determinata classe di estensioni. Queste restrizioni possono assumere la forma di una versione minima o di una versione massima. La limitazione a una versione minima consente alle API o alle funzionalità più recenti di essere disponibili solo per le estensioni più recenti mentre la limitazione a una versione manifest massima consente alle API o funzionalità precedenti di essere gradualmente deprecato.
In termini più semplici, una nuova versione manifest consente a Chrome di limitare le API e le funzionalità a questa nuova versione manifest, in per costringere gli sviluppatori di estensioni a migrare da alcune API meno recenti a causa del loro impatto negativo sull'utente esperienza. L'implementazione di un'estensione in Manifest V3 dovrebbe teoricamente fornire garanzie più forti dal punto di vista della sicurezza, della privacy e delle prestazioni.
Sebbene esista un'ampia gamma di modifiche delineate in Manifest V3, la modifica più controversa riguarda la decisione di Google di limitare le capacità di blocco presenti nell'esistente chrome.webRequest API (e concentrare l'API sull'osservazione invece che sul blocco) e quindi presentare queste capacità di blocco attraverso una nuova interfaccia chrome.declarativeNetRequest API. Questo particolare cambiamento ha infiammato la comunità poiché finisce per prendere di mira il meccanismo di blocco degli annunci della famosa estensione di blocco degli annunci, uBlocca originee colpisce direttamente i suoi oltre 10 milioni di utenti.
Prima di affrontare questo problema, diamo un'occhiata a come webRequest L'API viene confrontata con dichiarativaNetRequest API.
API di richiesta Web e API di richiesta netta dichiarativa
Il presente
La descrizione ufficiale di Web Request descrive l'API come segue:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Con Richiesta Web, Chrome invia Tutto i dati in una richiesta di rete all'interno in ascolto. L'estensione ha quindi la possibilità di valutare la richiesta e istruire Chrome su cosa fare con la richiesta: consentirla, bloccarla o inviarla con alcune modifiche.
Segui la sequenza di eventi per capire cosa succede quando le estensioni utilizzano l'API Richiesta Web. Quando un utente con un'estensione Richiesta Web installata fa clic su un collegamento, Chrome informa l'estensione che è stata effettuata una richiesta di dati prima che la richiesta raggiunga il server. L'estensione può scegliere di modificare la richiesta in questa fase. Il server quindi risponde, ma la risposta passa nuovamente attraverso l'estensione e l'estensione può stabilire se la risposta deve essere modificata. Chrome infine esegue il rendering della pagina e l'utente è in grado di visualizzare il risultato della sua azione di clic.
Mentre Chrome consegna il comando tutti i dati in una richiesta di rete, le estensioni che utilizzano l'API Web Request hanno accesso per leggere e modificare tutto ciò che un utente fa sul web. Quindi, mentre i blocchi di contenuti come uBlock Origin utilizzano saggiamente il potenziale di questa API, Google lo afferma altre estensioni con intenzioni dannose hanno abusato delle stesse per ottenere l'accesso ai dati personali degli utenti informazione. Secondo Google, da gennaio 2018 il 42% delle estensioni dannose utilizza la Web Request API. Google afferma inoltre che l'utilizzo dell'API come versione di blocco implica "costi di prestazione significativi". di esso richiede un processo persistente e spesso di lunga durata che è fondamentalmente incompatibile con il termine "pigro" processi.
Con Manifest V3 Google propone di limitare questa API nella sua forma di blocco. In alternativa, Google fornisce l'API Declarative Net Request.
Il futuro
La descrizione ufficiale di Declarative Net Request descrive l'API come segue:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Con Declarative Net Request, Chrome non ha bisogno di inviare tutte le informazioni su una richiesta all'estensione di ascolto. Invece, l'estensione registra regole con Chrome che dicono in anticipo al browser cosa fare se vengono rilevati determinati tipi di richieste.
L'estensione specifica in anticipo le sue regole. La richiesta dell'utente viene quindi confrontata con questa regola dal browser (e non dall'estensione), l'azione viene intrapresa anche dal browser e la pagina viene successivamente visualizzata. Google afferma che ciò consente loro di garantire l’efficienza poiché possono esercitare il controllo sull’algoritmo che determina il risultato e possono prevenire o disabilitare regole inefficienti. Presenta inoltre migliori garanzie di privacy per l'utente finale poiché i dettagli della richiesta di rete non sono esposti all'estensione. Poiché non sono più necessari processi persistenti e di lunga durata (poiché le regole vengono registrate in anticipo), Google lo afferma questo approccio apporta anche miglioramenti delle prestazioni che renderanno le estensioni significativamente più praticabili in caso di risorse limitate piattaforme.
La richiesta netta dichiarativa sarà disponibile sia per Manifest V2 (attuale) che per Manifest V3, ma sarà il modo principale in cui Google consentirà la modifica delle richieste di rete in Manifest V3.
La controversia
Le modifiche di Google sembrano avere senso finché non si sente l'altro lato della storia, principalmente quello degli ad-blocker. Questa particolare migrazione dell'API viene vista come il modo in cui Google elimina i blocchi degli annunci poiché cambia radicalmente il modo in cui funziona uno dei blocchi degli annunci più popolari. Ciò si collega alla "teoria" secondo cui Google è motivato verso questo cambiamento più dal punto di vista del business che dal punto di vista della sicurezza degli utenti. Dopotutto, Google dipende fortemente dalla pubblicità per le sue entrate e gli ad-blocker sono percepiti come una minaccia diretta per i clienti di Google su questo fronte, come è stato rivelato attraverso Presentazione del modulo SEC 10-K 2018 di Alphabet (attraverso Il registro):
Le tecnologie nuove ed esistenti potrebbero influire sulla nostra capacità di personalizzare gli annunci e/o potrebbero bloccare gli annunci online, danneggiando la nostra attività.
Sono state sviluppate tecnologie per rendere più difficile la personalizzazione degli annunci o per bloccare del tutto la visualizzazione degli annunci e di alcuni fornitori dei servizi online hanno tecnologie integrate che potrebbero potenzialmente compromettere la funzionalità principale dei servizi digitali di terze parti pubblicità. La maggior parte dei nostri ricavi Google deriva dalle commissioni pagateci in relazione alla visualizzazione di annunci online. Di conseguenza, tali tecnologie e strumenti potrebbero influenzare negativamente i nostri risultati operativi.
Google ha dovuto farlo rilasciare una dichiarazione per risolvere questo problema, ribadendo la propria posizione secondo cui il cambiamento è nell'interesse della privacy degli utenti e non un attacco diretto contro gli ad blocker:
Non stiamo impedendo lo sviluppo di blocchi pubblicitari né impedendo agli utenti di bloccare gli annunci. Vogliamo invece aiutare gli sviluppatori, inclusi quelli che bloccano i contenuti, a scrivere estensioni in modo da proteggere la privacy degli utenti.
È necessario fare riferimento a due dei più popolari ad-blocker disponibili su Google Chrome: uBlocca origine E Adblock Plus, che adottano entrambi approcci diversi per ottenere lo stesso risultato di blocco dei contenuti. uBlock Origin fa molto affidamento sull'API Web Request e la community ha preferito questa estensione nel corso degli anni. Anche Adblock Plus e altre estensioni di blocco dei contenuti si basano sulla parte di blocco di Richiesta Web, quindi le modifiche a questa API finiranno per influenzare la maggior parte dei blocchi di contenuti almeno in una certa misura.
La spinta di Google a deprecare Web Request essenzialmente ucciderà uBlock Origin nel suo formato attuale, qualcosa che influenzerà davvero molti utenti. Mentre gli utenti senza fedeltà (e senza intenzione di preoccuparsi di come viene ottenuto il blocco degli annunci) troveranno soluzioni alternative che presentano i loro inconvenienti, diventerà impossibile per i lealisti e gli appassionati di inventare nuovi progetti di motori di filtro per aggirare le varie tecniche che i siti Web eventualmente inventeranno per combattere i blocchi degli annunci su questa specifica API.
Anche la Declarative Net Request è stata proposta come un motore di filtraggio piuttosto limitato, così com'era inizialmente previsto avere un limite di 30.000 regole di filtro statico per estensione (regole dichiarate durante l'installazione); e limite di 5.000 regole sulle regole di filtro dinamico per estensione (regole che possono essere aggiunte dopo l'installazione). Eventuali regole in eccesso verranno ignorate, il che è un po' un problema poiché EasyList per Adblock Plus ha 70.000 regole, mentre uBlock Origin può essere configurato per funzionare con oltre 100.000 regole. Dopo la reazione iniziale della comunità, Google ha risposto promettendo di modificare il limite delle regole statiche da 30.000 regole per estensione a un massimo globale di 150.000 regole. Ciò ha quindi l'effetto collaterale di impedire agli utenti di utilizzare altri script ricchi di regole insieme a un blocco degli annunci, quindi gli utenti dovranno destreggiarsi tra le proprie preferenze.
Oltre al limite di filtraggio limitato, Richiesta netta dichiarativa può reindirizzare solo a URL statici, quindi non è incluso alcun supporto per la corrispondenza dei modelli. uBlock Origin fa molto affidamento sulla corrispondenza dei modelli e sullo sviluppatore dell'estensione ha dichiarato che non è possibile effettuare il retrofit l'algoritmo di corrispondenza della sua estensione per soddisfare i requisiti API. L'API richiederebbe anche un aggiornamento completo dell'estensione per aggiornare semplicemente l'elenco dei filtri, il che sarebbe un'attività troppo frequente considerando il frequenza con cui questi elenchi di filtri vengono aggiornati. Naturalmente, questi aggiornamenti dipenderanno anche dai criteri e dai processi di revisione delle estensioni di Google.
D'altra parte, Google ha sempre mantenuto la sua posizione secondo cui il suo intento di allontanarsi da Web Request proviene da a dal punto di vista della sicurezza, poiché l'API Web Request è troppo potente nella sua forma attuale e lascia aperto uno spazio molto ampio per abuso. Questo abuso non è solo teorico, poiché Google ha affermato che il 42% delle estensioni dannose hanno abusato di questa API. Quello di AppleSafari API di blocco dei contenuti è stato progettato come Declarative Net Request per ragioni simili, poiché c'è meno spazio di sfruttamento per uno sviluppatore non autorizzato. Nella richiesta Web depotenziata, le richieste di rete sarebbero ancora osservabili, ma avrebbero bisogno di autorizzazioni sugli host pertinenti. Con Manifest V3, anche le autorizzazioni dell'host stanno cambiando in modo significativo e non possono più essere concesse in modo generale al momento dell'installazione.
Google ha anche utilizzato i costi generali delle prestazioni come motivatore per il passaggio. La valutazione delle richieste di rete avviene nel thread JavaScript dell'estensione, il che può incidere negativamente sulle prestazioni. In confutazione, lo sviluppatore di uBlock Origin menziona la sua estensione non comporta alcuna penalizzazione significativa delle prestazioni anche quando si devono applicare fino a 140.000 filtri statici. Si sostiene che i costi sostenuti siano facilmente recuperabili dalle risorse a cui viene impedito di essere scaricate da server remoti e quindi non elaborate dal browser.
Anche se Google non utilizza questo ragionamento, un argomento contro Web Request può essere avanzato anche per quanto riguarda l’efficienza con il blocco degli annunci. Con Richiesta Web, se un'estensione non risponde in tempo (a causa di un ritardo o di un arresto anomalo), la richiesta di gestione della rete viene chiaramente consentita, consentendo agli annunci di sfuggire al blocco degli annunci. La Net Request dichiarativa, invece, non soffrirebbe di questo inconveniente. Invece, gli annunci passeranno se non rimangono intrappolati nelle regole statiche, e questo accadrà il più delle volte.
Conclusione
Dalle spiegazioni di cui sopra, è chiaro che la Declarative Net Request non è un clone della funzionalità 1:1 per il blocco funzionalità dell'API Richiesta Web e gli sviluppatori di estensioni sono destinati a essere seccati quando il loro duro lavoro verrà ostacolato tali cambiamenti. Ma anche il ragionamento di Google ha un peso: Web Request è troppo potente e i suoi poteri devono esserlo ridotto nell'interesse più ampio della comunità degli utenti (che comprende utenti medi insieme a appassionati).
Anche il passaggio alla Declarative Net Request avrebbe potuto essere una mossa positiva per le pubbliche relazioni: dopo tutto, Google sta aggiungendo un'API di blocco dei contenuti integrata a Chrome! Ma dal momento che la nuova API comporta pesanti restrizioni, la comunità giustamente vede questo come un taglio delle loro ali. In un mondo ideale, Google avrebbe dovuto esplorare il funzionamento degli ad blocker come uBlock Origin prima di lanciare la nuova API. Allo stato attuale, la nuova API potrebbe avvalersi di ulteriori allentamenti sui limiti delle regole per adattarsi a scenari in cui gli utenti vorrebbero utilizzare due estensioni ad alto utilizzo di filtri.
Secondo Il registro, le prime build con le modifiche a Manifest V3 saranno disponibili da luglio 2019 in poi. Ci auguriamo che Google tenga conto del feedback ricevuto dalla community di sviluppatori di estensioni con queste build.
Un ringraziamento speciale al redattore capo di XDA Mishaal Rahman per i suoi input e assistenza!
Modifica: l'articolo equiparava erroneamente il funzionamento di Adblock Plus a quello dell'API Declarative Net Request. L'articolo è stato modificato di conseguenza. Adblock Plus sarà interessato anche dalla rimozione delle funzionalità di blocco dell'API Web Request.