#1223: Other Spec Review: Responsively-sized iframes
Discussions
Log in to see TAG-private discussions.
Discussed
Jun 1, 2026 (See Github)
Dan: I have one main concern: this is a two-way opt-in. The embedding site lights up the feature for iframe, and the iframe has a one-bit opt-in--a meta tag that they include. The embedee does not make any decision about who they enable it for. Multiple embeddees can pull in an embedder if they don't set their CSP properly. I'm not the only one to rasie thise concern, so we can "plus one" the existing critique. I want to be more constructive, though. Should the op-tin be CPS, similar to frame ancestors? I don't know that I have enough of a feel for all of the CSPs to know if that's an appropriate use. If anyone has thoughts on that, I would love input.
Jeffrey: CSP is very complicated, and I'm reluctant to say "please add more stuff to it". Maybe we stick the list of domains in this meta tag. Or we say, "find a way to put this info next to each other."
Dan: I can draft a response along those lines. I'll check with Esahn before I post.
Discussed
Jun 8, 2026 (See Github)
Dan: Discussed with Essan, we will maybe try to work on it asynchronously more Lola: I saw that Luke and he discussed it a bit today..
Discussed
Jun 22, 2026 (See Github)
Dan: Will reach out to @toreini to determine what the mutual position is
Discussed
Jun 29, 2026 (See Github)
(Skipped.)
Discussed
Jul 6, 2026 (See Github)
Dan: I think I understand the point Ehsan was making in the proposal. I have drafted a comment and encourage people to review it.
Luke: I might have a different take. I think the CFP is enough. I think the securitiy model is acceptable.
Christian: Dan, do you want to edit the proposed comment?
Dan: It would be helpful if we could be on a call with Ehsan to discuss. Will take this to Slack.
Comment by @dandclark Jul 14, 2026 (See Github)
Since it looks like fenced frames will be sticking around in Chrome per https://privacysandbox.google.com/overview/status it would be good if the explainer could elaborate a bit more on why they're excluded. Presumably this is in line with <fencedframe>'s design goal of limiting communication between the embedder and embedee, but it'd be good for the explainer to call this out as something that needs to be a permanent exclusion rather than something that might be implemented later.
Comment by @dandclark Jul 22, 2026 (See Github)
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 that 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.
OpenedApr 27, 2026
Specification
https://drafts.csswg.org/css-sizing-4/#responsive-iframes
Explainer
https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md
Links
The specification
Where and by whom is the work is being done?
Feedback so far
You should also know that...
No response
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1223