LGTM2 On Wed, Jun 21, 2023 at 11:46 AM Chris Harrelson <chris...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8BwtxFW9OdHqOOVpLwr7ohvUQ6UUvWzSCjsTRse%3DHV1A%40mail.gmail.com?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/CAFUtAY-mX-ziUw%3DFnbRsiHvBT1i8GJucE-iYeFTH15m-b05hGg%40mail.gmail.com.
