Ok. LGTM to experiment from M102 to M104. On Wed, May 4, 2022 at 7:15 AM Shivani Sharma <[email protected]> wrote:
> > > On Wed, May 4, 2022 at 9:11 AM Mike West <[email protected]> wrote: > >> On Monday, May 2, 2022 at 8:48:53 PM UTC+2 Shivani Sharma wrote: >> >>> Thanks Yoav! >>> >>> On Mon, May 2, 2022 at 7:27 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Sat, Apr 30, 2022 at 12:31 AM Shivani Sharma < >>>> [email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected], [email protected] >>>>> >>>>> 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 <[email protected]> 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. >>> >> >> FLEDGE was approved for experimentation only through M104. Given the >> tight relationship between FLEDGE and Fenced Frames, it makes sense to me >> for them to have the same timeline. Is there a scenario in which you think >> it makes sense for developers to want to experiment with Fenced Frames in >> the absence of APIs like FLEDGE that depend upon them? >> > > Sounds good to align with FLEDGE timeline since at the moment that is the > only API which is in OT that requires fenced frames opaque-ads mode: 102 > through 104 inclusive. > >> >> -mike >> >> >>> >>>> >>>>> >>>>> 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 [email protected]. >>>>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0_LY_qnLYn33ozEw2s7S48ugj1y1B%2BeOVcjnqr3QqAvCA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0_LY_qnLYn33ozEw2s7S48ugj1y1B%2BeOVcjnqr3QqAvCA%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9zCpScEPL_q6ftbXGgTtuaORCKTzmOXLtK1FbzoKByFw%40mail.gmail.com.
