As in this proposal, the browser should only send the user's most preferred language in the Accept-Language header instead of sending all languages.

For cross-origin iframe subresource requests, it will inherit the Accept-Language header from their parent frame. However, due to fenced frame's privacy guarantee of not allowing communication between the embedding frame and the fenced frame, it indicates that the fenced frame should not get the knowledge of the language.

For the initial prototype, we are going to not share the negotiation language to the fenced frame inner page, which will use the primary language (the first language in user's accept-language list) as default, to monitor how it works.

Previously, we talked about urn:uuids mapping to URLs. But this is a bit imprecise, because there was actually other metadata associated with those URLs, like reporting metadata for FLEDGE reportEvent(), budget metadata for sharedStorage, etc.

This proposal makes this explicit, saying that urn:uuids map to a set of attributes, one of which is the src attribute. And we can add additional attributes like width and height that allow consumer APIs to have more control over and flexibility with information flow for their particular use case. See this document for the full proposal.

Here is an existing issue about how the proposal affects FLEDGE: WICG/turtledove#312

We welcome feedback. 🙂

In Chromium, we're implementing a flag in chrome://flags to enable what we're calling "default mode", which exposes the FencedFrameConfig constructor so you can more-easily use fenced frames without setting up the whole auction ceremony and infrastructure.

We should mention this in the explainer for ease of developer testing and adoption.

/cc @shivanigithub

See #106 (review).

/cc @gtanzer

Hey folks,

The "here" link about opaque URL on line 83 of the README isn't working.

Therefore the URL of the ad is an opaque url (details here) — which can be used for rendering, but cannot be inspected directly.

I believe it should be updated to: https://github.com/shivanigithub/fenced-frame/blob/master/explainer/opaque_src.md

And I recommend updating the sentence for clarity, as there are often 2 URLs associated with an ad (the URL for the creative that loads in the ad slot and the URL that a user can click on, the conversion URL).

Therefore, the URL for the ad creative is an opaque url — which can be used for rendering, but cannot be inspected directly.

We will organize WICG meetings to discuss Fenced Frames related topics as we accumulate topics.

Please enter agenda items as comments/suggestions in this Google Doc.

Please comment/watch/star this issue to make suggestions, or receive notifications regarding meetings.

Hi, thanks for submitting this really interesting proposal. I'm wondering what you envision the UA object would look like? Given that this proposal would need to have something like an opaque URL, what else would need to be obscured?

While playing around the current implementation of Fenced Frames I wanted to be able to programmatically access contents of a Fenced Frame.
Usually, for such automated testing I'd use either Selenium or CDP (Chrome DevTools Protocol) commands for more obscure use cases.
Those ways seems not to be (yet) available for the nightlies.
Selenium bindings seem to treat fenced frame differently from other iframes and won't allow "switching" into the frame.
CDP does not (to the best of my knowledge) expose a way to access the contents of a fenced frame
Yet, the DevTools through the UI allow access to the Fenced Frames contents.

A simplified test case I'd like to run looks like this:

• load test page w/ fenced frame
• run an assertion if the fenced frame exists
• run an assertion on the fenced frame's contents (ie:

Please also have a look at the public tests that we've got published:
RTBHOUSE/chromium-fledge-tests@8b70943

I was wondering if you could point me to the right direction - how can I build an automated test against a Fenced Frame with the current builds at hand?

Currently the HTML Standard mentions that UAs should prompt users to confirm POST resubmissions here but we want a carve-out for fenced frames. We should also check if there are any other places in the standard where resubmission confirmations are mandated, but nothing jumps out to me.

This was discussed in the BlinkOn 16 session for fenced frames, where I asked why iframe was not reused. @domfarolino said that the mutability of attributes makes things more complex (please correct if I got the point wrong), and further said that maybe separate elements instead of <fencedframe mode=...> could make sense to ensure there's no mutation of the mode for the lifetime of the element.

I didn't see an existing issue for this, so filed this one.

Focus for a fenced frame is gated on user activation to prevent a script from pulling focus across a fenced boundary. This behavior should be formalized in the spec.

Design doc: https://docs.google.com/document/d/18W-lq8uexg-vFfq0cxM6IGshwaAInjpdit-jAhhOytI/edit?usp=sharing

We are currently thinking this would exist on Window and be called fencedAPIs. Similar to frameElement it would be null based on runtime logic.

The iframe element supports loading=lazy. It seems to me like it would be useful for fencedframe also.

Possibly the same could be said for some of the other attributes of iframe also: https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element

cc @domfarolino

Thank you for submitting this proposal, sounds really interesting!

As per your explainer - a Fenced Frame is a “top-level browsing context”.

For some use cases it would be great to have the possibility to separate contexts not only from the top level browsing context, but also from children.
One of such cases is PLTD where adequate privacy protection requires for the “ad” frame to be blind of it’s “product” children [see: section “Creative Construction”].

Could you please share your thoughts on nesting of Fenced Frames?

In order to prevent joining information from multiple opaque URLs, or communicating information adaptively into the fenced frame, embedder-initiated navigations should create a fresh slate inside the fenced frame, in particular rerandomizing the storage partitioning nonce.

In HTML, descendant nodes of a fenced frame element represent nothing and that the parser treats anything inside the iframe element as text. Define what happens for fenced frames in this scenario.

Powerful APIs are restricted in fenced frames by some security mechanism like permission policies or sandbox. However, some other APIs that can be communication channels between the embedder and the frame are currently restricted by per-API error handling. We need to update the spec to be consistent with the current implementation.

Target APIs:

• Background Fetch
• Background Sync
• Notification
• Push Messaging
• Payments (Payment Handler)
• Content Index
• Badging

I think the explainer would benefit from a document/section that explains the core differences to sandboxed iframes like the following:

<iframe src=bloburl sandbox="allow-popups allow-top-navigation-by-user-activation" />

Sandboxed frames are treated as a top level origin if they're opaque (!allow-same-origin).

• My understanding is the core difference here (in opaque-ads) is that the frame has an origin but is isolated from the embedding frame.
• https://github.com/WICG/fenced-frame/blob/master/explainer/opaque_src.md#proposed-solution seems like a non serializable URL object that once loaded has a serializable URL inside the frame.

I'm quite interested if the existing primitives of the web can be used rather than these new ones.

Will there be a permissions policy allow attribute, like a regular frame? I personally think there should be, but it could lead to some interesting artifacts (like how the permissions policy from the header wouldn't match the policies visible to the JS context)

Also of interest for Client Hints.

Specify top-level navigation inside opaque-ads fenced frames using the new reserved target "_unfencedTop", which acts like "_top" but ignores fence boundaries.

Decision point: should _unfencedTop act like a normal target name outside opaque-ads fenced frames, or be prohibited?

What will be the implications for 3rd party verification vendors if networking will be disabled by default?
Are you planning on potentially opening up to integrations with such vendors so information like viewability / IVT could be sent out of a fenced iframe?

This is being filed as a follow-up to #74, specifically see the comment https://github.com/WICG/fenced-frame/pull/74/files#r1181069647.

The frame size is frozen at first navigation and coerced to the nearest allowed size.

If the publisher cannot interact with the fence frame, how can the publisher verify that ads are actually being displayed? If they are getting no revenue from this user, they may want to put up a dialog asking the user to either turn off their ad blocker or pay for content before allowing them to see it.

window.close() on a fenced frame shouldn't start the window closing steps.

Chromium had a bug where this was observable via window.closed() but it should likely do nothing an exit early before starting the closing steps.

See https://chromium-review.googlesource.com/c/chromium/src/+/3607497 for context (and a WPT test)

Currently, Fenced Frames disallow all Permission policies for privacy reasons:
https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md

This currently breaks the Attribution Reporting API in Fenced Frames which has the permission policy attribution-reporting:
https://wicg.github.io/attribution-reporting-api/#permission-policy-integration

Using Attribution Reporting API in fenced frames is likely essential for some ads use-cases (e.g. using attribution api with FLEDGE). So we should fix this.

Proposal:

We should allow the Attribution Reporting API in "opaque-ads mode" fenced frames by default, and only allow the creating of "opaque-ads mode" Fenced Frames for a particular origin if the Attribution Reporting API is allowed for that origin.

This limits the ability for sites to use "opaque-ads mode" without the Attribution Reporting API, but that seems manageable, given that ads-mode Fenced Frames probably are all interested in the measurement APIs anyway.

See WICG/turtledove#281 for more context.

Remove fenced frame config mapping when urn iframes are gone (and the construct is no longer necessary)

_unfencedTop: https://chromium-review.googlesource.com/c/chromium/src/+/3763126

Fenced frames only allow potentially trustworthy urls and don't support upgrading insecure requests. The behavior should be documented in the explainer/spec.

Currently iframes are able to observe changes in their intersection with an ancestor element or with a top-level document's viewport via the IntersectionObserver API. Fenced frames cannot observe the IO API because that could be used as a channel of communication between the embedding page and the FF.

But there are dependent use cases e.g. ads require this information for billing, spam detection etc. and we are working towards an alternative to the IO API where the browser provides some new APIs that allow such reporting.

This could be something declarative, similar to the reporting API proposed here or an alternative design.

The design is not finalized at the moment and we are looking to understand design constraints/requirements from consumers like ad tech vendors. Please chime in with your thoughts/inputs for this.

Basically element.scrollIntoView() inside an out-of-viewport iframe will cause the embedder to scroll the iframe into view, where the iframe will continue to scroll its element into view as well. This does not happen in fenced frames because it can be a communication channel, so we'll need to capture this in the spec and also a WPT

The proposal would add yet another sandbox-type of (i)frame, similarly to anonymous iframe.
There are already way too many ways how the behavior of an (i)frame can be controlled, so it would be better to think of coherent way to do it all and not add more and more ways.
I'd start by listing somewhere all the ways the behavior can be currently tweaked, and which behavior exactly and how the new proposals work with all the existing stuff.

(I'm not yet sure whether the platform should have the features Fenced Frame would add, partially because the proposal seems to be still very unclear on many things)

The rationale for this discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=1271408#c22

Fenced frames will be treated as top-level browsing contexts, and the existing spec says "If target is not a child browsing context, then return true." Therefore, no embedder policy would be applied if we literary understand the spec.

We might need to update the spec to tell how the policy should be applied for fenced frames.

When the topmost frame document have the following CSP header:
Content-Security-Policy: sandbox allow-same-origin allow-scripts allow-top-navigation-by-user-activation;

In the Chrome console the following warning appears:
Can't create a fenced frame. A sandboxed document can load fenced frames only when all of the following permissions are set: allow-same-origin, allow-forms, allow-scripts, allow-popups, allow-popups-to-escape-sandbox and allow-top-navigation-by-user-activation.

Latest Chrome stable channel, Privacy Sandbox trial on.
Is this the intended functionality? Why does the fenced frame require all the permissions set for the topmost frame?
it's a lack of security at all for the top frame. So what is the goal then?

Since the initial implementation of fenced frames will allow network access, my understanding is that existing functionality for blocking specific network requests (e.g. declarativeNetRequest in Chrome) should continue to work as it does now.

Even if the embedding page only sees the opaque urn:uuid value, the requests coming from within the fenced frame will use the actual URL values and will be available for content blocking.

Would it be possible to confirm this?

Hi,

reportEvent is designed for Fenced Frame. What is the function's behavior when the JS script is loaded in iFrame? Is it a no-op?

Thanks,
Shaojie

Since moving to w3c's spec-prod to build the spec, there is a spec.html file generated in the github-pages branch, but by default the spec loads index.html (from the old build system). I think to fix this, we'll need to modify the GitHub actions script as described in: https://w3c.github.io/spec-prod/#change-output-location-for-built-files

It's good to clarify how the service worker works in fenced frames.

• Which pages are controlled by the service worker in FF
• What happen if the service worker is registered to the same origin outside of FF
• Which APIs are restricted
• etc

The network partitioning key will be updated to include a nonce for the FF tree in the fetch spec. Similar changes will be required for the storage partitioning key.

Motivation

It’s observed that Payment Service Providers decorate their buttons with card info to increase conversion rate. This card info often includes the network icon and a part of the card number. This depends on the 3p cookie which will get deprecated under the Privacy Sandbox. In order to retain the feature, this issue proposes using Fenced Frame as a work around, and proposes a read-only mode to Fenced Frame to support this use case.

Fig: Example payment button structure

Use outside of payments

The proposal described here does not need to be restricted to payments. Any form of third-party button that wishes to show personalized information to a user, without leaking that information to the host site, could use it. Other examples may include login buttons (e.g., 'Login as Alice') or social media buttons.

High level

A typical design of the button involves:

• the merchant page of origin A, which has the payment button to capture the click.
• an iframe of origin B, shown under the button, displaying the card information.
• the 3p cookie, which provides the iframe with the user id.
• a server of origin B, where the iframe requests the user’s card info.
  Since the 3p cookie will be deprecated, this design will lose a place to store the user id, and thus break the flow.

This issue proposes a new read-only mode for the Fenced Frame and a new design for the button depending on this mode. In our new design, the iframe on the merchant page is replaced with a Fenced Frame in a read-only mode. The read-only mode has a two-state design, which allows Fenced Frame to read 3p cookies without the risk of the cookie leaking out of the frame.

Upon creation, the Fenced Frame starts its life in state one, where the Fenced Frame has network access but no cookie access. The browser requests the main document and the subresources. After the load is finished, the Fenced Frame transitions to state two, where the access to the network is revoked but the 3p cookie is available to read. The Fenced Frame then reads the card info from the cookie and displays it.

Fig: Comparison of two payment button implementations.

Details

How to allow the button to display card numbers only on trusted merchants?

In the past, this was often achieved by attaching the merchant’s url as the “referrer” header to the payment server. Since the Fenced Frame doesn’t have the “referrer”(TODO: quote needed), we propose attaching the “eTLD+1” of the top level (in the frame hierarchy) page as a new “top-level-site” header to the navigation request. Upon receiving this header, the payment server can decide whether to display the card number to this top-level site.

Fenced Frame has no cookie access in state one.

In order to prevent the cookie from leaking to the payment server, the fenced frame’s navigation request should not carry the “Cookie” header.

Fenced Frame should close all output channels in state two.

The fenced frame in state two is allowed to take input from the unpartitioned cookie (read CHIP to distinguish between partitioned and unpartitioned cookie), and its url parameters, but its output channels are revoked to prevent the cookie from being exfiltrated. These channels include:

• write cookie
• send network requests
• postMessage

How the embedder can pass information into the Fenced Frame.

The embedder can pass info into the Fenced Frame through URL parameters. This enables the use cases that the embedder may want to style the payment button to make it consistent with the embedder. Note that postMessage between the Fenced Frame and the embedder in both directions is not allowed.

How the Fenced Frame can display different network icons based on the card.

The payment server can send all of the network icons as subresources of the page, setting them to hidden by default. The 3p cookie should record the card network id. The Fenced Frame can then use the network id to decide which network icon to show.

Known issues

The card info data in the cookie may get stale.

Once the card info data gets written into the unpartitioned cookie, it will need to wait until the user revisits the payment page in 1st party context to be able to update it. This poses the issue that the card info in the cookie may get stale in the meantime. For example, if the user has removed the card from their account somehow, the button would still show the removed card’s info. Users could visit the payment page in 1st party context when they visit the payment page directly, or when they click the button to open the payment popup / payment handler.

Detailed document related to this is here

It’s great to read through the detailed privacy considerations, thank you!

In some applications of Fenced Frames, like Turtledove, it is important to ensure that the content renders in a deterministic and reproducible way.

The proposal could benefit if, we could disallow Fenced Frames from accessing time related javascript API’s like Date, for use cases related to interest based advertising.
Both the original Turtledove proposal as well as extensions like our own OBTD could protect the user better with deterministic and reproducible outcomes

What do you think?

Currently, Fenced Frames disallow all Permission policies for privacy reasons.

Shared Storage is going to add its permissions policy as well. The following Shared Storage use cases will benefit from being allowed from inside the Fenced Frame:

• A/B Experiments - Shared storage allows for assigning experiment groups to users and selecting between up to 8 different urls to display to a user. The URL selection is done from a javascript worklet, and the selected URL is rendered by a fenced frame. However, to measure the effectiveness of the experiment, the organization needs to be able to send a report to an aggregation service. It is important to send the report from within the fenced frame, and not from within the JS worklet, as orgs will want to confirm the content successfully loaded prior to sending a report, which is particularly important if the content is an ad a brand is paying for. 
• Multiple, nested url selection calls - while likely a future use case, there is a potential need to allow multiple organizations to utilize shared storage to prevent one entity further upstream (say for example in an ad decision chain) from preventing other organizations from utilizing shared storage (we will need to ensure we are “budgeting” properly for entropy leakage, hence why it is a future/under consideration use case). It is likely that if an SSP uses some information from shared storage to then render a URL within a fenced frame pointing to a DSP, that the DSP would be unable to reference information in its own shared storage to further refine the ad decision. 

"Modes/Use cases of fenced frames" link on https://github.com/WICG/fenced-frame is broken

User activation notification/consumption never crosses fence boundaries, i.e. it behaves as if the fenced frame is in a separate frame tree.

Currently, I am getting an error The "shared-storage" Permissions Policy denied the method on window.sharedStorage when a Shared Storage value is about to be set from within a Fenced Frame.
The documentation, Permission policy for API backed fenced frames
states,

the OT recently added an exception for attribution-reporting and shared-storage APIs. It allows a fenced frame to be navigated successfully only if the embedding frame has not opted out from these features and enables it for the fenced frame by default (without an allow attribute).

My understanding is that although permission policies are disabled for Fenced Frames during the Origin Trials, it is supposed to allow Shared Storage usage from within a Fenced Frame by default.
Is my understanding that Shared Storage values can be set currently from within a Fenced Frame incorrect? Or should I check if I have explicitly opted out from shared-storage usage?

There are quite a few cases where an opaque ad won't be allowed to load. Developers will have an API to let them know if fenced frame creation will fail for any reason, which should be put in the spec.