global object in strict mode

David Bruant bruant.d at
Fri Aug 24 11:25:05 PDT 2012

Le 24/08/2012 20:15, Mark S. Miller a écrit :
> On Fri, Aug 24, 2012 at 10:51 AM, Brendan Eich <brendan at
> <mailto:brendan at>> wrote:
>     Kris Kowal wrote:
>         On Fri, Aug 24, 2012 at 10:41 AM, Brendan
>         Eich<brendan at <mailto:brendan at>>  wrote:
>             I'm not sure what the problem is -- I read the old thread,
>             and noticed the
>             solution:
>             var global = Function("return this")();
>             This is good for any code mode, strict or non-strict. Does
>             CSP ban Function
>             as well as eval?
>         CSP does forbid the Function constructor, by the edict "Code
>         will not
>         be created from strings".
> Section 4.2 "If unsafe-eval is not
>         allowed..."
>     Sure, makes sense (I think I even knew that once -- have to catch
>     up on CSP when I have some time, next millennium :-P).
>     Is it common to want an expression, usable in any context
>     (non-strict, strict, CSP, deep in a function nest with potentially
>     many names in scope, some of which might shadow globals), that
>     evaluates to "the current global object"?
>     JS libraries do things like
>     (funciton (global) {
>       // all the code here
>     })(this);
>     and that works, as well as the brute force
>     var global = this;
>     approach. But one must take care not to shadow the name.
>     Could ES6 add a predefined global property named 'global', set to
>     reference the global object? I suppose maybe - it would be
>     writable or (to use WebIDL's term) [Replaceable]. We can't just
>     make a const global, we will break extant code.
>     Is this global global important to standardize?
> It is important to not standardize. The global provides essentially
> the full authority provided by that frame. CSP restricts eval and
> Function presumably for some security reason ;). ES5/strict prevents
> ambient access to the global because it leads both to bad software
> engineering and to security holes. SES makes use of that inability to
> provide a virtualized global to untrusted code executing within the
> frame. SES virtualizes Function and eval at the same time, which
> prevents backdoor access to the real global.
Not saying that I'm in favor of a global global, but SES could provide a
virtualized global when untrusted code asks for the free variable
"global" as it certainly does with the "window" and "frames" variable.

When it'll be possible to have the virtualized global as a proxy, it
will be possible to even dynamically replace accesses to the global
object with the vitualized object regardless of how it's been aliased.

My point being that adding a global global does not increase the
security hazard.
I however agree it sort of sends the wrong message.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list