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

Re: iframe sandbox suggestion

From: Artur Adib <arturadib@gmail.com>
Date: Tue, 27 Jul 2010 22:17:24 -0400
Message-ID: <AANLkTinMxVgyLiiNGjpyhXAY=W-dg6js8aOyrrit=SNg@mail.gmail.com>
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 GMT

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