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

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](https://www.w3.org/TR/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.

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

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