Re: [w3ctag/design-reviews] Specification review for fenced frames (Issue #838)

> 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.

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.

> 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.

On the surface, it appears that iframes and fenced frames are "similar enough" to justify extending `<iframe>`, yeah. But please see the discussion in https://github.com/WICG/fenced-frame/issues/30. Both the processing model and security/privacy model is _significantly_ differently. Think of it as a `rel=preload|modulepreload` kind of situation. But nevertheless, this is ultimately a question for HTML editors, and we haven't really received any pushback on this, and in fact Domenic Denicola urged us strongly to go with a new element, so we're very much of the mindset that the right experts have weighed in, and that our proposal has been responsive to their feedback.

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

Message ID: <w3ctag/design-reviews/issues/838/2241937560@github.com>