On Jan 11, 2010, at 8:38 AM, Mark S. Miller wrote:
On Mon, Jan 11, 2010 at 3:03 AM, Kevin Curtis <[email protected]
> wrote:
Re isolation, sandboxing - and modules.
Is there is a case for the ability to 'configure and freeze' a
global object for sandboxing, SES and maybe modules. Indeed the
'restricted eval' can be seen as more specific case of an eval which
takes a 'configured and frozen global' environment. With a frozen
global all bindings should be able to be resolved at the time eval
is called. Effectively, restricted evaled code will have 'const x =
<object>' binding added to it's scope - where 'x' is a property from
the configured global object.
N.B - if a restricted eval takes a second param as a string to
configure the 'global environment' for the evaled code then it would
avoid the closure peeking issue.
What's the "closure peeking issue"?
I hate to jog your memory on this, since you seem to have forgotten,
which must be a happier state than remembering:
http://peter.michaux.ca/articles/module-pattern-provides-no-privacy-at-least-not-in-javascript-tm
Fixed in Firefox 3.5, even with two-arg eval still present.
Just by following the ES3 book, we should not add a second argument to
eval in the future. Chapter 15 intro beefed up language in ES1 and 2
that was weak about implementations adding arguments to standardized
builtins. It's a no-no.
So any better eval will have to be eval.better() or Object.betterEval
or some such name added in a safer-to-extend object than the global
object or any standardized builtin's prototype object.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
