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

Nouvel en-tête de réponse HTTP permettant de limiter l'écriture de script à l'échelle du domaine et de 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 par script synchrone entre les pages multi-origines sur le même site. Les navigateurs peuvent également utiliser Origin-Agent-Cluster comme indice indiquant 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 jugé intéressant à prototyper. Il a reçu une réaction préliminaire positive de la part des représentants de WebKit, le moteur de navigateur utilisé par Safari.

En attendant, vous pouvez déployer l'en-tête Origin-Agent-Cluster auprès de tous vos utilisateurs dès aujourd'hui. Les navigateurs qui ne le comprennent pas l'ignorent simplement. Et comme les pages des groupes d'agents basés sur l'origine peuvent en réalité faire moins de choses que celles basées sur le site (par défaut), il n'y a pas de problème d'interopérabilité à craindre.

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

Le Web repose sur le Règlement d'origine identique, une fonctionnalité de sécurité qui limite 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. Autrefois, même si des origines distinctes ne pouvaient pas accéder aux données de l'autre, elles partageaient toujours des ressources telles que les threads, les processus et l'allocation de mémoire du système d'exploitation. Cela signifiait que si un onglet était lent, tous les autres onglets étaient ralentis. 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 différents processus. Le fonctionnement exact varie selon le navigateur: la plupart des navigateurs présentent un certain niveau de séparation entre les onglets, mais différents éléments iframe d'un même onglet peuvent partager un processus. Étant donné que les processus comportent un certain coût mémoire, ils utilisent des heuristiques pour éviter d'en créer trop: par exemple, Firefox dispose d'une limite de processus configurable par l'utilisateur, et Chrome modifie son comportement entre ordinateur (où la mémoire est plus abondante) et mobile (où elle est rare).

Ces heuristiques ne sont pas parfaites. Ils souffrent d'une limitation importante: en raison d'exceptions à la règle de 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'empêcher automatiquement de s'échanger des sous-domaines.

Ce comportement par défaut est appelé "clusters d'agents par site": 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 avec clé origine, de sorte qu'elle ne soit groupée qu'avec d'autres pages ayant exactement la même origine. En particulier, les pages multi-origines sur le même site seront exclues du cluster d'agents.

Cette séparation en option permet aux navigateurs d'attribuer à ces nouveaux clusters d'agents basés sur l'origine leurs propres ressources dédiées, qui ne sont pas combinées à celles d'autres origines. Par exemple, ces pages peuvent avoir 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 pourrait bénéficier de ces ressources dédiées.

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

Ce que les pages avec clé d'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 à d'autres pages multi-origines sur le 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

Les origines qui profitent le plus de l'en-tête Origin-Agent-Cluster sont celles qui:

  • Ils obtiennent de meilleurs résultats avec leurs propres ressources dédiées, si possible. Il peut s'agir, par exemple, de jeux gourmands en ressources, de sites de visioconférence ou d'applications de création multimédia.

  • Contient des iFrames gourmandes en ressources qui sont d'une origine différente, mais du même site. Par exemple, si https://mail.example.com intègre des iFrames https://chat.example.com, la définition de l'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.

  • Attendez-vous à être intégré sur des pages du même site d'origine différente, mais sachez qu'ils sont gourmands en ressources. Par exemple, si https://customerservicewidget.example.com s'attend à utiliser de nombreuses ressources pour le chat vidéo et qu'il sera intégré à différentes origines dans 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 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, il ne s'agit que de recommandations. 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 devez mesurer vos Web Vitals et, éventuellement, votre utilisation de la mémoire, pour voir l'impact de la clé d'origine. (L'utilisation de la mémoire en particulier est un problème potentiel, car l'augmentation du nombre de processus en jeu peut entraîner une surcharge de mémoire par processus.) Il ne suffit pas de déployer la saisie par clé d'origine et de croiser les doigts.

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

Le codage par origine des clusters d'agents via l'en-tête Origin-Agent-Cluster est lié, mais distinct de l'isolation inter-origine via les en-têtes Cross-Origin-Opener-Policy et Cross-Origin-Embedder-Policy.

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 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-origine.

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 est la syntaxe de l'en-tête structuré pour une valeur true booléenne.

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 les clés d'origine même sur les pages qui ne la demandent pas. Ou inversement: si la première page qu'un utilisateur consulte ne comporte pas d'en-tête, le navigateur se souviendra que votre origine ne souhaite pas être associée à une clé d'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 de garantir la cohérence de la saisie pour une origine. Si certaines pages d'une origine étaient associées à une clé d'origine, tandis que d'autres ne l'étaient pas, vous pouviez avoir deux pages de même origine placées dans des groupes d'agents différents et qui 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. Par conséquent, la spécification pour Origin-Agent-Cluster ignore l'en-tête s'il est incohérent avec ce qui a été vu précédemment pour une origine donnée. Dans Chrome, un avertissement de console s'affiche.

Cette cohérence est limitée à un groupe de contexte de navigation, qui est un groupe d'onglets, de fenêtres ou d'iframes pouvant tous se contacter 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 pour la première fois à votre site, 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. La valeur sera true dans les cas où l'en-tête (ou d'autres mécanismes, comme l'isolation cross-origin) a provoqué le chiffrement par origine ; false dans les cas contraires et undefined dans les navigateurs qui n'implémentent pas l'en-tête Origin-Agent-Cluster. L'enregistrement de ces données dans votre plate-forme d'analyse peut vous aider à vérifier que vous avez correctement configuré votre serveur.

Enfin, notez que l'en-tête Origin-Agent-Cluster ne fonctionne que dans 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 basés sur la clé d'origine.

Le chiffrement par 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 constitue pas une protection fiable contre les attaques par canal auxiliaire telles que Spectre.

Cela peut sembler un peu surprenant, car le chiffrement par origine peut parfois entraîner l'obtention d'un propre processus par votre origine, et les processus distincts constituent une défense importante contre les attaques par canal auxiliaire. 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 donner à votre origine un processus distinct, et il peut ne pas le faire pour diverses raisons:

  • Un navigateur peut ne pas implémenter la technologie nécessaire. Par exemple, Safari et Firefox peuvent actuellement placer des onglets distincts dans leurs propres processus, mais ne peuvent pas encore le faire pour les iFrames.

  • Le navigateur peut décider que le coût d'un processus distinct n'est pas justifié. 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 à l'aide d'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.

  • L'utilisateur ou le code exécuté sur un autre site peut déjà avoir accédé à une page avec clé de site sur votre origine, ce qui déclenche la garantie de cohérence et l'en-tête Origin-Agent-Cluster est entièrement 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 d'autres questions sur la spécification ou sur le fonctionnement de la fonctionnalité, vous pouvez créer une demande dans le dépôt GitHub de la norme 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: