shiva...@chromium.org, d...@chromium.org, jka...@chromium.org
https://github.com/WICG/fenced-frame/tree/master/explainer
https://wicg.github.io/fenced-frame/ (a rough shell at this point)
In a web that has its cookies and storage partitioned by top-frame site, there are occasions (such as Interest group based advertising or Conversion Lift Measurements) 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
https://github.com/w3ctag/design-reviews/issues/735
Pending
Gecko: No signal
WebKit: No signal
Edge: Edge is also exploring interest group based advertising, namely with the PARAKEET proposal. 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).
Web developers: Fenced frames (specifically the opaque-ads mode) are designed as a requirement for certain Privacy Sandbox APIs, like FLEDGE. There is significant interest in FLEDGE from many web advertising technology developers. WICG FLEDGE calls are well attended and fenced frames have sometimes been discussed with developers as part of those calls.
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).
(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, but that is not applicable to this fenced frame mode.)
Security
Security considerations are detailed here.
Privacy
Privacy considerations are detailed here.
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
We hope to get feedback from ad tech companies on their usage of fenced frames as part of FLEDGE.
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.
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.
While cookies will be partitioned in a unique and ephemeral partition from the start of the OT, other storage APIs as well as communication and service worker APIs will be partitioned later as described in the explainer here.
Network side channel mitigations as described in the explainer here.
See ongoing technical constraints for more challenges like covert channels.
Fenced frames are supported in developer tools, similar to iframes.
Yes.
Yes.
FencedFrames
Also requires “NoncedPartitionedCookies”
No.
https://bugs.chromium.org/p/chromium/issues/detail?id=1208744
https://bugs.chromium.org/p/chromium/issues/detail?id=1171739
We hope to start the Origin Trial sometime during M102 beta.
https://chromestatus.com/feature/5699388062040064
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ
Contact emails
shiva...@chromium.org, d...@chromium.org, jka...@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 or Conversion Lift Measurements) 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
TAG review
https://github.com/w3ctag/design-reviews/issues/735
TAG review status
Pending
Risks
Interoperability
Gecko: No signal
WebKit: No signal
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/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+...@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.
--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/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+unsubscribe@chromium.org.
-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/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+...@chromium.org.
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.