RE: iframe sandbox suggestion

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 00:20:07 UTC