How Chromium Fenced Frames Isolate Embedded Content

This article provides an overview of fenced frames (<fencedframe>) in the Chromium web browser and explains how they prevent communication between an embedding page and the content embedded within it. Unlike traditional <iframe> elements, which allow data sharing through various APIs and side channels, fenced frames enforce a strict boundary around embedded documents. By exploring the specific mechanisms fenced frames use—such as opaque URLs, blocked messaging APIs, and DOM restrictions—this guide illustrates how Chromium enables websites to display third-party content using cross-site data without allowing the host page and the embedded frame to track the user together.

The Problem with Traditional Iframes

To understand the role of fenced frames, it is necessary to look at the limitations of the standard <iframe>. While iframes isolate the Document Object Model (DOM) of cross-origin sites, they still permit intentional communication between the parent page and the embedded frame.

Developers can pass data across the iframe boundary using:

  • The window.postMessage() method.
  • URL parameters passed into the src attribute of the iframe.
  • Frame dimensions, which can be manipulated to pass binary data.
  • Access to the window.parent or window.top objects.

In a privacy-focused web environment, this communication is a risk. If an embedded frame has access to sensitive user data (such as browsing history for targeted advertising), it could use these communication channels to leak that data back to the embedding page, enabling cross-site user tracking.

How Fenced Frames Stop Communication

Fenced frames were introduced as part of Chromium's Privacy Sandbox initiative specifically to display content derived from sensitive cross-site data while guaranteeing that this data cannot escape to the surrounding page. They achieve this by severing all communication lines between the embedding context and the embedded content.

1. Blocking Messaging APIs

In a fenced frame, the window.postMessage() API is completely disabled between the parent page and the embedded frame. Neither side can send or receive messages from the other. Furthermore, the code inside a fenced frame cannot access window.parent or window.top. To the script running inside the fenced frame, it appears as though it is the top-level document.

2. Enforcing Opaque URLs

With a standard iframe, the embedding page can pass tracking identifiers to the embedded content simply by appending them to the URL (e.g., https://example.com/ad?user_id=123).

Fenced frames prevent this by disallowing the embedding page from setting a standard URL directly. Instead, a fenced frame can only load an "opaque URL" (specifically, a urn:uuid or a FencedFrameConfig object) generated by a secure browser API, such as the Protected Audience API or Shared Storage. The embedding page cannot read the actual destination URL, and it cannot modify it to sneak data into the frame.

3. Preventing Size-Based Side Channels

Even without messaging APIs, clever scripts could communicate by changing the width and height of an iframe to represent data bits, which the embedded content could then read by checking its own window.innerWidth and window.innerHeight.

Fenced frames eliminate this side channel. The size of the fenced frame is restricted to a pre-determined list of allowed dimensions, or it is locked once the content is loaded. If the parent page resizes the fenced frame, the browser simply scales the visual output without notifying the embedded document that a resize occurred. Conversely, the embedded content cannot dictate the size of the frame on the parent page.

4. Network and Storage Isolation

Fenced frames have completely partitioned storage (such as cookies and localStorage). Any data stored by the fenced frame is isolated to that specific instance and clears when the frame is destroyed. Additionally, for certain Privacy Sandbox use cases, fenced frames can have their network access revoked entirely after loading, ensuring that the embedded content cannot communicate with an external server to synchronize data with the embedding page.

Practical Application in Chromium

By combining these restrictions, fenced frames act as a one-way mirror. The user can see and interact with the embedded content, and the browser can use secure internal data to choose what content goes inside the frame. However, the embedding website remains completely blind to what was loaded inside the frame, and the frame remains blind to the identity of the website hosting it. This isolation is the foundational security model that allows Chromium to support personalized content, like advertisements, without allowing third-party tracking.