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 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. 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.
