- From: Dan Clark <notifications@github.com>
- Date: Wed, 22 Jul 2026 09:18:58 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1223/5048633119@github.com>
dandclark left a comment (w3ctag/design-reviews#1223) Thanks for sending this to the TAG! We had a few points of feedback. One is that the opt-in from the iframe isn't scoped in any way. The explainer [points out](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md#privacy-and-security) that [frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/frame-ancestors) can allow the developers to control where the frame is embedded, but it's concerning that there's no safety mechanism by default. So it'd be easy for a developer to use this feature while forgetting to apply the `frame-ancestors` restriction, leading to potential information leakage to a malicious embedder. For this reason we think user agents should at least warn developers if the feature is used without `frame-ancestors` (or `X-Frame-Options` which would also suffice). Secondly, since this is a new vector of cross-origin information sharing, we'd like to see more threat-modeling in the explainer considering what new privacy risk it introduces. If a bank website opts into this feature, could information about the user be leaked to the top level site? Could the top origin fingerprint the type of ads shown to the user if they were to opt-in? It's also worth comparing to how devs would build this functionality today using cross-origin postMessage etc. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1223#issuecomment-5048633119 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1223/5048633119@github.com>
Received on Wednesday, 22 July 2026 16:19:02 UTC