Leistungsisolation mit dem Header „Origin-Agent-Cluster“ anfordern

Ein neuer HTTP-Antwortheader, mit dem domainweites Scripting eingeschränkt und spezielle Ressourcen vom Browser angefordert werden können.

Domenic Denicola
Domenic Denicola

Origin-Agent-Cluster ist ein neuer HTTP-Antwortheader, der den Browser anweist, den synchronen Scripting-Zugriff zwischen Seiten mit unterschiedlichen Ursprüngen auf derselben Website zu verhindern. Browser können Origin-Agent-Cluster auch als Hinweis verwenden, dass der Ursprung eigene, separate Ressourcen erhalten soll, z. B. einen speziellen Prozess.

Derzeit ist die Origin-Agent-Cluster-Überschrift nur in Chrome 88 und höher implementiert. Es wurde in enger Zusammenarbeit mit Vertretern von Mozilla Firefox entwickelt, die es als Prototyping-würdig eingestuft haben. Vertreter von WebKit, der von Safari verwendeten Browser-Engine, haben es vorläufig positiv aufgenommen.

In der Zwischenzeit können Sie die Origin-Agent-Cluster-Überschrift jedoch für alle Nutzer bereitstellen. Browser, die das Tag nicht verstehen, ignorieren es einfach. Da auf Seiten in Clustern mit Ursprungsschlüsseln weniger Funktionen verfügbar sind als auf Seiten mit Websiteschlüsseln (Standard), gibt es keine Interkompatibilitätsprobleme.

Warum Browser Quellen auf einer Website nicht automatisch voneinander trennen können

Das Web basiert auf der Richtlinie für denselben Ursprung, einer Sicherheitsfunktion, die einschränkt, wie Dokumente und Scripts mit Ressourcen aus einem anderen Ursprung interagieren können. Eine Seite, die unter https://a.example gehostet wird, hat beispielsweise einen anderen Ursprung als eine Seite unter https://b.example oder https://sub.a.example.

Im Hintergrund nutzen Browser die Trennung, die Ursprünge bieten, auf unterschiedliche Weise. Früher konnten separate Ursprünge zwar nicht auf die Daten der anderen zugreifen, teilten sich aber dennoch Ressourcen wie Betriebssystem-Threads, Prozesse und Arbeitsspeicherzuweisung. Wenn also ein Tab langsam war, wurden auch alle anderen Tabs verlangsamt. Wenn ein Tab zu viel Arbeitsspeicher verbraucht, stürzt der gesamte Browser ab.

Browser sind heutzutage komplexer und versuchen, verschiedene Ursprünge in verschiedene Prozesse zu unterteilen. Wie genau das funktioniert, variiert je nach Browser: Die meisten Browser haben eine gewisse Trennung zwischen Tabs, aber verschiedene Iframes innerhalb eines Tabs können sich einen Prozess teilen. Da Prozesse mit einem gewissen Arbeitsspeicheraufwand verbunden sind, verwenden sie Heuristiken, um zu vermeiden, dass zu viele erstellt werden. So hat Firefox beispielsweise ein vom Nutzer konfigurierbares Prozesslimit und Chrome variiert sein Verhalten zwischen Desktop (wenn mehr Arbeitsspeicher verfügbar ist) und dem Mobilgerät (wenn es knapp ist).

Diese Heuristiken sind nicht perfekt. Außerdem haben sie eine wichtige Einschränkung: Da es Ausnahmen von der Richtlinie zum gleichen Ursprung gibt, die es Subdomains wie https://sub.a.example und https://a.example ermöglichen, miteinander zu kommunizieren, können Browser Subdomains nicht automatisch voneinander trennen.

Dieses Standardverhalten wird als „auf Websites gebundene Agent-Cluster“ bezeichnet, d. h., der Browser gruppiert Seiten nach ihrer Website. Der neue Origin-Agent-Cluster-Header fordert den Browser auf, dieses Standardverhalten für eine bestimmte Seite zu ändern und sie in einen Agentencluster mit Schlüssel origin einzufügen, damit sie nur mit anderen Seiten mit genau demselben Ursprung gruppiert wird. Insbesondere werden ursprungsübergreifende Seiten derselben Website aus dem Kundenservicemitarbeitercluster ausgeschlossen.

Durch diese optionale Trennung können Browser diesen neuen an Ursprünge gebundenen Kundenservicemitarbeiter-Clustern eigene Ressourcen zuweisen, die nicht mit denen anderer Ursprünge kombiniert werden. Solche Seiten könnten beispielsweise einen eigenen Prozess erhalten oder in separaten Threads geplant werden. Wenn Sie Ihrer Seite den Header Origin-Agent-Cluster hinzufügen, signalisieren Sie dem Browser, dass die Seite von solchen dedizierten Ressourcen profitieren würde.

Um die Trennung durchzuführen und diese Vorteile zu nutzen, müssen jedoch einige ältere Funktionen im Browser deaktiviert werden.

Was mit ursprungsgebundenen Seiten nicht möglich ist

Wenn sich Ihre Seite in einem Cluster mit anbieterbasierten Kundenservicemitarbeitern befindet, verlieren Sie einige Funktionen, die zuvor für die Kommunikation mit seiteninternen, anbieterübergreifenden Seiten verfügbar waren. Wichtig ist insbesondere:

  • Sie können document.domain nicht mehr festlegen. Dies ist eine ältere Funktion, die normalerweise ursprungsübergreifenden Seiten auf derselben Website erlaubt, synchron auf das DOM der jeweils anderen Seite zuzugreifen. In an Ursprünge gebundenen Agent-Clustern ist sie jedoch deaktiviert.

  • Sie können WebAssembly.Module-Objekte nicht mehr über postMessage() an andere seitenübergreifende Seiten derselben Website senden.

  • (Nur Chrome) Sie können keine SharedArrayBuffer- oder WebAssembly.Memory-Objekte mehr an andere seiteninterne, plattformübergreifende Seiten senden.

Wann sollten an Ursprünge gebundene Agent-Cluster verwendet werden?

Die Ursprünge, die vom Origin-Agent-Cluster-Header am meisten profitieren, sind die, die:

  • Sie erzielen die beste Leistung, wenn sie eigene Ressourcen haben. Beispiele hierfür sind leistungsintensive Spiele, Websites für Videokonferenzen oder Apps zum Erstellen von Multimediainhalten.

  • Enthält ressourcenintensive iFrames mit unterschiedlichem Ursprung, aber derselben Website. Wenn beispielsweise https://mail.example.com https://chat.example.com-Iframes einbettet, sorgt die Herkunftsschlüsselunghttps://mail.example.com/ dafür, dass der vom Chatteam geschriebene Code nicht versehentlich den vom E-Mail-Team geschriebenen Code beeinträchtigt. Außerdem kann der Browser angewiesen werden, ihnen separate Prozesse zuzuweisen, um sie unabhängig voneinander zu planen und ihre Leistungsauswirkungen aufeinander zu verringern.

  • Sie werden voraussichtlich auf Seiten mit unterschiedlichen Ursprüngen auf derselben Website eingebettet, sind aber ressourcenintensiv. Wenn https://customerservicewidget.example.com beispielsweise viele Ressourcen für den Videochat benötigt und in https://*.example.com an verschiedenen Stellen eingebettet wird, kann das Team, das dieses Widget verwaltet, den Origin-Agent-Cluster-Header verwenden, um die Leistungsauswirkungen auf die Einbettungsplattformen zu verringern.

Außerdem müssen Sie die oben genannten selten verwendeten plattformübergreifenden Kommunikationsfunktionen deaktivieren und dafür sorgen, dass auf Ihrer Website HTTPS verwendet wird.

Letztendlich sind das aber nur Richtlinien. Ob Origin-keyed Agent Clustering für Ihre Website von Vorteil ist, lässt sich am besten durch Messungen feststellen. Insbesondere sollten Sie Ihre Web Vitals und eventuell auch Ihre Arbeitsspeichernutzung messen, um festzustellen, welche Auswirkungen die Codierung auf Ursprünge hat. Insbesondere die Arbeitsspeichernutzung kann ein Problem darstellen, da eine Erhöhung der Anzahl der Prozesse zu einem höheren Arbeitsspeicheraufwand pro Prozess führen kann. Sie sollten die Herkunftsschlüsselung nicht einfach einführen und auf das Beste hoffen.

In welcher Beziehung steht das zur ursprungsübergreifenden Isolierung?

Die Zuordnung von Agent-Clustern über den Origin-Agent-Cluster-Header ist mit der ursprungsübergreifenden Isolierung über die Cross-Origin-Opener-Policy- und Cross-Origin-Embedder-Policy-Header verwandt, aber davon getrennt.

Bei jeder Website, die ursprungsübergreifend isoliert wird, werden auch die gleichen websiteübergreifenden ursprungsübergreifenden Kommunikationsfunktionen deaktiviert wie bei Verwendung des Origin-Agent-Cluster-Headers. Der Origin-Agent-Cluster-Header kann jedoch zusätzlich zur plattformübergreifenden Isolierung nützlich sein, da er dem Browser als zusätzlicher Hinweis dient, seine Heuristiken zur Ressourcenzuweisung zu ändern. Daher sollten Sie die Origin-Agent-Cluster-Überschrift auch auf Seiten anwenden, die bereits ursprungsübergreifend isoliert sind, und die Ergebnisse messen.

Origin-Agent-Cluster-Header verwenden

Konfigurieren Sie Ihren Webserver so, dass er den folgenden HTTP-Antwortheader sendet, um den Origin-Agent-Cluster-Header zu verwenden:

Origin-Agent-Cluster: ?1

Der Wert von ?1 ist die Syntax für strukturierte Header für einen booleschen true-Wert.

Es ist wichtig, diesen Header in allen Antworten von Ihrer Quelle zu senden, nicht nur auf einigen Seiten. Andernfalls kann es zu inkonsistenten Ergebnissen kommen, wenn der Browser sich eine Anfrage für die Schlüsselung von Ursprüngen „merkt“ und daher auch auf Seiten, auf denen keine Anfrage erfolgt, Schlüssel für Ursprünge verwendet. Oder umgekehrt: Wenn die erste Seite, die ein Nutzer besucht, keine Überschrift hat, merkt sich der Browser, dass Ihre Quelle nicht über den Ursprungsschlüssel identifiziert werden soll, und ignoriert die Überschrift auf den nachfolgenden Seiten.

Dieser „Speicher“ soll für eine einheitliche Schlüsselung für einen Ursprung sorgen. Wenn einige Seiten eines Ursprungs mit dem Ursprungsschlüssel verknüpft sind, andere aber nicht, können zwei Seiten mit demselben Ursprung in verschiedene Kundenservicemitarbeiter-Cluster eingeordnet werden und dürfen daher nicht miteinander kommunizieren. Das wäre sowohl für Webentwickler als auch für die internen Funktionen des Browsers sehr merkwürdig. Daher wird der Header von der Spezifikation für Origin-Agent-Cluster stattdessen ignoriert, wenn er nicht mit dem zuvor für einen bestimmten Ursprung übereinstimmt. In Chrome wird eine Konsolenwahrung angezeigt.

Diese Konsistenz bezieht sich auf eine Browserkontextgruppe, also eine Gruppe von Tabs, Fenstern oder Iframes, die sich alle über Mechanismen wie window.opener, frames[0] oder window.parent erreichen können. Das bedeutet, dass die Ursprungs- oder Website-Eingabe für einen Ursprung erst einmal festgelegt werden muss (d. h. der Browser muss den Header entweder sehen oder nicht sehen). Wenn Sie sie ändern möchten, müssen Sie einen ganz neuen Tab öffnen, der in keiner Weise mit dem alten verbunden ist.

Diese Details können für den Test des Origin-Agent-Cluster-Headers wichtig sein. Wenn Sie das Element zum ersten Mal auf Ihrer Website hinzufügen, reicht es nicht aus, die Seite einfach neu zu laden. Sie müssen den Tab schließen und einen neuen öffnen.

Mit der JavaScript-Eigenschaft window.originAgentCluster lässt sich prüfen, ob der Header Origin-Agent-Cluster angewendet wird. Das ist true, wenn der Header (oder andere Mechanismen wie die Cross-Origin-Isolation) die Schlüsselung des Ursprungs verursacht hat, false, wenn dies nicht der Fall ist, und undefined in Browsern, die den Origin-Agent-Cluster-Header nicht implementieren. Wenn Sie diese Daten in Ihrer Analyseplattform erfassen, können Sie prüfen, ob Ihr Server richtig konfiguriert ist.

Der Origin-Agent-Cluster-Header funktioniert nur in sicheren Kontexten, also auf HTTPS-Seiten oder auf http://localhost. Für HTTP-Seiten, die nicht lokal gehostet werden, werden keine Cluster mit Ursprungsschlüsseln unterstützt.

Origin-Keying ist keine Sicherheitsfunktion

Mit einem an Ursprünge gebundenen Agent-Cluster wird Ihr Ursprung zwar vom synchronen Zugriff von ursprungsübergreifenden Seiten derselben Website isoliert, aber es bietet keinen Schutz sicherheitsbezogener Header wie Cross-Origin-Resource-Policy und Cross-Origin-Opener-Policy. Insbesondere bietet er keinen zuverlässigen Schutz vor Side-Channel-Angriffen wie Spectre.

Das mag etwas überraschend sein, da die Origin-keying manchmal dazu führen kann, dass Ihr Ursprung einen eigenen Prozess erhält und separate Prozesse eine wichtige Abwehr gegen Side-Channel-Angriffe sind. Der Origin-Agent-Cluster-Header ist jedoch nur ein Hinweis in dieser Hinsicht. Der Browser ist nicht verpflichtet, Ihrem Ursprung einen separaten Prozess zu geben. Dies kann auch aus verschiedenen Gründen nicht der Fall sein:

  • Ein Browser implementiert diese Technologie möglicherweise nicht. Beispielsweise können Safari und Firefox derzeit separate Tabs in eigene Prozesse aufnehmen, aber noch nicht für Iframes.

  • Der Browser könnte entscheiden, dass sich der Aufwand eines separaten Prozesses nicht lohnt. Auf Android-Geräten mit wenig Arbeitsspeicher oder in Android WebView verwendet Chrome beispielsweise so wenige Prozesse wie möglich.

  • Der Browser möchte möglicherweise die Anfrage respektieren, die im Origin-Agent-Cluster-Header angegeben ist, könnte dies aber mit einer anderen Isolationstechnologie als Prozessen tun. Chrome verwendet beispielsweise Threads anstelle von Prozessen zur Erkundung dieser Art der Leistungsisolierung.

  • Der Nutzer oder Code, der auf einer anderen Website ausgeführt wird, hat möglicherweise bereits eine an Websites gebundene Seite auf Ihrem Ursprung aufgerufen. Dies hat dazu geführt, dass die Konsistenzgarantie funktioniert und der Origin-Agent-Cluster-Header vollständig ignoriert wird.

Aus diesen Gründen sollten Sie an Ursprünge gebundene Agent-Cluster nicht als Sicherheitsfunktion betrachten. Stattdessen können Sie dem Browser dabei helfen, die Ressourcenzuweisung zu priorisieren, indem Sie andeuten, dass Ihr Ursprung von speziellen Ressourcen profitieren würde und dass Sie im Austausch dafür bestimmte Funktionen aufgeben würden.

Feedback

Das Chrome-Team würde gerne von Ihnen hören, wenn Sie den Origin-Agent-Cluster-Header verwenden oder verwenden möchten. Ihr Interesse und Ihre Unterstützung helfen uns, Funktionen zu priorisieren und anderen Browseranbietern zu zeigen, wie wichtig sie sind. Tweeten Sie an @ChromiumDev und teilen Sie uns Ihre Meinung und Erfahrungen mit.

Wenn Sie weitere Fragen zur Spezifikation oder zur Funktionsweise der Funktion haben, können Sie ein Problem im GitHub-Repository des HTML-Standards melden. Wenn Probleme mit der Chrome-Implementierung auftreten, können Sie unter new.crbug.com einen Fehler melden. Das Feld „Components“ muss dabei auf Internals>Sandbox>SiteIsolation gesetzt sein.

Weitere Informationen

Weitere Informationen zu Clustern mit Herkunftsschlüsseln finden Sie unter den folgenden Links: