Extend frame-ancestors to allow resizing iframe based on its contents.

[briansmith]

When embedding a sandboxed iframe into a page it would be very useful to allow the page to use display: block styling for the iframe, so that the iframe is sized to the contents of the iframe.
For example, with this a comment widget like Disqus could be embedded in an iframe in a "seamless" way such that (modulo visual styling). That was the goal of iframe seamless which was never implemented. See w3c/csswg-drafts#1771 and whatwg/html#555.

Some people have suggested using Feature Policy for this, however the threat model and goals seem better aligned with CSP frame-ancestors and CSPEE. I think it is likely that the people who control the frame-ancestor and CSPEE policy for a given page also would be the ones who should make the decision on whether to allow this resizing behavior because it's a security concern.

Strawman proposal: Add a frame-ancestors-resizing directive that does exactly what frame-ancestors does, but ALSO allows the framing page to style the iframe like display: block, leaking the minimum necessary to the embedding page to allow this sizing behavior to work, presumably just the height of the page content's for whatever width the iframe is sized to. The default value of frame-ancestors-resizing would be 'none'; default-src and frame-ancestors would not affect it. The actual resizing behavior would be specified in CSS, not in CSP.

Thoughts?

(FWIW, my goal here is to get <iframe sandbox> practically workable for more widget embedding use cases.)

[craigfrancis]

Yes please!

I believe this is the only this problem which stops widgets being put in iframes, and this would really help with security (yes, I know, bit optimistic, I know some widget creators love having full access to the web page, when you "simply" include their JavaScript).

The other suggestion so far has been a separate header, e.g. Expose-Height-Cross-Origin; but you're right, frame-ancestors covers a similar issue, so I think adding a frame-ancestors-resizing would work well.

The only other issue mentioned so far has been circular styling issues (not a security issue). Safari has been able to work around this in their "frame flattening" feature... but I'd be happy to simply that by saying it's only the frame height that changes; and the browser only does 1 height calculation (when the CSS has loaded), then maybe a JS method could be called within the iframe to ask for it's height to be updated (e.g. as more content loads/changes), otherwise fallback to scroll bars. Widget creators should be able to work within that constraint.

[dveditz]

My initial reaction mirrored Mike's in whatwg/html#555 (comment) that CSP isn't a great fit for this.

[briansmith]

In particular, Mike said "I'd like to keep it negative to the extent possible." In other words, CSP by design doesn't grant capabilities; it instead limits already-granted capabilities.

OTOH, CSP embeded enforcement does grant the framing site capabilities, so maybe this could go in CSPEE, especially considering the scope of CSPEE.

[craigfrancis]

With CSPEE, isn't that the parent telling the iframed content the minimum policy it needs to have?

Where the framed content can:

• Return a normal CSP header - in this case frame-ancestors-resizing https://parent.example.com, to open (but still limit) the resizing ability to that parent domain.
• Return Allow-CSP-From: https://parent.example.com to simply accept the requested CSP (which could be a bit dangerous without checks).

Personally I quite like it sitting next to the already existing frame-ancestors, but I must admit I'll take anything at this point, even if that is a separate header.

[briansmith]

With CSPEE, isn't that the parent telling the iframed content the minimum policy it needs to have?

Yes. Allow-CSP-From: https://parent.example.com would, like you mentioned, give the parent extraordinary power to control the embedded frame. For example, the parent could disable security-critical scripts used by the framed content.

Anyway, I'm going to close this as I think it just doesn't work in CSP. It's unfortunate though, because frame-ancestors and this mechanism (and CSP-EE) are very closely related and should be managed together. Probably the relationship between them would "just" need to be documented clearly in each spec.

(The issues regarding this feature in the CSS and HTML issue trackers are still open.)

[annevk]

Perhaps the answer is that X-Frame-Options should be extended or revamped instead and putting that into CSP was the wrong call. As per whatwg/html#1230 they are enforced at a different point from most of CSP.

[craigfrancis]

Thanks @briansmith and @annevk - I was just getting hopeful that it might happen soon.

[annevk]

I'm happy to mentor someone willing to work on adding this. I suspect there's still implementer interest, but it's not really anyone's priority maybe?

[craigfrancis]

Maybe, I suspect most developers have given into the idea of websites just including 3rd party JavaScript to create content, whereas I want to lock that stuff into an iframe, for some basic isolation (ref security/privacy).

Unfortunately I'm more of a website developer, so I doubt I'll be learning and writing any C code any time soon (I can read it, but I'm also aware of the risks when it comes to writing it).

[annevk]

Ah, I meant mentoring for the changes necessary to various standards. If the design is sufficiently worked out the cost would become more clear to implementers.

[craigfrancis]

I'm happy to try tweaking documents, I'm just struggling to work out what's possible (e.g. the conversation in the other thread about how the height can be changed)... I don't want to suggest something that's going to be hard/problematic for the browsers to implement, otherwise it will never happen.