Intent to Experiment: Fenced frames

1,821 views
Skip to first unread message

Shivani Sharma

unread,
Apr 29, 2022, 6:31:49 PM4/29/22
to blink-dev, Josh Karlin, Dominic Farolino

Contact emails

shiva...@chromium.org, d...@chromium.org, jka...@chromium.org


Explainer

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


Specification

https://wicg.github.io/fenced-frame/ (a rough shell at this point)


Summary

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 several communication channels with their embedding frame (e.g., postMessage, URLs, size 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.

 

This intent to experiment is scoped to the two initial modes of fenced frames:

https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#default-mode

 

Blink component

Blink>FencedFrames


TAG review

https://github.com/w3ctag/design-reviews/issues/735


TAG review status

Pending


Risks


Interoperability


Gecko: No signal

WebKit: No signal


Edge: Edge is also exploring interest group based advertising, namely with the PARAKEET proposal.  PARAKEET, similar to TURTLEDOVE, relies on fenced frames for rendering the ad in the opaque-ads mode and are interested in collaborating (comment on WICG issue).


Web developers: Fenced frames (specifically the opaque-ads mode) are designed as a requirement for certain Privacy Sandbox APIs, like FLEDGE. There is significant interest in FLEDGE from many web advertising technology developers. WICG FLEDGE calls are well attended and fenced frames have sometimes been discussed with developers as part of those calls.


Compatibility risks

Fenced frames do not deprecate or change existing web behavior, so there should be no compatibility risk.

From other browsers' perspective, there may be medium-term interoperability risk with regards to having an architecture that enables the separation of fenced frames from the embedding page. Chrome's fenced frame design is based on a significant architecture project that makes this possible (Multiple Page Architecture).

(Note that there have been discussions with other browsers for fenced frames in the context of other use cases like unpartitioned storage access e.g. this issue, but that is not applicable to this fenced frame mode.)

 

              Security

Security considerations are detailed here.


Privacy

Privacy considerations are detailed here.


Browser Performance

In the current implementation, there isn’t a significant performance concern but we will be doing performance analysis when we do implement enhanced process isolation for fenced frames as per https://github.com/WICG/fenced-frame/blob/master/explainer/process_isolation.md


Goals for experimentation

We hope to get feedback from ad tech companies on their usage of fenced frames as part of FLEDGE.  


Experiment Configuration

The origin trial for this experiment will be shared among various Privacy Sandbox APIs. Our goal is to allow for coordinated experiments to be run by multiple different sites, across multiple APIs in one OT.


This shared origin trial, Privacy Sandbox Ads APIs, will be a third-party origin trial. To ensure that developers can run coordinated experiments without concern for exceeding page load usage thresholds, this Origin Trial will be available for a subset of users by default. Therefore, it will be necessary to feature test to ensure that the API surface you want to use is available after providing your OT token. A second advantage of this configuration is that different experimenters will experiment with the same users, which enables coordination for APIs like FLEDGE across third parties.


Ongoing technical constraints

The following mitigations will not be part of the initial OT and will be addressed in upcoming milestones:

  • Intersection observer will be supported just like in iframes initially in the OT but will eventually be replaced with a more private API. This is further described in the explainer here.

  • While cookies will be partitioned in a unique and ephemeral partition from the start of the OT, other storage APIs as well as communication and service worker APIs will be partitioned later as described in the explainer here

  • Network side channel mitigations as described in the explainer here.

  • See ongoing technical constraints for more challenges like covert channels. 

 

Debuggability

Fenced frames are supported in developer tools, similar to iframes.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Is this feature fully tested by web-platform-tests?

Yes.


Flag name

FencedFrames

Also requires “NoncedPartitionedCookies” 


Requires code in //chrome?

No. 


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1208744

https://bugs.chromium.org/p/chromium/issues/detail?id=1171739


Estimated milestones

We hope to start the Origin Trial sometime during M102 beta. 


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5699388062040064


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ


Yoav Weiss

unread,
May 2, 2022, 7:27:59 AM5/2/22
to Shivani Sharma, blink-dev, Josh Karlin, Dominic Farolino
On Sat, Apr 30, 2022 at 12:31 AM Shivani Sharma <shiva...@chromium.org> wrote:

Contact emails

shiva...@chromium.org, d...@chromium.org, jka...@chromium.org


Explainer

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


Specification

https://wicg.github.io/fenced-frame/ (a rough shell at this point)


Summary

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 several communication channels with their embedding frame (e.g., postMessage, URLs, size 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.

 

This intent to experiment is scoped to the two initial modes of fenced frames:

https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#default-mode

 

Blink component

Blink>FencedFrames


TAG review

https://github.com/w3ctag/design-reviews/issues/735


TAG review status

Pending


Risks


Interoperability


Gecko: No signal

WebKit: No signal


Might be good to ask for signals.
Is the current intent to run it till M104 (inclusive), similar to other intents under this OT umbrella?
  

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5699388062040064


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0-Htb44ezkojydCMKEWM9YnXL0Zc%2BGVE9xLO68csf8tJw%40mail.gmail.com.

Shivani Sharma

unread,
May 2, 2022, 2:48:53 PM5/2/22
to Yoav Weiss, blink-dev, Josh Karlin, Dominic Farolino
Thanks Yoav!

Sounds good. @Dominic Farolino is planning to reach out to the relevant mailing groups for both the browsers and will update here once we have reached out.  
We hope to start the Origin Trial sometime during M102 beta. We plan to continue the Origin Trial until at least M105 to give developers time to test the API and provide feedback. Once we are confident that the APIs are working properly, we will transition the OT from beta to stable channel. 

Mike West

unread,
May 4, 2022, 9:11:08 AM5/4/22
to blink-dev, Shivani Sharma, blink-dev, Josh Karlin, Dominic Farolino, Yoav Weiss
FLEDGE was approved for experimentation only through M104. Given the tight relationship between FLEDGE and Fenced Frames, it makes sense to me for them to have the same timeline. Is there a scenario in which you think it makes sense for developers to want to experiment with Fenced Frames in the absence of APIs like FLEDGE that depend upon them?

-mike
 
  

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5699388062040064


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Shivani Sharma

unread,
May 4, 2022, 10:15:17 AM5/4/22
to Mike West, blink-dev, Josh Karlin, Dominic Farolino, Yoav Weiss
Sounds good to align with FLEDGE timeline since at the moment that is the only API which is in OT that requires fenced frames opaque-ads mode: 102 through 104 inclusive.  

-mike
 
  

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5699388062040064


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
May 4, 2022, 11:54:51 AM5/4/22
to Shivani Sharma, Mike West, blink-dev, Josh Karlin, Dominic Farolino, Yoav Weiss
Ok. LGTM to experiment from M102 to M104.

Reply all
Reply to author
Forward
0 new messages