debugging interfaces

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__ /
> Setter__,


Yes, JavaScript is already pervasively reflective in a non-stratified way.
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
as well. De-facto JavaScript does have further reflective operators that do
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
> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Error/stack
> ).
>

This does violate information encapsulation and so does threaten
confidentiality. However, it provides no access and so does not threaten
integrity.


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

-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090616/bf69908c/attachment-0001.html>


More information about the es-discuss mailing list