Re: [whatwg] iframes, more sandbox

>  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?


It's part of the previous point. The overall point being "disallow any
modal from coming up from the iframe to the parent page. I'm not sure if
this is a complete list, but: alert, alert1, confirm, prompt, the one from
window.onbeforeunload, and the one from .htpasswd


>
>
>    - 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.


Awesome. This one is big in the risk of annoyingness. What I'd be curious
about is if audio/video can be prevented at a deep browser level. Like not
just fight against each possible way for code to make sound, but cut access
to whatever browser-to-computer system makes playing sound through the
browser possible at all.

I hope that's not confusing. I know precious little about this stuff. My
thinking is that since the autoplay restriction didn't help very much in
preventing sound, I can imagine further tightening like stopping .play()
from working, but then not doing anything to stop the web audio api for
instance. So rather than stop each one specifically, just neuter the whole
system.


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


The thinking here is that new iframes have a new window object. So in the
past I've dealt with annoyingness-prevention by overriding functions like
alert and confirm. But you can get around that by creating a new iframe (of
which there are rather infinite ways to do that) which gives you that fresh
window object in which to do an alert, which then pops up on the very top
parent page.

The other concern is the audio/video thing, in which an injected (say,
Vimeo) iframe can autoplay.

So this wouldn't be necessarily if both of those things were taken care of,
I suppose.


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


Stretch goal: setting some limit on memory usage by an iframe.


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


In my mind, perhaps the #1 reason to sandbox an iframe is preventing XSS.
There are so many ways to change the window location, it's awesome to have
a way to prevent them all. e.g. window["l"+"ocation"] = "http://google.com"
+ document.cookie (sigh). However, the goal (for me) isn't so much the
preventing of location changing but the danger of XSS. So perhaps it would
be possible to 1) still disallow all top location changing 2) allow
target="_blank" links that are sanitized (somehow guaranteed to not be
passing sensitive data). Maybe not possible.


>
>
>  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
>

- Chris Coyier

Received on Monday, 10 February 2014 22:59:55 UTC