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 dell'isolamento tra origini, la prova di ritiro di SharedArrayBuffer sui computer verrà [estesa fino a Chrome 124](/blog/shared-array-buffer-origin-trial-extension-124).

È giusto dire che SharedArrayBuffer ha avuto un atterraggio un po' stentato sul web, ma la situazione si sta stabilizzando. Tieni presente quanto segue:

In breve

SharedArrayBuffer è attualmente supportato in Firefox 79 e versioni successive e sarà disponibile in Android Chrome 88. 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 isolate multiorigine. Se ritieni di non 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 cross-origin per continuare a utilizzare SharedArrayBuffer, valuta l'impatto che avrà su altri elementi cross-origin sul tuo sito web, come i posizionamenti degli annunci. Controlla se SharedArrayBuffer viene utilizzato da una delle tue risorse di terze parti per comprendere l'impatto e ricevere indicazioni.

Panoramica dell'isolamento multiorigine

Puoi rendere una pagina isolata da origini diverse pubblicandola con questi parametri di intestazione:

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

Dopodiché, la tua pagina non potrà caricare contenuti cross-origin, a meno che la risorsa non lo consenta esplicitamente tramite un'intestazione Cross-Origin-Resource-Policy o le intestazioni 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 ritieni di non poter apportare queste modifiche in tempo per Chrome 92, puoi registrarti per una prova dell'origine per mantenere il comportamento corrente di Chrome per computer almeno fino a Chrome 113.

Nota: aggiornamento di dicembre 2021
Stiamo esplorando i modi per implementare Cross-Origin-Resource-Policy su larga scala, poiché l'isolamento multiorigine richiede l'attivazione esplicita di tutte le risorse secondarie. Per questo abbiamo avuto l'idea di andare nella direzione opposta: una nuova modalità "senza credenziali" per i COEP che consente di caricare le risorse senza l'intestazione CORP rimuovendo tutte le credenziali. Ci auguriamo che questo ti semplifichi il compito di assicurarti che le risorse secondarie inviino l'intestazione Cross-Origin-Resource-Policy.
Sebbene la modalità credentialless sia disponibile su Chrome dalla versione 96, non è ancora supportata da altri browser. Per questo motivo, alcuni sviluppatori potrebbero riscontrare difficoltà a implementare COOP o COEP in questa fase.
È inoltre noto che l'intestazione Cross-Origin-Opener-Policy: same-origin interromperà le integrazioni che richiedono interazioni tra finestre cross-origin, come OAuth e i pagamenti. Per ovviare a questo problema, stiamo valutando la possibilità di allentare la condizione per consentire l'isolamento cross-origin per Cross-Origin-Opener-Policy: same-origin-allow-popups. In questo modo sarà possibile la comunicazione con la finestra aperta automaticamente.
Se vuoi attivare l'isolamento cross-origin per utilizzare SharedArrayBuffer, ma queste sfide ti bloccano, ti consigliamo di registrarti per una prova dell'origine e di attendere che le nuove modalità siano disponibili. Non abbiamo intenzione di interrompere la prova dell'origine finché queste nuove modalità non saranno disponibili.

Consulta la sezione Letture consigliate in fondo a questa pagina per ulteriori indicazioni e informazioni sull'isolamento cross-origin.

Come ci siamo arrivati?

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

A gennaio 2018 è stata scoperta una vulnerabilità in alcune CPU molto diffuse. Per informazioni dettagliate, consulta l'annuncio, ma in sostanza il codice poteva utilizzare timer ad alta risoluzione per leggere la memoria a cui non aveva accesso.

Questo rappresentava 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. In realtà, non dovrei nemmeno sapere che hai aperto il sito di internet banking. Questi sono i concetti di base della sicurezza web.

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

Una misura generale è assicurarsi che il processo di sistema di una pagina web non contenga dati sensibili provenienti da altre fonti. Chrome ha investito in un'architettura multi-processo fin dall'inizio (ricordi la vignetta?), 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 attivazione da parte dell'altra origine. Queste richieste vengono effettuate con i cookies dell'altra origine, quindi si tratta di una richiesta completa "dopo l'accesso". Al giorno d'oggi, le nuove API richiedono l'attivazione dell'altra origine tramite CORS.

Abbiamo risolto il problema di queste API precedenti impedendo ai contenuti di entrare nel processo della pagina web se sembravano "errati" e lo 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, i contenuti vengono sottoposti a una procedura diversa.

Dopo aver implementato queste misure di mitigazione, abbiamo reintrodotto SharedArrayBuffer in Chrome 68 (luglio 2018), ma solo su computer. I requisiti di procedura aggiuntivi ci hanno impedito 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 con URL deducibili possano contenere dati privati.

Gli esperti di standard web si sono riuniti per trovare una soluzione più completa cross-browser. La soluzione è stata offrire alle pagine un modo per dichiarare: "Rinuncio alla mia possibilità di includere contenuti di altre origini in questa procedura senza la relativa attivazione". Questa dichiarazione viene eseguita tramite le intestazioni COOP e COEP pubblicate con la pagina. Il browser applica questa regola e, in cambio, la pagina ottiene accesso a SharedArrayBuffer e ad altre API con poteri simili. Altre origini possono attivare l'embedding dei contenuti tramite Cross-Origin-Resource-Policy o CORS.

Firefox è stato il primo browser a implementare 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 siamo ora. Chrome 88 restituisce SharedArrayBuffer su Android per le pagine isolate su più origini e Chrome 92 introduce gli stessi requisiti per i computer, sia per coerenza sia per ottenere un isolamento multiorigine totale.

Posticipazione della modifica di Chrome per computer

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

Richiedi un token per l'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, l'aspetto potrebbe essere simile al seguente:
  <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 di risposta risultante dovrebbe avere un aspetto simile al seguente:
  Origin-Trial: TOKEN_GOES_HERE

Per approfondire

Foto del banner di Daniel Gregoire su Unsplash