W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] iframes, more sandbox

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 07 Feb 2014 20:30:10 +0100
Message-ID: <52F53442.8080106@gmail.com>
To: Chris Coyier <chriscoyier@gmail.com>, whatwg@lists.whatwg.org
Hi Chris,

Le 06/02/2014 16:54, Chris Coyier a écrit :
> Hey folks. Long time listener, first time caller.
Thanks for participating :-)

> I'm hoping for more a little bit more control over <iframe>s. We have
> <iframe sandbox> which is pretty fantastic right now. I'd like to see some
> possibilities in both directions (more and less strict).
>
> More strict:
>   - Disallow modal dialogs (e.g. alert, confirm) but otherwise allowing
> scripts via allow-scripts
I like this. It enables to prevent sandboxed iframes from disrupting the 
user.
Maybe alongside allow-popup or as its own independent flag?

>   - Also dialogs like when a page or resource is .htpasswd protected
Is this part of the previous point or an independent addition?

>   - Do not make sound, period. Autoplay is already disabled in sandbox, but
> can be circumvented (e.g. by creating new audio element that autoplays,
> apis that create iframes (soundcloud, vimeo) that then play).
yep.

>   - Cannot contain another iframe
Why? Which problem does this solve?

>   - Essentially lower the risk-of-annoyance of an <iframe>
Do you have others in mind?

> Less strict:
>   - Allow some safe version of target="_blank" links
Can you elaborate on that?

> Right now the model for sandbox is "as strict as possible by default" then
> loosen restrictions with attribute values. So I'm not sure how this could
> be approached, since it feels like it would be weird to all the sudden make
> the sandbox attribute more strict than it was before and it also seems
> weird to have some attributes that strengthen strictness and some
> attributes that loosen it.
No worries, that can change. Wouldn't be the first time assumptions 
changes for a feature :-p

David
Received on Friday, 7 February 2014 19:30:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC