- From: Shane Hudson <mail@shanehudson.net>
- Date: Thu, 6 Feb 2014 16:46:35 +0000
- To: Chris Coyier <chriscoyier@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>
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 <chriscoyier@gmail.com> wrote: > Hey folks. Long time listener, first time caller. > > 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 > - 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 >
Received on Thursday, 6 February 2014 16:47:31 UTC