- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 20:55:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing][repsonsive-iframe] The behavior when content navigates out`, and agreed to the following: * `RESOLVED: For same-origin navigations we definitely keep the size` * `RESOLVED: Once we know the navigated-to page doesn't opt-in, we clear the intrinsic size` * `RESOLVED: Once we know the new page is not opted-in, we clear the size` * `RESOLVED: Check with security folks whether cross-origin case leaking info is an issue that needs mitigation` <details><summary>The full IRC log of that discussion</summary> <emilio> koji: smfr pointed out that we should define what happens when content navigates<br> <emilio> ... when content navigates in the iframe gets the natural size from it<br> <emilio> ... but when navigating out we can set to initial size, or keep the previous size<br> <TabAtkins> q+<br> <emilio> ... keeping is more natural from a user POV but can leak previous content size to the new content<br> <emilio> ... resetting stops that, but it can cause the size to jump<br> <emilio> ... we think we prefer to keep the last size<br> <iank_> (note the leak already somewhat happens with polyfills of this feature)<br> <emilio> q+<br> <emilio> ... it potentially leaks some information tho<br> <Rossen> ack TabAtkins<br> <emilio> TabAtkins: You wouldn't be able to tell that the size comes from anywhere else right?<br> <emilio> ... if you resize an iframe that's the size you get so you can't distinguish it<br> <emilio> ... worst case we could distinguish same vs. cross-origin navs<br> <emilio> ... but it should be fine to preserve the size I think<br> <TabAtkins> emilio: is the risk here... if th enavigation is triggered by the frame itself, it can already communicate that info<br> <TabAtkins> emilio: if nav is triggered by parent, parent can also communicate<br> <TabAtkins> emilio: so it seems to me, the reason this is aleady exposed in the polyfill is because the parent is coordinate the size<br> <TabAtkins> emilio: and at that point the comm channel is the embedder, the parent page<br> <TabAtkins> emilio: i dont' think you can communicate something with this that you couldn't comm via the query string, if the iframe is navigating itself<br> <TabAtkins> emilio: am i missing something?<br> <TabAtkins> emilio: so whats' the risk otherwise?<br> <TabAtkins> emilio: I guess an unintentional leak<br> <TabAtkins> emilio: but then you can't distinguish it from the page setting the size<br> <TabAtkins> ian: I think if we don't do it people will add a resize to the iframe and write the values in manually anyway<br> <emilio> iank_: if we don't do this people will just write the values in with a resizeobserver so they stick<br> <emilio> emilio: seems fine to me but would be good to get smfr or someone else from Apple to confirm<br> <emilio> PROPOSED: Keep previous size from the navigated away content<br> <emilio> q+<br> <emilio> Rossen: curious about what privacy / sec teams would thing<br> <emilio> ... I see iank_'s point about people being able to do this but that's a bit of cargo culting<br> <TabAtkins> emilio: what beahvior do we want once we've loaded the incoming page, and we see it's not opted in?<br> <TabAtkins> emilio: at that point do we want to clear the previous size?<br> <TabAtkins> Rossen: the previous size coudl be partial/incomplete anyway<br> <iank_> could we resolve to keep the size then simon/etc can follow up if needed?<br> <TabAtkins> emilio: that does give you a bit of extra info...<br> <smfr> ok by me<br> <TabAtkins> emilio: q is just do we want to keep the previous size or reset<br> <TabAtkins> Rossen: does this work cross-origin?<br> <TabAtkins> TabAtkins: yeah<br> <TabAtkins> Rossen: oh then def reset, yeah<br> <TabAtkins> emilio: well the cross-origin can see the value of the previous page, so leaking to cross-origin is already there<br> <iank_> it adds visual jump when it isn't needed. the polyfills today don't have this jump<br> <TabAtkins> Rossen: I think cross-origin navs should always reset eagerly<br> <TabAtkins> iank_: what's your threat model here?<br> <TabAtkins> Rossen: it exposes info you wouldn't otherwise have<br> <emilio> ack emilio<br> <TabAtkins> iank_: you can't determine how you got that info, tho<br> <TabAtkins> iank_: if the outside page sets `height:160px`, the cross-origin frame gets that 160px<br> <TabAtkins> iank_: no different from the value coming from frame-sizing<br> <TabAtkins> iank_: so i don't think clearing the info is useful...<br> <TabAtkins> emilio: resetting gives you more info. if you embed a cross-origin and you navigate to a different origin, cna the embedder know about that navigation?<br> <TabAtkins> emilio: can you get the url of the iframe?<br> <TabAtkins> emilio: but if you reset, then the resize would expose that<br> <fantasai> TabAtkins: wouldn't necessarily expose, because page can request size update<br> <fantasai> TabAtkins: if can't observe cross-origin, can't tell if it's due to cross-origin change or whether page requested a resize<br> <Rossen> ack fantasai<br> <emilio> fantasai: we seem to have agreement to preserve this at least for same-origin<br> <emilio> TabAtkins: yes<br> <emilio> fantasai: we can resolve on that<br> <emilio> PROPOSED: For same-origin navigations we definitely keep the size<br> <emilio> RESOLVED: For same-origin navigations we definitely keep the size<br> <emilio> fantasai: the other interesting question is what happens if the new page doesn't opt in<br> <emilio> ... do we resize to the initial size or we roll with the previous natural size<br> <emilio> emilio: it's probably more consistent to reset it, it'd be weird for the same page to give two different renderings depending on whether the navigated-from page happened to get measured or not<br> <fantasai> emilio++<br> <TabAtkins> +1<br> <emilio> PROPOSED: Once we know the new page is not opted-in, we reset the size<br> <TabAtkins> emilio: so imagine you ahve a page that opts in, it's an interstitial page<br> <TabAtkins> emilio: everything checks out, we measure the size and adjust<br> <TabAtkins> emilio: but it would be weird if navigating *before* DOMContentLoaded gave one rendering (the initial size) and navigating *Aafter* gave another (the measured size)<br> <TabAtkins> koji: so once we hit the </head> tag, we relayout<br> <TabAtkins> emilio: Yeah, once we know the page is not opting in, you'll clear the size and probably relayout<br> <TabAtkins> fantasai: probably worse to base it on DOMCotnentLoaded, want it as fast as possible<br> <TabAtkins> emilio: right, so </head> tag<br> <TabAtkins> koji: so what does it help? the page can still see the previous size<br> <TabAtkins> fantasai: thi sisn't security<br> <TabAtkins> fantasai: just, if the page hasn't opted in, it should lay out different based on whether it was *navigated to* by an opted-in page or not<br> <TabAtkins> s/it should/it shouldn't/<br> <fantasai> fantasai: whether previous page was tall or short, shouldn't change the rendering of this page (which has not opted in)<br> <emilio> fantasai: it's not only about whether you've navigated in the middle but also about whether it's a tall or short page<br> <emilio> koji: so when the child page it closes the `</head>` it sends a message to the parent process and resize<br> <emilio> ... at that point you'd have to relayout<br> <emilio> ... but it is fine to do multiple layouts here<br> <emilio> iank_: the info leak is happening regardless right?<br> <emilio> emilio: yeah this is just about getting consistent rendering<br> <emilio> PROPOSED: Once we know the navigated-to page doesn't opt-in, we clear the intrinsic size<br> <fantasai> PROPOSED: Once we know the new page is not opted-in, we reset the size<br> <TabAtkins> (and we always keep the previous page's size until then, regardless)<br> <emilio> RESOLVED: Once we know the navigated-to page doesn't opt-in, we clear the intrinsic size<br> <fantasai> RESOLVED: Once we know the new page is not opted-in, we clear the size<br> <emilio> fantasai: now remaining question is do we reset the size for cross-origin navigations or not<br> <emilio> ... (regardless of whether it's opted in)<br> <emilio> ... I think there's several things, one is preserving the size, the other is resetting the size as soon as it's cross-origin, the other one is to pretend to reset the size so that it's laid out into a default size container<br> <emilio> q+<br> <smfr> pretending sounds complicated<br> <emilio> ... so the page is pretending to see the default viewport<br> <emilio> emilio: observable via window.innerHeight<br> <Rossen> smfr +1<br> <fantasai> s/several things/several options/<br> <TabAtkins> emilio: in the pretending version, a few options<br> <TabAtkins> emilio: one is pretending frame-sizing isn't set, the other is pretending you're fixed size 300x150<br> <TabAtkins> emilio: former is especially bad, you don't know the size you'd have without frame-sizing without rerunnign layout<br> <TabAtkins> emilio: so my pref is, if we don't have concrete attack vectors, i'd like to just preserve the previous page's size<br> <TabAtkins> emilio: if we do, i like enforcing a 300x150 size for the iframe's document<br> <TabAtkins> emilio: that does change beahvior for existing docs<br> <TabAtkins> emilio: so my prefer is just not pretend and preserve the size<br> <iank_> +1 to emilio - we don't want to trigger a layout on the main frame for this purpose.<br> <TabAtkins> emilio: i don't think there's an attack vector<br> <emilio> iank_: I'm struggling to see what the attack vector would be<br> <emilio> ... but +1 to what emilio said<br> <emilio> smfr: if this is a payment flow the site might depend on whether apple pay or other method information is in use for example<br> <emilio> iank_: but you don't know if that size was imposed by the parent page or not<br> <emilio> smfr: not sure I agree, the site can assume if it knows it's using frame-sizing<br> <fantasai> iank_: Same as polyfill case<br> <emilio> iank_: not different from a page using the polyfill and exposing this<br> <emilio> emilio: in that case it's explicit, the parent is acting as a coordinator<br> <fantasai> emilio: Yeah, but in that case it's more explicit. Parent page is doing it explicitly<br> <emilio> smfr: that sounds like a bad polyfill<br> <fantasai> TabAtkins: polyfill wouldn't do the flickering behavior, it's bad<br> <smfr> (bad for privacy, not bad for flicker)<br> <fantasai> emilio: In this case, you don't require flicker necessarily. You can layout the child page with a 300x150 viewport unconditionally without changing layout of outer frame<br> <fantasai> emilio: from pov of parent, the size hasn't changed. So flicker isn't that bad.<br> <fantasai> TabAtkins: you're talking about the pretending case<br> <fantasai> emilio: Right, that's not possible to do in a polyfill<br> <fantasai> emilio: Has Google run this through security team?<br> <fantasai> emilio: To me, I find it very hard to come up with a realistic enough case ... maybe the payment processor example from Simon<br> <fantasai> emilio: If it's sensitive, before navigating away the previous page could size itself to zero and call this API<br> <fantasai> emilio: otherwise, there's no way to distinguish whether size is set by embedder or not<br> <emilio> fantasai: a sensitive page would ideally not opt-in?<br> <emilio> koji: I think what you're saying is equivalent to the child page sending the size to the parent<br> <emilio> ... if that child page navigates to a bad page<br> <emilio> ... I don't see much difference<br> <fantasai> emilio: originating page needs to have the meta opt-in<br> <fantasai> ... there's 2 pages, A and B in different origins.<br> <fantasai> ... let's say A has different sizes depending on whether you have Apple Pay<br> <fantasai> ... and page B wants to know<br> <fantasai> ... if page B opts in via meta tag<br> <fantasai> ... The only way for page A to not expose its content size would be<br> <fantasai> ... before navigating to clear the size<br> <fantasai> ... It is possible not to leak it, but do we want that to be the behavior.<br> <fantasai> ... In polyfill the parent page is coordinating between both<br> <Rossen> q?<br> <Rossen> ack emilio<br> <emilio> Rossen: what if we take the conservative resolution to pretend 300x150 and then based on conversations with experts we can come back and change it<br> <emilio> q+<br> <Rossen> ack emilio<br> <emilio> emilio: My concern with that is that unless we do the same for /all/ cross-origin iframes, then you're exposing different information (whether you were navigated from or not, or whether or not your parent uses frame-sizing)<br> <fantasai> emilio: Would be good to check with security folks whether they thing this is a real attack vector<br> <emilio> ... and doing it for all cross-origin iframes is a behavior change / performance issue<br> <fantasai> PROPOSED: Check with security folks whether cross-origin case leaking info is a real concern<br> <fantasai> PROPOSED: Check with security folks whether cross-origin case leaking info is an issue that needs mitigation<br> <fantasai> RESOLVED: Check with security folks whether cross-origin case leaking info is an issue that needs mitigation<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13589#issuecomment-4165477000 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 20:55:59 UTC