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

Jake Archibald
Jake Archibald
X Home page
Eiji Kitamura

Si può dire che SharedArrayBuffer ha avuto un atterraggio un po' difficile sul web, ma le cose si stanno sistemando. Ecco cosa devi sapere:

In breve

  • SharedArrayBuffer è attualmente supportato in Firefox 79 e versioni successive e sarà disponibile in Chrome 88 per Android. Tuttavia, è disponibile solo per le pagine con isolamento multiorigine.
  • SharedArrayBuffer è attualmente disponibile in Chrome per computer, ma a partire da Chrome 92 sarà limitato alle pagine con isolamento multiorigine. Se ritieni di non poter apportare questa modifica in tempo, puoi registrarti a una prova dell'origine per mantenere il comportamento attuale almeno fino a Chrome 113.
  • Se intendi attivare l'isolamento cross-origin per continuare a utilizzare SharedArrayBuffer valuta l'impatto che avrà su altri elementi cross-origin del tuo sito web, ad esempio i posizionamenti degli annunci. Controlla se SharedArrayBuffer viene utilizzato da una delle tue risorse di terze parti per comprendere l'impatto e le indicazioni.

Panoramica dell'isolamento multiorigine

Puoi rendere una pagina cross-origin isolated pubblicandola con le seguenti intestazioni:

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

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

Esiste anche un'API di reporting, che ti consente di 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 registrarti per una prova dell'origine per mantenere il comportamento attuale di Chrome per computer almeno fino a Chrome 113.

Per ulteriori indicazioni e informazioni sull'isolamento cross-origin, consulta la sezione Approfondimenti in fondo a questa pagina.

Come ci siamo arrivati?

SharedArrayBuffer è arrivato in Chrome 60 (luglio 2017, per chi pensa al tempo in termini di date anziché di versioni di Chrome) e tutto andava alla grande. Per 6 mesi.

A gennaio 2018 è stata rivelata una vulnerabilità in alcune CPU popolari. Consulta l'annuncio per tutti i dettagli, ma in sostanza significava che il codice poteva utilizzare timer ad alta risoluzione per leggere la memoria a cui non avrebbe dovuto avere accesso.

Questo era un problema per noi fornitori di browser, in quanto vogliamo consentire ai siti di eseguire codice sotto forma di JavaScript e WASM, ma controllare rigorosamente la memoria a cui questo codice può accedere. Se arrivi sul mio sito web, non dovrei essere in grado di leggere nulla dal sito di internet banking che hai aperto. Infatti, non dovrei nemmeno sapere che hai aperto il sito di internet banking. Questi sono i concetti fondamentali della sicurezza web.

Per mitigare questo problema, abbiamo ridotto la risoluzione dei nostri timer ad alta risoluzione, ad esempio performance.now(). Tuttavia, puoi creare un timer ad alta risoluzione utilizzando SharedArrayBuffer modificando la memoria in un ciclo stretto in un worker e leggendola in un altro thread. Questo problema non poteva essere mitigato in modo efficace senza influire pesantemente sul codice ben intenzionato, pertanto SharedArrayBuffer è stato disattivato del tutto.

Una mitigazione generale consiste nel garantire che il processo di sistema di una pagina web non contenga dati sensibili provenienti da altre fonti. Chrome ha investito fin dall'inizio in un'architettura multi-processo (ricordi il fumetto?), ma c'erano ancora casi in cui i dati di più siti potevano 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 comportamento "legacy" che consente di utilizzare i contenuti di altre origini senza il consenso esplicito dell'altra origine. Queste richieste vengono effettuate con i cookie dell'altra origine, quindi si tratta di una richiesta completa di accesso. Al giorno d'oggi, le nuove API richiedono che l'altra origine venga attivata utilizzando CORS.

Abbiamo aggirato queste API legacy impedendo ai contenuti di entrare nel processo della pagina web se sembravano "errati" e l'abbiamo chiamato blocco della lettura cross-origin. Pertanto, nei casi precedenti, non consentiremmo l'inserimento di JSON nel processo, in quanto non è un formato valido per nessuna di queste API. Ad eccezione degli iframe. Per gli iframe, inseriamo 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 procedura aggiuntivi non ci hanno permesso di fare lo stesso sui dispositivi mobili. È stato inoltre osservato che la soluzione di Chrome era incompleta, in quanto bloccavamo solo i formati di dati "errati", mentre è possibile (anche se insolito) che CSS/JS/immagini validi in URL intuibili contengano dati privati.

Gli esperti di standard web si sono riuniti per trovare una soluzione cross-browser più completa. La soluzione è stata quella di dare alle pagine un modo per dire "Rinuncio alla mia capacità di inserire contenuti di altre origini in questo processo senza il loro consenso". Questa dichiarazione viene effettuata tramite le intestazioni COOP e COEP servite con la pagina. Il browser lo impone e, in cambio, la pagina ottiene l'accesso a SharedArrayBuffer e ad altre API con poteri simili. Altre origini possono attivare l'incorporamento dei contenuti tramite Cross-Origin-Resource-Policy o CORS.

Firefox è stato il primo a distribuire SharedArrayBuffer con questa limitazione nella versione 79 (luglio 2020).

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

Ed è qui che ci troviamo ora. Chrome 88 riporta SharedArrayBuffer su Android per le pagine con isolamento multiorigine e Chrome 92 introduce gli stessi requisiti per il desktop, sia per coerenza sia per ottenere l'isolamento multiorigine totale.

Ritardare la modifica di Chrome per computer

Si tratta di un'eccezione temporanea sotto forma di "prova dell'origine" che offre agli utenti più tempo per implementare pagine con isolamento multiorigine. Consente di attivare SharedArrayBuffer senza richiedere l'isolamento multiorigine della pagina. L'eccezione scade in Chrome 113 e si applica solo a Chrome per computer.

  1. Richiedi un token per la tua origine.
  2. 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 un aspetto simile a questo:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Se puoi configurare il tuo server, puoi anche aggiungere il token utilizzando un'intestazione HTTP Origin-Trial. L'intestazione della risposta risultante dovrebbe avere un aspetto simile a questo:
      Origin-Trial: TOKEN_GOES_HERE

Per approfondire

Foto del banner di Daniel Gregoire su Unsplash