[whatwg] some thoughts on sandboxed IFRAMEs

[Michal Zalewski]

> How do I use the <jail> tag to sandbox advertisements?

Huh? But that's not the point I am making... I am not arguing that
iframe sandbox should be abandoned as a bad idea - quite the opposite.

I was merely suggesting that we *expand* the same logic, and the same
excellent security control granularity, to span and div; this seems
like it would not increase the implementation complexity in any
significant way. We could then allow these to be populated with secure
contents in three ways:

1) Guarded closing tag - this is simple and bullet-proof; but may
conflict with XML serializations, and hence require some hacks,

2) CDATA or @doc-like approaches. Less secure because it does not
enforce a security control, but less contentious, and already being
considered for IFRAMEs.

3) .innerHTML, which would be then safe by default, without the need
for .innerSafeHTML (and the associated ambiguities) or explicit
.toStaticHTML calls.

This allows people to utilize the mechanism for so many more
additional use cases without the performance and usability cost of
IFRAMEs, and does not subvert the original ad / gadget use case in any
way.

*This* is what I find greatly preferred to having separate, completely
disjointed APIs with different semantics for ads / gadgets and other
"full page" contents, for small snippets of JS-inserted HTML, and for
server-returned data.

> 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.

I am not suggesting this at all; extending the spec to cover, or at
least hint these cases would be a good idea. This is not to say the
functionality as currently speced out should be scraped. My points
were:

1) If we want to keep it limited to the ads / gadget case, we should
make it clear in the spec, reconsider the applicability of
allow-same-origin in this context, and definitely revise the as of now
unsafe getusercontent example, etc. I am not entirely sold that this
is a beneficial strategy in the long run, but as long as the
alternatives were considered, so be it.

2) If we want to make the implementation useful for other scenarios as
well, and avoid the proliferation of HTML-sandboxing APIs with
different security controls, we should still keep the spec mostly as
is, and I have no objection to implementations incorporating it; BUT
it would be beneficial to allow it to be extended as outlined above,
or in a similar general way, specifically making it easy to sandbox
inline HTML, and to place thousands of sandboxed containers on a page
without making the renderer implode.

/mz