Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiornamenti di SharedArraybu in Chrome 88 per Android e Chrome 92 per computer desktop

Jake Archibald

Eiji Kitamura

Nota:
Aggiornamento, gennaio 2024
Per avere più tempo per allentare in modo affidabile il requisito di attivazione multiorigine l'isolamento, la prova relativa al ritiro di SharedArrayBuffer su desktop sarà [estesa fino a Chrome 124](/blog/shared-array-buffer-origin-trial-extension-124).

Possiamo dire che SharedArrayBuffer ha avuto un atterraggio un po' spiacevole sulla web, ma le cose si stanno sistemando. Tieni presente quanto segue:

In breve

SharedArrayBuffer è attualmente supportato su Firefox 79 e versioni successive e sarà disponibile in Android Chrome 88. Tuttavia, è disponibile soltanto per le pagine con isolato multiorigine.
SharedArrayBuffer è attualmente disponibile in Chrome per computer, ma da Chrome 92 sarà limitato alle pagine con isolamento multiorigine. Se non pensi di puoi apportare la modifica in tempo, puoi registrarti a una prova dell'origine per mantenere il comportamento attuale almeno fino a Chrome 113.
Se intendi abilitare l'isolamento multiorigine per continuare a utilizzare SharedArrayBuffer valutano l'impatto che questo avrà su altre origini multiorigine elementi sul tuo sito web, come i posizionamenti degli annunci. Controlla se SharedArrayBuffer viene utilizzato da qualsiasi risorsa di terze parti per comprendere l'impatto e guida.

Panoramica dell'isolamento multiorigine

Puoi rendere una pagina isolata multiorigine pubblicandola con questi intestazioni:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Una volta eseguita questa operazione, la pagina non potrà caricare contenuti multiorigine a meno che la risorsa lo consenta esplicitamente tramite un file Cross-Origin-Resource-Policy intestazione o intestazioni CORS (Access-Control-Allow-* e così via).

È disponibile anche un'API di reporting, può raccogliere dati sulle richieste non riuscite a causa di Cross-Origin-Embedder-Policy e Cross-Origin-Opener-Policy.

Se ritieni di non poter apportare queste modifiche in tempo per Chrome 92, puoi registrarsi a una prova dell'origine per mantenere l'attuale versione di Chrome Desktop comportamento precedente almeno alla versione 113 di Chrome.

Nota: aggiornamento, dicembre 2021
Stiamo esplorando modi per eseguire il deployment di Cross-Origin-Resource-Policy su larga scala, poiché l'isolamento multiorigine richiede l'attivazione esplicita di tutte le risorse secondarie. E noi hanno avuto l'idea di andare nella direzione opposta: un nuovo COEP "senza credenziali" personalizzata che ti consente caricare risorse senza l'intestazione CORP rimuovendo tutte le relative credenziali. Me spero che questo alleggerirà l'onere di verificare che le sottorisorse stiano inviando l'intestazione Cross-Origin-Resource-Policy.
Sebbene la modalità credentialless sia disponibile su Chrome a partire dalla versione 96, supportata da altri browser, alcuni sviluppatori potrebbero trovarla difficile implementare COOP o COEP in questa fase.
Inoltre, è noto che l'intestazione Cross-Origin-Opener-Policy: same-origin interrompere le integrazioni che richiedono interazioni con finestre multiorigine, come OAuth e pagamenti. Per mitigare questo problema, stiamo esplorando le attività più rilassanti di sicurezza per abilitare multiorigine e l'isolamento a Cross-Origin-Opener-Policy: same-origin-allow-popups. In questo modo sia possibile la comunicazione con la finestra aperta.
Se vuoi abilitare l'isolamento multiorigine per utilizzare SharedArrayBuffer, ma bloccati da queste verifiche, consigliamo di registrarsi per un'origine di Google Cloud e attendere che le nuove modalità siano disponibili. Non stiamo prevedendo di terminare la prova dell'origine fino a quando queste nuove modalità non saranno disponibili.

Consulta la sezione Per approfondire in fondo a questa pagina. per ulteriori indicazioni e informazioni sull'isolamento multiorigine.

Come ci siamo arrivati?

SharedArrayBuffer è arrivato con Chrome 60 (luglio 2017, per chi pensare al tempo in date anziché nelle versioni di Chrome) e tutto è stato ottimo. Per 6 mesi.

A gennaio 2018 è stata individuata una vulnerabilità in alcune CPU popolari. Consulta le annuncio per tutti i dettagli, ma in sostanza significava che il codice poteva utilizzare contenuti timer per leggere la memoria a cui non dovrebbe avere accesso.

Questo è stato un problema per noi fornitori di browser, in quanto vogliamo consentire ai siti di eseguire codice sotto forma di JavaScript e WASM, ma controlli rigorosamente la memoria di accesso al codice. Se arrivi sul mio sito web, non dovrei essere in grado di leggere qualsiasi cosa dal sito di internet banking che avete aperto. In realtà non dovrei anche sapere che hai un sito di internet banking aperto. Questi sono i concetti fondamentali di sicurezza sul web.

Per ovviare a questo problema, abbiamo ridotto la risoluzione dei nostri timer ad alta risoluzione, come performance.now(). Tuttavia, puoi creare un timer ad alta risoluzione utilizzando SharedArrayBuffer modificando la memoria in un stretto loop in un worker e leggendo in un altro thread. Questo problema non può essere mitigato in modo efficace senza avere un impatto significativo su codice ben intenzionato, pertanto SharedArrayBuffer è stato disattivato del tutto.

Una mitigazione generale è garantire che il processo di sistema di una pagina web non contenga sensibili provenienti da altre parti del mondo. Chrome ha investito in un processo multi-processo architettura fin dall'inizio (ricordi il fumetto?), ma c'erano casi in cui i dati di più siti potrebbero finire nello stesso processo:

<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->

Queste API hanno un'architettura un comportamento che consente ai contenuti provenienti da altre origini di utilizzata senza l'attivazione dell'altra origine. Queste richieste vengono effettuate con cookie dell'altra origine, quindi è un accesso completo richiesta. Oggi, le nuove Le API richiedono l'attivazione dall'altra origine utilizzando CORS.

Abbiamo risolto queste API legacy impedendo ai contenuti di entrare nel la procedura della pagina web se sembra "errata" e l'ha chiamata blocco della lettura multiorigine. Nei casi precedenti, quindi, non consentiremmo a JSON di accedere al processo, in quanto un formato valido per ognuna di queste API. ad eccezione degli iframe. Per gli iframe i contenuti in un processo diverso.

Con queste mitigazioni in atto, abbiamo reintrodotto SharedArrayBuffer in Chrome 68 (luglio 2018), ma solo su computer. I requisiti di processo aggiuntivi ci consentivano non potrebbero fare lo stesso sui dispositivi mobili. È stato anche notato che la soluzione di Chrome era incompleta, perché bloccavamo solo lo stato "Risposta errata" formati di dati, mentre (anche se insolito) che CSS/JS/immagini validi in URL ipotizzabili possano contengono dati privati.

Standard web che le persone si sono unite per creare una versione più completa soluzione. La soluzione è stata quella di dare alle pagine la possibilità di dire: "Con la presente rinuncio di integrare contenuti di altre origini in questo processo senza la relativa attivazione". Questa dichiarazione viene effettuata tramite le intestazioni COOP e COEP. pubblicati con la pagina. Il browser impone questa condizione e in cambio la pagina guadagna l'accesso a SharedArrayBuffer e ad altre API con potenze simili. Altre origini attivare l'incorporamento dei contenuti Cross-Origin-Resource-Policy o CORS.

Firefox è stato il primo a distribuire SharedArrayBuffer con questa restrizione, in versione 79 (luglio 2020).

Poi, a gennaio 2021, ho scritto questo articolo e tu l'hai letto. Ciao.

Ed è qui che siamo ora. Chrome 88 riporta SharedArrayBuffer su Android per le pagine con isolamento multiorigine e Chrome 92 offre le stesse desktop, sia per coerenza, sia per ottenere requisiti multiorigine e l'isolamento dei dati.

Rimandare la modifica di Chrome per desktop

Si tratta di un'eccezione temporanea sotto forma di "prova dell'origine" che offre alle persone di tempo per implementare le pagine con isolamento multiorigine. Consente SharedArrayBuffer senza richiedere l'isolamento multiorigine della pagina. La scade in Chrome 113 e l'eccezione si applica solo ai computer Chrome.

Richiedi un token per la tua origine.
Aggiungi il token alle tue pagine. Puoi farlo in due modi:
- Aggiungi un tag origin-trial <meta> all'intestazione di ogni pagina. Ad esempio: potrebbe avere il seguente aspetto:
  <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- Se puoi configurare il server, puoi anche aggiungere il token utilizzando un'intestazione HTTP Origin-Trial. L'intestazione della risposta risultante deve avrà il seguente aspetto:
  Origin-Trial: TOKEN_GOES_HERE

Per approfondire

Foto del banner di Daniele Gregoire su Unsplash