W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: <iframe doc="">

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Mon, 25 Jan 2010 13:02:14 -0500
Message-ID: <7c2a12e21001251002v15b03ac6p3cf41c03f0bcd178@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Lars Gunther <gunther@keryx.se>, "public-html@w3.org WG" <public-html@w3.org>
On Mon, Jan 25, 2010 at 5:16 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> My understanding is that the purposes is solely defense in depth, at least until it is widely enough deployed that it can be relied on. Even then, it's probably best to combine it with a whitelist filter. Certainly the security experts I've talked to would promote its use as an additional mechanism, and if anyone asked me for advice on deploying sandboxed iframes, I would tell them the same.

srcdoc="" will likely not be usable at all until it's widely
supported.  There's no decent fallback, is there?  If it can't be used
as the sole line of defense for a simple rich-text blog comment
implementation, I'm not sure what use it has.  Defense-in-depth seems
like an overly speculative use-case -- if you already have decent HTML
whitelisting, bugs are unlikely enough that it wouldn't be worth the
hassle of also putting comments in srcdoc="".

The advantages of using <iframe sandbox srcdoc=""> as your entire
security mechanism is that 1) it's much easier than doing actual
whitelisting, and 2) it will automatically allow all new features as
they come out.  I notice that Google Reader still doesn't whitelist
<video>, for instance, although my browser supports it.

Of course, users can post obnoxious comments even if sandboxed with
scripting disabled, like audio with autoplay.  The only realistic
solution here is server-side whitelisting; an automatic browser-based
solution is too inflexible.  However, such comments don't pose an
actual security threat, so it's conceivable srcdoc="" might be useful
anyway.  I'm not sure, though.

The uses of srcdoc="" (where you want to sandbox some content that's
available to you on the server side at content generation time) might
include:

* Blog comments
* Wiki pages
* Web mail, feed aggregators, and the like

On reflection, I'm not at all sure that anyone much would use srcdoc
in a serious app -- it's probably too rigid.  It could be useful for
quick hack-ups, but I don't know if those are worth it.  Who would
actually use srcdoc?

> (To clarify relation to the thread topic, this doesn't necessarily depend on doc/srcdoc, just on sandboxed iframes in general. As far as I'm aware, srcdoc is just there to make sandboxed iframes easier to use, it is not required to get the security benefits.)

srcdoc is only useful for some types of sandboxed iframes.  It would
normally be useless for ads, tracker scripts, and things in that vein,
since those are usually included from a different server.  The
use-cases for sandbox are clearly good, but I'm not so sure about
srcdoc.
Received on Monday, 25 January 2010 18:02:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT