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

Ein neuer HTTP-Antwortheader, um domainweites Scripting einzuschränken und dedizierte Ressourcen vom Browser anzufordern.

Domenic Denicola
Domenic Denicola
X GitHub

Origin-Agent-Cluster ist ein neuer HTTP-Antwortheader, der den Browser anweist, synchronen Scripting-Zugriff zwischen ursprungsübergreifenden Seiten derselben Website zu verhindern. Browser können Origin-Agent-Cluster auch als Hinweis verwenden, dass der Ursprung eigene, separate Ressourcen erhalten sollte, z. B. einen dedizierten Prozess.

Browserkompatibilität

Derzeit ist der Origin-Agent-Cluster-Header erst ab Chrome 88 implementiert. Er wurde in enger Zusammenarbeit mit Vertretern von Mozilla Firefox entwickelt, die ihn als wertvolles Prototyping gekennzeichnet haben. Darüber hinaus wird er von den Vertretern von WebKit, der von Safari verwendeten Browser-Engine, vorab positiv aufgenommen.

In der Zwischenzeit können Sie den Origin-Agent-Cluster-Header für alle Nutzer bereitstellen. Browser, die sie nicht verstehen, ignorieren sie einfach. Und da Seiten in ursprungsgebundenen Agent-Clustern tatsächlich weniger Funktionen können als an Websites gebundene Funktionen (Standardeinstellung), besteht kein Interoperabilitätsproblem.

Warum Browser die Herkunft derselben Website nicht automatisch trennen können

Das Web basiert auf der Same-Origin-Policy, einer Sicherheitsfunktion, die einschränkt, wie Dokumente und Skripts mit Ressourcen anderer Herkunft interagieren können. Beispiel: Eine unter https://a.example gehostete Seite hat einen anderen Ursprung als der Ursprung unter https://b.example oder der unter https://sub.a.example.

Im Hintergrund nutzen Browser die von den Ursprüngen ermöglichte Trennung auf unterschiedliche Weise. Früher konnten separate Ursprünge nicht auf die Daten des jeweils anderen zugreifen, aber sie teilen sich Ressourcen wie Betriebssystem-Threads, Prozesse und Arbeitsspeicherzuweisung. Wenn also ein Tab langsam war, werden auch alle anderen Tabs langsamer. Wenn ein Tab zu viel Arbeitsspeicher verbraucht, könnte es den gesamten Browser zum Absturz bringen.

Browser sind heutzutage komplexer und versuchen, verschiedene Ursprünge in verschiedene Prozesse zu unterteilen. Die genaue Funktionsweise variiert je nach Browser: In den meisten Browsern gibt es eine gewisse Trennung zwischen Tabs. Verschiedene iFrames innerhalb eines einzelnen Tabs teilen möglicherweise jedoch einen Prozess. 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 vorhanden 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 Same-Origin-Richtlinie gibt, die es Subdomains wie https://sub.a.example und https://a.example erlaubt, 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. Mit dem neuen Origin-Agent-Cluster-Header wird der Browser aufgefordert, dieses Standardverhalten für eine bestimmte Seite zu ändern. Dazu wird sie in einen Agent-Cluster mit Ursprung eingebunden, sodass er nur mit anderen Seiten gruppiert wird, die denselben Ursprung haben. Insbesondere werden ursprungsübergreifende Seiten derselben Website aus dem Agent-Cluster ausgeschlossen.

Durch diese Opt-in-Trennung können Browser diesen neuen an Ursprünge gebundenen Agent-Clustern eigene dedizierte Ressourcen zuweisen, die nicht mit denen anderer Ursprünge kombiniert werden. Solche Seiten können 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.

Damit die Trennung durchgeführt und diese Vorteile genutzt werden können, muss der Browser jedoch einige Legacy-Funktionen deaktivieren.

Was mit ursprungsgebundenen Seiten nicht möglich ist

Wenn sich Ihre Seite in einem an Ursprünge gebundenen Agent-Cluster befindet, geben Sie einige Möglichkeiten auf, mit ursprungsübergreifenden Seiten derselben Website zu kommunizieren, die zuvor verfügbar waren. Wichtig ist insbesondere:

  • Sie können document.domain nicht mehr festlegen. Dies ist ein Legacy-Feature, das es normalerweise ermöglicht, dass ursprungsübergreifende Seiten derselben Website synchron auf das DOM der anderen Seiten zugreifen. In an Ursprünge gebundenen Agent-Clustern ist sie jedoch deaktiviert.

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

  • (Nur Chrome) Sie können keine SharedArrayBuffer- oder WebAssembly.Memory-Objekte mehr an andere ursprungsübergreifende Seiten derselben Website 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:

  • Die besten Ergebnisse mit eigenen dedizierten Ressourcen erzielen, wenn möglich Beispiele hierfür sind leistungsintensive Spiele, Websites für Videokonferenzen oder Anwendungen zum Erstellen von Multimedia.

  • Enthält ressourcenintensive iFrames mit unterschiedlichem Ursprung, aber derselben Website. Wenn https://mail.example.com beispielsweise https://chat.example.com-iFrames einbettet, sorgt die Origin-keying https://mail.example.com/ dafür, dass der vom Chatteam geschriebene Code nicht versehentlich mit dem vom E-Mail-Team geschriebenen Code in Konflikt steht. Außerdem kann der Browser den Browser anweisen, separate Prozesse zu erstellen, um diese unabhängig zu planen und die Auswirkungen auf die Leistung zu verringern.

  • Erwartungsgemäß sind sie auf Seiten derselben Website mit unterschiedlichem Ursprung eingebettet, sind aber ressourcenintensiv. Wenn https://customerservicewidget.example.com beispielsweise davon ausgeht, viele Ressourcen für Videochats zu verwenden, und in https://*.example.com an verschiedenen Quellen eingebettet wird, könnte das Team, das dieses Widget verwaltet, den Origin-Agent-Cluster-Header verwenden, um die Auswirkungen auf die Einbettungen zu verringern.

Außerdem musst du die oben genannten selten verwendeten Funktionen für die ursprungsübergreifende Kommunikation deaktivieren und prüfen, ob auf deiner Website HTTPS verwendet wird.

Letztendlich sind dies aber nur Richtlinien. Ob ursprungsgebundene Agent-Cluster für Ihre Website hilfreich sind oder nicht, lässt sich letztlich am besten anhand von Messungen bestimmen. Insbesondere sollten Sie Ihre Web Vitals und eventuell auch Ihre Arbeitsspeichernutzung messen, um herauszufinden, welche Auswirkungen die Codierung auf Ursprünge hat. Insbesondere die Arbeitsspeichernutzung ist ein mögliches Problem, da eine Erhöhung der Anzahl der laufenden Prozesse zu einem höheren Arbeitsspeicher-Overhead pro Prozess führen kann. Sie sollten nicht einfach die Origin-keying einführen und auf das Beste hoffen.

In welchem Zusammenhang steht das mit der ursprungsübergreifenden Isolierung?

Die Origin-keying von Agent-Clustern über den Header Origin-Agent-Cluster bezieht sich auf die ursprungsübergreifende Isolation über die Header Cross-Origin-Opener-Policy und Cross-Origin-Embedder-Policy, ist 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 ursprungsübergreifenden Isolierung nützlich sein, da er einen zusätzlichen Hinweis an den Browser gibt, um seine Heuristik für die Ressourcenzuweisung zu ändern. Sie sollten daher trotzdem erwägen, den Origin-Agent-Cluster-Header anzuwenden und die Ergebnisse zu messen, auch auf Seiten, die bereits ursprungsübergreifend isoliert sind.

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 eines strukturierten Headers für einen booleschen Wert vom Typ true.

Es ist wichtig, diesen Header für alle Antworten von Ihrem Ursprungsserver zu senden, nicht nur für einige Seiten. Andernfalls kann es zu inkonsistenten Ergebnissen kommen, bei denen der Browser sich „merkt“, dass er eine Anfrage zur Ursprungscodierung sieht, und somit auch auf Seiten, die nicht danach fragen, Ursprungsschlüssel erstellt. Umgekehrt gilt: Wenn die erste Seite, die ein Nutzer besucht, keinen Header hat, merkt sich der Browser, dass Ihr Ursprung nicht an den Ursprung gebunden sein soll, und ignoriert die Kopfzeile auf den nachfolgenden Seiten.

Warum kann der Browser den Header nicht immer berücksichtigen?

Der Grund für diesen „Speicher“ besteht darin, die Konsistenz der Codierung für einen Ursprung sicherzustellen. Wenn einige Seiten eines Ursprungs ursprungsgebunden sind und andere nicht, könnten Sie zwei Seiten mit demselben Ursprung haben, die in verschiedenen Agent-Clustern abgelegt wurden und daher nicht miteinander kommunizieren durften. Das wäre sehr seltsam, sowohl für Webentwickler als auch für die internen Strukturen des Browsers. 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 dann eine Konsolenwarnung angezeigt.

Diese Konsistenz bezieht sich auf eine Browserkontextgruppe. Dabei handelt es sich um eine Gruppe von Tabs, Fenstern oder iFrames, die sich alle über Mechanismen wie window.opener, frames[0] oder window.parent gegenseitig erreichen können. Wenn also die Ursprungs- oder Website-Verschlüsselung eines Ursprungs geklärt wurde, d. h. der Browser den Header entweder sieht oder nicht sieht, muss bei einer Änderung ein völlig neuer Tab geöffnet werden, der in keiner Weise mit dem alten Tab verbunden ist.

Diese Details können zum Testen des Origin-Agent-Cluster-Headers wichtig sein. Wenn du es zum ersten Mal zu deiner Website hinzufügst, funktioniert das einfache Aktualisieren der Seite nicht. Du musst den Tab schließen und einen neuen öffnen.

Mit dem JavaScript-Attribut window.originAgentCluster kannst du prüfen, ob der Origin-Agent-Cluster-Header angewendet wird. Der Wert ist true, wenn der Header (oder andere Mechanismen wie die ursprungsübergreifende Isolierung) die Origin-keying verursacht, false, wenn dies nicht der Fall ist, und undefined in Browsern, in denen der Origin-Agent-Cluster-Header nicht implementiert ist. Die Protokollierung dieser Daten in Ihrer Analyseplattform kann eine wertvolle Überprüfung darstellen, ob Sie Ihren Server richtig konfiguriert haben.

Der Origin-Agent-Cluster-Header funktioniert nur in sicheren Kontexten, also auf HTTPS-Seiten oder auf http://localhost. HTTP-Seiten, die nicht auf localhost basieren, unterstützen keine an Ursprünge gebundenen Agent-Cluster.

Die Ursprungsverschlüsselung ist keine Sicherheitsfunktion

Wenn Sie einen an Ursprünge gebundenen Agent-Cluster verwenden, 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 es 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. Beachten Sie jedoch, dass der Origin-Agent-Cluster-Header nur ein Hinweis in dieser Hinsicht ist. 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 die entsprechende Technologie möglicherweise nicht. Zum Beispiel können derzeit in Safari und Firefox separate Tabs in eigene Prozesse eingefügt werden, für iFrames jedoch noch nicht.

  • 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 im Origin-Agent-Cluster-Header angegebene Anfrage berücksichtigen, kann dazu aber eine andere Isolationstechnologie als Prozesse verwenden. Chrome nutzt 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 an Ursprünge gebundene Agent-Cluster nicht als Sicherheitsfeature angesehen werden. Es ist vielmehr eine Möglichkeit, den Browser bei der Priorisierung der Ressourcenzuweisung zu unterstützen. Es wird angedeutet, dass Ihr Ursprung von dedizierten Ressourcen profitieren würde und Sie bereit sind, im Gegenzug auf bestimmte Features zu verzichten.

Feedback

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

Falls Sie weitere Fragen zur Spezifikation oder zur Funktionsweise der Funktion haben, können Sie ein Problem im GitHub-Repository für HTML-Standards melden. Falls bei der Implementierung in Chrome Probleme auftreten, können Sie unter new.crbug.com einen Fehler melden. Setzen Sie dabei das Feld „Components“ (Komponenten) auf Internals>Sandbox>SiteIsolation.

Weitere Informationen

Weitere Informationen zu an Ursprüngen gebundenen Agent-Clustern finden Sie unter den folgenden Links: