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 siSharedArrayBuffer
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.
- Demandez un jeton pour votre origine.
- 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
- Ajoutez une balise
Documentation complémentaire
- Guide pour activer l'isolation multi-origine
- Isoler vos pages en multi-origine
- Pourquoi l'isolation multi-origine est-elle nécessaire ?
Photo de bannière de Daniel Gregoire sur Unsplash