Fenced frames

[shivanigithub]

Introduction

In a web that has its cookies and storage partitioned by top-frame site, there are occasions (such as Interest group based advertising or Conversion Lift Measurements) when it would be useful to display content from different partitions in the same page. This can only be allowed if the documents that contain data from different partitions are isolated from each other such that they're visually composed on the page, but unable to communicate with each other. Iframes cannot be used for this purpose since they have several communication channels with their embedding frame (e.g., postMessage, URLs, size attribute, name attribute, etc.). We propose fenced frames, a new element to embed documents on a page, that explicitly prevents communication between the embedder and the frame.

Overview

The fenced frame enforces a boundary between the embedding page and the embedded document such that user's identity/information visible to the two sites is not able to be joined together and exfiltrated.

The different use cases and their privacy model are discussed as the different fenced frame modes here.

Fenced frames are embedded contexts that have the following characteristics:

• They’re not allowed to communicate with the embedder and vice-versa, except for certain information such as limited size information.
• They may have access to browser-managed, limited unpartitioned user data, for example, turtledove interest group.

The idea is that the fenced frame should not have access to both of the following pieces of information and be able to exfiltrate a join on those:

• User information on the embedding site
  • Accessible via communication channels
• Information from other top-site partitions
  • Accessible via an API (e.g., Turtledove) or via access to unpartitioned storage

A primary use case for a fenced frame is to have read-only access to some other partition’s storage, for example, in Turtledove, it is the interest-based ad to be loaded which was added while visiting another site. The URL of the ad is sufficient to give away the interest group of the user to the embedding site. Therefore the URL for the ad creative is an opaque url in this mode of fenced frame (details here) — which can be used for rendering, but cannot be inspected directly.

Fenced frame API

The proposed fenced frame API is to have a new element type and treat it as a top-level browsing context.
In this approach, a fenced frame behaves as a top-level browsing context that is embedded in another page. This is aligned with the model that a fenced frame is similar to a “tab” since it has minimal communication with the embedding context and is the root of its frame tree and all the frames within the tree can communicate normally with each other.
Having said that, since fenced frames are embedded frames, they also behave like iframes in many ways. For example:

• Browser extensions will access a fenced frame as an iframe, e.g., for ad blocking.
• Browser features like accessibility, developer tools etc. will access a fenced frame like an iframe.

Read the complete Explainer.

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the explainer.

[erik-anderson]

Microsoft is interested in collaborating on this. This is an important primitive needed to support new APIs that will be needed to keep reasonable use cases working after top-level site state partitioning is in place.

[shivanigithub]

Thanks @erik-anderson!
Look forward to collaborating.

[yoavweiss]

The repo is now live on https://github.com/WICG/fenced-frame
Happy incubating!! :)