Hi @domfarolino - Some notes from our TAG breakout today: We're noting that we had previously reviewed an earlier version of this spec and given it a positive review. In fact, we had also specifically called it out as a positive development in our finding on Improving the Web Without Third Party Cookies.

We're concerned that the changes to this API include Shared Storage as a dependency. Please note that not only does this not have multi-stakeholder support, but important stakeholders have actively expressed opposition to it: e.g. see the Webkit Standards Position comment, by @annevk and the Mozilla Standards Position. We've also noted this as an issue in our ongoing review of Shared Storage. Can you please clarify – is there a dependency on Shared Storage? Does this dependency improve user experience or developer experience of this feature? What's your plan in the (very likely) case that Shared Storage is not implemented by other browsers?

We are actually working on a design principle that would state config objects should also accept plain object literals whenever possible. Would that guidance be helpful in your design process?

We appreciate the thorough job done on documenting this API. Looking through the use cases though, we're struggling to find the user need. We're noting the goal articulated in the main explainer but what's missing is a simple articulation of what benefit the user derives from the inclusion of this API in the platform - from the web user's point of view. We'd also like to see an explanation and code example of how the API is used in its most simple form.

Hi there. Just to reiterate @torgo's last point - I've found it challenging to review this across an 12 page, very detailed technical explainer. While this is great documentation, it isn't really in the spirit of the purpose that TAG explainers need to serve. I have the impression there is a lot of context shared between the people who are working on this day-to-day that I'm missing due to not having a lot of exposure to or a deep understanding of the work, so it's hard for me to know which parts to focus on.

Please could you provide a one-pager primer or overview, and take note of our tips on how to write effective explainers? This can of course link out to more detail, but the key points should be captured a single document.

A smaller point - FLEDGE, Turtledove and Protected Audience are used interchangeably throughout. I understand that these are all effectively the same thing? It would also be helpful if you could improve consistency here.

The fenced frames proposal does not depend on Shared Storage, no. Shared Storage in some part depends on fenced frames, but not the other way around.

I've filed https://github.com/WICG/shared-storage/issues/98 to note that any shared storage-specific APIs that appear in the fenced frames specification should be _instead specified in the shared storage specification as extensions of the fenced frames spec, to make the dependency very clear — that fenced frames as a feature can stand alone without shared storage.

We are actually https://github.com/w3ctag/design-principles/issues/11#issuecomment-1515585583 that would state config objects should also accept plain object literals whenever possible. Would that guidance be helpful in your design process?

I do think this guidance would be pretty useful in general, although we might be running into the "wherever possible" loophole a bit, since the value of a FencedFrameConfig object actually has to do with an internal token that is unique to the config and irreplicable on the web platform. The config is largely read-only, reflecting the pieces of information that a config generator API is allowed to expose to the web platform without compromising privacy, so being able to interchange this with a JS-created bag of properties might not be immediately possible for us without considering another mode of fenced frames which allows user/web-platform-created config objects (which we've indeed discussed in the past, and is on the table for future consideration).

Regarding the explainer feedback, I was really hopeful that https://github.com/WICG/fenced-frame/blob/master/explainer/README.md would be sufficient to review. I feel that it's not too much longer than a lot of explainers, indeed links out to many other documents as you recommended, and I think we capture "the key points in a single document".

I was really hopeful that https://github.com/WICG/fenced-frame/blob/master/explainer/README.md would be sufficient to review

Any chance you could add end-user needs and code examples?

When we discussed in our earlier call, we struggled to get a sense of the end-to-end experience of using the API as a developer, from the perspectives of the various parties involved. I think code examples (and possibly a diagram) would help with this.

The code example that is present includes: fencedframe.config = new FencedFrameConfig('demo_fenced_frame.html'); which - if I understand correctly from the spec and your comments above - is explicitly not how this API is supposed to be used?

The fenced frames proposal does not depend on Shared Storage, no.

Thanks @domfarolino. I think that really needs to be clarified in the explainer because from our read of the explainer (and apparently from Anne's read as well) it looked like a dependency.

Also: I appreciate the work that's gone into the explainer(s) already and sorry if this seems like make-work. As we've noted in our explainer explainer we're really trying to get people to start from end-user need. This derives from the architectural principle of putting users' needs first.

@rhiaro wrote:

A smaller point - FLEDGE, Turtledove and Protected Audience are used interchangeably throughout. I understand that these are all effectively the same thing? It would also be helpful if you could improve consistency here.

@domfarolino can you clarify this? Is there a single name we should be using to refer to this?

Yeah, we're slowly trying to update everything to use Protected Audience instead of the other two names (including renaming repositories when necessary, etc.) The naming around these things has indeed gotten unnecessarily confusing, sorry! We'll be making changes across the Privacy Sandbox proposals for consistency.

Hi all. We are looking at this at our W3CTAG f2f. We had a long discussion about how the shape of this, changing the relationship between an iFrame and its embedding page — it must not be unique to the advertising use cases you've listed.

We brainstormed along the lines of a site presenting user-generated content in an iFrame, and the payments processes. Have you explored use cases out side the ones you're citing? And if so, what overlaps are you finding?

Hi all. We are looking at this at our W3CTAG f2f. We had a long discussion about how the shape of this, changing the relationship between an iFrame and its embedding page — it must not be unique to the advertising use cases you've listed.

We brainstormed along the lines of a site presenting user-generated content in an iFrame, and the payments processes. Have you explored use cases out side the ones you're citing? And if so, what overlaps are you finding?

Totally agree that the idea of fenced frames is not unique to the use cases supported thus far. We are actively also working towards supporting the personalized payment button use case as is being discussed on this issue and mentioned in our earlier TAG review: comment and support from the ecosystem. We are hoping to update our explainer/spec as we make more progress on the design for the same.

FYI, linking a few recent updates to the spec for new features:

Send Automatic Beacons Once https://github.com/WICG/fenced-frame/pull/109

Serializable Fenced Frames Configs https://github.com/WICG/fenced-frame/pull/111

Creative Macros in Fenced Frames Ads Reporting (FFAR) Protected Audience: https://github.com/WICG/turtledove/pull/762/files Fenced Frames: https://github.com/WICG/fenced-frame/pull/113

There are a few more recent updates to the spec for new features:

Send Automatic Beacons to Every Registered Destination: WICG/fenced-frame#122 WICG/fenced-frame#129

Ad Size Macro Substitution WICG/turtledove#801

There are a few more recent updates to the spec for new features:

Enable Leaving Ad Interest Groups from Urn iFrames and Ad Component Frames https://github.com/WICG/turtledove/pull/880

Introduce reserved.top_navigation_start/commit https://github.com/WICG/fenced-frame/pull/130

There is a recent update to the spec for a new feature:

Allow Cross-Origin Subframes to Send Automatic Beacons https://github.com/WICG/fenced-frame/pull/133

Hi folks -

We're noting that there have been many spec changes since our last comment but no changes to the explainer. Can you please explain what has changed since our previous review and a short explanation of why you made these changes?

We appreciate that you updated this thread with links each time you make updates to the spec, however these would also be better as updates to the explainer. It's good for an explainer to be a living document.

In general, we're concerned about the direction this is headed since our last review. Concepts such as "exfiltration budget" which seem to be at odds with the stated goals of the fenced frames proposal itself?

We've previously asked for use cases and user needs and we haven't really seen anything back. These should be added to the explainer as well.

Hi folks -

We're noting that there have been many spec changes since our last comment but no changes to the explainer. Can you please explain what has changed since our previous review and a short explanation of why you made these changes?

We appreciate that you updated this thread with links each time you make updates to the spec, however these would also be better as updates to the explainer. It's good for an explainer to be a living document.

In general, we're concerned about the direction this is headed since our last review. Concepts such as "exfiltration budget" which seem to be at odds with the stated goals of the fenced frames proposal itself?

We've previously asked for use cases and user needs and we haven't really seen anything back. These should be added to the explainer as well.

Responding to explainer updates below but I had a quick clarification before that, I don't see "exfiltration budget" in any of the updates above, could that comment be referring to another TAG review, perhaps? Similarly for the comment about use cases, the use cases are actually defined in the fenced frames explainer - is that comment for another TAG review too?

Sure, we would be happy to link the explainer updates corresponding to the spec updates linked above. Since most of these updates are in the Protected Audience + Fenced Frames reporting space, most of those explainer updates are in the Protected Audience repo and we can list them here in a follow up comment.

Hi @shivanigithub thanks for getting back so quickly.

When beginning our re-review of this earlier we found references to exfiltration budget in the specification itself. We didn't recall this concept from our review in #735.

The use cases we see in the explainer are not from a user needs perspective as far as we can tell. We'd appreciate a perspective on how these features impact end users, developers, and other parties who may be involved (eg. advertisers). What are the problems each set of users is facing? How do the proposed features solve them? What trade-offs are there?

The questions in this comment we left in July still stand as far as I can tell.

The "exfiltration budget" field is only used by the Shared Storage spec (will go here once they resolve the reference: https://wicg.github.io/shared-storage/#issue-7ff511a8)

When the fenced frame config is not being created for Shared Storage, "exfiltration budget metadata" is null. Or if Shared Storage isn't supported, the field does not need to be implemented. I'll add a line to that effect in the spec.

[Catching up on this thread now as I was unexpectedly out sick for a long while. Thanks for your patience, the fenced frames team is in the process of responding on the remaining open questions here.]

We're noting that there have been many spec changes since our last comment but no changes to the explainer. Can you please explain what has changed since our previous review and a short explanation of why you made these changes?

Below is the list of all the recent spec changes we've made, along with links to their explainer updates + either links to the GH issues that prompted it or explanations for why we made the changes.

Send Automatic Beacons Once Spec: WICG/fenced-frame#109 Explainer: WICG/turtledove#718 Background: WICG/turtledove/issues/743 (originally raised by adtech partners but I wrote the issue for tracking purposes)

Serializable Fenced Frames Configs Spec: WICG/fenced-frame#111 Explainer: N/a Background: Supports a use case that involves running an ad auction in a subframe and then postMessaging it to a parent frame to create the actual fenced frame.

Creative Macros in Fenced Frames Ads Reporting (FFAR) Spec: Protected Audience: WICG/turtledove#762 Spec: Fenced Frames: WICG/fenced-frame#113 Explainer: WICG/turtledove#763 Background: WICG/turtledove/issues/477

Send Automatic Beacons to Every Registered Destination: Spec: WICG/fenced-frame#122 Spec: WICG/fenced-frame#129 Explainer: WICG/turtledove#808 Background: WICG/turtledove/issues/826

Ad Size Macro Substitution Spec: WICG/turtledove#801 Explainer: WICG/turtledove#417 Background: WICG/turtledove/issues/312

Enable Leaving Ad Interest Groups from Urn iFrames and Ad Component Frames Spec: WICG/turtledove#880 Explainer: WICG/turtledove#879 Background: Expanding functionality since there wasn't any reason to disallow this in component frames/URN iframes.

Introduce reserved.top_navigation_start/commit Spec: WICG/fenced-frame#130 Explainer: WICG/turtledove#885 Background: WICG/turtledove/issues/822 (originally raised by adtech partners but I wrote the issue for tracking purposes)

Allow Cross-Origin Subframes to Send Automatic Beacons Spec: WICG/fenced-frame#133 Explainer: WICG/turtledove#904 Background: WICG/turtledove/issues/877

Hi @blu25 - we are just reviewing it today. We appreciate you taking the time to collate the information you've provided. However, it's difficult for us to parse the list - which is a lot of links to PRs where you need a lot of context to understand how they fit in, context that we lack. This is one reason we ask for explainers with reviews - which provide that context.

I'd also like to point out that we've returned a negative review on Protected Audience. So if there is a hard dependency now between this work and Protected Audience then it's unlikely that this will get a positive review from TAG.

Even so, we strongly recommend that you write an explainer which talks through this proposal, starting from user needs - as documented in our explainer guide.

Hi @blu25 - we are just reviewing it today. We appreciate you taking the time to collate the information you've provided. However, it's difficult for us to parse the list - which is a lot of links to PRs where you need a lot of context to understand how they fit in, context that we lack. This is one reason we ask for explainers with reviews - which provide that context.

A majority of the changes listed in this list are part of the “Fenced Frames Ads Reporting (FFAR)” infrastructure that is explained in detail in this explainer: https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md which is a short to medium term solution provided for Protected Audience adopters to be able to report on ad impressions within a fenced frame. Since some of the API surfaces are invoked from the fenced frame, they are part of the fenced frames spec but FFAR is ultimately a Protected Audience solution and is not core to fenced frames functionality.

Given your stated objection to Protected Audience, we ask that you instead consider only the following change from the above list that impacts fenced frames in general: Serializable Fenced Frames Configs.

I'd also like to point out that we've returned a negative review on Protected Audience. So if there is a hard dependency now between this work and Protected Audience then it's unlikely that this will get a positive review from TAG.

Even so, we strongly recommend that you write an explainer which talks through this proposal, starting from user needs - as documented in our explainer guide.

To add to above, fenced frames do not have a dependency on Protected Audience and are a generic element providing stronger isolation between the embedder and the frame, such that they are visually composed on the same page but cannot join cross-site identifiers. As the TAG had requested above, the updated use cases document is now published here. As an example of non-Protected Audience use case that fenced frames intend to support, as mentioned in the earlier comment, we are in the process of adding functionality for local unpartitioned data access which will support use cases like personalized payment buttons. That functionality is described in this explainer and the spec is currently in progress. Since this is a major update, we are happy to open a new TAG request specifically for this when the spec is more ready, or add to this request, as the TAG reviewers may see fit.

To add to above, fenced frames do not have a dependency on Protected Audience and are a generic element providing stronger isolation between the embedder and the frame, such that they are visually composed on the same page but cannot join cross-site identifiers. As the TAG had requested above, the updated use cases document is now published here. As an example of non-Protected Audience use case that fenced frames intend to support, as mentioned in the earlier comment, we are in the process of adding functionality for local unpartitioned data access which will support use cases like personalized payment buttons. That functionality is described in this explainer and the spec is currently in progress. Since this is a major update, we are happy to open a new TAG request specifically for this when the spec is more ready, or add to this request, as the TAG reviewers may see fit.

I created an early design TAG review for this new functionality described above: https://github.com/w3ctag/design-reviews/issues/975

Thanks so much to those who joined our F2F session today to go into further depth on Fenced Frames. The following is consensus feedback:

First, we wanted to reiterate the importance of security and privacy. As we mentioned, we have just put forward the Privacy Principles document for W3C Statement. We want to make sure the web works for everyone, especially marginalised communities for whom privacy risks are often magnified. In that light, we are urging you to pay further attention to abuse cases, where bad actors could potentially make use of this technology to exfiltrate sensitive data.

We are concerned that some of the use cases described might be considered abuse cases in some situations. The payment case raised, for example, involved the presentation to a user of a newly visited site of information that could make them erroneously believe that they had been to the site before.

We are also concerned with the amount of complexity this is introducing into the platform. Beyond the obvious usability issues, too much complexity is also a security risk in itself, as developers are using primitives they do not understand rather than making informed decisions. If the solutions are too complex, developers will use a solution "that works" without understanding the drawbacks, and it can be "open everything from the top-level".

Some of us have reservations that a new element is warranted, rather than augmenting iframe which conceptually has the same general purpose (embedding and displaying another HTML page). Or, perhaps it would be more appropriate to build a baseline abstraction from which each specific usage is derived.

In addition, we don’t fully understand whether the use cases warrant an API that is such a significant departure from the way other embedding elements work. Is it not possible to implement these privacy mitigations and new capabilities with a syntax and DOM API more similar to other HTML elements like iframe? (e.g. with a src content attribute and corresponding IDL attribute). If so, why?

This introduces a new wrinkle on the threat model for the web. Presently, websites cooperate with the browser to keep information that is jointly held by sites and the browser as private from other websites. Fenced Frames introduce a case where websites might cooperate to attack information that is held by the browser as private. This new threat model requires new forms of isolation that ensure that content in a fenced frame cannot release information to the site outside of that context. We would like to see more work done to analyze this and better understand it.

We are concerned that some of the use cases described might be considered abuse cases in some situations. The payment case raised, for example, involved the presentation to a user of a newly visited site of information that could make them erroneously believe that they had been to the site before.

What's the user harm you're imagining would be caused in these cases? What's the incentive for that abuse? Are there any examples of such abuse enabled by third-party cookies in the last ~30 years?

Presently, websites cooperate with the browser to keep information that is jointly held by sites and the browser as private from other websites. Fenced Frames introduce a case where websites might cooperate to attack information that is held by the browser as private.

Could you elaborate on that? I'm failing to translate that to Fenced Frames in particular and to the web's threat model in general. How are websites today cooperating with the browser to keep information private? What browser private information would fenced frames allow websites to attack?

We are concerned that some of the use cases described might be considered abuse cases in some situations. The payment case raised, for example, involved the presentation to a user of a newly visited site of information that could make them erroneously believe that they had been to the site before.

I just want to make sure I'm clear on the implications of this — this critique is about the user's perception, not about the actual privacy model, right? In that case, I think honestly any technology that offers a privacy-preserving alternative to what was previously possible in a web with third party cookies is vulnerable to this critique, since these privacy-preserving variants are about solving the privacy problem, not the perception problem. This is not to say that the perception problem — the fact that users might feel "creeped out", or not realize that their privacy is better under the hood when it doesn't feel any better to them — isn't important. I'm just trying to separate these two and figure out where the critique lands.

Some of us have reservations that a new element is warranted, rather than augmenting iframe which conceptually has the same general purpose (embedding and displaying another HTML page). Or, perhaps it would be more appropriate to build a baseline abstraction from which each specific usage is derived.

On the surface, it appears that iframes and fenced frames are "similar enough" to justify extending <iframe>, yeah. But please see the discussion in https://github.com/WICG/fenced-frame/issues/30. Both the processing model and security/privacy model is significantly differently. Think of it as a rel=preload|modulepreload kind of situation. But nevertheless, this is ultimately a question for HTML editors, and we haven't really received any pushback on this, and in fact Domenic Denicola urged us strongly to go with a new element, so we're very much of the mindset that the right experts have weighed in, and that our proposal has been responsive to their feedback.

The core problem we're concerned about is that the use cases are in some ways also abuse cases.

The Google Pay example is a great example here. No doubt the Google Pay team believes that this is an unqualified improvement to their product. They show that more people buy things if they show the last four digits of the card number in the Google Pay button. If we think of the feature from the perspective of making shopping more pleasant and streamlined, by showing people that payment through this button uses a service that is known to them, that has real upsides. People presented with information from an actor they trust (if they do in fact trust Google Pay services, which seems likely, at least to some extent, if they've already added their card info to it) might then feel reassured about the handling of their information.

However, that example also demonstrates the use of a subtle misrepresentation. People might reasonably believe that they have made a purchase on this website before, because the site appears to already have their payment information, when this is not necessarily true. In the case where the user has not bought anything from the site before, pressing the pay button and proceeding through the payment flow reveals lots of information about the user to the site which the site did not previously have. Yet the appearance of the button makes the user believe that the site already has this information, and that the net increase of information about themselves that the site possesses is zero. That increases the perception that the site is trustworthy in their eyes. Using that misrepresentation to nudge behavior is the very definition of a deceptive design pattern (Privacy Zuckering, as it happens).

The same arguments might be used for federated login buttons. Google accounts also presented similar UX for logins, showing a user icon and account name on sites that people had not visited before. Blocking third-party cookies disabled that feature; this use of fenced frames would re-enable it. The effect is the same sort of misrepresentation, and may result in users revealing information to sites that they otherwise would not have.

We are also concerned that the abuse scenarios here have not been given due consideration. The potential for abuse from a good actor here seems pretty strong, but the potential for this capability to be exploited by a bad actor is potentially far worse.

Tangential to the above conversation, but there is a new change to the spec documented below:

Fix 'src' permissions policy allowlist for fenced frames Spec: https://github.com/WICG/fenced-frame/pull/172 Explainer: N/a Background: Some fenced frames did not parse the 'src' allowlist for the allow attribute properly. This change has the 'src' allowlist be parsed as expected. Since this is a bug fix and the behavior now aligns with expected behavior, no explainer update is needed.