Thanks Yoav! On Mon, May 2, 2022 at 7:27 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Sat, Apr 30, 2022 at 12:31 AM Shivani Sharma <shivani...@chromium.org> > wrote: > >> Contact emails >> >> shivani...@chromium.org, d...@chromium.org, jkar...@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 >> <https://github.com/WICG/turtledove> or Conversion Lift Measurements >> <https://github.com/w3c/web-advertising/blob/main/support_for_advertising_use_cases.md#conversion-lift-measurement>) >> 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: >> >> - >> >> Opaque-ads: >> >> https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#opaque-ads >> - >> >> Default: >> >> >> https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#default-mode >> >> >> Blink component >> >> Blink>FencedFrames >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFencedFrames> >> >> 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. > Sounds good. @Dominic Farolino <d...@chromium.org> is planning to reach out to the relevant mailing groups for both the browsers and will update here once we have reached out. > > >> >> Edge: 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 TURTLEDOVE, relies on fenced frames for rendering the >> ad in the opaque-ads mode and are interested in collaborating (comment >> on WICG issue >> <https://github.com/WICG/proposals/issues/52#issuecomment-1063481655>). >> >> Web developers: Fenced frames (specifically the opaque-ads mode) are >> designed as a requirement for certain Privacy Sandbox APIs, like FLEDGE >> <https://github.com/WICG/turtledove/blob/main/FLEDGE.md#4-browsers-render-the-winning-ad>. >> There is significant interest in FLEDGE from many web advertising >> technology developers. WICG FLEDGE calls >> <https://github.com/WICG/turtledove/issues/88> 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 >> <https://docs.google.com/document/d/1NginQ8k0w3znuwTiJ5qjYmBKgZDekvEPC22q0I4swxQ/edit?usp=sharing> >> ). >> >> (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 <https://github.com/privacycg/storage-access/issues/41>, >> but that is not applicable to this fenced frame mode.) >> >> >> >> Security >> >> Security considerations >> <https://github.com/WICG/turtledove/blob/main/Original-TURTLEDOVE.md#security-considerations>are >> detailed here >> <https://github.com/WICG/fenced-frame/tree/master/explainer#security-considerations> >> . >> >> Privacy >> >> Privacy considerations are detailed here >> <https://github.com/WICG/fenced-frame/tree/master/explainer#privacy-considerations> >> . >> >> 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 >> <https://github.com/WICG/turtledove/blob/main/FLEDGE.md#4-browsers-render-the-winning-ad> >> . >> >> 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 >> >> <https://github.com/WICG/fenced-frame/blob/master/explainer/integration_with_web_platform.md#viewability> >> . >> - >> >> While cookies will be partitioned in a unique and ephemeral partition >> from the start of the OT, other storage APIs >> >> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md#storage-apis> >> as well as communication >> >> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md#communication-apis> >> and service worker APIs >> >> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md#serviceworker-api> >> will be partitioned later as described in the explainer here >> >> <https://github.com/WICG/fenced-frame/blob/master/explainer/storage_cookies_network_state.md#not-available-in-the-first-version> >> . >> - >> >> Network side channel mitigations as described in the explainer here >> >> <https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md> >> . >> - >> >> See ongoing technical constraints >> >> <https://github.com/WICG/fenced-frame/blob/master/explainer/README.md#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 >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ? >> >> 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. >> > > Is the current intent to run it till M104 (inclusive), similar to other > intents under this OT umbrella? > 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. > > >> >> 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/w9hm8eQCmNI> >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0-Htb44ezkojydCMKEWM9YnXL0Zc%2BGVE9xLO68csf8tJw%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/CADAcp08P_Q11rztEKYRPfrC6f907N2giJ_11yCtsGzydS%2Bqu0A%40mail.gmail.com.
