Mises à jour de SharedArrayBuffer dans Android 88 et de Chrome 92 pour ordinateur

Jake Archibald
Jake Archibald
X Page d'accueil
Eiji Kitamura

On peut dire que SharedArrayBuffer a eu quelques difficultés sur le Web, mais que ça ne va pas. Voici les informations à retenir :

En bref

  • SharedArrayBuffer est actuellement compatible avec Firefox 79 et versions ultérieures et sera disponible dans Chrome 88 pour Android. Toutefois, il n'est disponible que pour les pages isolées multi-origines.
  • SharedArrayBuffer est actuellement disponible dans Chrome pour ordinateur, mais à partir de Chrome 92, il sera limité aux pages isolées multi-origines. Si vous pensez ne pas pouvoir effectuer cette modification à temps, vous pouvez vous inscrire à une phase d'évaluation pour conserver le comportement actuel jusqu'à Chrome 113 au moins.
  • Si vous avez l'intention d'activer l'isolation multi-origine pour continuer à utiliser SharedArrayBuffer, évaluez l'impact que cela aura sur d'autres éléments multi-origines de votre site Web, tels que les emplacements d'annonces. Vérifiez si SharedArrayBuffer est utilisé par l'une de vos ressources tierces pour en comprendre l'impact et les conseils.

Présentation de l'isolation multi-origine

Vous pouvez rendre une page isolée multi-origine en la diffusant avec les en-têtes suivants:

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

Une fois cette opération effectuée, votre page ne pourra plus charger de contenu multi-origine, sauf si la ressource l'autorise explicitement via un en-tête Cross-Origin-Resource-Policy ou des en-têtes CORS (Access-Control-Allow-*, etc.).

Il existe également une API de création de rapports, qui vous permet de recueillir des données sur les requêtes qui ont échoué en raison de Cross-Origin-Embedder-Policy et de Cross-Origin-Opener-Policy.

Si vous pensez ne pas pouvoir apporter ces modifications à temps pour Chrome 92, vous pouvez vous inscrire à une phase d'évaluation afin de conserver le comportement actuel de Chrome pour ordinateur jusqu'à Chrome 113 au moins.

Consultez la section Complément d'informations en bas de cette page pour obtenir plus de conseils et d'informations sur l'isolation multi-origine.

Comment y sommes-nous parvenus ?

SharedArrayBuffer est arrivé dans Chrome 60 (de juillet 2017, pour ceux d'entre vous qui pensent au temps dans des dates plutôt qu'aux versions Chrome), et tout s'est bien passé. Pendant 6 mois.

En janvier 2018, une vulnérabilité a été détectée dans certains processeurs populaires. Consultez l'annonce pour en savoir plus, mais cela signifiait essentiellement que le code pouvait utiliser des minuteurs haute résolution pour lire la mémoire à laquelle il ne devrait pas avoir accès.

Cela posait un problème pour nous, les éditeurs de navigateurs, car nous voulons autoriser les sites à exécuter du code sous la forme de JavaScript et WASM, mais contrôler strictement la mémoire à laquelle ce code peut accéder. Si vous accédez à mon site Web, je ne devrais pas pouvoir lire quoi que ce soit sur le site bancaire en ligne que vous avez également ouvert. En fait, je ne devrais même pas savoir que votre site bancaire en ligne est ouvert. Ce sont des principes fondamentaux de la sécurité sur le Web.

Pour atténuer ce problème, nous avons réduit la résolution de nos minuteurs haute résolution tels que performance.now(). Toutefois, vous pouvez créer un minuteur haute résolution à l'aide de SharedArrayBuffer. Pour ce faire, modifiez la mémoire dans une boucle étroite dans un nœud de calcul, puis lisez-la dans un autre thread. Cela ne pouvait pas être atténué efficacement sans affecter fortement le code bien intentionné. SharedArrayBuffer a donc été complètement désactivé.

Une atténuation générale consiste à s'assurer que le processus système d'une page Web ne contient pas de données sensibles provenant d'ailleurs. Chrome avait investi dans une architecture multiprocessus dès le départ (vous souvenez-vous de la bande dessinée ?), mais il existait encore des cas où les données provenant de plusieurs sites pouvaient se retrouver dans le même processus:

<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… -->

Ces API ont un comportement "ancien" qui permet d'utiliser du contenu d'autres origines sans que ces dernières ne soient activées. Ces requêtes sont effectuées avec les cookies de l'autre origine. Il s'agit donc d'une requête complète "connectée". Aujourd'hui, les nouvelles API nécessitent l'activation de l'autre origine à l'aide de CORS.

Nous avons contourné ces anciennes API en empêchant le contenu d'entrer dans le processus de la page Web s 'il paraissait incorrect et nous l'avons appelée blocage de la lecture multi-origine. Ainsi, dans les cas ci-dessus, nous n'autorisons pas JSON à entrer dans le processus, car ce format n'est valide pour aucune de ces API. (à l'exception des iFrames). Dans le cas des cadres iFrame, le contenu est soumis à un processus différent.

Maintenant que ces mesures d'atténuation ont été mises en place, nous avons rétabli SharedArrayBuffer dans Chrome 68 (juillet 2018), mais uniquement sur ordinateur. Les exigences de processus supplémentaires nous rendaient impossible de faire de même sur les appareils mobiles. Il a également été noté que la solution de Chrome était incomplète, car nous ne bloquions que les formats de données "incorrects", alors qu'il est possible (bien que inhabituel) que des images CSS/JS/images valides associées à des URL devinables contiennent des données privées.

Les spécialistes des normes du Web se sont réunis pour proposer une solution multinavigateur plus complète. La solution consistait à donner aux pages un moyen de dire "Par la présente, je renonce à ma capacité à intégrer des contenus d'autres origines dans ce processus sans leur acceptation". Cette déclaration est effectuée via les en-têtes COOP et COEP diffusés avec la page. Le navigateur applique cela et, en échange, la page a accès à SharedArrayBuffer et à d'autres API ayant des pouvoirs similaires. Pour d'autres origines, vous pouvez activer l'intégration de contenu via Cross-Origin-Resource-Policy ou CORS.

Firefox a été le premier à fournir SharedArrayBuffer avec cette restriction, dans la version 79 (juillet 2020).

Puis, en janvier 2021, j'ai rédigé cet article, et vous l'avez lu. Bonjour.

Et c'est là que nous en sommes maintenant. Chrome 88 rétablit SharedArrayBuffer sur Android pour les pages isolées multi-origines, tandis que Chrome 92 applique les mêmes exigences aux ordinateurs de bureau, à la fois pour la cohérence et pour l'isolation multi-origine totale.

Retarder la modification de Chrome pour ordinateur

Il s'agit d'une exception temporaire sous la forme d'un "phase d'évaluation" qui laisse plus de temps aux utilisateurs pour implémenter des pages isolées multi-origines. Il active SharedArrayBuffer sans exiger que la page soit isolée multi-origine. L'exception expire dans Chrome 113 et ne s'applique qu'à Chrome pour ordinateur.

  1. Demandez un jeton pour votre origine.
  2. Ajoutez le jeton à vos pages. Pour cela, vous pouvez procéder de deux façons :
    • Ajoutez une balise <meta> origin-trial au début de chaque page. Par exemple:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Si vous pouvez configurer votre serveur, vous pouvez également ajouter le jeton à l'aide d'un en-tête HTTP Origin-Trial. L'en-tête de réponse obtenu doit ressembler à ceci:
      Origin-Trial: TOKEN_GOES_HERE

Complément d'informations

Bannière photo par Daniel Gregoire sur Unsplash