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

We can't say "identities can be joined as soon as the user clicks" if we mean "one bit leaks for each click".

I'd missed that the fenced frame can't itself open a popup at an arbitrary URL. https://github.com/WICG/fenced-frame/blob/master/explainer/fenced_frames_with_local_unpartitioned_data_access.md#information-flow-and-design says the surrounding page has to decide what URL to open. Since that has no more information than an `<a href>`, and I don't see a reason that nav-tracking mitigations (to the extent they're possible at all) won't apply across both, it doesn't seem like this violates the ["leave the web better" principle](https://w3ctag.github.io/design-principles/#leave-the-web-better).

This still puts a lot of responsibility on whatever consent screen appears behind that popup: if users have concluded that the surrounding page already knows their cross-site identity, the consent screen has to counteract that in order to [get an accuration notion of the user's intent](https://w3ctag.github.io/privacy-principles/#principle-consent-user-preference). Is that plausible?

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

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