Module isolation

Brendan Eich 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:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100111/20598918/attachment.html>


More information about the es-discuss mailing list