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

The TAG agrees that it would be useful to enable the user-focused use case here. Specifically, the web is in the situation that sites show a list of third-party providers, each of which might or might not be able to help the user sign in, pay, or perform some other function on the main site. The user may not remember which of those providers they've stored the relevant data with, and it's frustrating to click one of these buttons only to find that it can't help you. In a browser with 3p cookies, those buttons can give an indication of what data they have access to, but as browsers [phase that out](https://www.w3.org/2001/tag/doc/web-without-3p-cookies/), this sort of button can no longer provide these capabilities. It seems useful to try to prevent that frustration, if doing so is possible without confusing users about what [identity they've already presented to the main site](https://w3ctag.github.io/privacy-principles/#principle-identity-per-context).

The explainer is very unclear about whether that use case is actually the fundamental goal of this proposal. If the explainer is literally correct that the goal is to "decorate a third-party widget with cross-site information about the user", we think that's very likely to be a **harmful** goal and incompatible with our work on privacy principles for the web.

Even if we've correctly understood the use case, we think the proposed solution in this feature makes it too hard for users to correctly infer who already has access to that information. If a user incorrectly infers that the containing site already knows their identity, they're more likely to then "agree" to share their identity with the site, violating the [privacy principle on identity](https://w3ctag.github.io/privacy-principles/#principle-identity-per-context). The [two concrete examples of when to use this feature](https://github.com/WICG/fenced-frame/blob/master/explainer/fenced_frames_with_local_unpartitioned_data_access.md#introduction-and-goals) appear to be causing this sort of mistake in practice, whether or not their designers intended the deception. 


For example, Google Accounts presents a login chip on a number of websites (such as [Reddit](https://www.reddit.com/)). [Some versions of this chip](https://developers.google.com/identity/gsi/web/guides/offerings#one_tap) show your Google account name, profile image, and email address. Several members of the TAG have concluded from this UI that they had already used Google to log into a site, even though they hadn't. We then clicked through the login chip, creating a connection between Google and the site that we hadn't intended or wanted. Even if it wasn't intentional on the part of the UI designers, this had the effect of reducing our [autonomy](https://w3ctag.github.io/privacy-principles/#autonomy). FedCM seems like a better solution for login than letting the providers embed cross-site data.


Google Pay implemented a button that presents the last four digits of a credit card, taken from the last transaction with that service, even if the transaction was elsewhere on the web. This [greatly improved the rates at which people completed a purchase](https://developers.googleblog.com/en/updated-google-pay-button-increases-click-through-rates/). However, we're concerned that, like in the login case, this increase in purchases might be happening because users incorrectly concluded that they'd already bought something from the active site, and we haven't seen UX research that explored users' beliefs in this case. Further work on [Payment Handlers](https://github.com/w3ctag/design-reviews/issues/231) might be a better way to expose this sort of hint.


We don't mean to imply that Google is unusual in these practices. These techniques lead to better business outcomes for websites and their service providers, and it's perhaps unsurprising that neither group has checked what fraction of users are getting the outcomes they want. But we need that evidence before considering this UI in [user agents](https://w3ctag.github.io/design-principles/#priority-of-constituencies). And these are just the relatively benign cases: once a browser removes 3p cookies, truly malicious actors have a much stronger incentive to find ways to trick users into joining their identities (see some ideas in https://github.com/WICG/turtledove/issues/990). This proposal doesn't analyze or protect against that risk.


One might argue that the proposal is ok because it just allows websites to give their users false beliefs, and a user has to still separately consent before their private information is released, but as far as we can tell, identities can be joined as soon as the user clicks, which isn't sufficient for the browser to know they've consented. Even if there were a separate consent screen, its task seems very difficult, needing to both explain what the user's being asked to consent to, and override anything the user's been convinced to believe about what information the site already has.


We suspect that embedding information from a different context inherently enables deception about the surrounding site's knowledge. Certainly embedded sites could do the work of explaining what information their embedders already have, but we've seen that the default behavior is not to do that, and we _haven't_ seen either what malicious actors could do with this when motivated, or a creative analysis of the worst abuse cases. If you intend to pursue something akin to this general approach, a thorough analysis of the ways in which this might be abused and mitigated is essential.


We want to reiterate that the core use case seems valuable to solve, and we encourage you to keep trying to solve it. To do this safely, we suspect that you'll need to show the available information in browser UI, rather than inside the content area.

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

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