Specification review for fenced frames #838
Comments
|
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 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.
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 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". |
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: |
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:
@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 @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.] |
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 Serializable Fenced Frames Configs Creative Macros in Fenced Frames Ads Reporting (FFAR) Send Automatic Beacons to Every Registered Destination: Ad Size Macro Substitution Enable Leaving Ad Interest Groups from Urn iFrames and Ad Component Frames Introduce reserved.top_navigation_start/commit Allow Cross-Origin Subframes to Send Automatic Beacons |
|
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. |
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.
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. |
I created an early design TAG review for this new functionality described above: #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. Some of us have reservations that a new element is warranted, rather than augmenting 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 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. |
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?
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. |
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.
On the surface, it appears that iframes and fenced frames are "similar enough" to justify extending |
|
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. |
こんにちは 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
srcattribute from the fenced frame element, in favor or manipulating the element with the newFencedFrameConfiginterface, which can be returned from various APIs related to this proposal, such as Protected Audience and Shared Storage.Details
Further details:
We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify [GitHub usernames]
The text was updated successfully, but these errors were encountered: