W3C home > Mailing lists > Public > public-html-comments@w3.org > July 2010

RE: iframe sandbox suggestion

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 27 Jul 2010 19:37:57 +0000 (UTC)
To: Arthur Clifford <art@artspad.net>, Artur Adib <arturadib@gmail.com>
cc: public-html-comments@w3.org
Message-ID: <Pine.LNX.4.64.1007271927440.7470@ps20323.dreamhostps.com>
On Thu, 1 Apr 2010, Arthur Clifford wrote:
> 
> I recently had to develop a launcher for opening a survey monkey survey. 
> The site had said that a survey could be in a frame, but I tried it and 
> in safari that had all kinds of issues because the way survey monkey 
> designed their site they refer to top a lot which was causing security 
> sandbox problems. They even amended their page to say they don't support 
> frames.
> 
> The problem there is that if I am a developer creating a site, I 
> shouldn't have to worry about it being embedded in another page. If I 
> want to allow that, I should be able to instruct the embedding browser 
> to treat my framed site like it was its own window where top refers to 
> the top frame in my page/site and everything my site does gets treated 
> as if it were in a tab or a new window. If I don't indicate that, say 
> I'm not so savvy but I created a cool little calculater page that does a 
> lot of referencing to top, and another developer wants to embed my page 
> via an iframe. If they do that, the calculator will break because top is 
> not the iframe but the top window. They should be able to, with an 
> attribute on the frame or iframe tag, be able to tell the browser to 
> treat that frame as a self-contained environment that can't directly 
> refer to the window or outer page. If it refers to window, it refers to 
> the frame it is contained in. Keep in mind, I'm talking about an 
> optional attribute/switch so that if you want to have a frame that is 
> aware of the rest of the page/window that should be an option too.
> 
> There's the other case of my not wanting my content frameable. Which is 
> what escaping frames is all about. True I could have a little sniffer 
> page with a script that detects whether the window's location is 
> undefined because the page in my domain is not the same as the window's 
> location (which I've done in the past). But those sorts of hacks that 
> have been used for years shouldn't be necessary in a standard that's at 
> v5. Why not tell the server the content is framed so that the content 
> providers have a choice of whether to serve their content in a framed 
> context? I'm trying to suggest an html (javascript-less) approach to 
> frame detection. Because if a user turns off javascript and I have a 
> vanilla html page I don't want framed, I can't really do much about that 
> with things the way they are. Unless I've missed something somewhere.

On Fri, 2 Apr 2010, Artur Adib wrote:
>
> I couldn't agree more with Arthur:
> 
> "[...] I shouldn't have to worry about it being embedded in another 
> page. If I want to allow that, I should be able to instruct the 
> embedding browser to treat my framed site like it was its own window 
> where top refers to the top frame in my page/site and everything my site 
> does gets treated as if it were in a tab or a new window."
> 
> Essentially, my attitude is that a sandboxed iframe should behave as a 
> "browser-in-a-browser": their top frame is their top frame, not their 
> parent's.
> 
> My problem with the existing solution to clickjacking is that it makes 
> websites that otherwise wouldn't mind being framed by a legit service 
> start frame-busting no matter what.

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).

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 Tuesday, 27 July 2010 19:38:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:04 GMT