Il 21 novembre, la directory AMO (addons.mozilla.org) inizierà ad accettare e firmare digitalmente i componenti aggiuntivi utilizzando la versione 109 del manifest di Chrome. Questi componenti aggiuntivi possono essere testati nelle build notturne di Firefox. Nelle versioni stabili, il supporto per la versione 17 di manifest sarà abilitato in Firefox 2023, previsto per il 2023 gennaio XNUMX. Il supporto per la seconda versione del manifesto sarà mantenuto per il prossimo futuro, ma alla fine del XNUMX, valutata la dinamica del trasferimento delle integrazioni alla terza versione del manifesto, verrà valutata la possibilità di deprecare il supporto per la seconda versione del manifesto. sarà considerato.
Il manifest di Chrome definisce le funzionalità e le risorse disponibili per le estensioni scritte utilizzando l'API WebExtensions. A partire dalla versione 57, Firefox è passato completamente all'utilizzo dell'API WebExtensions per lo sviluppo di componenti aggiuntivi e ha smesso di supportare la tecnologia XUL. Il passaggio a WebExtensions ha permesso di unificare lo sviluppo di componenti aggiuntivi con le piattaforme Chrome, Opera, Safari ed Edge, ha semplificato il porting di componenti aggiuntivi tra diversi browser web e ha permesso di sfruttare appieno la modalità multiprocesso di funzionamento (i componenti aggiuntivi di WebExtensions possono essere eseguiti in processi separati, isolati dal resto del browser). Per unificare lo sviluppo di componenti aggiuntivi con altri browser, Firefox offre una compatibilità quasi completa con la seconda versione del manifest di Chrome.
Chrome sta attualmente lavorando per passare alla versione 2024 del manifest e il supporto per la versione XNUMX verrà interrotto a gennaio XNUMX. L'obiettivo principale delle modifiche apportate nella nuova versione è semplificare la creazione di componenti aggiuntivi sicuri e ad alte prestazioni e rendere più difficile la creazione di componenti aggiuntivi non sicuri e lenti. Poiché la terza versione del manifest è stata criticata e romperà molti componenti aggiuntivi di sicurezza e blocco dei contenuti, Mozilla ha deciso di abbandonare la piena compatibilità con il manifest in Firefox e implementare alcune modifiche in modo diverso.
La principale insoddisfazione rispetto alla terza versione del manifesto è legata alla traduzione in modalità di sola lettura dell'API webRequest, che ha permesso di connettere i propri gestori che hanno pieno accesso alle richieste di rete e possono modificare il traffico al volo. Questa API viene utilizzata in uBlock Origin e molti altri componenti aggiuntivi per bloccare contenuti inappropriati e garantire sicurezza. Invece dell'API webRequest, la terza versione del manifest offre un'API dichiarativaNetRequest a capacità limitata, che fornisce l'accesso a un motore di filtro integrato che elabora in modo indipendente le regole di blocco, non consente l'uso dei propri algoritmi di filtro e non consentono di impostare regole complesse che si sovrappongono a seconda delle condizioni.
Tra le funzionalità di implementazione del nuovo manifest in Firefox:
- È stata aggiunta una nuova API dichiarativa di filtro dei contenuti, ma a differenza di Chrome, il supporto per la vecchia modalità di blocco dell'API webRequest non è stato interrotto.
- Il manifest definisce la sostituzione delle pagine in background con l'opzione Service Workers, che viene eseguita come processi in background (Background Service Workers). Per garantire la compatibilità in futuro, Firefox supporterà i Service Worker, ma attualmente sono sostituiti da un nuovo meccanismo di Pagine eventi, che è più familiare agli sviluppatori web, non richiede una rielaborazione completa dei componenti aggiuntivi ed elimina le limitazioni associate a l'impiego dei Lavoratori dei Servizi. Le pagine degli eventi consentiranno alle aggiunte di pagine in background esistenti di conformarsi ai requisiti della terza versione del manifest, mantenendo l'accesso a tutte le funzionalità necessarie per lavorare con il DOM.
- Il nuovo modello di richiesta di autorizzazione granulare: il componente aggiuntivo non potrà essere attivato per tutte le pagine contemporaneamente (l'autorizzazione "all_urls" è stata rimossa), ma funzionerà solo nel contesto della scheda attiva, ad es. l'utente dovrà confermare che il componente aggiuntivo funzioni per ciascun sito. In Firefox, tutte le richieste di accesso ai dati del sito saranno considerate facoltative e la decisione finale sulla concessione dell'accesso spetterà all'utente, che potrà decidere selettivamente quale componente aggiuntivo concedere l'accesso ai propri dati su un determinato sito.
Per gestire i permessi è stato aggiunto all'interfaccia un nuovo pulsante “Unified Extensions”, che può già essere testato nelle nightly build di Firefox. Il pulsante fornisce un mezzo per controllare direttamente a quali siti ha accesso ciascun componente aggiuntivo: l'utente può concedere e revocare l'accesso di un componente aggiuntivo a qualsiasi sito. La gestione delle autorizzazioni si applica solo ai componenti aggiuntivi basati sulla terza versione del manifest; per i componenti aggiuntivi basati sulla seconda versione del manifest, non viene eseguito il controllo granulare degli accessi ai siti.
- Modifica nella gestione delle richieste multiorigine: in conformità con il nuovo manifest, gli script di elaborazione del contenuto saranno soggetti alle stesse restrizioni sui permessi della pagina principale in cui sono incorporati questi script (ad esempio, se la pagina non ha accesso al location API, anche i componenti aggiuntivi dello script non riceveranno questo accesso). Questa modifica è completamente implementata in Firefox.
- API basata su promesse. Firefox supporta questa API e per la terza versione del manifest lo sposterà nello spazio dei nomi "chrome.*".
- Vietare l'esecuzione di codice scaricato da server esterni (stiamo parlando di situazioni in cui il componente aggiuntivo carica ed esegue codice esterno). Firefox utilizza il blocco del codice esterno e gli sviluppatori di Mozilla hanno aggiunto ulteriori tecniche di tracciamento del download del codice offerte nella terza versione del manifest. Per gli script di elaborazione del contenuto viene fornita una policy di restrizione dell'accesso al contenuto separata (CSP, Content Security Policy).
Fonte: opennet.ru