In a web that has its cookies and storage partitioned by top-frame sites, there are occasions (such as Interest group based advertising or Consistent A/B experiments across sites) when it would be useful to display content based on inputs from different partitions on the same page. For such use cases, it would be ideal from a privacy perspective, 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.
At the time of this I2S, fenced frames can be created and navigated using the `FencedFrameConfig` object returned from the following APIs:
(For future use cases of fenced frames, separate I2S would be sent.)
TAG reviews and status
early design review (status: complete),
specification review (status: pending)
Link to Origin Trial feedback summary
Fenced frames are part of the unified Privacy Sandbox OT and are an integral part of the privacy design of “Protected Audience” and “Shared Storage” APIs. For easier adoption, these consumer APIs don’t currently enforce the use of fenced frames, but we have had multiple testers testing these APIs with fenced frames. We’ve incorporated feedback and feature requests from those testers, some examples are given below:
Attribution reporting API support for event-level reporting (explainer),
reserved.top_navigation support for component ads (explainer),
Dev tools integration with reportEvent beacons,
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Supported on all the above platforms except Android WebView.
Neutral though we haven’t received formal positions on the above issues yet. If these browsers implement the use cases that fenced frames support e.g. interest based advertising or future fenced frame use cases like personalized payment buttons then it’s more likely for them to implement fenced frames.
Edge is also exploring interest group based advertising, namely with the PARAKEET proposal. PARAKEET, similar to “Protected Audience”, relies on fenced frames for rendering the ad and are interested in collaborating (comment on WICG issue).
Web developers: Fenced frames are designed as a requirement for certain Privacy Sandbox APIs, like Protected Audience API. There is significant interest in FLEDGE from many web developers. WICG FLEDGE calls are well attended and fenced frames have often been discussed with developers as part of those calls and on github issues on the “Protected Audience” WICG repository.
Fenced frames have a stricter information flow as compared to iframes and no information flows from the embedding context to the fenced frame or vice versa. This makes it a challenge to have traditional methods of measurement and spam detection to be applied as they do in iframes. In the short term, fenced frames do allow event level reporting but eventually new methods like aggregate reporting would be required and that’s a long-term challenge for the industry to adapt to.
Fenced frames do not deprecate or change existing web behavior, so there should be no compatibility risk.
There are no concerns for developers to take advantage of this feature immediately, as-is.
Developers can either test fenced frames in conjunction with the consumer APIs or separately using the test-only mode (GH issue).
The following are ongoing technical considerations and will be addressed in upcoming milestones accompanied by separate I2Ss and spec changes. These will be breaking changes and should be anticipated by developers:
Currently, the network is unrestricted in fenced frames but will eventually be addressed to mitigate the network side channel leak. The leak is described in the explainer here.
Currently, intersection observer API is supported just like in iframes but will eventually either be replaced with a more private solution or the outflow of information from the FF will be restricted (see point above). This is further described in the explainer here.
Currently event-level reporting is allowed with information from various contexts as per the explainer here. In the future, the event level reporting surface `window.fence.reportEvent` will either change in behavior to become more privacy-preserving or will be a no-op and not send out a beacon. This won’t be a breaking change for the script on the page but impacts the ecosystem since reporting is impacted.
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ
Intent to experiment:
Intent to extend origin trial:
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/80c0731a-6fab-43b8-9117-c445525de51dn%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8BwtxFW9OdHqOOVpLwr7ohvUQ6UUvWzSCjsTRse%3DHV1A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-mX-ziUw%3DFnbRsiHvBT1i8GJucE-iYeFTH15m-b05hGg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fc98490f-9b90-9a01-62c4-230579c2939d%40chromium.org.
Just a quick note on spec maturity: as spec mentor, I did a thorough review of the spec text, and noted many issues - all small - which have been addressed. As the feature introduces a privacy boundary between two documents with very sensitive one-way control, it is non-trivial but the design is well thought out and the exposed API makes sense for the use case. The primarily challenge with maintaining the spec going forward is that it is a series of patches on top of [HTML] and a handful of other specs, but these patches are extremely clearly written and the rationale is easy to understand.On Wed, Jun 21, 2023 at 8:57 AM Mike Taylor <mike...@chromium.org> wrote:
On 6/21/23 11:53 AM, Rick Byers wrote:
On Wed, Jun 21, 2023 at 11:46 AM Chris Harrelson <chri...@chromium.org> wrote:
Thank you for thoroughly working through all the design and specification steps for this feature. Glad to see some positive signals from the TAG about the fundamental design in particular.
I agree that Alex's comments are good to answer and investigate for future work, but also they aren't blocking this intent. (Confirmed this interpretation with Alex.)
On Wed, Jun 21, 2023 at 8:42 AM Alex Russell <sligh...@chromium.org> wrote:
I'm not going to weigh in on if this should ship right now, but I want to express some disappointment that this design seems to be launching without a way to load from a bundle and a flag for removing the ability to load from the network. We have a lot of use-cases that would benefit from a version of <fencedframe> that was more capable and generic, rather than being narrowly targeted at an ads use-case.
What's the prognosis for fixing those deficiencies in near-future work?