Mark S. Miller
erights at google.com
Tue Jun 16 09:27:32 PDT 2009
On Tue, Jun 16, 2009 at 7:18 AM, Jordan Osete <jor at joozt.net> wrote:
> After a quick look into this PDF (very instructive, thanks), I think I
> understand the advantages of having a mirror API that is clearly distinct
> from the rest of the ES API.
> However, ES already has a number of reflection features built in, that are
> clearly not stratified. From the prototype and constructor property,
> for...in statements that allow to list properties, typeof, instanceof,
> including new ones like the functions to __define / __lookup a Getter__ /
However, none of these violate the encapsulation of the one and only
encapsulation mechanism present in EcmaScript -- functions evaluating to
lexical closure that capture the variables in their scope. All the new
reflective operators introduced by ES5 were careful to respect this boundary
violate encapsulation -- <function-instance>.caller,
<function-instance>.arguments, arguments.caller, and arguments.callee. ES5
specifies that these be disabled for strict functions so that the
encapsulation of strict functions remains defensible.
> including the actual stack traces API (like the Mozilla Stack object
This does violate information encapsulation and so does threaten
confidentiality. However, it provides no access and so does not threaten
> Also, there are a variety of environments a JS "thread" can run in today.
> For browsers, it may run in an HTML page, or in a Web worker, but it may
> also run in a command-line interpreter, and even as a server-side language.
> Will all those need different ways to get JS threads for examination ?
> As for the browser, for example (sorry, it is by far the environment I am
> most familiar with), I think it would be nice to still allow a page to
> access this mirror API to "explore" another page, without needing explicit
> user consent under certain conditions (like a same-origin policy for the
> inspector / inspected page, for example). Test suites come to mind.
> Would this kind of things be acceptable, from a security point of view ?
Not by itself, no.
> It *seems* Opera Dragonfly is using some kind of "Scope" thing as its
> mirror / proxy API (
> http://dev.opera.com/articles/view/opera-dragonfly-architecture/), and
> then the rest is pure web (Opera developers' insight would be welcome on
> that matter).
> However (still about the browser), even the proxy part can be moved to pure
> web technologies (like XHR, through some server), in a debugging lib. That
> would leave only the mirror API to define in the standard.
Will take a look. Thanks for the pointer.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss