Fenced Frame API

Eine Hauptquelle von Datenschutz- und Sicherheitsproblemen im Web ist das Einbetten von Inhalten in <iframe>-Elementen. Historisch gesehen wurden <iframe>s verwendet, um Cookies von Drittanbietern zu setzen, die zum Teilen von Informationen und zur Nachverfolgung von Nutzern über verschiedene Websites hinweg genutzt werden können. Zusätzlich können Inhalte, die in einem <iframe> eingebettet sind, mit dem einbettenden Dokument kommunizieren (zum Beispiel mittels Window.postMessage()).

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

Die meisten modernen Browser arbeiten an Mechanismen zur Partitionierung des Speichers, sodass Cookie-Daten nicht mehr für das Tracking verwendet werden können (zum Beispiel siehe Cookies with Independent Partitioned State (CHIPS) oder Firefox State Partitioning).

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

• Die Kommunikation kann nicht zwischen den <fencedframe>-Inhalten und ihrer einbettenden Website geteilt werden.
• Ein <fencedframe> kann auf standortübergreifende Daten zugreifen, jedoch nur unter einer sehr spezifischen Reihe von kontrollierten Umständen, die die Privatsphäre der Nutzer wahren.
• Ein <fencedframe> kann nicht frei manipuliert oder seine Daten über reguläre Skripting-Methoden (zum Beispiel das Lesen oder Setzen der Quell-URL) abgerufen werden. Inhalte im <fencedframe> können nur über spezifische APIs eingebettet werden.
• Ein <fencedframe> kann nicht auf das DOM des einbettenden Kontexts zugreifen, und der einbettende Kontext kann auch nicht auf das DOM des <fencedframe> zugreifen.

Für weitere Informationen über das Kommunikationsmodell der fenced frames lesen Sie den Leitfaden zur Kommunikation mit eingebetteten Frames.

<fencedframe>s werden von anderen APIs verwendet, um verschiedene Arten von standortübergreifenden Inhalten einzubetten oder Daten zu sammeln und damit unterschiedliche Anwendungsfälle auf datenschutzbewahrende Weise zu erfüllen. Die meisten von ihnen haben sich zuvor auf Cookies von Drittanbietern oder andere datenschutzgefährdende Mechanismen verlassen.

• Die Shared Storage API bietet Zugriff auf nicht partitionierte, standortübergreifende Daten in einer sicheren Umgebung, indem Ergebnisse in einem <fencedframe> berechnet und/oder angezeigt werden. Zum Beispiel:
  • Werbetreibende können die Reichweite einer Anzeige messen oder nachfolgende Anzeigen basierend darauf ausliefern, welche Nutzer bereits auf anderen Websites gesehen wurden.
  • Entwickler können A/B-Tests durchführen, indem sie Variationen einem Nutzer basierend auf einer Gruppe zeigen, der sie zugeordnet sind, oder basierend darauf, wie viele Nutzer jede Variation 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öchte Sie ihnen vielleicht keine Mitgliedschaftsanzeigen mehr auf anderen Ihrer Dienste zeigen.
• Die Protected Audience API ermöglicht Entwicklern die Implementierung von interessengruppenbasierter Werbung, nämlich Remarketing und benutzerdefinierte Zielgruppennutzung. Sie kann mehrere Gebote für Werbeplatzierungen bewerten und die gewinnende Anzeige in einem <fencedframe> anzeigen.
• Die Private Aggregation API kann Daten aus <fencedframe>s sammeln (ausgehend vom gemeinsamen Speicher oder der Protected Audience API) und aggregierte Berichte erstellen.

Wie oben erwähnt, kontrollieren Sie den Inhalt, der in einem <fencedframe> eingebettet ist, nicht direkt über reguläre Skripte.

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

Das folgende Beispiel erhält ein FencedFrameConfig aus einer Anzeigenauktion der Protected Audience API, das dann verwendet wird, um die gewinnende Anzeige 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.

In beiden Fällen speichert der Browser eine URL, die den Zielort des einzubettenden Inhalts enthält – gemappt auf den undurchsichtigen URN oder die interne url-Eigenschaft des FencedFrameConfig. Der URL-Wert kann nicht durch JavaScript, das im einbettenden Kontext ausgeführt wird, 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 Funktionen, die speziell relevant für die Funktionalität der Fenced Frame API sind. Zum Beispiel bietet Fence.reportEvent() eine Möglichkeit, das Einreichen von Berichtsdaten ü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 entwickelt wurden, können über Berechtigungspolitiken, die auf ihnen festgelegt sind, aktiviert werden; andere politisch kontrollierte Funktionen sind in diesem Kontext nicht verfügbar. Siehe Berechtigungspolitiken, 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 aus einem <fencedframe> heraus gemacht werden, einschließlich eingebetteter Kind-<iframe>s innerhalb eines <fencedframe>.

Sec-Fetch-Dest: fencedframe

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

Supports-Loading-Mode: fenced-frame

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

• User-Agent-Client-Hinweise sind innerhalb von fenced frames nicht verfügbar, da sie sich auf Berechtigungspolitik-Delegation stützen, was zur Datenweitergabe genutzt werden könnte.
• Strikte Cross-Origin-Opener-Policy-Einstellungen werden auf neue Browsing-Kontexte durchgesetzt, die aus innerhalb von fenced frames geöffnet werden, sonst könnten sie genutzt werden, um Informationen an andere Ursprünge weiterzugeben. Jedes neue Fenster, das aus einem fenced frame heraus geöffnet wird, hat rel="noopener" und Cross-Origin-Opener-Policy: same-origin gesetzt, um sicherzustellen, dass Window.opener null zurückgibt und platziert es in seiner eigenen Browsing-Kontext-Gruppe.
• Content-Security-Policy: fenced-frame-src wurde hinzugefügt, um gültige Quellen für verschachtelte Browsing-Kontexte, die in <fencedframe>-Elemente geladen werden, zu spezifizieren.
• Content-Security-Policy: sandbox-benutzerdefinierte Einstellungen können nicht von fenced frames geerbt werden, um Datenschutzprobleme zu mildern. Für ein fenced frame, das geladen werden soll, müssen Sie keine sandbox-CSP angeben (was die untenstehenden 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 Events werden auf fenced frames nicht ausgelöst, da sie Informationen in Form eines Seitendeletionszeitstempels weitergeben können. Implementierungen streben danach, so viele potenzielle Lecks wie möglich zu eliminieren.

FencedFrameConfig

Repräsentiert die Navigation eines <fencedframe>, das heißt, welcher Inhalt darin angezeigt wird. Ein FencedFrameConfig wird aus einer Quelle wie der Protected Audience API zurückgegeben und als Wert der HTMLFencedFrameElement.config festgelegt.

Fence

Enthält mehrere Funktionen, die relevant für die Funktionalität von fenced frames sind. Steht nur Dokumenten zur Verfügung, die innerhalb eines <fencedframe>s eingebettet sind.

HTMLFencedFrameElement

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

Navigator.deprecatedReplaceInURN()

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

Window.fence

Gibt ein Fence-Objektbeispiel für den aktuellen Dokumentkontext zurück. Ist nur für Dokumente verfügbar, die innerhalb eines <fencedframe>s 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, dass Sie Ihre Website in einen Privacy-Sandbox-Einschreibungsprozess einschreiben. Wenn Sie dies nicht tun, werden die API-Aufrufe mit einer Konsolen-Meldung fehlschlagen.

Die folgenden Demos verwenden alle <fencedframe>s:

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

Ein Browseranbieter opponiert dieser Spezifikation. Bekannte Standardspositionen sind wie folgt:

• Mozilla (Firefox): Negativ

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