brendan at mozilla.com
Mon Jan 11 10:39:20 PST 2010
On Jan 11, 2010, at 8:38 AM, Mark S. Miller wrote:
> On Mon, Jan 11, 2010 at 3:03 AM, Kevin Curtis <kevinc1846 at googlemail.com
> > 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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss