Fenced Frame API

Eine der Hauptquellen für Datenschutz und Sicherheits-probleme im Web sind Inhalte, die in <iframe>-Elemente eingebettet sind. Historisch gesehen wurden <iframe>s verwendet, um Drittanbieter-Cookies zu setzen, die genutzt werden können, um Informationen zu teilen und Nutzer über Webseiten hinweg zu verfolgen. Zusätzlich kann der in einem <iframe> eingebettete Inhalt mit dem einbettenden Dokument kommunizieren (zum Beispiel mithilfe von Window.postMessage()).

Das einbettende Dokument kann auch Skripte verwenden, um verschiedene Arten von Informationen aus dem <iframe> zu lesen — zum Beispiel können Sie potenziell signifikante Tracking-/Fingerprinting-Daten aus dem eingebetteten URL von 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 Speicherpartitionierung, sodass Cookie-Daten nicht mehr für das Tracking verwendet werden können (zum Beispiel siehe Cookies mit unabhängigem partitioniertem Zustand (CHIPS) oder Firefox-Status-Partitionierung).

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

• Kommunikation nicht zwischen den <fencedframe>-Inhalten und der einbettenden Webseite geteilt werden kann.
• Ein <fencedframe> auf domänenübergreifende Daten zugreifen kann, aber nur in einem sehr spezifischen Satz von kontrollierten Umständen, die die Privatsphäre der Nutzer wahren.
• Ein <fencedframe> nicht frei manipuliert oder seine Daten über reguläres Skripting (zum Beispiel Lesen oder Festlegen der Quell-URL) abgerufen werden können. <fencedframe>-Inhalte können nur über spezifische APIs eingebettet werden.
• Ein <fencedframe> nicht auf das DOM des einbettenden Kontexts zugreifen kann, und umgekehrt.

Für weitere Informationen über das Kommunikationsmodell von Fenced Frames lesen Sie den Leitfaden zu Kommunikation mit eingebetteten Frames.

<fencedframe>s werden von anderen APIs verwendet, um verschiedene Arten von domänenübergreifenden Inhalten einzubetten oder Daten zu sammeln, wodurch unterschiedliche Anwendungsfälle auf privacy-freundliche Weise erfüllt werden. Die meisten dieser Anwendungsfälle haben vorher auf Drittanbieter-Cookies oder andere Mechanismen gesetzt, die der Privatsphäre abträglich waren.

• Die Shared Storage API bietet in einem sicheren Umfeld Zugang zu unpartitionierten domänenübergreifenden Daten, um Ergebnisse zu berechnen und/oder anzuzeigen in einem <fencedframe>. Zum Beispiel:
  • Werbetreibende können die Reichweite einer Anzeige messen oder nachfolgende Anzeigen basierend darauf bedienen, welche Benutzer bereits auf anderen Seiten gesehen haben.
  • Entwickler können A/B-Tests durchführen und Variationen einem Benutzer basierend auf einer Gruppe, der sie zugeordnet sind, oder darauf, wie viele Benutzer jede bereits gesehen haben, zeigen.
  • Unternehmen können die Benutzererfahrung basierend darauf anpassen, was Nutzer auf anderen Seiten gesehen haben. Zum Beispiel, wenn sie bereits eine Mitgliedschaft erworben haben, möchten Sie ihnen vielleicht keine Anzeigen für eine Mitgliedschaftsanmeldung über Ihre anderen Eigenschaften hinweg zeigen.
• Die Protected Audience API erlaubt Entwicklern, interessenbasierte Werbung, nämlich Remarketing und benutzerdefinierte Zielgruppenanwendungsfälle, zu implementieren. Sie kann mehrere Gebote für Werbeflächen bewerten und die Gewinneranzeige in einem <fencedframe> anzeigen.
• Die Private Aggregation API kann Daten aus <fencedframe>s sammeln (stammend von Shared Storage oder der Protected Audience API) und aggregierte Berichte erstellen.

Wie oben erwähnt, kontrollieren Sie den eingebetteten Inhalt eines <fencedframe> nicht direkt über reguläre Skripte.

Um einzurichten, welcher Inhalt in einem <fencedframe> angezeigt wird, generiert eine nutzende 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 eine FencedFrameConfig von einer Anzeigenauktion der Protected Audience API, die dann verwendet wird, um die Gewinneranzeige in einem <fencedframe> anzuzeigen:

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 das resultierende Promise zu einem undurchsichtigen URN (zum Beispiel urn:uuid:c36973b5-e5d9-de59-e4c4-364f137b3c7a) aufgelöst, das nur in einem <iframe> verwendet werden kann.

So oder so speichert der Browser eine URL, die den Zielort des Inhalts einbettet — gemappt auf den undurchsichtigen URN oder die interne url-Eigenschaft des FencedFrameConfig. Der URL-Wert kann von JavaScript, das im einbettenden Kontext ausgeführt wird, nicht gelesen werden.

In 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 Funktionen, die speziell für die Fenced Frame API-Funktionalität relevant sind. Zum Beispiel bietet Fence.reportEvent() eine Möglichkeit, die Übermittlung von Berichts-Daten über ein Beacons an eine oder mehrere spezifizierte URLs auszulösen, um Anzeigenansichten und Klicks zu melden.

Nur spezifische Funktionen, die dazu entwickelt wurden, in <fencedframe>s verwendet zu werden, können über Berechtigungspolitiken, die auf ihnen gesetzt werden, aktiviert werden; andere von der Politik kontrollierte Funktionen sind in diesem Kontext nicht verfügbar. Siehe Verfügbarkeit von Berechtigungspolitiken für Fenced Frames für mehr Details.

Ein Sec-Fetch-Dest-Header mit dem Wert fencedframe wird für alle Anfragen gesetzt, die von innerhalb eines <fencedframe> gestellt werden, einschließlich eingebetteter Kind-<iframe>s innerhalb eines <fencedframe>.

Sec-Fetch-Dest: fencedframe

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

Supports-Loading-Mode: fenced-frame

Andere Effekte von Fenced Frames auf HTTP-Header sind wie folgt:

• User-Agent Client Hints sind innerhalb von Fenced Frames nicht verfügbar, da sie auf Berechtigungspolitik-Delegation beruhen, die zum Datenleak verwendet werden könnte.
• Strenge Cross-Origin-Opener-Policy-Einstellungen werden für neue Browser-Kontexte erzwungen, die von innerhalb eines Fenced Frames geöffnet wurden, da sie ansonsten verwendet werden könnten, um Informationen zu anderen Ursprüngen 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 seine eigene Browsing-Kontextgruppe platziert.
• Content-Security-Policy: fenced-frame-src wurde hinzugefügt, um gültige Quellen für verschachtelte Browsing-Kontexte zu spezifizieren, die in <fencedframe>-Elemente geladen werden.
• Content-Security-Policy: sandbox-benutzerdefinierte Einstellungen können nicht von Fenced Frames geerbt werden, um Datenschutzprobleme abzumildern. Damit ein Fenced Frame geladen werden kann, müssen Sie entweder keinen sandbox-CSP spezifizieren (was die untenstehenden Werte impliziert), oder die folgenden sandbox-Werte spezifizieren:
  • 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 für Fenced Frames nicht ausgelöst, da sie Informationen in Form eines Seitenlöschungszeitstempels leaken können. Implementierungen zielen darauf ab, so viele potenzielle Leaks wie möglich zu eliminieren.

FencedFrameConfig

Repräsentiert die Navigation eines <fencedframe>, d.h. welchen Inhalt es anzeigt. Ein FencedFrameConfig wird von einer Quelle wie der Protected Audience API zurückgegeben und als Wert von HTMLFencedFrameElement.config gesetzt.

Fence

Enthält mehrere Funktionen, die für die Fenced Frame-Funktionalität relevant sind. Verfügbar nur für Dokumente, die innerhalb eines <fencedframe> eingebettet sind.

HTMLFencedFrameElement

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

Navigator.deprecatedReplaceInURN()

Ersetzt spezifizierte Zeichenfolgen innerhalb der gemappten URL, die einem gegebenen undurchsichtigen URN oder der internen url-Eigenschaft eines FencedFrameConfig entspricht.

Window.fence

Gibt eine Fence-Objektinstanz für den aktuellen Dokumentenkontext zurück. Verfügbar nur für Dokumente, die innerhalb eines <fencedframe> eingebettet sind.

Bestimmte API-Funktionen, die FencedFrameConfigs erstellen, wie Navigator.runAdAuction() (Protected Audience API) und WindowSharedStorage.selectURL() (Shared Storage API), sowie andere Funktionen wie Fence.reportEvent(), erfordern die Registrierung Ihrer Seite im Privacy Sandbox Registrierungsprozess. Wenn Sie dies nicht tun, schlagen die API-Aufrufe mit einer Konsolenwarnung fehl.

Die folgenden Demos verwenden alle <fencedframe>s:

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

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