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

Jake Archibald
Jake Archibald
X Home page
Eiji Kitamura

Giusto per dire che SharedArrayBuffer ha avuto un po' di errore sul web, ma le cose si stanno risolvendo. Tieni presente quanto segue:

In breve

  • SharedArrayBuffer è attualmente supportato in Firefox 79 e versioni successive e arriverà in Android Chrome 88. Tuttavia, è disponibile solo per le pagine con isolamento multiorigine.
  • SharedArrayBuffer è attualmente disponibile in Chrome desktop, ma da Chrome 92 sarà limitato alle pagine isolate multiorigine. Se non pensi di poter apportare questa modifica in tempo, puoi registrarti per una prova dell'origine per mantenere il comportamento attuale almeno fino a Chrome 113.
  • Se intendi attivare l'isolamento multiorigine per continuare a utilizzare SharedArrayBuffer, valuta l'impatto che questa operazione avrà su altri elementi multiorigine sul 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 linee guida.

Panoramica dell'isolamento multiorigine

Puoi rendere una pagina isolata multiorigine pubblicandola con queste intestazioni:

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

Dopo averlo 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 un'intestazione CORS (Access-Control-Allow-* e così via).

È disponibile 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 non pensi di poter apportare queste modifiche in tempo per Chrome 92, puoi registrarti per una prova dell'origine per mantenere il comportamento attuale di Chrome desktop almeno fino alla versione 113 di Chrome.

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

Come ci siamo arrivati?

SharedArrayBuffer è arrivato in Chrome 60 (a luglio 2017, per chi pensa al tempo trascorso piuttosto che alle versioni di Chrome). È stato tutto eccellente. Per 6 mesi.

Nel gennaio 2018 è stata rilevata una vulnerabilità in alcune CPU più diffuse. Per i dettagli completi, consulta l'annuncio, ma significava essenzialmente che il codice poteva utilizzare timer ad alta risoluzione per leggere la memoria a cui non avrebbe dovuto accedere.

Questo rappresentava un problema per noi fornitori di browser, poiché vogliamo consentire ai siti di eseguire il codice in forma di JavaScript e WASM, ma di controllare rigorosamente la memoria a cui questo codice può accedere. Se arriva sul mio sito web, non dovrei riuscire a leggere niente informazioni sul sito di internet banking che hai aperto. Non dovrei neanche sapere che hai il tuo sito di internet banking aperto. Questi sono i fondamenti della sicurezza web.

Per limitare 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 ciclo chiuso in un worker e leggendola in un altro thread. Ciò non ha potuto essere evitato in modo efficace senza un impatto significativo sul codice ben intenzionale, pertanto SharedArrayBuffer è stato disattivato del tutto.

Una mitigazione generale consiste nell'assicurare che il processo di sistema di una pagina web non contenga dati sensibili provenienti da altre fonti. Chrome aveva investito in un'architettura multi-processo fin dall'inizio (non ricordi il fumetto?), ma ci sono stati 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 contenuti di altre origini senza attivare l'altra origine. Queste richieste vengono effettuate con i cookie dell'altra origine, quindi è una richiesta completa "con accesso eseguito". Oggi, le nuove API richiedono l'attivazione dell'altra origine utilizzando CORS.

Abbiamo evitato queste API legacy impedendo ai contenuti di entrare nel processo della pagina web se sembravano "sbagliati", definendoli blocco della lettura multiorigine. Quindi, nei casi precedenti, non consentiremo a JSON di entrare nel processo, poiché non è un formato valido per nessuna di queste API. Cioè, tranne gli iframe. Per gli iframe, mettiamo i contenuti in un processo diverso.

Una volta implementate queste mitigazioni, abbiamo reintrodotto SharedArrayBuffer in Chrome 68 (luglio 2018), ma solo su computer. Non potevamo fare lo stesso sui dispositivi mobili a causa dei requisiti di processo aggiuntivi. Abbiamo notato inoltre che la soluzione di Chrome era incompleta, in quanto bloccavamo solo i formati di dati "sbagliati", mentre è possibile (anche se insolito) che immagini CSS/JS/immagini valide e URL intuibili possano contenere dati privati.

Gli standard web si sono uniti per ideare una soluzione cross-browser più completa. La soluzione era quella di fornire alle pagine un modo per dire: "Con la presente, rinuncio alla mia capacità di inserire in questo processo contenuti di altre origini senza la loro attivazione". Questa dichiarazione viene eseguita tramite intestazioni COOP e COEP pubblicate con la pagina. Il browser applica questo requisito e in cambio la pagina ottiene l'accesso a SharedArrayBuffer e ad altre API con funzionalità 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 l'hai letto. Ciao.

Ed è qui che siamo ora. Chrome 88 riporta SharedArrayBuffer su Android per le pagine isolate multiorigine, mentre Chrome 92 applica gli stessi requisiti per i computer desktop, sia per la coerenza che per ottenere l'isolamento multiorigine totale.

Ritardo della modifica di Chrome nei desktop

Si tratta di un'eccezione temporanea sotto forma di "prova dell'origine" che offre agli utenti più tempo per implementare pagine isolate multiorigine. Attiva SharedArrayBuffer senza richiedere l'isolamento multiorigine della pagina. L'eccezione scade in Chrome 113 e l'eccezione 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 <meta> origin-trial in intestazione di ogni pagina. Ad esempio, l'URL potrebbe avere un aspetto simile a questo:
      <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 dovrebbe avere un aspetto simile a questo:
      Origin-Trial: TOKEN_GOES_HERE

Per approfondire

Foto del banner di Daniele Gregoire su Unsplash