- From: Artur Adib <arturadib@gmail.com>
- Date: Tue, 27 Jul 2010 22:17:24 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: Arthur Clifford <art@artspad.net>, public-html-comments@w3.org
On Tue, Jul 27, 2010 at 3:37 PM, Ian Hickson <ian@hixie.ch> wrote: > This is a difficult situation, because we have three conflicting needs: > > - Applications defined using hierarchies of <iframe>s that use "top" > instead of "parent" to refer to each other break down when framed. > > - Applications want to be able to test whether "top" really is the top, > to protect against clickjacking through framing. > > - Applications (specifically ads) that are securely sandboxed want to be > able to navigate the top-level frame (e.g. when the author wants to > follow the ad). Not much to say about the 1st need. As to the second, checking and/or changing top to avoid clickjacking is a cumbersome hack. Echoing what Arthur said, if people don't want their site to be framed, there should be a standard for that. Apparently, IE, Safari, and Chrome already support the HTTP header X-FRAME-OPTIONS [1]. That seems to be a step in the right direction. With regards to the third need, if the author of the host content wants to follow the ad, they can do so as they have control over the browser top, so the sandboxed ad per se has no need to mess with the browser top. Additionally, if the iframe is sandboxed it won't be able to navigate top anyway, unless the host explicitly turns on 'allow-top-navigation', an option which would become redundant with this new interpretation of 'top'. (Reiterating, the top would be just the sandboxed outermost frame, and not the browser top, so the ad is free to do whatever they want with it). In a nutshell, I still think that considering an iframe as a 'browser-in-a-browser' makes the most sense. Every attempt to access the outside of this 'inner-browser' sounds more like a hack to me. It's not unlike allowing a webpage to access and mess with your OS's desktop, which is a big No-No if you look at it from that angle. [1] http://en.wikipedia.org/wiki/Clickjacking -- Artur Adib http://arturadib.blogspot.com http://www.linkedin.com/in/arturadib > > The first of these has a simple workaround: when writing applications > defined using hierarchies of <iframe>s, don't use "top" -- instead use > "parent" (or parent.parent, etc) to keep your cross-frame references > relative, rather than making references to the top-level browsing context. > This is similar to how scripting libraries can use lambdas and lexical > scope to provide thin APIs without stomping all over the global namespace. > > Because the first can be worked around, I think we should leave "top" to > mean "top" in all contexts, as needed by the other two use cases. The > alternative is to introduce new mechanisms to do these cases, which just > means the Web API becomes even more redundant and complicated. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Wednesday, 28 July 2010 02:17:53 UTC