Re: [whatwg] iframes, more sandbox
On Thu, 6 Feb 2014, Chris Coyier wrote: I'm hoping for more a little bit more control over iframes. 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 We could do this by having an allow-limited-scripts instead of allow-scripts, which doesn't allow things like alert() and confirm(). We'd need a precise list of what should be allwoed and what should not. Or, we could just kill those APIs in sandboxed iframes. How many sandboxed iframes rely on alert() in a non-annoying fashion? - Also dialogs like when a page or resource is .htpasswd protected I'm actually rather surprised that browsers still show these for iframed content. (I checked, and Firefox, Safari, and Chrome indeed do.) Maybe we should see if we could get that changed to a non-modal solution before providing a markup way to prevent it altogether. - 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). You can circumvent it via script (calling .play()). That's all, though. We could block .play() and friends via allow-limited-scripts, if that's the issue. Or we could automute all media elements and make the unmuting APIs blocked if you have allow-limited-scripts set. It's presumably ok if the user is the one that plays the audio in the iframe? Less strict: - Allow some safe version of target=_blank links Isn't that what allow-popups does? On Mon, 10 Feb 2014, Chris Coyier wrote: 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 What is alert1? 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. Web Audio would be something we could prevent if allow-limited-scripts was enabled. Or, we could mute the audio in the iframe if that was set, with a non-modal infobar allowing the user to unmute it. I'm skeptical about wanting to prevent audio when an iframe contains a video that the user started or unmuted though. - 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. If you can access the frame's Window object, the frame can access yours. So that seems like a very dangerous game. Unless you have allow-same-origin, you're not going to be able to get to the iframe contents anyway. And unless you have allow-scripts, they're not going to be running any scripts. And if you have both, you've lost. The other concern is the audio/video thing, in which an injected (say, Vimeo) iframe can autoplay. If we prevent audio, a nested iframe can't play audio. Sandbox applies to all subiframes. Stretch goal: setting some limit on memory usage by an iframe. That's somewhat up to the UA. 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. If you're allowing scripting, there's no way to tell if the data is sensitive or not. Fundamentally, a page could encrypt the data in a way that makes it look like noise. But I don't really understand what XSS you're concerned about. If you're worried about the page accessing the local origin's content, then sandboxing solves that (unless you set allow-same-origin). If you're concerned about the page running script, then sandboxing solves that (unless you set allow-scripts). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframes, more sandbox
I'm hoping for more a little bit more control over iframes. 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
Re: [whatwg] iframes, more sandbox
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 iframes. 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
[whatwg] iframes, more sandbox
Hey folks. Long time listener, first time caller. I'm hoping for more a little bit more control over iframes. 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 - Also dialogs like when a page or resource is .htpasswd protected - 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). - Cannot contain another iframe - Essentially lower the risk-of-annoyance of an iframe Less strict: - Allow some safe version of target=_blank links 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. Mike West from Google suggested I take this conversation here. Thanks Mike! --- Chris Coyier
Re: [whatwg] iframes, more sandbox
This sounds like an interesting idea, but I think it would quite easily get out of hand if people wanted some options from More Strict but not all of them, there would probably need to be a finer control of permissions. ~ Shane Hudson On Thu, Feb 6, 2014 at 3:54 PM, Chris Coyier chriscoy...@gmail.com wrote: Hey folks. Long time listener, first time caller. I'm hoping for more a little bit more control over iframes. 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 - Also dialogs like when a page or resource is .htpasswd protected - 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). - Cannot contain another iframe - Essentially lower the risk-of-annoyance of an iframe Less strict: - Allow some safe version of target=_blank links 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. Mike West from Google suggested I take this conversation here. Thanks Mike! --- Chris Coyier
