Re: [w3ctag/design-reviews] Fenced frames with local unpartitioned data access (Issue #975)

martinthomson left a comment (w3ctag/design-reviews#975)

> are you arguing that these well-established (and very common) third-party payment widgets are deceptive / harmful for users on the web?

Well-established is debatable (given that this specific behavior is impossible in most browsers, modulo the one that allows tracking).

But yes, this enables deception.  I can't present empirical evidence of harm, but that's not the standard that applies here.  Those presenting the new concept need to present evidence that harm is absent or at least mitigated such that the benefit more than outweighs the harm.

It is not only the "positive" use cases that need to be considered in that analysis (for the record, I don't regard either of these as positive, they are both not-so-subtly manipulative, but that's my own subjective view).  This has to consider the potential for the feature to be used maliciously.

> What I believe Shivani meant is that there is no additional information that a Fenced Frame could contribute here vs. any other element on the page, thus not changing the status quo. Am I correct here?

I am saying that Shivani's assertion is incorrect when you consider that webpages are shown to people[^1].

[^1] I can't even imagine what this could do to an agentic AI. Maybe nothing, because the agent might not care about privacy in the same way that they don't care about anything.  Either way, that's not the issue in question, so we don't have to consider it for the moment.

Let me give you a simple example: there is one bit of information available to the fenced frame.  That bit could mean anything, but let's say that it corresponds to some private trait, known to the third party and not the current page.  

A site could use two of these fenced frames, using that bit to decide which gets to be rendered as completely blank and which gets to be rendered as something that is highly likely to result in a click.  There are lots of things that people routinely click on in certain contexts, this is not special.  How about this:

![Image](https://github.com/user-attachments/assets/fd2211b9-846b-41f9-b2e2-684e47c96e15)

vs.

![Image](https://github.com/user-attachments/assets/8ae4fc25-b500-47eb-8472-3c88de1d97e7)

That is, both buttons shift depending on the value of that bit.  It's pretty unsubtle, but this arrangement virtually guarantees a click in the location that has content (users with screen readers are potentially duped, but I'm less clear on what you might do to deceive them this way).  The site then learns the value of the bit with high certainty.

The [Protected Audience issue thread](https://github.com/WICG/turtledove/issues/990) explores other attack modalities.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/975#issuecomment-2759776547
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/975/2759776547@github.com>