Fenced frames

[domfarolino]

WebKittens

No response

Title of the spec

Fenced frames

URL to the spec

https://wicg.github.io/fenced-frame/

URL to the spec's repository

https://github.com/wicg/fenced-frame

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/fenced-frame/tree/master/explainer

TAG Design Review URL

w3ctag/design-reviews#735

Mozilla standards-positions issue URL

mozilla/standards-positions#781

WebKit Bugzilla URL

No response

Radar URL

No response

Description

Fenced frames is a framing isolation primitive designed for maximum isolation between a frame and its embedder, between which no communication is allowed. Compared with iframes, this entails a similar visual experience but radically different processing model. A fenced frame is therefore suitable for (but not required to) hosting cross-site data which must not be joined across contexts. Please note that while the motivation for fenced frames is in part fueled by FLEDGE and Shared Storage, this proposal is entirely independent and stands on its own, and is to be evaluated as such. It can indeed be used independent of those APIs.

Please note two things:

1. At the time of filing this, the spec is a work in progress
2. Due to the inevitably cross-cutting nature of fenced frames, the explainer layout is vast. Above, we've linked to an explainer folder in our repository where mini explainers for various components of our proposal live, such as integration with general web platform concepts, discussion about existing networking side-channels that our proposal will evolve to cover, and the various use-cases for fenced frames, including the aforementioned FLEDGE and Shared Storage proposals.

/cc @shivanigithub

[annevk]

It can indeed be used independent of those APIs.

If I understand things correctly you need a config-generating API in order to be able to use a fenced frame and those APIs are the only config-generating APIs that exist.

That would mean this is blocked on #158 or #10, neither of which I suspect we'll end up positive on.

Is there another config-generating API or am I misunderstanding the setup?

[shivanigithub]

Thanks @annevk for your question.

At the moment, yes, 158 and 10 are the config-generating APIs. However, going forward we are planning to add additional use cases for fenced frames, one of them being personalized payment buttons : see issue and supporting comment from the ecosystem.

Additionally, the implementation also supports a way of testing fenced frames (issue) without invoking the currently supported config generating APIs. It's behind a flag which when enabled allows creating a FencedFrameConfig object using a url.

Please let us know if there are more follow up questions.

[shivanigithub]

Thanks @annevk for your question.

At the moment, yes, 158 and 10 are the config-generating APIs. However, going forward we are planning to add additional use cases for fenced frames, one of them being personalized payment buttons : see issue and supporting comment from the ecosystem.

As an update, we've created the TAG review for fenced frames accessing local unpartitioned data here, which is the proposal that will support personalized payment buttons use case: w3ctag/design-reviews#975
The use cases explainer document is also updated to include this functionality.