[whatwg] iframes, more sandbox

David Bruant bruant.d at gmail.com
Fri Feb 7 11:30:10 PST 2014


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



More information about the whatwg mailing list