Fenced Frame API

Eine Hauptquelle für Datenschutz und Sicherheitsprobleme im Web sind Inhalte, die in <iframe>-Elemente eingebettet sind. Historisch wurden <iframe>s verwendet, um Drittanbieter-Cookies zu setzen, die zum Teilen von Informationen und zum Verfolgen von Nutzern über Websites hinweg eingesetzt werden können. Darüber hinaus kann der in einem <iframe> eingebettete Inhalt mit seinem einbettenden Dokument kommunizieren (zum Beispiel durch die Verwendung von Window.postMessage()).

Das einbettende Dokument kann auch Skripte verwenden, um verschiedene Informationen aus dem <iframe> auszulesen — zum Beispiel können Sie potenziell erhebliche Tracking/Fingerprinting-Daten erhalten, wenn Sie die eingebettete URL aus der src-Eigenschaft lesen, insbesondere wenn sie URL-Parameter enthält. Das <iframe> kann auch auf das DOM des einbettenden Kontexts zugreifen und umgekehrt.

Die meisten modernen Browser arbeiten an Mechanismen zur Partitionierung von Speicher, sodass Cookie-Daten nicht mehr zum Tracking verwendet werden können (siehe zum Beispiel Cookies mit unabhängigem partitionierten Zustand (CHIPS) oder Firefox State Partitioning).

<fencedframe>-Elemente zielen darauf ab, ein weiteres Stück dieses Puzzles zu lösen — sie sind <iframe>s in Form und Funktion sehr ähnlich, außer dass:

• Kommunikation nicht zwischen den <fencedframe>-Inhalten und ihrer einbettenden Site geteilt werden kann.
• Ein <fencedframe> kann auf Cross-Site-Daten zugreifen, aber nur in einem sehr spezifischen Satz von kontrollierten Umständen, die den Datenschutz des Nutzers bewahren.
• Ein <fencedframe> kann nicht frei manipuliert oder seine Daten über reguläre Skripte zugänglich gemacht werden (zum Beispiel durch Lesen oder Setzen der Quell-URL). <fencedframe>-Inhalte können nur über spezifische APIs eingebettet werden.
• Ein <fencedframe> kann nicht auf das DOM des einbettenden Kontexts zugreifen, und umgekehrt kann der einbettende Kontext nicht auf das DOM des <fencedframe> zugreifen.

Weitere Informationen über das Kommunikationsmodell von fenced frames finden Sie im Kommunikationsleitfaden mit eingebetteten Frames.

<fencedframe>s werden von anderen APIs verwendet, um verschiedene Arten von Cross-Site-Inhalten einzubetten oder Daten zu sammeln, und erfüllen unterschiedliche Anwendungsfälle in einer datenschutzfreundlichen Weise. Die meisten davon beruhten zuvor auf Drittanbieter-Cookies oder anderen Mechanismen, die schlecht für den Datenschutz waren.

• Die Shared Storage API bietet Zugriff auf nicht partitionierte Cross-Site-Daten in einer sicheren Umgebung und berechnet und/oder zeigt Ergebnisse in einem <fencedframe> an. Zum Beispiel:
  • Werbetreibende können die Reichweite einer Anzeige messen oder nachfolgende Anzeigen basierend darauf ausliefern, welche die Nutzer bereits auf anderen Websites gesehen haben.
  • Entwickler können A/B-Tests durchführen und Varianten basierend auf einer Gruppe, der ein Nutzer zugewiesen ist, oder basierend darauf zeigen, wie viele Nutzer jede bereits gesehen haben.
  • Unternehmen können die Nutzererfahrung basierend darauf anpassen, was sie auf anderen Websites gesehen haben. Zum Beispiel, wenn sie bereits eine Mitgliedschaft erworben haben, möchten Sie ihnen möglicherweise keine Mitgliedschafts-Anzeigen auf Ihren anderen Seiten anzeigen.
• Die Protected Audience API ermöglicht es Entwicklern, interessengruppenbasiertes Werben zu implementieren, nämlich Remarketing- und benutzerdefinierte Audience-Anwendungsfälle. Sie kann mehrere Gebote für Werbeflächen auswerten und die gewinnende Anzeige in einem <fencedframe> anzeigen.
• Die Private Aggregation API kann Daten aus <fencedframe>s (stammend aus dem Shared Storage oder der Protected Audience API) sammeln und aggregierte Berichte erstellen.

Wie oben erwähnt, kontrollieren Sie die eingebetteten Inhalte in einem <fencedframe> nicht direkt über reguläre Skripte.

Um festzulegen, welche Inhalte in einem <fencedframe> angezeigt werden, erzeugt eine verwendende API (wie Protected Audience oder Shared Storage) ein FencedFrameConfig-Objekt, das dann via JavaScript als Wert der HTMLFencedFrameElement.config-Eigenschaft des <fencedframe> gesetzt wird.

Das folgende Beispiel erhält ein FencedFrameConfig von einer Anzeigenauktion der Protected Audience API, das dann zum Anzeigen der gewinnenden Anzeige in einem <fencedframe> verwendet wird:

const frameConfig = await navigator.runAdAuction({
  // ...auction configuration
  resolveToConfig: true,
});

const frame = document.createElement("fencedframe");
frame.config = frameConfig;

resolveToConfig: true muss in den runAdAuction()-Aufruf übergeben werden, um ein FencedFrameConfig-Objekt zu erhalten. Wenn resolveToConfig auf false gesetzt ist, wird die resultierende Promise in eine opake URN aufgelöst (zum Beispiel urn:uuid:c36973b5-e5d9-de59-e4c4-364f137b3c7a), die nur in einem <iframe> verwendet werden kann.

So oder so speichert der Browser eine URL, die den Zielort der einzubettenden Inhalte enthält — entweder zur opaken URN oder zur internen url-Eigenschaft des FencedFrameConfig gemappt. Der URL-Wert kann von JavaScript, das im einbettenden Kontext ausgeführt wird, nicht gelesen werden.

Innerhalb von Dokumenten, die in <fencedframe>s eingebettet sind, hat JavaScript Zugriff auf eine Window.fence-Eigenschaft, die eine Fence-Instanz für dieses Dokument zurückgibt. Dieses Objekt enthält mehrere speziell für die Fenced Frame API relevante Funktionen. Zum Beispiel bietet Fence.reportEvent() eine Möglichkeit, die Übermittlung von Berichts-Daten über ein Beacon an eine oder mehrere spezifizierte URLs auszulösen, um Anzeigenansichten und -klicks zu melden.

Nur spezifische Funktionen, die für die Verwendung in <fencedframe>s vorgesehen sind, können über festgelegte Berechtigungspolicen aktiviert werden; andere politisch kontrollierte Funktionen sind in diesem Kontext nicht verfügbar. Siehe Berechtigungspolicen, die für fenced frames verfügbar sind für weitere Details.

Ein Sec-Fetch-Dest-Header mit einem Wert von fencedframe wird für alle Anfragen gesetzt, die von innerhalb eines <fencedframe>s kommen, einschließlich Kinder-<iframe>s, die in einem <fencedframe> eingebettet sind.

Sec-Fetch-Dest: fencedframe

Der Server muss einen Supports-Loading-Mode-Response-Header mit einem Wert von fenced-frame für jedes Dokument setzen, das in ein <fencedframe> oder ein <iframe>, das innerhalb eines <fencedframe>s eingebettet ist, geladen werden soll.

Supports-Loading-Mode: fenced-frame

Andere Auswirkungen von fenced frames auf HTTP-Header sind wie folgt:

• User-agent client hints sind innerhalb fenced frames nicht verfügbar, da sie auf Berechtigungspolitik-Delegation basieren, die zum Datenleak verwendet werden könnte.
• Strikte Cross-Origin-Opener-Policy-Einstellungen werden auf neue Browsing-Kontexte, die von innerhalb fenced frames geöffnet werden, durchgesetzt, da diese andernfalls verwendet werden könnten, um Informationen an andere Ursprünge zu leaken. Jedes neue Fenster, das von innerhalb eines fenced frames geöffnet wird, hat rel="noopener" und Cross-Origin-Opener-Policy: same-origin gesetzt, um sicherzustellen, dass Window.opener null zurückgibt und es in seiner eigenen Browsing-Kontextgruppe platziert wird.
• Content-Security-Policy: fenced-frame-src wurde hinzugefügt, um gültige Quellen für verschachtelte Browsing-Kontexte, die in <fencedframe>-Elemente geladen werden, anzugeben.
• Content-Security-Policy: sandbox-benutzerdefinierte Einstellungen können nicht von fenced frames geerbt werden, um Datenschutzprobleme zu mildern. Für das Laden eines fenced frames müssen Sie entweder keine sandbox-CSP festlegen (was die unten genannten Werte impliziert) oder die folgenden Sandbox-Werte angeben:
  • allow-same-origin
  • allow-forms
  • allow-scripts
  • allow-popups
  • allow-popups-to-escape-sandbox
  • allow-top-navigation-by-user-activation

beforeunload und unload-Ereignisse werden auf fenced frames nicht ausgelöst, da sie Informationen in Form eines Seitenlöschungszeitstempels leaken können. Implementierungen zielen darauf ab, potenzielle Datenleaks so weit wie möglich zu eliminieren.

FencedFrameConfig

Repräsentiert die Navigation eines <fencedframe>, d.h. welche Inhalte darin angezeigt werden. Ein FencedFrameConfig wird von einer Quelle wie der Protected Audience API zurückgegeben und als Wert der HTMLFencedFrameElement.config-Eigenschaft gesetzt.

Fence

Enthält mehrere Funktionen, die für die fenced frame-Funktionalität relevant sind. Nur für Dokumente verfügbar, die in einem <fencedframe> eingebettet sind.

HTMLFencedFrameElement

Repräsentiert ein <fencedframe>-Element in JavaScript und bietet Eigenschaften zur Konfiguration.

Navigator.deprecatedReplaceInURN()

Ersetzt angegebene Zeichenfolgen innerhalb der zu einer gegebenen opaken URN oder der internen url-Eigenschaft eines FencedFrameConfig gemappten URL.

Window.fence

Gibt ein Fence-Objekt für den aktuellen Dokumentenkontext zurück. Nur für Dokumente verfügbar, die in einem <fencedframe> eingebettet sind.

Bestimmte API-Funktionen, die FencedFrameConfigs erzeugen, wie Navigator.runAdAuction() (Protected Audience API) und WindowSharedStorage.selectURL() (Shared Storage API), sowie andere Funktionen wie Fence.reportEvent(), erfordern, dass Sie Ihre Website in einem Privacy Sandbox Anmeldeprozess anmelden. Wenn Sie dies nicht tun, schlagen die API-Aufrufe mit einer Konsolenwarnung fehl.

Die folgenden Demos nutzen alle <fencedframe>s:

• Shared Storage API-Demos (die auch einige Beispiele für die Private Aggregation API enthalten)
• Protected Audience API-Demo

• Fenced frames auf developers.google.com
• The Privacy Sandbox auf developers.google.com