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

[whatwg] iframes, more sandbox

From: Chris Coyier <chriscoyier@gmail.com>
Date: Thu, 6 Feb 2014 07:54:34 -0800
Message-ID: <CAESLD-4unc=fYJN=1hMOHZJ37RcC1hxr-d_UjFr1XJ7bSpNqoA@mail.gmail.com>
To: whatwg@lists.whatwg.org
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 15:55:23 UTC

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