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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
