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

Jake Archibald
Jake Archibald
X Page d'accueil
Eiji Kitamura

Il faut dire que SharedArrayBuffer a connu un lancement un peu difficile sur le Web, mais les choses se calment. Voici les informations à retenir :

En bref

  • SharedArrayBuffer est actuellement compatible avec Firefox 79 et versions ultérieures, et sera disponible dans Android Chrome 88. 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 ne pensez pas pouvoir effectuer ce changement à temps, vous pouvez vous inscrire à un essai de l'origine pour conserver le comportement actuel jusqu'à au moins Chrome 113.
  • Si vous souhaitez activer l'isolation inter-origine pour continuer à utiliser SharedArrayBuffer, évaluez l'impact qu'elle aura sur les autres éléments inter-origine de votre site Web, tels que les emplacements d'annonces. Vérifiez si SharedArrayBuffer est utilisé par l'une de vos ressources tierces pour comprendre l'impact et obtenir des conseils.

Présentation de l'isolation multi-origine

Vous pouvez isoler une page de manière inter-origine en la diffusant avec ces en-têtes:

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

Une fois cette opération effectuée, votre page ne pourra pas 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.).

Une API de création de rapports est également disponible pour collecter des données sur les requêtes ayant échoué en raison de Cross-Origin-Embedder-Policy et Cross-Origin-Opener-Policy.

Si vous ne pensez pas pouvoir apporter ces modifications à temps pour Chrome 92, vous pouvez vous inscrire à un essai d'origine pour conserver le comportement actuel de Chrome pour ordinateur jusqu'à Chrome 113 au minimum.

Consultez la section Ressources complémentaires au bas de cette page pour en savoir plus sur l'isolation inter-origine.

Comment y sommes-nous parvenus ?

SharedArrayBuffer est arrivé dans Chrome 60 (juillet 2017, pour ceux d'entre vous qui pensent en termes de dates plutôt qu'en versions de Chrome), et tout était parfait. Pendant six mois.

En janvier 2018, une faille a été révélée dans certains processeurs populaires. Pour en savoir plus, consultez l'annonce. En résumé, cela signifie que le code pouvait utiliser des minuteurs haute résolution pour lire de la mémoire à laquelle il n'avait pas accès.

Cela posait problème pour nous, fournisseurs de navigateurs, car nous souhaitons autoriser les sites à exécuter du code sous la forme de JavaScript et de 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 de banque en ligne que vous avez également ouvert. En fait, je ne devrais même pas savoir que vous avez ouvert votre site de banque en ligne. Il s'agit des principes fondamentaux de la sécurité Web.

Pour y remédier, 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 en modifiant la mémoire dans une boucle étroite dans un nœud de calcul, puis en la lisant dans un autre thread. Cela ne pouvait pas être atténué efficacement sans avoir un impact important sur le code bien intentionné. SharedArrayBuffer a donc été désactivé complètement.

Une mesure d'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 a investi dans une architecture multiprocessus dès le départ (vous vous souvenez de la bande dessinée ?), mais il arrivait encore que des données de plusieurs sites se retrouvent 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 présentent un comportement "ancien" qui permet d'utiliser le contenu d'autres origines sans autorisation de l'autre origine. Ces requêtes sont effectuées avec les cookies de l'autre origine. Il s'agit donc d'une requête "connectée" complète. De nos jours, les nouvelles API exigent que l'autre origine active l'option à 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 semblait "incorrect". Nous avons appelé cette méthode le blocage de lecture inter-origine. Par conséquent, dans les cas ci-dessus, nous n'autoriserions pas le format JSON à entrer dans le processus, car il ne s'agit pas d'un format valide pour aucune de ces API. À l'exception des iFrames. Pour les iFrames, nous plaçons le contenu dans un autre processus.

Une fois ces mesures d'atténuation en place, nous avons réintroduit SharedArrayBuffer dans Chrome 68 (juillet 2018), mais uniquement sur ordinateur. Les exigences de processus supplémentaires nous ont empêchés 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 rare) que des CSS/JS/images valides sur des URL devinables puissent contenir des données privées.

Les experts en normes Web se sont réunis pour trouver une solution plus complète inter-navigateurs. La solution a consisté à donner aux pages la possibilité d'indiquer "Je renonce à mon droit d'intégrer du contenu d'une autre origine dans ce processus sans leur autorisation". Cette déclaration est effectuée via les en-têtes COOP et COEP servis avec la page. Le navigateur applique cette règle, et en échange, la page accède à SharedArrayBuffer et à d'autres API disposant de pouvoirs similaires. D'autres origines peuvent activer l'intégration de contenu via Cross-Origin-Resource-Policy ou CORS.

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

Puis, en janvier 2021, j'ai écrit cet article, et vous le lisez. Bonjour.

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

Retarder le changement dans Chrome pour ordinateur

Il s'agit d'une exception temporaire sous la forme d'un "essai d'origine" qui donne aux utilisateurs plus de temps pour implémenter des pages isolées multi-origines. Il active SharedArrayBuffer sans que la page ne 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 dans l'en-tête de chaque page. Par exemple, cela peut se présenter comme suit:
      <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 se présenter comme suit:
      Origin-Trial: TOKEN_GOES_HERE

Documentation complémentaire

Photo de bannière par Daniel Gregoire sur Unsplash