Yves: Need to evaluate the API change made, ex: removing src and adding a new FencedFrameConfig interface, to be used by shared storage API

Yves: they did change the API - adding a config ... we need to re-review. Noticed that Anne did some review in the webkit stds position...

bumped to next week

Yves: they changed their API and now it's using a concifg object that is stored in the shared storage.

Dan: So dependency on shared storage

Yves: yes and negative feedback...

Amy: mentioned in webkit standards position

Amy: config also seems more complicated than src. Also hooks into turtledove/fledge "Protected Audience"

Yves: this config is a way to add context or state to URLs, many people wanted this in the past

Lea: Does the dependency on shared storage improve the developer or user experience? We should ask what is the plan if the opposition continues, do they have a plan b?

Lea: what does the config class look like? we have a principle in the works that any class input to an api should also be available as a plain object

Yves: the fact they are changing from just using a url to a config object that just has a url inside is to keep more information/context about that url. Something that has been used in manyp laces to add context to a specific url. Not sure it's a good thing in general. What's the motive behind that? a URL should be self describing

Lea: the code example is more of a sketch. I can't find any description of these objects. Is it a data centric class or not?

Hadley: in the spec

Lea: interface where everything is an attribute... which accepts a string

Amy: the spec answers my question.. cannot be constructed manually from JS

Lea: this seems ergonmically bad, but there can be tradeoffs with security/privacy

Amy: presumably something to do with the url needing to be obscured by the browser... but I don't understand why that prevents the manual construction

Lea: I'd love to see an end to end example.. Even if advertising is the primary use case. Site A wants to have ads. Site B provides privacy-respecting ads. How does this work? What code do they use?

Dan: I don't know.. i'ts not written like that. We need a primer

Lea: it says it can't be constructed from js... but they have an example in their readme that does new FencedFrameConfig. Complicated. I can't tell if the use case requires this kind of complexity.

Lea: is the primary use case to protect user priacy against instances like embedding the facebook like button

Dan: I think so. But it's described in such an abstract way. "The ability to correlate the user’s identity/information on the embedding site with that on the embedded site." Seems to be that scenario.

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.

Dan: posts comment

Tess: this feels like it should have more use cases.

Hadley: payments? The shopping site needs to know that the transaction has gone through. And

Tess: yes. what about an ebook reader. Contents of the epub are web content. I don't think there is a need for the ebook to communicate with the reader app/website -- Js in the book does not need to talk to the website. Although, it could be the same site... though it could be google.com and googleusercontent.com, where they isolate untrusted content that they didn't write. The site wants to pritect itself from the book. What breaks there? Scrolling, pagination. Can you read the book? Most are a document per chapter, so multiple documents. So how would you read the book? Not the book in a frame, i'ts a content document in the frame.

So the ebook reader needs too know that the reader has scrolled to the end, or pagination, etc.

Just thinking out loud about other use cases.

I suspect that the containing page needs to know info about the enclosed page, where it might be ableto get the info from the zip file, but not all. The metadata in the zip file doesn't know the screen size, the font size, etc.

So I guess you can't use a fenced frame, because there is some info that needs to go back and forth.

The use case they're envisioning is adversarial, to prevent the adtech from learning info the shouldn't learn. Isn't the case in other use cases. In the books case, it's sort of adversarial -- I might purposely upload a malicious book --

Is there scripting, (which you could turn off). Maybe there is werid stuff you can do in CSS, which you could prevent with cross document loads

Hadley: payments isn't adversarial in the same way... it's not that the sites don't trust each other, it's that I as the user don't want them to talk more than I want.

Tess: right. Stripe, as a white labelled service, are going for seamlessly embedding themselves in the page the user is using. The user shouldn't care. They offer multiple payment methods (apple pay, paypal, etc etc). As a user, I know that paypal knows stuff about me. I want to be able to tell by looking at my browser that paypal is in a different enviroment from the page, and I want to belive that that different visual means something about who has access to what.

But in fact, the paypal popup needs to know something about the thing you're buying

Hadley: or just the total?

[discussion about how these work]

Tess: Both of these cases show that the user expectation is coming out of...

[Enter torgo]

Dan: we could ask them about use cases in payment...

Tess: We should ask "Are there use cases outside of ad tech?" - should be relevant to other cases ...

Hadley: and having it just for ads means developer complexity...

Tess: an <ad> element has always been rejected by the ad community bceacuse it would make ad blockers easier... Carrots and sticks... The carrot would be "if you don't use fenced frames, you don't get the data from your partition that allows you to do the targeting." that's a pretty enticing carrot. If you're just designing for the ad case we might be missing opportunities... e-book also an interesting one. e-reader needs to be able to inject style - impose user preferences like dark mode or font... so maybe not.

Tess: back when payments people working on payment handler they wanted payment handler to present a "sheet" that would be a payment flow... different from iFrame but similar to it... would this be sufficient for that?

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?

Hadley: we asked for more more use cases... user-gen content, payments, process... the reply from Shavini said they would update their explainer... then a series of updates on the spec...

Amy: we also asked for user needs and code examples in the explaienr and I asked a specific question about the api and there has been no response to that...

Matthew: i don't think the last updates are included in the explainer...

Amy:

Peter: concerned about all of the workarounds for ads..

Amy: the first review was for something for private ads. Now looks like poking holes in what they originally built to benefit advertises

Peter: exfiltration budget.. convoluted..

Yves: we really need to look at leaks and exfiltration

Peter: fence interface.. buyer/seller, etc. Isn't this just a mechanism for sending data between frames?

Dan: isn't that auction stuff?

Peter: what they say it's for is frames that can't talk to the outer document... why build the rest of this, to give the communication mechanisms you need for running ad auctions? This is an ad element. It's isn't a fenced frame.

Amy: Appreciate the surface level effort that the keep updating the issue, but it's not helpful that they are just links to PRs with no explanation

Dan: Well they do say what they've added

Amy: We should ask them to update the explainer each time they add a new feature.

Peter: we've asked before for use cases that aren't adtech.. If it's just an ad element, call it an ad element.

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?

Thanks for updating this thread with links each time you make updates to the spec, however could you also update the explainer with this new information as you go as well? It's good for an explainer to be a living document.

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.

bumped

Martin: protected audience has a bug - with fenced frames - https://github.com/WICG/turtledove/issues/990

Martin: describes a threat vector of bad actor using a capcha style UI to get someone to decribe contents of a fenced frame (contents that the site should not be able to learn)

Martin: Any secret information is released if someone clicks on it.. and there are no controls over how big a fenced frame is or the content that it shows...

Dan: explainer and spec changes came in last month

Martin: macros gives the outside site the ability to pass variables into the URL...

Martin: suggest that we could decline and refer to Protected Audience

Matthew: Say we decline this but we are expecting consensus in the community with respect to attriibution - wouldn't we want to see something like this with respect to attribution? it would improve the situation slightly when it comes to privacy...

Martin: i don't see that this works for any scenario unless you click on the fenced frame... navigation causes information to flow between web sites...

discussion about need for fenced frames

Martin: there are things on the platform ... non-cross-origin images (not marked CORS) - if you have one of those on the web site you don't get to know what the pictures are that were drawn on the screen... once we start talking about more and more capabilities it gets more difficult. If you show an ad on a page and the ad is replaced with nothing or a white square then the page doesn't get to know about that. It's necessary for some a11y scenarios...

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.

added pending external feedback label

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.

Thanks so much to those who joined our F2F session today to go into further depth on Fenced Frames.

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.