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. > > 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? > > 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/CAL5BFfXM9Yd8f5bCrQo-HokWUz0dxJeUSunCtCvM0wvUH%2B6ooA%40mail.gmail.com.
