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

Jake Archibald
Jake Archibald
X Page d'accueil
Eiji Kitamura

Il est légitime de dire que SharedArrayBuffer a connu des atterrissages plus ou moins difficiles sur le sur le Web, mais les choses se stabilisent. Voici les informations à retenir :

En bref

  • SharedArrayBuffer est actuellement compatible avec Firefox 79 et les versions ultérieures et sera bientôt disponible sur 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 dans Chrome 92 elle sera limitée aux pages isolées multi-origines. Si vous pensez ne pas à temps, vous pouvez vous inscrire à une phase d'évaluation pour conserver le comportement actuel jusqu'à Chrome au moins 113.
  • Si vous avez l'intention d'activer l'isolation multi-origine pour continuer à utiliser SharedArrayBuffer évaluent l'impact que cela aura sur les autres origines multi-origines d'éléments sur votre site Web, comme les emplacements d'annonces. Vérifier si SharedArrayBuffer est utilisée par l'ensemble de vos ressources tierces pour comprendre l'impact conseils.

Présentation de l'isolation multi-origine

Vous pouvez rendre une page isolée multi-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 plus charger de contenu multi-origines, à moins la ressource l'autorise explicitement via un Cross-Origin-Resource-Policy. en-tête ou en-têtes CORS (Access-Control-Allow-*, etc.).

Comme l'API Reporting est également disponible, peut collecter des données sur les requêtes ayant échoué suite à Cross-Origin-Embedder-Policy et Cross-Origin-Opener-Policy.

Si vous ne pensez pas pouvoir apporter ces changements à temps pour Chrome 92, vous pouvez vous inscrire à une phase d'évaluation afin de conserver la version actuelle de Chrome pour ordinateur. jusqu'à Chrome 113 ou version ultérieure.

Consultez la section Documentation complémentaire au 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 (juillet 2017, pour ceux d'entre vous qui pensez à des dates plutôt qu'à des versions de Chrome), et tout s'est bien passé. Pendant 6 mois.

En janvier 2018, une faille a été découverte dans certains processeurs populaires. Consultez le annonce pour obtenir tous les détails, mais cela signifiait essentiellement que le code pouvait utiliser des minuteurs pour lire la mémoire à laquelle il ne devrait pas avoir accès.

C'était un problème pour nos fournisseurs de navigateurs, car nous voulons autoriser les sites à s'exécuter sous la forme de JavaScript et WASM, mais qui contrôlent strictement la mémoire, auquel le code peut accéder. Si vous arrivez sur mon site Web, je ne devrais pas pouvoir lire tout ce qui provient du site bancaire en ligne que vous avez ouvert. En fait, je ne devrais pas même si votre site bancaire en ligne est ouvert. Ce sont 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 en tant que performance.now(). Cependant, 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 et en lisant dans un autre fil de discussion. Cela ne pourrait pas être efficacement atténué sans ayant un impact important sur le code bien intentionné, SharedArrayBuffer a été désactivé dans son ensemble.

Une mesure d'atténuation générale consiste à s'assurer que le processus système d'une page Web ne contient pas des données sensibles ailleurs. Chrome avait investi dans une stratégie dès le départ (vous souvenez-vous de cette bande dessinée ?), mais il y avait dans quels cas les données provenant de plusieurs sites peuvent 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 une "ancienne" qui permet aux contenus d'autres origines d'être utilisées sans l'activation de l'autre origine. Ces requêtes sont effectuées avec les cookies de l'autre origine, il s'agit donc d'un requête. De nouveaux Les API nécessitent l'activation de l'autre origine via CORS

Nous avons contourné ces anciennes API en empêchant le contenu d'entrer dans du processus d'une page Web si celle-ci semblait incorrecte et si elle était qualifiée de blocage de lecture multi-origines. Dans les cas ci-dessus, nous n'autoriserons donc pas JSON à entrer dans le processus, un format valide pour l'une de ces API. Autrement dit, à l'exception des cadres iFrame. Pour les cadres iFrame, placer le contenu dans un processus différent.

Une fois ces mesures d'atténuation appliquées, nous avons réintroduit SharedArrayBuffer dans Chrome 68 (juillet 2018), mais uniquement sur ordinateur. Ces exigences supplémentaires signifient que nous avons ne pouvaient pas faire la même chose sur les appareils mobiles. On a également remarqué que la solution de Chrome était incomplète, car nous ne bloquions que le mot "incorrect" ; formats de données, alors qu'il que des images CSS/JS/images valides avec des URL devinables qui contiennent des données privées.

Des spécialistes des normes Web se sont réunis pour créer une solution multiplate-forme solution. La solution consistait à donner aux pages un moyen de dire : "Par la présente, je renonce à mon la possibilité d'intégrer des contenus d'autres origines dans ce processus sans leur activation". Cette déclaration se fait via des en-têtes COOP et COEP. diffusées avec la page. Le navigateur fait en sorte que cela soit possible et, en échange, la page acquiert Accès à SharedArrayBuffer et à d'autres API ayant des droits similaires. Autres origines peuvent activer l'intégration de contenu Cross-Origin-Resource-Policy ou CORS.

Firefox a été le premier à proposer SharedArrayBuffer avec cette restriction, en 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 ramène SharedArrayBuffer à Android pour les pages isolées multi-origines, tandis que Chrome 92 apporte la même concernant les ordinateurs de bureau, à la fois pour assurer la cohérence et pour atteindre le multi-origine l'isolation.

Retarder la modification de Chrome pour ordinateur

Il s'agit d'une exception temporaire sous la forme d'une "phase d'évaluation" qui donne aux gens plus de temps pour implémenter des pages isolées multi-origines. Il permet SharedArrayBuffer sans que la page ne soit isolée multi-origine. La expire dans Chrome 113 et ne s'applique qu'aux ordinateurs Chrome.

  1. Demandez un jeton pour votre origine.
  2. Ajoutez le jeton à vos pages. Vous disposez pour cela de deux méthodes: <ph type="x-smartling-placeholder">
      </ph>
    • Ajoutez une balise <meta> origin-trial à l'en-tête de chaque page. Par exemple : L'URL ressemble généralement à ceci:
      <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 résultant doit ressemble à ceci:
      Origin-Trial: TOKEN_GOES_HERE

Documentation complémentaire

Photo de bannière de Daniel Gregoire sur Unsplash