Remove `<iframe seamless>`
annevk opened this issue · 27 comments
This seems like a good candidate for direct removal since per http://caniuse.com/#search=seamless nobody is doing this.
Are the use cases for this simply left unsolved, or is it being done cooperatively with postMessage between the embedder and embedded frame?
I don't think that solves all equally well, but it seems like shadow DOM solves most of them pretty well.
Support was removed from Blink in January 2014, and from the blink-dev discussion I take the sentiment to be more disinterest than disapproval.
It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.
It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.
I notice that in one of Adam Barth’s comments in the thread you cited, he says:
We're considering removing the feature because it's adding complexity to the style recalculation engine. Specifically, when working to improve style recalculation performance, we've often run into code and complexity that exists only to serve iframe@seamless. Removing that code and complexity will let us improve style recalculation performance faster.
As far as web-developer feedback on the feature, some comments from Ben Vinegar from last year are worth reading; among other things he says:
But while we’re not interested in the style component of the seamless
attribute, we – and probably all developers that hack on iframes – are
interested in the resizing behaviour it introduces. Right now we deploy
fairly complex code, both inside the iframed document, and on the parent
document, to resize the iframe element when the iframed content changes
size [2]. Every iframed application with dynamically-sized content does the
same.To me, it’s crazy that it’s 2013 and there’s still no native way to have
the browser automatically resize an iframe. And yet we have seamless. But
it not only resizes: it adds all this other bundled behaviour, and strictly
serves a fringe use case where somebody is distributing iframes on the same
origin.My suggestion is to split seamless into its three major parts: style
inheritance, iframe resizing, and browsing context.
So I think the gist of it all both from the implementor side and the web-dev side is that seamless as-specced doesn’t seem to be what anybody wanted to begin with. Or at least it’s more than anybody actually wanted. And anyway like @annevk says, it’s seems a lot of it’s since been “overcome by events” in light of Shadow DOM.
Note also that seamless requires changes to the event model that have never been specified.
how should the removal of iframe seamless change for browsing context , as it would take a lot of changes for it's spec.
Yeah, things that look like they can be removed:
- everything that says seamless
- master concept in the "Browsing context names" section
- the three columns about seamless in the big table
- "explicit self-navigation override"
Basically everything that builds on top of the seamless feature can go.
This is really disappointing as web components do not provide any security, you can't import a web component without it being able to manipulate the page it's in.
Yeah. It would have been cool if someone implemented, IMO, but a number of factors made it not a good tradeoff for implementers given other technologies that serve overlapping use cases (even if none of them serve the exact use case).
Well, here it is, now 2016 as I add this comment, and I am still using a terminal emulator to display my notes. I'd rather use a web browser for display, because, with things like html, latex, mathjax, and chemdoodle, my notes could draw from a rather rich expressive palette. But then, I also prefer a "modular" approach to writing, cutting and pasting together smaller documents, and then also, assembling those smaller sections to form a larger document. And it's nice to have the smaller bits both able to display on their own, and also contribute to that larger document. But, as it is, in 2016, there is still no simple native html markup to allow this sort of thing. https://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file
Some people had hoped that some combination of "iframe", "seamless", and 'target="_parent"' would address this issue - but no. Instead, whatever the technical issues might be, there seems to be a kind of "stupid white men" paternalism that favors complex script-based source material intended to obfuscate rather than simplify. The implication being that end-users must not be content producers. And browser developers set-out to enforce this dictum. It's political, not technical.
Is that too harsh? Where is the simple html construct that assembles a single larger web page from a group of smaller pages, and adopts the styles from its hosting page, without resorting to a lot of javascript?
BTW, "seamless" was back in again in the HTML 5.1 draft in 2016 Mar 10:
https://www.w3.org/TR/2016/WD-html51-20160310/semantics-embedded-content.html#seamless-iframe
but out again in the HTML 5.1 draft in 2016 Jun 02:
https://www.w3.org/TR/2016/WD-html51-20160602/semantics-embedded-content.html#the-iframe-element
Iframe "seamless" has not returned in the HTML 5.1 draft, 2016 Jun 21:
https://www.w3.org/TR/html51/semantics-embedded-content.html#the-iframe-element
or in the HTML 5.2 draft, 2016 Aug 18:
https://www.w3.org/TR/html52/semantics-embedded-content.html#the-iframe-element
If you are concerned, file an Issue:
https://github.com/w3c/html/issues/new
Hello @thx1111 and welcome to WHATWG.
Please read the following:
https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F (3rd bullet point in this case)
Also please read: https://wiki.whatwg.org/wiki/Code_of_Conduct - try to be respectful, ranting and blaming is not very helpful. Thanks!
It seems like the issue is that "seamless" inherited styles, which seemed foolish to begin with. I think "seamless" would be fine if it simply "autofit" it's content, such that embedding an iframe could effect the document flow of the document its embedded in. It's too bad this wasn't just added back in with just auto-resizing.
Note that auto-fitting the height turned out be a serious timing attack vector unless we restricted with CORS.
@rniwa Oh? How did that make a site vulnerable?
@matthew-dean : You can detect what kind of content was shown inside the frame based on how long it look to layout / style / paint.
I'd still find it useful if a CORS check allowed me to combine sandbox (or a second domain) and seamless to load pages I control which then contain <script> embeds for things like Disqus.
Having variable-length resources in a scrollable iframe really isn't the best user experience most of the time but, at the very least, I'd really like to be able to keep all remotely loaded content from running in the same origin as my pages.
@rniwa I don't see how that would be possible; there are too many variables on load time, and detailed eventing would be presumably sandboxed. There are how many billions or trillions of web pages? How could you reliably profile page loads for pages that may change, and over connections that vary in latency throughout the day/week?
Well, timing attack is typically done on a very specific website, which the attacker knows. A typical timing attack is robust against websites changing its content. You can read various research paper on this matter. e.g. https://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf
Hmm, still.... a theoretical successful detection doesn't equate to real-world exploits, as one of the requirements of such an exploit would be injection into the page hosting the iframe, or a user unwittingly installing a malicious script into their webpage. Even the calculate style vulnerability of the past relied on malicious scripts being allowed access in the first place.
Instead of limiting the utility of useful features of the web, maybe we should focus on the root cause, which is un-sandboxed third-party scripts having full access to the host environment instead of a limited or white-listed API. It just seems unfortunate if a very useful feature of the web becomes a casualty of poor design elsewhere.
It seems like the issue is that "seamless" inherited styles, which seemed foolish to begin with. I think "seamless" would be fine if it simply "autofit" it's content, such that embedding an iframe could effect the document flow of the document its embedded in. It's too bad this wasn't just added back in with just auto-resizing.
+1
I desperately need autofit sandboxed iframes in many of my apps. Essentially whenever I want to show untrusted HTML. In many realistic use cases (web forums, conversation view, user-supplied descriptions on an app store, reviews, comments, etc), I want the iframe element to size to its content. In such cases, the sandboxed iframe is an additional protection, on top of sanitizing. It also prevents CSS styles from leaking into the parent doc.
This issue, and iframe seamless seems like an example of making perfect the enemy of good.
This was removed because, as @rniwa states:
You can detect what kind of content was shown inside the frame based on how long it look to layout / style / paint.
The irony is that because this feature was rejected, the fallback is what it has always been, which is to force a user to include a 3rd-party script in their page, in order to properly create and size the iframe. So the rejection of this feature does not make sense, because for whatever security concerns there are, the effective result of not having it are worse from a security perspective, and more subject to cross-site scripting / man-in-the-middle attacks, so I hope that someday this can be revisited and that can be part of the conversation. So, if there are theoretical attacks from layout / style / paint (which I don't really believe browsers cannot mitigate from varying timings slightly), it seems to be relatively minor vs. the real-world cost from the fact that this feature still does not exist.
I like the idea of auto-sizing iframes though I think a few things need to be cleared up:
- Timing attacks aren't hypothetical issues but are an important part of what browsers have to deal with. In 2018, the famous Spectre and Meltdown vulnerabilities were discovered which were based on timing attacks. To prevent pages in a browser from using the vulnerabilities to peek at information in each other, browsers had to suddenly rework how iframes were implemented and had to remove their existing support for SharedArrayBuffer and WebAssembly multithreading until new CORS headers were implemented that allowed sites to use them safely. The caution in this thread looks very justified in retrospect.
- The security issues could likely be dealt with by requiring pages to opt in through a header to supporting auto-sizing when inside of an auto-sizing iframe. (There are existing examples of security issues being solved like this such as in the X-Frame-Options header, the CSP "frame-ancestors" directive, CORS headers, etc.)
- Auto-sizing iframes (where both sides have to opt in) would be merely a convenience feature, as to my knowledge it's already possible with some javascript on both sides of an iframe without needing to unsafely load scripts from third-party domains, so it's definitely not worth doing in a way that adds a vulnerability. (If it's not already possible to cleanly do with cooperating javascript on both sides, then it might be a smaller/easier/quicker change for browsers to fix that first.)