Specification review for fenced frames

[domfarolino]

こんにちは TAG-さん!

I'm requesting a TAG review of fenced frames.

Overview of proposal
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 do not suit this purpose since they have many 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.

Delta
Please note that previously we had an early-review TAG design review that had resolved positively: #735 (comment). Since then, our spec has become considerably more fleshed out, and parts of our API surface have changed substantially, captured in https://github.com/WICG/fenced-frame/blob/master/explainer/fenced_frame_config.md that we discussed at last year's TPAC. More or less, we've removed the src attribute from the fenced frame element, in favor or manipulating the element with the new FencedFrameConfig interface, which can be returned from various APIs related to this proposal, such as Protected Audience and Shared Storage.

Details

• Explainer: https://github.com/WICG/fenced-frame/tree/master/explainer
• Specification URL: https://wicg.github.io/fenced-frame/
• Tests: https://github.com/web-platform-tests/wpt/tree/master/fenced-frame
• User research: N/A
• Security and Privacy self-review: https://github.com/WICG/fenced-frame/blob/master/explainer/TAG_Security_Privacy_Questionnaire.md
• Primary contacts (and their relationship to the specification):
  • Dominic Farolino @domfarolino, editor of the spec; Shivani Sharma @shivanigithub (primary explainer author and champion of fenced frames)
• Organization(s)/project(s) driving the specification: Google Chrome Privacy Sandbox
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Review request for Fenced Frames #735
  • Fenced frames mozilla/standards-positions#781
  • Fenced frames WebKit/standards-positions#173
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://github.com/WICG/fenced-frame/issues
  • https://chromestatus.com/feature/5699388062040064
  • https://chromestatus.com/feature/5100526168440832

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Per https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline, Google Chrome is planning to launch the privacy sandbox APIs in Q3 of 2023
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG HTML Standard
• Major unresolved issues with or opposition to this specification: At the time of writing, while most of the spec infrastructure exists, we are currently in the process of spec'ing our integration with the following (though the behavior is already clear from our explainers):
  • Sandboxing flags
  • Private network access
  • Event reporting and its associated Fetch integration
• This work is being funded by: Google Chrome

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify [GitHub usernames]