Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

On Sep 26, 2009, at 12:20 AM, David-Sarah Hopwood wrote:

> Maciej Stachowiak wrote:
>> I think there are two possible perspectives on what constitutes
>> "magnify[ing] the problem" or "widening the gap"
>>
>> A) Any new kind of requirement for implementations of object  
>> interfaces
>> that can't be implemented in pure ECMAScript expands the scope of the
>> problem.
>> B) Any new interface that isn't implementable in ECMAScript widens  
>> the
>> gap, even if it is for a reason that also applies to legacy
>
> My view is firmly B, for the reasons given below.
>
>> My view is A. That's why I pointed to legacy interfaces - if the
>> construct can't go away from APIs in general, but we wish to  
>> implement
>> all APIs in ECMAScript, then ultimately it is ECMAScript that must
>> change, so using the same construct again doesn't create a new  
>> problem.
>
> Yes it does:
>
> - In many cases, APIs are partially redundant, in such a way that
>   developers can choose to avoid some of the legacy interfaces without
>   any significant loss of functionality. By doing so, they can avoid  
> the
>   problems caused by clashes between names defined in HTML, and  
> names of
>   ECMAScript methods. If new APIs also use catch-alls, they are less
>   likely to be able to do this.
>
> - The potential name clashes created by catch-alls also create a  
> forward
>   compatibility issue: if a new method is added to an interface, it
>   might clash with names used in existing HTML content. In the case of
>   legacy interfaces, it is less likely that we want to add new methods
>   to them, and so this forward compatibility issue is less of a  
> problem.

It seems like these first two reasons are pragmatic concerns about  
fully general property access catchalls, which are independent of  
anyone's desire to implement the interfaces in ECMAScript. These  
arguments also do not apply to other kinds of extended host object  
behavior, such as array-like index access, or the fact that  
document.all compares as boolean false.

>
> - Implementors of subsets in which the DOM APIs are "tamed" for  
> security
>   reasons can choose not to implement some APIs that are problematic  
> for
>   them to support; but if new APIs are equally problematic, they  
> will be
>   unable to provide access to that functionality.

I think trying to tame the DOM APIs is a quixotic task anyway.

A common example cited is to embedding a widget via direct DOM  
embedding in a "safe" way. Presumably "safe" means you have toprevent  
the widget reading or modifying the DOM outside its subtree, prevent  
executing JS outside the sandbox, and prevent displaying content  
outside its designated bounds. To achieve this, you have to restrict  
the behavior of nearly every single DOM method, often in extremely  
complicated ways that amount to reimplementing major portions of  
browser functionality.

Consider for example the setAttribute method on the Element interface.  
You have to intercept attempts to set the "style" attribute, parse the  
CSS being set, and make sure that the widget is not trying to use CSS  
positioning or overflow to display outside its bounds. You can't just  
forbid CSS styling entirely, because that makes it impossible to make  
a decent-looking widget. previousSibling, nextSibling, ownerDocument  
all have to be prevented from going outside the tree. Any method to  
find particular elements has to be essentially rewritten to prevent  
going outside the tree, even something as basic as  
document.getElementById(). Attempts to set the "id" attribute have to  
be intercepted and the id has to be silently rewritten if it clashes  
with an id used in the embedding content, so that getElementById()  
calls by the embedder aren't tricked into manipulating the embedded  
content. Timers have to be reimplemented to make sure their JavaScript  
is executed in the sandbox. Setting <a href> to a "javascript:" URL  
has to be prevented, unless you completely override the navigation  
behavior of <a> elements. Creating plugins or Java applets has to be  
prevented, since they can't be made to follow the security  
constraints. document.write() and innerHTML have to be intercepted,  
and the contents have to be parsed as HTML to prevent any forbidden  
constructs in the markup. This is just scratching the surface, and  
we've already found that CSS parsing, HTML parsing and DOM query  
methods will have to be reimplemented (from scratch, yet in a way that  
matches what the browser does) to make this work. Note that none of  
this complexity is imposed by exotic host object behaviors, it's all  
intrinsic to the way the Web platform works. Even considering the case  
of taming LocalStorage, the catchall behavior is the least of your  
worries.

The best way to serve this kind of use case is either an <iframe> with  
postMessage, or inventing an entirely new API for embedded content  
that doesn't even try to look anything like the DOM, and just exposes  
a carefully selected set of capabilities. I don't think our time is  
well spent trying to accommodate the use case of building a security  
facade on top of the DOM.

Regards,
Maciej

Received on Saturday, 26 September 2009 19:59:40 UTC