Manifest V3 di Google danneggia ancora la privacy, la sicurezza e l’innovazione

Sono trascorsi più di due anni dalla nostra risposta iniziale alla proposta Manifest V3 di Google . Manifest V3 è l'ultima serie di modifiche alle regole del browser Chrome per le estensioni del browser. Ogni aggiornamento della versione manifest delle estensioni introduce modifiche non compatibili con le versioni precedenti per spostare apparentemente la piattaforma in avanti. Nel 2018, Manifest V3 è stata inquadrata come una proposta , con Google che ha ripetutamente affermato di ascoltare il feedback . Diamo un'occhiata per vedere a che punto siamo quando il 2021 si conclude.

Da quando ha annunciato Manifest V3 nel 2018, Google ha lanciato Manifest V3 in Chrome, ha iniziato ad accettare estensioni Manifest V3 nel Chrome Web Store, ha co-annunciato l' adesione al W3C WebExtensions Community Group (formato in collaborazione con Apple, Microsoft e Mozilla) e, la maggior parte di recente, è stata definita una sequenza temporale per la deprecazione di Manifest V2 . Le nuove estensioni di Manifest V2 non saranno più accettate a partire da gennaio 2022 e Manifest V2 non funzionerà più a partire da gennaio 2023.

Secondo Google, Manifest V3 migliorerà la privacy, la sicurezza e le prestazioni. Fondamentalmente non siamo d'accordo.

Secondo Google, Manifest V3 migliorerà la privacy, la sicurezza e le prestazioni . Fondamentalmente non siamo d'accordo. Le modifiche in Manifest V3 non fermeranno le estensioni dannose, ma danneggeranno l'innovazione, ridurranno le capacità di estensione e danneggeranno le prestazioni del mondo reale. Google ha ragione a vietare il codice ospitato in remoto (con alcune eccezioni per cose come gli script utente), ma questa è una modifica alle norme che non doveva essere combinata con il resto di Manifest V3.

La risposta della community a Manifest V3, sia nel gruppo Google delle estensioni di Chromium che nel gruppo della comunità W3C WebExtensions , è stata ampiamente negativa. Gli sviluppatori sono preoccupati per la rottura delle estensioni di Manifest V3 , confusi dalla scarsa documentazione e frustrati dall'incertezza sulla funzionalità mancante unita alla scadenza del termine del ciclo di vita di Manifest V2.

Google ha reagito in modo selettivo, colmando alcune enormi lacune nelle funzionalità e aumentando i propri limiti arbitrari sulle regole di blocco dichiarativo. Tuttavia, non ci sono segni che Google abbia alterato la rotta sulle parti più dolorose di Manifest V3. Qualcosa di simile è successo quando Chrome ha annunciato l' aggiunta di un'icona "pezzo del puzzle" alla barra degli strumenti di Chrome. Tutte le icone delle estensioni dovevano essere nascoste all'interno del menu dei pezzi del puzzle ("sbloccato") per impostazione predefinita. Nonostante il feedback universalmente negativo, Google ha continuato a nascondere le estensioni per impostazione predefinita. L'esperienza del pezzo del puzzle di Chrome continua a confondere gli utenti fino ad oggi.

Il WebExtensions Community Group del World Wide Web Consortium (W3C) è uno sviluppo positivo, manon affronterà lo squilibrio di potere creato dalla schiacciante quota di mercato di Chrome: oltre due terzi di tutti gli utenti a livello globale utilizzano Chrome come browser. È improbabile che questa supermaggioranza di utenti Web migri via a causa di un litigio tecnico sulle API di estensione. Indipendentemente da ciò che Google decide di fare, gli sviluppatori di estensioni dovranno aggirarlo o perdere la maggior parte dei loro utenti. E poiché è improbabile che gli sviluppatori vogliano mantenere basi di codice separate per browser diversi, altri browser saranno fortemente incentivati ​​ad adottare qualsiasi insieme di API di estensione che Google finirà per implementare.

Invece di lavorare in vera collaborazione sulla prossima iterazione delle estensioni del browser, Google si aspetta che Manifest V3 venga trattato come una conclusione scontata. La partecipazione al gruppo WebExtensions conferisce a Google l'apparenza della collaborazione anche se continua a fare comunque quello che stava per fare. In breve, Google entra nella stanza come un gorilla di 800 libbre non disposto ad ascoltare o lavorare in modo significativo con la comunità.

Forzare la riscrittura di tutte le estensioni per i requisiti di Google senza corrispondenti vantaggi per gli utenti è una mossa fondamentalmente ostile agli utenti da parte di Google

Forzare la riscrittura di tutte le estensioni per i requisiti di Google senza corrispondenti vantaggi per gli utenti è una mossa fondamentalmente ostile agli utenti da parte di Google. Manifest V3 viola i principi di progettazione "centrato sull'utente", "compatibilità", "prestazioni" e "manutenibilità" della carta del gruppo WebExtensions .

Sebbene la risposta di Google al feedback della community sia stata di modifiche e correzioni ai margini, abbiamo prestato attenzione a ciò che dicono gli sviluppatori . Le carenze di Manifest V3 sono state messe a fuoco.

Richiedere gli addetti ai servizi per le estensioni è dannoso

La maggior parte delle estensioni del browser sono costruite attorno a una pagina di sfondo, un luogo in cui ogni tipo di lavoro avviene fuori dalla vista mentre l'utente naviga. Con l'odierna Manifest V2, le estensioni in Chrome possono scegliere di utilizzare una pagina di sfondo effimera basata su "eventi" o di utilizzare una pagina di sfondo persistente. Le pagine temporanee vengono chiuse e riavviate ripetutamente, ogni volta che Chrome decide di farlo. Le pagine persistenti continuano a funzionare finché il browser è aperto. Oltre alle API delle estensioni, entrambi i tipi di pagine in background delle estensioni hanno accesso al set standard di API dei siti web.

Manifest V3 rimuove la scelta, richiedendo invece che tutte le estensioni siano basate su "operatori di servizio". I service worker sono temporanei, basati su eventi e non hanno accesso al set standard di API del sito web. Oltre alla rimozione del meccanismo di "blocco webRequest", di cui parliamo di seguito, il ribasamento di tutte le estensioni sugli addetti ai servizi è uno dei cambiamenti più dannosi in Manifest V3.

Ribasare tutte le estensioni sugli addetti ai servizi è uno dei cambiamenti più dannosi in Manifest V3

I service worker sono script JavaScript eseguiti in background, indipendentemente dal sito Web che li ha avviati. Gli operatori di servizio hanno lo scopo di consentire ai siti Web di eseguire attività precedentemente difficili o impossibili che ottimizzano le prestazioni del sito Web o forniscono funzionalità offline. Ad esempio, la prima volta che visiti twitter.com, il sito Web installa un service worker nel tuo browser. L'operatore di servizio rimarrà installato e potrebbe continuare a eseguire attività, anche se perdi la connettività di rete o esci da twitter.com.

Gli addetti ai servizi conferiscono ai siti Web superpoteri, fornendo alle app Web funzionalità altrimenti difficili o impossibili. Ma i lavoratori dei servizi non hanno la stessa libertà di eseguire il codice dei siti Web e ci sono limiti alla durata della vita dei lavoratori dei servizi. Ogni lavoratore del servizio ascolta i messaggi dal proprio sito Web, esegue le proprie attività e si spegne poco dopo. Questo ha senso, poiché il sito Web è l'attore principale che chiede aiuto al suo operatore di servizio. Ma questo modello non si traduce bene nelle estensioni del browser.

Gli operatori di servizio sono stati progettati per lavorare con i siti Web e sono una parte standardizzata della piattaforma Web . Ma non esiste uno standard di service worker equivalente per WebExtensions. Poiché le estensioni migliorano il browser, l'applicazione degli stessi limiti di esecuzione da parte dei lavoratori dei servizi del sito Web non ha senso, eppure questo è esattamente ciò che ha fatto Google.

A volte, le estensioni fanno cose che agiscono esplicitamente contro le intenzioni degli sviluppatori del browser, ad esempio quando i tracker blocker limitano le informazioni che escono da Chrome.

I siti Web e i relativi operatori di servizio sono sviluppati dagli stessi team e sono pensati per lavorare in tandem. Ma i browser e le estensioni del browser sono creati da team diversi con obiettivi diversi. Le estensioni dovrebbero aggiungere nuove funzionalità a cui gli sviluppatori di browser non hanno pensato o omesso intenzionalmente. A volte, le estensioni fanno cose che agiscono esplicitamente contro le intenzioni degli sviluppatori del browser, ad esempio quando i tracker blocker limitano il flusso di informazioni in uscita da Chrome . Chrome continua a essere l'unico browser principale senza una protezione di monitoraggio integrata significativa . Le estensioni Web necessitano di maggiore libertà per operare da sole, il che significa un accesso di prima classe alle API del browser e alla memoria persistente.

Dai un'occhiata al lungo elenco di casi d'uso noti danneggiati dalla richiesta di personale di servizio. La riproduzione senza interruzioni dell'audio, l'analisi dell'HTML, la richiesta di geolocalizzazione , la comunicazione tramite i canali dati WebRTC e la possibilità di avviare un addetto ai servizi separato sono tutte infrante nel nuovo paradigma.

In Manifest V2, le estensioni vengono trattate come applicazioni di prima classe con il proprio ambiente di esecuzione persistente. Ma sotto la V3, sono trattati come accessori, hanno privilegi limitati e possono essere eseguiti solo in modo reattivo.

Secondo il feedback degli ingegneri di Mozilla , un vantaggio legittimo dei lavoratori dell'assistenza potrebbe essere quello di ottenere estensioni per gestire con garbo la risoluzione anticipata su Android. Ma ci sono modi per raggiungere questo obiettivo che non comportano questo grado di danno. E se uno degli obiettivi di Google per Manifest V3 è aiutare a portare estensioni a Chrome su Android, Google non ha comunicato queste informazioni. Come possono i browser e gli sviluppatori di estensioni collaborare per portare avanti le estensioni quando sembra che Google non sia disposta a condividere tutte le ragioni dietro Manifest V3?

dichiarativoNetRequest da solo è inadeguato

Oltre a proporre di trasferire le estensioni a una fondazione di servizio inadatta, Manifest V3 di Google sta cambiando il modo in cui le estensioni di blocco dei contenuti possono funzionare.

Le estensioni basate su Manifest V2 utilizzano webRequest, un'API flessibile che consente alle estensioni di intercettare e bloccare o modificare in altro modo le richieste e le risposte HTTP. Manifest V3 elimina le funzionalità di blocco e modifica di webRequest a favore della nuova API dichiarativaNetRequest. L'API webRequest di sola intercettazione o "osservazionale", che consente alle estensioni di monitorare, anche se non modificare, le richieste, presumibilmente rimarrà in Manifest V3, sebbene l'API sia interrotta in Manifest V3 in questo momento, con la segnalazione di bug pertinente aperta per oltre due anni .

Se la tua estensione deve elaborare le richieste in un modo che non è coperto dalle regole esistenti, non puoi farlo.

Come suggerisce il nome, la nuova API dichiarativaNetRequest è dichiarativa. Oggi le estensioni possono intercettare ogni richiesta che una pagina web fa e decidere cosa fare con ciascuna al volo. Ma un'API dichiarativa richiede agli sviluppatori di definire in anticipo cosa farà la loro estensione con richieste specifiche, scegliendo da un insieme limitato di regole implementate dal browser. È scomparsa la capacità di eseguire funzioni sofisticate che decidono cosa fare con ogni singola richiesta. Se la tua estensione deve elaborare le richieste in un modo che non è coperto dalle regole esistenti, non puoi farlo.

Da ciò segue il problema principale con la richiesta di un'API dichiarativa per il blocco. La tecnologia pubblicitaria si evolve rapidamente e gli sviluppatori di estensioni per la privacy devono essere in grado di cambiare il loro approccio ad essa nel tempo. A peggiorare le cose, gli sviluppatori di estensioni non possono dipendere dagli ingegneri del browser Google per reagire in modo tempestivo o del tutto. Google ha abbandonato lo sviluppo dell'API di estensione per anni prima di Manifest V3. Ad esempio, mentre le estensioni hanno la capacità di "scoprire" i domini CNAME in Firefox da oltre tre anni, Chrome non ha ancora il supporto per l'uncloaking CNAME . E mentre questo supporto potrebbe arrivare ad un certo punto in futuro come parte di dichiarativaNetRequest, molti anni indietro rispetto a Firefox, che ne dici di sbloccare i CNAME altrove, come in webRequest osservazionale?

Come abbiamo scritto nel 2019 , "Per gli sviluppatori di estensioni per il blocco di annunci e tracker, le API flessibili non sono solo belle da avere, sono un requisito. Quando particolari protezioni della privacy acquistano popolarità, annunci e tracker si evolvono per eluderle. Di conseguenza, anche le estensioni di blocco devono evolversi o rischiano di diventare irrilevanti. […] Se Google decide che le estensioni per la privacy possono funzionare solo in un modo specifico, abbasserà permanentemente la bilancia a favore di annunci e tracker".

Abbiamo molte domande su come l'API dichiarativa interagirà con altri progetti Google. Le tecnologie Privacy Sandbox di Google saranno esposte a dichiarativeNetRequest? Se dichiarativeNetRequest funziona esclusivamente sulla base della corrispondenza del pattern URL, in che modo le estensioni bloccheranno le sottorisorse prive di URL significativi, facilitato da un altro sforzo di Google chiamato WebBundles ? Man mano che più tracciamenti si spostano sul server , le estensioni di Manifest V3 saranno in grado di tenere il passo? Manifest V3 è un gradino in un percorso in cui le parti di Google del Web diventano sbloccabili dalle estensioni?

Rifiutiamo dichiarativeNetRequest in sostituzione del blocco di webRequest. Invece, Google dovrebbe consentire agli sviluppatori di scegliere di utilizzare una delle API.

Rifiutiamo dichiarativeNetRequest in sostituzione del blocco di webRequest. Invece, Google dovrebbe consentire agli sviluppatori di scegliere di utilizzare una delle API. La messa a disposizione di entrambe le API può comunque soddisfare gli obiettivi dichiarati di Google di rendere le estensioni più sicure e più performanti. Google potrebbe utilizzare Chrome Web Store per guidare le estensioni che in realtà non richiedono il blocco di WebRequest verso l'API dichiarativa. Google potrebbe anche fornire strumenti per sviluppatori di estensioni che analizzerebbero automaticamente la tua estensione per potenziali miglioramenti, come gli strumenti di controllo forniti per promuovere le migliori pratiche per gli sviluppatori di siti web. Inoltre, le estensioni che utilizzano webRequest dovrebbero essere contrassegnate per un'ulteriore revisione; questo dovrebbe essere chiaramente comunicato agli sviluppatori di estensioni.

Dichiarazioni di prestazioni di Google

Google ha affermato che parte del motivo delle sue restrizioni Manifest V3 è il miglioramento delle prestazioni. Se le estensioni possono avere pagine di sfondo persistenti, l'argomento è che quelle pagine rimarranno inattive e sprecheranno memoria. Inoltre, Google afferma che webRequest è un'API inefficiente a causa del modo in cui attraversa gli interni del browser e il codice di estensione e perché consente alle estensioni mal implementate di rallentare Chrome. Google non ha fornito prove a sostegno di queste affermazioni.

In effetti, molte delle estensioni più popolari accelerano drasticamente la normale navigazione bloccando annunci e tracker che monopolizzano le risorse . D'altra parte, le restrizioni imposte da Manifest V3 causeranno funzionalità interrotte e prestazioni degradate per le attività di estensione comuni.

Questo esercizio dovrebbe smentire rapidamente le affermazioni di Google.

Mentre una pagina di sfondo dell'estensione persistente continuerà a utilizzare la memoria finché il browser è aperto, prova ad aprire Task Manager di Chrome qualche volta. Quindi confronta la memoria consumata da ogni sito Web che hai aperto con la memoria consumata dalle tue estensioni (presumibilmente molto meno). Quindi, se sei un utente di estensioni per la privacy o per il blocco degli annunci, prova a disabilitarle e a ricaricare i tuoi siti web. Questo esercizio dovrebbe smentire rapidamente le affermazioni di Google. La memoria consumata dai vari siti Web aperti, soprattutto senza l'aiuto di estensioni di privacy e sicurezza per bloccare tracker e inserzionisti ad alta intensità di memoria, dovrebbe sminuire la memoria consumata dalle estensioni stesse.

Inoltre, l'avvio e l'eliminazione ripetuti delle estensioni basate sui lavoratori del servizio comporteranno un maggiore carico della CPU. Ad esempio , un'estensione che utilizza schede, navigazione web o API di richiesta web osservativa verrà costantemente richiamata durante la navigazione fino a quando l'utente non interrompe la navigazione o viene raggiunto il limite di cinque minuti. Quando l'utente riprende la navigazione, l'operatore del servizio dovrà essere riavviato immediatamente. Immagina quante volte un'estensione del genere verrà riavviata durante una giornata tipo e con quale fine?

Qualsiasi estensione che dipenda da un'elaborazione una tantum relativamente costosa all'avvio (ad esempio, modelli di apprendimento automatico o WebAssembly ) è particolarmente adatta alla natura effimera dei lavoratori dei servizi.

Oltre a danneggiare le prestazioni, l'arresto arbitrario degli addetti ai servizi di estensione interromperà la funzionalità.

Oltre a danneggiare le prestazioni, l'arresto arbitrario degli addetti ai servizi di estensione interromperà la funzionalità. L'utente potrebbe essere nel mezzo dell'interazione con la funzionalità fornita dall'estensione su alcune pagine Web quando il lavoratore del servizio dell'estensione viene disattivato. Dopo il riavvio di un lavoratore del servizio, l'estensione potrebbe avere dati di configurazione non aggiornati o mancanti e non funzionerà correttamente senza che l'utente sappia di ricaricare la pagina. Il ritardo aggiuntivo causato dall'avvio dell'operatore del servizio interromperà i casi d'uso che dipendono dalla velocità di messaggistica tra la pagina Web e l'estensione. Ad esempio, un'estensione che modifica dinamicamente il menu di scelta rapida in base al tipo di elemento cliccato non è più in grado di comunicare al proprio interno in tempo per modificare il menu prima che si apra.

Regressioni e bug

Oltre a tutto il resto, il lancio di Manifest V3 da parte di Google è stato affrettato e pieno di bug.

Anche se non sarai più in grado di caricare nuove estensioni Manifest V2 sul Chrome Web Store a partire da gennaio 2022 (il prossimo mese!), intere classi di estensioni esistenti sono completamente interrotte in Manifest V3. Come accennato in precedenza, webRequest osservativo è ancora interrotto , così come la messaggistica nativa . Manipolazione di pagine Web in background, WebSocket , estensioni di script utente , WebAssembly : tutto rotto.

Anche l'iniezione di script nei contesti di pagina prima che accada qualsiasi altra cosa ( document_start "main world" injection ) è interrotta. Questa è una funzionalità fondamentale per le estensioni di privacy e sicurezza. Gli sviluppatori di estensioni devono ricorrere a brutti hack per eseguire questa iniezione con i parametri di configurazione, ma sono tutti rotti in Manifest V3 e la promessa sostituzione di Manifest V3 non è ancora disponibile.

Nel frattempo, i primi utenti di Manifest V3 stanno riscontrando bug che causano l' interruzione del funzionamento delle loro estensioni quando vengono rilasciate nuove versioni di estensione. Anche qualcosa di così basilare come l'internazionalizzazione è rotto all'interno dei lavoratori dei servizi .

La deludente risposta di Mozilla

Mozilla, apparentemente costretta a seguire la scia di Google per motivi di compatibilità, ha annunciato che richiederà anche estensioni per passare ai lavoratori dei servizi. Sebbene Mozilla continuerà a supportare le funzionalità di blocco di webRequest, oltre a implementare dichiarativeNetRequest, è stato inquadrato come una sospensione temporanea "finché non ci sarà una soluzione migliore che copra tutti i casi d'uso che consideriamo importanti".

Recentemente, in un segno tardivo del feedback della comunità che ha finalmente avuto qualche effetto, un ingegnere di Mozilla ha proposto un compromesso sotto forma di " pagine di eventi limitati ". Le pagine di eventi limitate ridurrebbero il dolore di Manifest V3 ripristinando il set standard di API del sito Web nelle pagine di sfondo dell'estensione. Un rappresentante di Apple ha espresso sostegno da parte di Safari. Google ha detto di no .

Invece di seguire Google in Manifest V3, Mozilla dovrebbe combattere con le unghie e con i denti contro la proposta di Google. Dovrebbe essere assolutamente chiaro che Google agisce da solo nonostante il feedback della community estremamente negativo. Una proposta non può diventare uno standard quando tutti gli altri si oppongono. Il comportamento di Mozilla sta oscurando il tradimento di Google dell'ecosistema delle estensioni. Inoltre, dà un falso senso di concorrenza e consenso quando in realtà questo è uno dei primi esempi del dominio del mercato e del comportamento anticoncorrenziale di Google.

Conclusione

Qual è il futuro delle estensioni? Come spiegato nella nostra risposta del 2019 , la rimozione del blocco webRequest non interromperà le estensioni abusive, ma danneggerà le estensioni di privacy e sicurezza. Se Manifest V3 è solo un passo verso un'esperienza di estensioni più "sicura" (cioè limitata), che aspetto avrà Manifest V4? Se la risposta è un minor numero di API meno potenti al servizio della "sicurezza", gli utenti alla fine ne risentiranno. L'universo delle possibili estensioni sarà limitato a ciò che Google sceglie esplicitamente di consentire e gli sviluppatori creativi scopriranno di non avere gli strumenti per innovare. Nel frattempo, le estensioni che difendono la privacy e la sicurezza degli utenti contro varie minacce sul Web rimarranno bloccate nel passato, incapaci di adattarsi all'evolversi delle minacce.

Non dovremmo fare affidamento sugli sviluppatori di browser per pensare a tutte le esigenze del Web diversificato, e non è necessario: questo è il bello delle estensioni.

Lo standard WebExtensions è ciò che tutti noi facciamo per essere. Se vogliamo prendere alla lettera il WebExtensions Community Group, dovremmo rendere le estensioni più capaci insieme. In effetti, dovremmo semplificare la scrittura di estensioni sicure, performanti e rispettose della privacy, ma non a costo di perdere potenti funzionalità di tutela della privacy. Dovremmo rendere più facile rilevare gli abusi, ma non a costo di perdere la capacità di innovare. Non dovremmo fare affidamento sugli sviluppatori di browser per pensare a tutte le esigenze del Web diversificato, e non è necessario: questo è il bello delle estensioni.

Il prossimo aggiornamento della versione manifest delle estensioni dovrebbe aprire le porte per autorizzare tutti noi, non vincolato dal fatto che tu possa convincere alcuni ingegneri del browser della validità delle tue esigenze. Google deve annullare il trasferimento ai lavoratori dell'assistenza, ripristinare il blocco di WebRequest e interrompere la deprecazione di Manifest V2 fino a quando tutte le regressioni della funzionalità non vengono risolte. Qualsiasi cosa al di fuori di questo è nel migliore dei casi un riconoscimento non sincero delle preoccupazioni condivise degli sviluppatori e, nel peggiore dei casi, una vera e propria ostilità nei confronti della comunità delle estensioni in generale.

Maggiori informazioni

• Attenzione agli utenti di Chrome: Manifest V3 è ingannevole e minaccioso
• Manifest V3: politica del Web aperta travestito da pecora
• I piani di Google per le estensioni di Chrome non aiuteranno davvero la sicurezza