Intent to Ship: Fenced Frames

[Shivani Sharma]

Contact emails

shiva...@chromium.org , d...@chromium.org, jka...@chromium.org

 

Explainer

https://github.com/WICG/fenced-frame/tree/master/explainer

Spec

https://wicg.github.io/fenced-frame/

Summary

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:

• Protected Audience API runAdAuction() (code snippet)

• Shared Storage API selectUrl() (code snippet)

(For future use cases of fenced frames, separate I2S would be sent.)

Blink component

Blink>FencedFrames

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,

• etc.

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.

Demo link

https://browsing-context.glitch.me/host-fenced-frame.html

Debuggability

• DevTools are supported for fenced frames similar to how they are supported for iframes.
• DevTools’ network tab will include the beacons sent from a fenced frame as part of fenced frames ads reporting.
• We also support a developers testing mode behind a non-web-exposed flag where a `FencedFrameConfig` can be created with a plain url, to enable testing fenced frames without invoking the above mentioned consumer APIs. At the moment, this is at chrome://flags/#enable-fenced-frames-developer-mode, but we will likely move it to DevTools in the future.

Risks

Interoperability

Gecko: https://github.com/mozilla/standards-positions/issues/781

WebKit: https://github.com/WebKit/standards-positions/issues/173

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:

Positive signal. 

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.  

Compatibility risks

Fenced frames do not deprecate or change existing web behavior, so there should be no compatibility risk.

 Activation

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

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes

Tests: https://github.com/web-platform-tests/wpt/tree/master/fenced-frame

Results: https://wpt.fyi/results/fenced-frame?label=experimental&label=master&aligned

Anticipated spec changes

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.

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 

Intent to experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ 

Intent to extend origin trial:

https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ 

https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ 

https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ 

[Alex Russell]

Hey all,

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?

Best,

Alex

[Chris Harrelson]

LGTM1

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

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

[Rick Byers]

LGTM2

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.

[Mike Taylor]

LGTM3

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.

[Joshua Bell]

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.

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.

[Shivani Sharma]

Thanks all!

(Response inline)

On Wed, Jun 21, 2023 at 12:19 PM Joshua Bell <jsb...@chromium.org> wrote:

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:

LGTM3

On 6/21/23 11:53 AM, Rick Byers wrote:

LGTM2

On Wed, Jun 21, 2023 at 11:46 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

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:

Hey all,

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?

Thanks Alex for the question!
We would love to know more about the use cases and determine from there how fenced frames could be extended to support those.

The currently supported use cases (interest based ads and the more generic selectURL API) are definitely not the only ones that fenced frames are anticipated to support.
For instance, we’re discussing a non-ads use case (personalized payment provider button) here and have received ecosystem support for the same.
We hope to add support for this and other use cases that we learn from the ecosystem, and are open to general purpose approaches.
The API surface for fenced frames configuration via FencedFrameConfig allows multiple consumer APIs to create FencedFrameConfig objects relevant to their needs and is thus extendable for future use cases.

Re. network access for the existing use cases, as mentioned in the "anticipated spec changes" section, unrestricted network access might lead to a privacy side channel and we are actively discussing how to mitigate that in the future.