Re: [whatwg] Additional attribute value for iframe sandbox

[Ian Hickson]

On Mon, 30 Apr 2012, Tim Streater wrote:
>
> I'd like to request that it be possible for links in sandboxed iframes, 
> when clicked, to open in a new window. My reading of the documentation 
> suggests that in a sandboxed iframe, links are disabled except that 
> "allow-top-navigation" permits the equivalent of "target='_top'". In 
> effect, I'd like a new value that permits "target='_blank'". Testing 
> today tells me that in fact in Safari 5.1.5 at least, a sandboxed iframe 
> does not interfere in any way with links.
> 
> My use case is this. My application, a mail client, receives html emails 
> and uses an iframe to display them. A good example of such a mail can be 
> seen here:
> 
> http://www.newscientist.com/data/projects/newsletter/newsletter20120430rwau.html
> 
> (When I receive it, the recipient's email address is in the bottom part 
> of the page rather than #emailaddr#.) This is an example of a trusted 
> email which has links. At present, my application strips out scripts as 
> a primitive security measure, but I'd rather use a sandboxed iframe if 
> possible. However, a user will expect to be able to click on a link in 
> such an email and have a new window opened, separate from the email 
> client. Hence my request for a new value for the sandbox attribute.

On Mon, 30 Apr 2012, Charles Pritchard wrote:
> On 4/30/12 2:04 PM, Tim Streater wrote:
> > On 30 Apr 2012 at 21:17, Charles Pritchard  wrote:
> > > They've got an allow-popup in IE and I think WebKit. It's just a 
> > > little slow going in getting it firmly out there.
> >
> > Yes, I saw that as I worked on through the archive. But they want to 
> > enforce the same restrictions on the newly-opened window as the iframe 
> > had. I'd prefer no restrictions, but also no connection back from the 
> > opened window to its parent. IOW, just as if one had opened a new 
> > browser window and typed the URI in manually.
> 
> The about:blank +  hack is no fun; the thing used to break 
> out of origin in webkit.
> 
> I'd hoped iframe sandbox had that solved.

Well, nothing stops the user from opening any links the user wants to open 
wherever the user wants to open them. All sandbox="" does is prevent the 
page from automatically opening pages.

I'm not 100% clear on what you're trying to block with sandbox if that's 
not sufficient. Maybe if you could describe your threat model in more 
detail it would be clearer?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Additional attribute value for iframe sandbox

[Charles Pritchard]

On 4/30/12 2:04 PM, Tim Streater wrote:

On 30 Apr 2012 at 21:17, Charles Pritchard  wrote:


They've got an allow-popup in IE and I think WebKit.
It's just a little slow going in getting it firmly out there.

Yes, I saw that as I worked on through the archive. But they want to enforce 
the same restrictions on the newly-opened window as the iframe had. I'd prefer 
no restrictions, but also no connection back from the opened window to its 
parent. IOW, just as if one had opened a new browser window and typed the URI 
in manually.


Thanks for that clarification. Sandbox certainly has some subtleties.

The about:blank +  hack is no fun; the thing used to break 
out of origin in webkit.


I'd hoped iframe sandbox had that solved.


-Charles

Re: [whatwg] Additional attribute value for iframe sandbox

[Tim Streater]

On 30 Apr 2012 at 21:17, Charles Pritchard  wrote: 

> They've got an allow-popup in IE and I think WebKit.
> It's just a little slow going in getting it firmly out there.

Yes, I saw that as I worked on through the archive. But they want to enforce 
the same restrictions on the newly-opened window as the iframe had. I'd prefer 
no restrictions, but also no connection back from the opened window to its 
parent. IOW, just as if one had opened a new browser window and typed the URI 
in manually.

--
Cheers  --  Tim

[whatwg] Additional attribute value for iframe sandbox

[Tim Streater]

I'd like to request that it be possible for links in sandboxed iframes, when 
clicked, to open in a new window. My reading of the documentation suggests that 
in a sandboxed iframe, links are disabled except that "allow-top-navigation" 
permits the equivalent of "target='_top'". In effect, I'd like a new value that 
permits "target='_blank'". Testing today tells me that in fact in Safari 5.1.5 
at least, a sandboxed iframe does not interfere in any way with links.

My use case is this. My application, a mail client, receives html emails and 
uses an iframe to display them. A good example of such a mail can be seen here:

  


(When I receive it, the recipient's email address is in the bottom part of the 
page rather than #emailaddr#.) This is an example of a trusted email which has 
links. At present, my application strips out scripts as a primitive security 
measure, but I'd rather use a sandboxed iframe if possible. However, a user 
will expect to be able to click on a link in such an email and have a new 
window opened, separate from the email client. Hence my request for a new value 
for the sandbox attribute.

--
Cheers  --  Tim