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.
