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 de script synchrone entre des pages multi-origines d'un même site. Les navigateurs peuvent également utiliser Origin-Agent-Cluster pour indiquer à votre origine qu'elle 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 ont indiqué qu'il est utile pour le prototypage. Il a également reçu une réception préliminaire positive de la part de représentants de WebKit, le moteur de navigateur utilisé par Safari.

Cependant, vous pouvez déployer l'en-tête Origin-Agent-Cluster pour tous vos utilisateurs sans 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 en fait effectuer moins d'opérations que celles basées sur le site (option par défaut), il n'y a aucun problème d'interopérabilité à craindre.

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

Le Web repose sur les règles de même origine, qui sont une fonctionnalité de sécurité limitant la façon 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 d'une page à l'adresse https://b.example ou de la page https://sub.a.example.

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

De nos jours, les navigateurs sont plus sophistiqués et tentent de séparer les différentes origines en plusieurs processus. Le fonctionnement varie selon les navigateurs: la plupart des navigateurs présentent un certain niveau de séparation entre les onglets, mais différents iFrames au sein d'un même onglet peuvent partager un 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 fait varier son comportement entre l'ordinateur de bureau (où la mémoire est plus abondante) et le mobile (où il est rare).

Ces méthodes heuristiques ne sont pas parfaites. Ils sont également soumis à une limitation importante: comme il existe des exceptions à la règle d'origine commune qui permettent à des 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, afin qu'elle ne soit regroupée qu'avec d'autres pages ayant exactement la même origine. En particulier, les pages multi-origines sur un même site sont exclues du cluster d'agents.

Cette séparation avec acceptation permet aux navigateurs de fournir à ces nouveaux clusters d'agents selon l'origine leurs propres ressources dédiées, qui ne sont pas combinées à celles d'autres origines. Par exemple, ces pages peuvent bénéficier de leur propre processus ou être programmées sur des fils de discussion distincts. En ajoutant l'en-tête Origin-Agent-Cluster à votre page, vous indiquez au navigateur qu'elle pourrait bénéficier de ces ressources dédiées.

Toutefois, pour effectuer cette séparation et bénéficier de ces avantages, le navigateur doit désactiver certaines anciennes fonctionnalités.

Ce que les pages selon l'origine ne peuvent pas faire

Lorsque votre page se trouve dans un cluster d'agents selon l'origine, vous renoncez à certaines capacités de communication avec les pages multi-origines d'un même site qui étaient auparavant disponibles. En particulier :

  • Vous ne pouvez plus définir document.domain. Il s'agit d'une ancienne fonctionnalité qui permet normalement aux pages multi-origines d'un 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 vers d'autres pages multi-origines du même site via postMessage().

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

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

L'en-tête Origin-Agent-Cluster bénéficie le plus des origines suivantes:

  • Pour obtenir de meilleurs résultats avec leurs propres ressources dédiées, si possible. Il peut s'agir de jeux gourmands en performances, de sites de visioconférence ou d'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 des iFrames https://chat.example.com, l'ajout de clé d'origine https://mail.example.com/ garantit que le code écrit par l'équipe de chat ne peut pas interférer accidentellement avec le code écrit par l'équipe de messagerie, et peut indiquer au navigateur des processus distincts pour les planifier indépendamment et réduire leur impact sur les performances les uns sur les autres.

  • Ils s'attendent à être intégrés sur des pages d'origines différentes et situées sur le même site, mais savent qu'ils sont gourmands en ressources. Par exemple, si https://customerservicewidget.example.com prévoit d'utiliser de nombreuses ressources pour le chat vidéo et sera intégré à différentes origines tout au long de https://*.example.com, l'équipe qui gère ce widget peut utiliser l'en-tête Origin-Agent-Cluster pour essayer de réduire son impact sur les performances sur les intégrateurs.

Vous devez également vous assurer que vous pouvez désactiver les fonctionnalités de communication multi-origines rarement utilisées susmentionnées et que votre site utilise HTTPS.

Mais au bout du compte, ce ne sont que des lignes directrices. Au final, il est préférable de déterminer si les clusters d'agents selon l'origine peuvent aider votre site ou non par des mesures. En particulier, vous devrez mesurer vos Web Vitals, et éventuellement l'utilisation de la mémoire, pour voir l'impact de l'identification 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 plus importante.) Ne vous contentez pas de déployer la détection de l'origine en espérant que tout ira bien.

Quel est le lien avec l'isolation multi-origine ?

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

Tout site isolé multi-origine désactive également les mêmes fonctionnalités de communication multi-origines 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 toujours être utile en plus de l'isolation multi-origine, car il offre un indice supplémentaire au navigateur pour modifier ses heuristiques d'allocation des ressources. Vous devez 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 afin 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 à toutes les réponses de votre origine, et pas seulement à certaines pages. Sinon, vous pouvez obtenir des résultats incohérents. Le navigateur "se souviendra" de voir une requête de clé d'origine, ce qui lui permettra d'utiliser des clés d'origine même sur les pages qui ne la demandent pas. Ou inversement: 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 souhaite pas être basée sur 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 clé pour une origine. Si certaines pages d'une origine étaient liées à l'origine, mais pas d'autres, vous pourriez avoir deux pages de la même origine qui ont été placées dans des clusters d'agents différents et n'étaient donc pas autorisées à communiquer entre elles. Ce serait très étrange, tant pour les développeurs Web que pour les composants internes du navigateur. Ainsi, la spécification de 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 contexte de navigation, c'est-à-dire un groupe d'onglets, de fenêtres ou d'iFrames qui peuvent tous communiquer via des mécanismes tels que window.opener, frames[0] ou window.parent. Cela signifie qu'une fois que la clé d'origine ou de site d'une origine a été réglée (par le navigateur qui 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 détails peuvent être importants pour tester l'en-tête Origin-Agent-Cluster. Lorsque vous l'ajoutez à votre site pour la première fois, il ne suffit pas d'actualiser la page. Vous devez fermer l'onglet et en ouvrir un autre.

Pour vérifier si l'en-tête Origin-Agent-Cluster est appliqué, utilisez la propriété JavaScript window.originAgentCluster. Il s'agit de true dans les cas où l'en-tête (ou d'autres mécanismes, tels que l'isolation multi-origine) a causé l'ajout de clé d'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 sur votre plate-forme d'analyse peut fournir une vérification utile de la configuration de 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 autres que localhost ne sont pas compatibles avec les clusters d'agents selon l'origine.

La clé d'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 des pages multi-origines sur le même site, elle n'offre pas la protection des en-têtes de sécurité tels que Cross-Origin-Resource-Policy et Cross-Origin-Opener-Policy. En particulier, il ne s'agit pas d'une protection fiable contre les attaques par canal secondaire comme Spectre.

Cela peut être un peu surprenant, car la clé d'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 à ce sujet. Le navigateur n'est pas tenu de définir un processus distinct pour votre origine, et il se peut qu'il ne le fasse pas pour diverses raisons:

  • Il est possible qu'un navigateur ne mette pas en œuvre la technologie nécessaire pour effectuer cette opération. Par exemple, actuellement, Safari et Firefox peuvent placer des onglets distincts dans leurs propres processus, mais pas encore pour les iFrames.

  • Le navigateur peut décider qu'un processus distinct n'en vaut pas la peine. 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 pourrait le faire en utilisant une technologie d'isolation différente de celle des processus. Par exemple, Chrome effectue l'exploration à l'aide de threads au lieu de processus pour ce type d'isolation des performances.

  • Il se peut que l'utilisateur ou le code exécuté sur un autre site aient déjà accédé à une page associée au site de votre origine. Par conséquent, la garantie de cohérence s'affiche et l'en-tête Origin-Agent-Cluster est 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'aider le navigateur à hiérarchiser l'allocation des ressources, en laissant entendre que votre origine bénéficierait de ressources dédiées (et que vous êtes prêt à renoncer à certaines fonctionnalités en échange).

Commentaires

L'équipe Chrome aimerait connaître votre avis si vous utilisez ou envisagez d'utiliser l'en-tête Origin-Agent-Cluster. Votre intérêt général et votre assistance nous aident à hiérarchiser les fonctionnalités et à montrer aux autres fournisseurs de navigateurs à quel point ils sont importants. Envoyez un tweet à @ChromiumDev et faites-nous part de vos commentaires et de vos expériences dans Chrome DevRel.

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

En savoir plus

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