- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Mon, 25 Jan 2010 13:02:14 -0500
- 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 UTC