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

Re: iframe sandbox suggestion

From: Artur Adib <arturadib@gmail.com>
Date: Fri, 2 Apr 2010 11:18:58 -0400
Message-ID: <w2obfb5ebad1004020818s42b8e624w5faccfd76a4a221c@mail.gmail.com>
To: art@artspad.net
Cc: Ian Hickson <ian@hixie.ch>, public-html-comments@w3.org
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.

-Artur



On Thu, Apr 1, 2010 at 8:21 PM, Arthur Clifford <art@artspad.net> wrote:
> Here's a case in point:
>
> 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.
>
> Art
>
> -----Original Message-----
> From: public-html-comments-request@w3.org
> [mailto:public-html-comments-request@w3.org] On Behalf Of Ian Hickson
> Sent: Thursday, April 01, 2010 4:50 PM
> To: Arthur Clifford
> Cc: 'Artur Adib'; public-html-comments@w3.org
> Subject: RE: iframe sandbox suggestion
>
> On Thu, 1 Apr 2010, Arthur Clifford wrote:
>>
>> What about providing an attribute for frames/iframes that told the user
>> agent to treat the framed content like its own window where top refer's
>> to the frames url not the top document's url. You could also specify
>> that user agents include a header of something like "Window-context:
>> frame" on get requests from framed content. That way server-side scripts
>> could detect inclusion in frames and react as appropriate.
>>
>> Flash/Flex has similar issues where you can have flash content within
>> flash, but a flash developer (for the embedded movie) might refer to
>> "root" (roughly equivalent to top) and that messes things up in an
>> embedded context. So, there's a property that can be used to tell the
>> Flash player to treat requests for root in embedded context as root for
>> the embedded movie not root for the outer (top) flash movie.
>>
>> So, generally:
>>  * Embedded/framed content needs to be flagged as embedded content
>>  * Embedded/framed content needs to be treated as if it were not embedded.
>>  * Embedded/framed content creators should be able to prevent their
> content
>> from being embedded by having access to some indicator that the content
> was
>> embedded.
>
> I don't understand what problem this solves. Can't you already do all
> this by just using 'window'?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>
Received on Friday, 2 April 2010 15:19:31 GMT

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