W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] some thoughts on sandboxed IFRAMEs

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Sun, 13 Dec 2009 14:31:26 -0800
Message-ID: <448e9a320912131431n34ce0520t38ad8c6c70da3b8c@mail.gmail.com>
On Sun, Dec 13, 2009 at 2:00 PM, Adam Barth <whatwg at adambarth.com> wrote:

> The sandbox tag is great at addressing that use case. ?I don't see why
> we should delay it in the hopes that the <jail> tag comes back to
> life.

And Adam - as you know, I have deep respect for your expertise and
contributions in this area, so please do not take this personally...
but this really strikes me as throwing random ideas at the wall, and
seeing which ones stick.

This is sometimes beneficial - but we are dealing with possibly
revolutionary security mechanisms in the browser, meant to counter one
of the most significant unsolved security challenges on the web. And
this mode of  engineering is probably why we have a different
same-origin policies for XMLHttpRequest, DOM  access, cookies,
third-party cookie setting, Flash, Java, Silverlight... plus assorted
ideas such as MSIE zones on top of it. It's the reason why their sum
is less secure than each of the mechanisms individually.

Still, this is not an attempt to dismiss the hard work: implementing
sandboxed IFRAMEs as-is and calling it a day *will* make the Internet
a safer place. But a collection of walled off, incompatible APIs with
different security switches and knobs, all of  them to perform a
common task, does strike me as suboptimal - and I do think it's
avoidable. Especially since, I am guessing, some of the pragmatic
objections to guarded tags were probably due to implementation
complexity or dubious usability, all of which are probably moot with
@sandbox in place.

Furthermore, in this particular case, I am really concerned that the
spec is at odds with itself - you mention certain specific use cases,
but the spec seems to be after a broader goal: sandboxing
user-supplied content in general. In doing so, it gives some bad
advice (again, the user content example is exploitable, at least until
the arrival of some out-of-scope security mechanism to prevent it).

I think I stated the concerns reasonably well earlier in the thread;
but if they sound unwarranted or inflammatory, I can admit a defeat.

Received on Sunday, 13 December 2009 14:31:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC