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 seSharedArrayBuffer
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.
- Richiedi un token per la tua origine.
- 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
- Aggiungi un tag
Per approfondire
- Una guida per attivare l'isolamento multiorigine
- Come isolare multiorigine le pagine
- Perché è necessario l'isolamento multiorigine
Foto del banner di Daniele Gregoire su Unsplash