LGTM1 Thank you for thoroughly working through all the design and specification steps for this feature. Glad to see some positive signals from the TAG about the fundamental design in particular.
I agree that Alex's comments are good to answer and investigate for future work, but also they aren't blocking this intent. (Confirmed this interpretation with Alex.) On Wed, Jun 21, 2023 at 8:42 AM Alex Russell <slightly...@chromium.org> wrote: > Hey all, > > I'm not going to weigh in on if this should ship right now, but I want to > express some disappointment that this design seems to be launching without > a way to load from a bundle and a flag for removing the ability to load > from the network. We have a lot of use-cases that would benefit from a > version of <fencedframe> that was more capable and generic, rather than > being narrowly targeted at an ads use-case. > > What's the prognosis for fixing those deficiencies in near-future work? > > Best, > > Alex > > On Tuesday, June 20, 2023 at 5:07:07 AM UTC-7 Shivani Sharma wrote: > >> 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/80c0731a-6fab-43b8-9117-c445525de51dn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/80c0731a-6fab-43b8-9117-c445525de51dn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw8BwtxFW9OdHqOOVpLwr7ohvUQ6UUvWzSCjsTRse%3DHV1A%40mail.gmail.com.
