Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specification review for fenced frames #838

Open
1 task done
domfarolino opened this issue Apr 25, 2023 · 28 comments
Open
1 task done

Specification review for fenced frames #838

domfarolino opened this issue Apr 25, 2023 · 28 comments
Assignees
Labels
Missing: Multi-stakeholder support Lack of multi-stakeholder support Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Provenance: Privacy Sandbox

Comments

@domfarolino
Copy link

domfarolino commented Apr 25, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of fenced frames.

Overview of proposal
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 many communication channels with their embedding frame (e.g., postMessage, URLs, size attribute, name 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.

Delta
Please note that previously we had an early-review TAG design review that had resolved positively: #735 (comment). Since then, our spec has become considerably more fleshed out, and parts of our API surface have changed substantially, captured in https://github.com/WICG/fenced-frame/blob/master/explainer/fenced_frame_config.md that we discussed at last year's TPAC. More or less, we've removed the src attribute from the fenced frame element, in favor or manipulating the element with the new FencedFrameConfig interface, which can be returned from various APIs related to this proposal, such as Protected Audience and Shared Storage.

Details

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: Per https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline, Google Chrome is planning to launch the privacy sandbox APIs in Q3 of 2023
  • The group where the work on this specification is currently being done: WICG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG HTML Standard
  • Major unresolved issues with or opposition to this specification: At the time of writing, while most of the spec infrastructure exists, we are currently in the process of spec'ing our integration with the following (though the behavior is already clear from our explainers):
  • This work is being funded by: Google Chrome

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify [GitHub usernames]

@torgo
Copy link
Member

torgo commented Jul 10, 2023

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.

@rhiaro
Copy link
Contributor

rhiaro commented Jul 10, 2023

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.

@domfarolino
Copy link
Author

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.

@domfarolino
Copy link
Author

I've filed WICG/shared-storage#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 w3ctag/design-principles#11 (comment) 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".

@rhiaro
Copy link
Contributor

rhiaro commented Jul 11, 2023

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?

@torgo
Copy link
Member

torgo commented Jul 11, 2023

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.

@torgo
Copy link
Member

torgo commented Jul 13, 2023

@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?

@domfarolino
Copy link
Author

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.

@gtanzer
Copy link

gtanzer commented Jan 16, 2024

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.

@plinss plinss removed this from the 2024-02-26-week milestone Mar 11, 2024
@torgo torgo added this to the 2024-03-18-week milestone Mar 17, 2024
@plinss plinss removed this from the 2024-03-18-week milestone Mar 25, 2024
@shivanigithub
Copy link

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

@blu25
Copy link

blu25 commented Apr 16, 2024

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

@torgo torgo added this to the 2024-04-22-week:e milestone Apr 21, 2024
@torgo
Copy link
Member

torgo commented May 15, 2024

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.

@martinthomson martinthomson added the Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review label May 22, 2024
@plinss plinss removed this from the 2024-05-20-week:e milestone May 27, 2024
@shivanigithub
Copy link

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.

@torgo torgo added this to the 2024-07-15-f2f-Seattle milestone Jun 30, 2024
@shivanigithub
Copy link

shivanigithub commented Jul 10, 2024

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: #975

@torgo
Copy link
Member

torgo commented Jul 18, 2024

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.

@yoavweiss
Copy link

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?

@domfarolino
Copy link
Author

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 WICG/fenced-frame#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.

@martinthomson
Copy link
Contributor

martinthomson commented Jul 30, 2024

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.

@blu25
Copy link

blu25 commented Sep 17, 2024

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: WICG/fenced-frame#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Missing: Multi-stakeholder support Lack of multi-stakeholder support Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Provenance: Privacy Sandbox
Projects
None yet
Development

No branches or pull requests