Wiki · Concept · Last reviewed June 25, 2026

Fenced Frame API

The Fenced Frame API is a browser proposal for embedding cross-site documents behind a boundary that restricts communication between the embedded content and the page around it.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, fenced frames, ad tech, embedded content, web governance

Definition

The Fenced Frame API is a web-platform proposal for embedding a document in a way that prevents ordinary communication between the embedded document and its embedder. The WICG draft says the fenced frame enforces a boundary so user data visible to two sites cannot be joined together. MDN describes the <fencedframe> element as similar to an <iframe>, except that communication, scripting access, and cross-site data access are restricted.

The motivating problem is not generic embedding; ordinary iframes already do that. The problem is rendering content chosen through privacy-sensitive APIs, such as ad auctions or shared-storage URL selection, without letting the surrounding page learn the sensitive choice or reshape the embedded environment. Google Privacy Sandbox frames fenced frames as a way to allow selected content to use cross-site data without sharing that data with the embedding context.

Fenced frames are not a universal privacy shield. MDN marks the API as limited availability and experimental, and notes a negative Mozilla standards position. The WICG document is a Community Group Report rather than a W3C Standard. Current claims should therefore identify browser support, enrollment requirements, and the API that generated the frame configuration.

Mechanism

The element is <fencedframe>, but the content is normally set through a FencedFrameConfig rather than a normal script-controlled URL. MDN says FencedFrameConfig objects cannot be constructed manually in JavaScript; they are returned by sources such as the Protected Audience API and assigned to HTMLFencedFrameElement.config. The WICG draft says config-generating APIs include Protected Audience and Shared Storage.

The boundary blocks direct DOM access in both directions. MDN says the embedding context cannot access the fenced frame's DOM, the fenced frame cannot access the embedder's DOM, and the frame cannot be manipulated through ordinary scripting such as reading or setting the source URL. Google Privacy Sandbox also distinguishes normal URLs from browser-managed opaque sources such as urn:uuid, depending on use case.

Several headers and reporting surfaces matter. Google Privacy Sandbox says requests from fenced frames use Sec-Fetch-Dest: fencedframe, and documents loaded in a fenced frame must return Supports-Loading-Mode: fenced-frame. MDN also describes Fence.reportEvent() for reporting ad views and clicks, and says some config-generating features and reporting calls require Privacy Sandbox enrollment.

Agent Context

For AI Browsers and Computer Use, fenced frames matter because an agent may see and interact with embedded content while being unable to inspect why that content appeared. A shopping agent might see an ad, offer, or payment module whose selection came from a browser-managed auction or shared-storage operation. The surrounding DOM may not reveal the winning ad URL or relevant cross-site data.

Agent logs should therefore avoid treating visible fenced-frame content as ordinary page content. The record should distinguish the top-level task, the embedding site, the config-generating API, the visible interaction, and any report events. A fenced frame boundary can protect some data flows while also hiding the reasons for a rendered choice from both the user and the agent operator.

Governance Use

A serious deployment record should name the embedding site, embedded origin, config-generating API, whether the input was a FencedFrameConfig or opaque URN, response headers, report-event destinations, enrollment status, sandbox and allow attributes, and user-facing fallback. It should also state the purpose: Protected Audience rendering, Shared Storage URL selection, ad-event reporting, conversion-lift measurement, or another specific flow.

The API belongs near Shared Storage API, Attribution Reporting API, Private State Tokens, Real-Time Bidding, and Data Minimization. Those pages separate storage, measurement, trust signals, ad markets, and collection limits.

Limits

Fenced frames are not consent, auditability, or a complete anti-tracking system. They restrict communication channels between two contexts, but the surrounding advertising or measurement system still decides what data is collected, what auctions run, what reporting events fire, and what summaries are produced. A privacy claim about the frame does not settle the legitimacy of the business process around it.

Debugging and accountability are also harder when the URL, winning ad, or selection logic is intentionally hidden from the embedder. Reviewers should ask who can inspect the generated config, who receives beacons, what user controls exist, and how accessibility, fraud review, security monitoring, and agent oversight work when ordinary page inspection is limited.

Review Record

Source Discipline

Claims about the core boundary, fencedframe element, FencedFrameConfig, config mappings, and draft status should cite the WICG report. Claims about limited availability, experimental status, DOM restrictions, enrollment, interfaces, and MDN element behavior should cite MDN. Claims about opaque sources, headers, Shared Storage context, and Privacy Sandbox implementation framing should cite Google Privacy Sandbox.

Spiralist Reading

Spiralism reads fenced frames as a lesson in sealed presentation. A wall between page and frame can reduce one kind of leakage, but it also creates a chamber where the reason for what appears may be harder to contest. The boundary is useful only if the system around it remains answerable.

Sources

Return to Wiki