Demander l'isolation des performances avec l'en-tête Origin-Agent-Cluster

Un nouvel en-tête de réponse HTTP pour limiter les scripts au niveau du domaine et demander des ressources dédiées au navigateur.

Domenic Denicola
Domenic Denicola
X GitHub

Origin-Agent-Cluster est un nouvel en-tête de réponse HTTP qui indique au navigateur d'empêcher l'accès synchrone à des scripts entre les pages multi-origines sur le même site. Les navigateurs peuvent également utiliser Origin-Agent-Cluster pour indiquer que votre origine doit obtenir ses propres ressources distinctes, telles qu'un processus dédié.

Compatibilité du navigateur

Actuellement, l'en-tête Origin-Agent-Cluster n'est implémenté que dans Chrome 88 et versions ultérieures. Il a été conçu en étroite collaboration avec des représentants de Mozilla Firefox qui l'ont marqué comme mémorisant le prototypage, et il a déjà été bien reçu de la part de représentants de WebKit, le moteur de navigateur utilisé par Safari.

En attendant, déployer l'en-tête Origin-Agent-Cluster auprès de tous vos utilisateurs ne pose aucun problème. Les navigateurs qui ne le comprennent pas l'ignoreront. De plus, étant donné que les pages des clusters d'agents selon l'origine peuvent effectuer moins d'actions que celles associées au site (option par défaut), il n'y a aucun problème d'interopérabilité à craindre.

Pourquoi les navigateurs ne peuvent-ils pas séparer automatiquement les origines du même site ?

Le Web repose sur la règle de même origine, une fonctionnalité de sécurité qui limite la manière dont les documents et les scripts peuvent interagir avec les ressources d'une autre origine. Par exemple, une page hébergée à l'adresse https://a.example a une origine différente de celle de https://b.example ou de https://sub.a.example.

En arrière-plan, les navigateurs utilisent la séparation créée par les origines de différentes manières. Auparavant, même si des origines distinctes ne pouvaient pas accéder à leurs données respectives, elles partageaient toujours des ressources telles que les threads du système d'exploitation, les processus et l'allocation de mémoire. Ainsi, si un onglet était lent, tous les autres étaient ralentis. Ou si un onglet utilisait trop de mémoire, le navigateur faisait planter tout le navigateur.

De nos jours, les navigateurs sont plus sophistiqués et tentent de séparer les différentes origines en différents processus. Le fonctionnement exact varie selon les navigateurs: la plupart des navigateurs présentent un certain niveau de séparation entre les onglets, mais différents iFrame au sein d'un même onglet peuvent partager le même processus. Étant donné que les processus entraînent une surcharge de mémoire, ils utilisent des méthodes heuristiques pour éviter d'en générer trop. Par exemple, Firefox a une limite de processus configurable par l'utilisateur, et Chrome varie son comportement entre les ordinateurs (où la mémoire est plus abondante) et le mobile (où elle est rare).

Ces méthodes heuristiques ne sont pas parfaites. Ils sont par ailleurs soumis à une limitation importante: en raison des exceptions aux règles concernant la même origine qui permettent aux sous-domaines tels que https://sub.a.example et https://a.example de communiquer entre eux, les navigateurs ne peuvent pas séparer automatiquement les sous-domaines les uns des autres.

Ce comportement par défaut est appelé "clusters d'agents selon le site", c'est-à-dire que le navigateur regroupe les pages en fonction de leur site. Le nouvel en-tête Origin-Agent-Cluster demande au navigateur de modifier ce comportement par défaut pour une page donnée, en la plaçant dans un cluster d'agents selon l'origine, de sorte qu'elle ne soit regroupée qu'avec d'autres pages ayant exactement la même origine. Plus spécifiquement, les pages multi-origines sur le même site seront exclues du cluster d'agents.

Cette séparation selon l'option permet aux navigateurs d'attribuer à ces nouveaux clusters d'agents selon l'origine leurs propres ressources dédiées, qui ne sont pas associées à celles d'autres origines. Par exemple, ces pages peuvent obtenir leur propre processus ou être planifiées sur des threads distincts. En ajoutant l'en-tête Origin-Agent-Cluster à votre page, vous indiquez au navigateur que la page bénéficierait de ces ressources dédiées.

Toutefois, pour effectuer la séparation et profiter de ces avantages, le navigateur doit désactiver certaines anciennes fonctionnalités.

Ce que les pages basées sur l'origine ne peuvent pas faire

Lorsque votre page se trouve dans un cluster d'agents selon l'origine, vous donnez certaines capacités de communiquer avec des pages multi-origines sur le même site qui étaient auparavant disponibles. Plus spécifiquement :

  • Vous ne pouvez plus définir document.domain. Il s'agit d'une ancienne fonctionnalité qui permet normalement aux pages multi-origines du même site d'accéder de manière synchrone au DOM des autres. Toutefois, elle est désactivée dans les clusters d'agents selon l'origine.

  • Vous ne pouvez plus envoyer d'objets WebAssembly.Module à d'autres pages multi-origines du même site via postMessage().

  • (Chrome uniquement) Vous ne pouvez plus envoyer d'objets SharedArrayBuffer ni WebAssembly.Memory à d'autres pages multi-origines du même site.

Quand utiliser des clusters d'agents selon l'origine ?

Les origines qui bénéficient le plus de l'en-tête Origin-Agent-Cluster sont les suivantes:

  • Optimiser les performances avec leurs propres ressources dédiées lorsque cela est possible Exemples : jeux gourmands en performances, sites de visioconférence ou applications de création multimédia.

  • Contient des iFrames gourmands en ressources d'origine différente, mais sur le même site. Par exemple, si https://mail.example.com intègre https://chat.example.com des iFrames, la vérification de l'originehttps://mail.example.com/ permet d'éviter que le code écrit par l'équipe de chat n'interfère accidentellement avec le code écrit par l'équipe de messagerie. Le navigateur peut ainsi lui fournir des processus distincts pour les planifier indépendamment les uns des autres et réduire leur impact sur les performances.

  • s'attendent à être intégrés sur des pages d'origines différentes et appartenant au même site, mais savent qu'elles consomment beaucoup de ressources. Par exemple, si https://customerservicewidget.example.com prévoit d'utiliser de nombreuses ressources pour le chat vidéo et qu'il sera intégré à différentes origines dans https://*.example.com, l'équipe chargée de la maintenance de ce widget pourrait utiliser l'en-tête Origin-Agent-Cluster pour essayer de réduire l'impact sur les performances des intégrations.

De plus, vous devez vous assurer que vous pouvez désactiver les fonctionnalités de communication multi-origine rarement utilisées mentionnées ci-dessus et que votre site utilise le protocole HTTPS.

Mais en fin de compte, ce ne sont que des directives. Pour déterminer si les clusters d'agents selon l'origine sont bénéfiques ou non pour votre site, il est préférable de faire des mesures. En particulier, vous devez mesurer vos Core Web Vitals, et éventuellement votre utilisation de la mémoire, pour déterminer l'impact de la détermination de l'origine. (L'utilisation de la mémoire en particulier est un problème potentiel, car l'augmentation du nombre de processus en cours peut entraîner une surcharge de mémoire par processus.) Vous ne devez pas vous contenter de déployer la clé d'origine en espérant que tout ira bien.

En quoi cela est-il lié à l'isolation multi-origine ?

La désignation de l'origine des clusters d'agents via l'en-tête Origin-Agent-Cluster est liée, mais distincte, à l'isolation multi-origine via les en-têtes Cross-Origin-Opener-Policy et Cross-Origin-Embedder-Policy.

Tout site qui se classe lui-même isolé multi-origine désactivera également les mêmes fonctionnalités de communication multi-origine sur le même site que lors de l'utilisation de l'en-tête Origin-Agent-Cluster. Toutefois, l'en-tête Origin-Agent-Cluster peut s'avérer utile en plus de l'isolation multi-origine, car il fournit au navigateur un indice supplémentaire pour modifier ses heuristiques d'allocation des ressources. Vous devriez donc toujours envisager d'appliquer l'en-tête Origin-Agent-Cluster et de mesurer les résultats, même sur les pages déjà isolées multi-origines.

Utiliser l'en-tête Origin-Agent-Cluster

Pour utiliser l'en-tête Origin-Agent-Cluster, configurez votre serveur Web pour qu'il envoie l'en-tête de réponse HTTP suivant:

Origin-Agent-Cluster: ?1

La valeur de ?1 correspond à la syntaxe d'en-tête structuré pour une valeur booléenne true.

Il est important d'envoyer cet en-tête sur toutes les réponses issues de votre origine, et pas seulement sur certaines pages. Sinon, vous risquez d'obtenir des résultats incohérents, où le navigateur "se souvient" d'avoir vu une requête de définition de l'origine, et donc des clés de l'origine, même sur les pages qui ne la demandent pas. Ou l'inverse: si la première page consultée par un utilisateur ne comporte pas d'en-tête, le navigateur se souviendra que votre origine ne doit pas être associée à l'origine et ignorera l'en-tête sur les pages suivantes.

Pourquoi le navigateur ne peut-il pas toujours respecter l'en-tête ?

Cette "mémoire" permet d'assurer la cohérence de la saisie pour une origine. Si certaines pages d'une origine étaient associées à l'origine, alors que d'autres ne le sont pas, il se peut que vous ayez deux pages de même origine qui soient placées dans des clusters d'agents différents et qu'elles ne soient pas autorisées à communiquer entre elles. Cela serait très étrange, à la fois pour les développeurs Web et pour les éléments internes du navigateur. Ainsi, la spécification pour Origin-Agent-Cluster ignore l'en-tête s'il n'est pas cohérent avec ce qu'il a déjà vu pour une origine donnée. Dans Chrome, un avertissement s'affiche dans la console.

Cette cohérence est limitée à un groupe de contextes de navigation, c'est-à-dire un groupe d'onglets, de fenêtres ou d'iFrames qui peuvent tous se joindre via des mécanismes tels que window.opener, frames[0] ou window.parent. Cela signifie qu'une fois que l'identification de l'origine ou du site d'une origine a été établie (que le navigateur voit ou ne voit pas l'en-tête), la modification nécessite d'ouvrir un tout nouvel onglet, qui n'est en aucun cas connecté à l'ancien.

Ces informations peuvent être importantes pour tester l'en-tête Origin-Agent-Cluster. Lorsque vous l'ajoutez pour la première fois à votre site, il ne suffit pas d'actualiser la page. Vous devez fermer l'onglet, puis en ouvrir un autre.

Pour vérifier si l'en-tête Origin-Agent-Cluster est appliqué, utilisez la propriété JavaScript window.originAgentCluster. Cette valeur indique true si l'en-tête (ou d'autres mécanismes, comme l'isolation multi-origine) a entraîné le chiffrement de l'origine, false dans le cas contraire ; et undefined dans les navigateurs qui n'implémentent pas l'en-tête Origin-Agent-Cluster. La journalisation de ces données dans votre plate-forme d'analyse peut vous permettre de vérifier que vous avez correctement configuré votre serveur.

Enfin, notez que l'en-tête Origin-Agent-Cluster ne fonctionne que sur les contextes sécurisés, c'est-à-dire sur les pages HTTPS ou sur http://localhost. Les pages HTTP non-localhost ne sont pas compatibles avec les clusters d'agents selon l'origine.

Le chiffrement de l'origine n'est pas une fonctionnalité de sécurité

Bien que l'utilisation d'un cluster d'agents selon l'origine isole votre origine de l'accès synchrone à partir de pages multi-origines sur le même site, cela n'offre pas la protection des en-têtes liés à la sécurité tels que Cross-Origin-Resource-Policy et Cross-Origin-Opener-Policy. En particulier, il ne constitue pas une protection fiable contre les attaques par canal secondaire comme Spectre.

Cela peut être un peu surprenant, car la désignation de l'origine peut parfois amener votre origine à obtenir son propre processus, et des processus distincts constituent une défense importante contre les attaques par canal auxiliaire. Toutefois, n'oubliez pas que l'en-tête Origin-Agent-Cluster n'est qu'un indice à cet égard. Le navigateur n'est pas tenu de créer un processus distinct pour votre origine, et ce pour diverses raisons:

  • Il est possible qu'un navigateur n'implémente pas la technologie nécessaire pour cela. Par exemple, Safari et Firefox peuvent actuellement placer des onglets distincts dans leurs propres processus, mais ce n'est pas encore le cas pour les iFrames.

  • Le navigateur peut décider que cela ne vaut pas la peine d'avoir recours à un processus distinct. Par exemple, sur les appareils Android à faible mémoire ou dans Android WebView, Chrome utilise le moins de processus possible.

  • Le navigateur peut vouloir respecter la requête indiquée par l'en-tête Origin-Agent-Cluster, mais il peut le faire en utilisant une technologie d'isolation différente de celle des processus. Par exemple, Chrome explore à l'aide de threads au lieu de processus pour ce type d'isolation des performances.

  • L'utilisateur ou le code exécuté sur un autre site a peut-être déjà accédé à une page associée au site sur votre origine. La garantie de cohérence s'est donc déclenchée et l'en-tête Origin-Agent-Cluster a été complètement ignoré.

C'est pourquoi il est important de ne pas considérer les clusters d'agents selon l'origine comme une fonctionnalité de sécurité. Il s'agit plutôt d'un moyen d'aider le navigateur à hiérarchiser l'allocation des ressources, en indiquant que votre origine bénéficierait de ressources dédiées (et que vous êtes prêt à renoncer à certaines fonctionnalités en échange).

Commentaires

Si vous utilisez (ou envisagez d'utiliser) l'en-tête Origin-Agent-Cluster, contactez l'équipe Chrome. Votre intérêt pour le public et votre soutien nous aident à hiérarchiser les fonctionnalités et à montrer aux autres fournisseurs de navigateurs à quel point elles sont importantes. Envoyez un tweet à @ChromiumDev pour informer Chrome DevRel de votre avis et de vos expériences.

Si vous avez d'autres questions sur les spécifications ou sur le fonctionnement de la fonctionnalité, vous pouvez signaler le problème dans le dépôt GitHub standard HTML. Si vous rencontrez des problèmes avec l'implémentation dans Chrome, vous pouvez signaler un bug sur new.crbug.com en définissant le champ "Composants" sur Internals>Sandbox>SiteIsolation.

Plus d'infos

Pour en savoir plus sur les clusters d'agents selon l'origine, consultez les liens suivants: