Re: The <iframe> element and sandboxing ideas

Further comments after attending a talk at an IEEE security workshop (where
Ian's proposal was presented to various security experts):

1) I take back my suggestion about considering <div sandbox="..."> versus
Ian's original <iframe sandbox="..." />. Ian's original approach, although
more restrictive, does start off from a foundation based on security
concerns and then attempts to find ways to loosen them. The problem with
<div> is that if the content is not well-formed and inserts an extra
</div>, then the content after the </div> would not be sandboxed.

2) Olaf suggested that there might be another attribute to propagate
events. This is definitely highly desirable in some scenarios. Note that
the CDF WG has done some work that relates at least partially, although I
wouldn't be surprised if Ian isn't all that positive on CDF. Nevertheless,
here is the spec: http://www.w3.org/TR/WICD/. The WICD spec focuses on
various aspects of not just event propagation, but also hyperlink
propagation and focus management. All of these topics seem worthy of
consideration in terms of bridging between the host web page and any of the
iframes it embeds.

3) It seems to me that for some of the propagation areas (e.g., CSS
propagation, event propagation, focus-model integration) you would want
both the container and the component to opt-in before the propagation
occurred. For example, with CSS propagation, there may be cases where the
component only wants certain of its own characteristics to be stylable by
the parent. If you look at typical Ajax widgets, which use CSS for
controlling the visual rendering, there are some aspects which are meant to
be stylable by the developer, some aspects that are meant to be "themable"
(i.e., stylable via a shared theme), and other aspects which the widget
needs to control exclusively and should not be overridden. I would assume
that there are also security issues with allowing the parent to override
the styling of an embedded iframe because conceivably someone could invoke
a bank website within an iframe and it wouldn't be good if the parent could
override some of the CSS for the bank's website. Similarly, you probably
wouldn't want the parent frame to be able to listen to keystrokes that
happen within the child iframe (e.g., your password). For some of the
information passing between parent and child, it might be best to somehow
use a publish/subscribe mechanism like how postMessage() works, where both
both parent and child have to opt-in before the propagation occurs.

Jon


public-webapi-request@w3.org wrote on 05/22/2008 07:58:06 AM:

> FYI - We have had some discussion in and around the topic of better
> iframes at OpenAjax Alliance:
>
> http://www.openajax.org/runtime/wiki/Better_IFrames_Better_Sandboxing
>
> However, people see shortcomings with all proposals listed on that
> page. Our hope was that the HTML5 leaders would figure out a good
> approach, so I am glad to see that Ian has started discussion on this
topic.
>
> Regarding Martin's comments, I think it is a correct objective to
> find a bridge between what exists with today's browsers and what we
> hope will exist in future browsers. The Ajax community usually needs
> to get the desired result in both legacy browsers and new browsers.
>
> If you need to sandbox in today's browsers, what the community tends
> to use one of two approaches: (1) require that sandboxed components
> be expressed in a restricted subset of HTML and/or JavaScript, such
> as Caja or ADSafe or the markup restrictions for portlets, (2) place
> the sandboxed components into an IFRAME whose domain or subdomain
> differs from everything else on the page (ie, leveraging the browser
> same-domain policy to achieve sandboxing). The problem with approach
> #1 is that some functionality (potentially critical) is disabled and
> developers have to in effect learn a new language. The problem with
> approach #2 is that isolation is an all-or-nothing proposition and
> there are shortcomings with IFRAMEs, such as lack of automatic
> content sizing. Ian's proposal below addresses these IFRAME
> shortcomings directly, which is great.
>
> If I had time to think extensively about this issue (which I don't),
> I would attempt to craft a proposal that used an approach where an
> Ajax library performed the mapping between what exists today (i.e.,
> IFRAME) and what would exist in the future, where Ajax libraries
> could be eliminated once older browsers were put out of commission.
> My initial thought would be to put a 'sandbox' attribute on a DIV
> rather than on an IFRAME. That way, you end up with more powerful
> sandboxing, along the lines of what Doug Crockford proposed with his
> <module> tag. Newer browsers would deliver the sandboxing features
> that Ian is proposing below. For older browsers, someone could
> author an Ajax library that looked for DIV elements with a 'sandbox'
> attribute, and under the hood transformed the DOM such that it
> achieved sandboxing via IFRAMEs and implements the flexibility that
> Ian describes in his proposal via typical ugly Ajax hacks, such as
> passing messages via postMessage (or the even uglier fragment
> identifer approach).
>
> Jon
>
>
>
>
> [image removed] Martin Atkins <mart@degeneration.co.uk>
>

>
> Martin Atkins <mart@degeneration.co.uk>
> Sent by: public-webapi-request@w3.org
> 05/22/08 05:20 AM
>
> [image removed]
> To
>
> [image removed]
> Ian Hickson <ian@hixie.ch>
>
> [image removed]
> cc
>
> [image removed]
> whatwg <whatwg@whatwg.org>, HTMLWG <public-html@w3.org>,
public-webapi@w3.org
>
> [image removed]
> Subject
>
> [image removed]
> Re: The <iframe> element and sandboxing ideas
>
> [image removed]
>
> [image removed]
>
>
>
> Ian Hickson wrote:
> > Summary:
> >
> >  * I've added a sandbox="" attribute to <iframe>, which by default
> >    disables a number of features and takes a space-separated list of
> >    features to re-enable:
> >
> [snip list]
>
> Unless I'm missing something, this attribute is useless in practice
> because legacy browsers will not impose the restrictions. This means
> that as long as legacy browsers exist (i.e. forever) server-side
> filtering must still be employed to duplicate the effects of the sandbox.
>
> One alternative would be to use a different element name so that
> fallback content can be provided for legacy browsers. In the short term,
> this is likely to be something like this:
>
> <sandbox src="/comments/blah">
> <iframe src="/comments/blah?do-security-filtering=1"></iframe>
> </sandbox>
>
> Once a large percentage of browsers support <sandbox> authors can start
> to be less accommodating with their fallback content, either by
> filtering out HTML tags entirely (which I'd assume is easier than just
> filtering out script) or at the extreme just setting the fallback
> content to be "Your browser is not supported".
>
> This comment does not address "seamless", which seems to be orthogonal
> and can thus be equally applied to both sandbox and iframe as currently
> specified.
>
>
> [image removed]