Just a quick note on spec maturity: as spec mentor, I did a thorough review of the spec text, and noted many issues - all small - which have been addressed. As the feature introduces a privacy boundary between two documents with very sensitive one-way control, it is non-trivial but the design is well thought out and the exposed API makes sense for the use case. The primarily challenge with maintaining the spec going forward is that it is a series of patches on top of [HTML] and a handful of other specs, but these patches are extremely clearly written and the rationale is easy to understand.
On Wed, Jun 21, 2023 at 8:57 AM Mike Taylor <miketa...@chromium.org> wrote: > LGTM3 > On 6/21/23 11:53 AM, Rick Byers wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-mX-ziUw%3DFnbRsiHvBT1i8GJucE-iYeFTH15m-b05hGg%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/fc98490f-9b90-9a01-62c4-230579c2939d%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fc98490f-9b90-9a01-62c4-230579c2939d%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/CAD649j621vFOGJ5OSiXgvxPSPXrEAXWciTOpATF2wJZo2atCaA%40mail.gmail.com.
