Contact emails shivani...@chromium.org , d...@chromium.org, jkar...@chromium.org
Explainer https://github.com/WICG/fenced-frame/tree/master/explainer Spec https://wicg.github.io/fenced-frame/ Summary In a web that has its cookies and storage partitioned by top-frame sites, there are occasions (such as Interest group based advertising <https://github.com/WICG/turtledove> or Consistent A/B experiments across sites <https://github.com/WICG/shared-storage#simple-example-consistent-ab-experiments-across-sites>) when it would be useful to display content based on inputs from different partitions on the same page. For such use cases, it would be ideal from a privacy perspective, 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. At the time of this I2S, fenced frames can be created and navigated using the `FencedFrameConfig` object returned from the following APIs: - Protected Audience API runAdAuction() (code snippet <https://github.com/WICG/turtledove/blob/main/FLEDGE.md#:~:text=const%20result%20%3D%20await,fencedFrame.config%20%3D%20result%3B> ) - Shared Storage API selectUrl() (code snippet <https://github.com/WICG/shared-storage#:~:text=const%20frameConfig%20%3D%20await%20window.sharedStorage.selectURL(%0A%20%20%27creative%2Dselection%2Dby%2Dfrequency%27%2C%20%0A%20%20ads.urls%2C%20%0A%20%20%7B%20%0A%20%20%20%20data%3A%20%7B%20%0A%20%20%20%20%20%20campaignId%3A%20ads.campaignId%20%0A%20%20%20%20%7D%2C%0A%20%20%20%20resolveToConfig%3A%20true%2C%0A%20%20%7D)%3B%0A%0A//%20Render%20the%20frame%0Adocument.getElementById(%27my%2Dfenced%2Dframe%27).config%20%3D%20frameConfig%3B> ) (For future use cases of fenced frames, separate I2S would be sent.) Blink component Blink>FencedFrames <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFencedFrames> TAG reviews and status early design review <https://github.com/w3ctag/design-reviews/issues/735#issuecomment-1226822420> (status: complete), specification review <https://github.com/w3ctag/design-reviews/issues/838> (status: pending) Link to Origin Trial feedback summary Fenced frames are part of the unified Privacy Sandbox OT and are an integral part of the privacy design of “Protected Audience” and “Shared Storage” APIs. For easier adoption, these consumer APIs don’t currently enforce the use of fenced frames, but we have had multiple testers testing these APIs with fenced frames. We’ve incorporated feedback and feature requests from those testers, some examples are given below: - Attribution reporting API support for event-level reporting (explainer <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#support-for-attribution-reporting> ), - reserved.top_navigation support for component ads (explainer <https://github.com/WICG/turtledove/pull/541>), - Dev tools integration with reportEvent beacons, - etc. Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Supported on all the above platforms except Android WebView. Demo link https://browsing-context.glitch.me/host-fenced-frame.html Debuggability - DevTools are supported for fenced frames similar to how they are supported for iframes. - DevTools’ network tab will include the beacons sent from a fenced frame as part of fenced frames ads reporting <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md> . - We also support a developers testing mode behind a non-web-exposed flag where a `FencedFrameConfig` can be created with a plain url, to enable testing fenced frames without invoking the above mentioned consumer APIs. At the moment, this is at chrome://flags/#enable-fenced-frames-developer-mode, but we will likely move it to DevTools in the future. Risks Interoperability Gecko: https://github.com/mozilla/standards-positions/issues/781 WebKit: https://github.com/WebKit/standards-positions/issues/173 Neutral though we haven’t received formal positions on the above issues yet. If these browsers implement the use cases that fenced frames support e.g. interest based advertising or future fenced frame use cases like personalized payment buttons <https://github.com/WICG/fenced-frame/issues/15> then it’s more likely for them to implement fenced frames. Edge: Positive signal. Edge is also exploring interest group based advertising, namely with the PARAKEET proposal <https://github.com/WICG/privacy-preserving-ads/blob/main/Parakeet.md>. PARAKEET, similar to “Protected Audience”, relies on fenced frames for rendering the ad and are interested in collaborating (comment on WICG issue <https://github.com/WICG/proposals/issues/52#issuecomment-1063481655>). Web developers: Fenced frames are designed as a requirement for certain Privacy Sandbox APIs, like Protected Audience API <https://github.com/WICG/turtledove/blob/main/FLEDGE.md#4-browsers-render-the-winning-ad>. There is significant interest in FLEDGE from many web developers. WICG FLEDGE calls <https://github.com/WICG/turtledove/issues/88> are well attended and fenced frames have often been discussed with developers as part of those calls and on github issues on the “Protected Audience” WICG repository. Fenced frames have a stricter information flow as compared to iframes and no information flows from the embedding context to the fenced frame or vice versa. This makes it a challenge to have traditional methods of measurement and spam detection to be applied as they do in iframes. In the short term, fenced frames do allow event level reporting <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md> but eventually new methods like aggregate reporting would be required and that’s a long-term challenge for the industry to adapt to. Compatibility risks Fenced frames do not deprecate or change existing web behavior, so there should be no compatibility risk. Activation There are no concerns for developers to take advantage of this feature immediately, as-is. Developers can either test fenced frames in conjunction with the consumer APIs or separately using the test-only mode (GH issue <https://github.com/WICG/fenced-frame/issues/94>). Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? Link to test suite results from wpt.fyi. Yes Tests: https://github.com/web-platform-tests/wpt/tree/master/fenced-frame Results: https://wpt.fyi/results/fenced-frame?label=experimental&label=master&aligned Anticipated spec changes The following are ongoing technical considerations and will be addressed in upcoming milestones accompanied by separate I2Ss and spec changes. These will be breaking changes and should be anticipated by developers: - Currently, the network is unrestricted in fenced frames but will eventually be addressed to mitigate the network side channel leak. The leak is described in the explainer here <https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md> . - Currently, intersection observer API is supported just like in iframes but will eventually either be replaced with a more private solution or the outflow of information from the FF will be restricted (see point above). This is further described in the explainer here <https://github.com/WICG/fenced-frame/blob/master/explainer/integration_with_web_platform.md#viewability> . - Currently event-level reporting is allowed with information from various contexts as per the explainer here <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md>. In the future, the event level reporting surface `window.fence.reportEvent` will either change in behavior to become more privacy-preserving or will be a no-op and not send out a beacon. This won’t be a breaking change for the script on the page but impacts the ecosystem since reporting is impacted. 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 Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ Intent to extend origin trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp093_yvrvYDigFOZVdzmBN_cW0y6xLbthQHjNQY5K%2BjVgw%40mail.gmail.com.
