[modules] Global Free Variable

68 views
Skip to first unread message

Kris Kowal

unread,
Apr 14, 2009, 2:01:05 AM4/14/09
to serv...@googlegroups.com
And here's another somewhat non-contentious proposal. This would be
an amendment to the securable modules proposal:

1.) The free variable "global" must be available to a module.
2.) The "global" object must contain all of the standard JavaScript
primordial variables (including Object, Array, String, Date, and
Math).
3.) Interoperable modules may use the free variable to access
primordial objects directly.
4.) "global" may be frozen in secure sandboxes.
5.) "global" and its contents must be identical in all modules from a
given sandbox.
6.) "global" and its contents must be identical in all modules for all
secure sandboxes.
7.) "global" and its contents must be identical in all modules for all
permissive sandboxes.

5, 6, & 7 are intended to guarantee that instanceof identity can only
break for the primordial objects straddling the boundary between
secure and insecure sandboxes. Thus, all secure sandboxes can share
one deeply frozen global scope and are guaranteed to not communicate
across that channel, and all permissive sandboxes can monkey patch
their common globals and be guaranteed to be able to communicate
across that channel.

This bike shed comes in several possible hues:

A.) GLOBAL
B.) global
C.) __global__
D.) g4l
E.) none of the above. Instead: ________
F.) none of the above nor any other free variable for directly
accessing the global object

Show of hands?

Kris Kowal

George Moschovitis

unread,
Apr 14, 2009, 2:15:29 AM4/14/09
to serverjs

> Show of hands?

A

-g.

Ondrej Zara

unread,
Apr 14, 2009, 2:30:31 AM4/14/09
to serv...@googlegroups.com

This bike shed comes in several possible hues:

A.) GLOBAL
B.) global
C.) __global__
D.) g4l
E.) none of the above.  Instead: ________
F.) none of the above nor any other free variable for directly
accessing the global object

Show of hands?


B


Ondrej

 

Kris Kowal



Hannes Wallnoefer

unread,
Apr 14, 2009, 3:04:40 AM4/14/09
to serv...@googlegroups.com
2009/4/14 Kris Kowal <cowber...@gmail.com>:
>
> B.) global

B.)

Hannes

Tom Robinson

unread,
Apr 14, 2009, 3:23:32 AM4/14/09
to serv...@googlegroups.com
B

Kevin Dangoor

unread,
Apr 14, 2009, 7:22:27 AM4/14/09
to serv...@googlegroups.com

Mark Miller

unread,
Apr 14, 2009, 7:56:02 AM4/14/09
to serv...@googlegroups.com

E. I don't much care what other name is chosen, but I plead for anything but 'global'. Since it should normally have *only* primordials, it is not the EcmaScript global object, so we should not choose a name that encourages confusion.

For concreteness, I suggest 'primordials'.

--markm's android

Ondrej Zara

unread,
Apr 14, 2009, 8:46:10 AM4/14/09
to serv...@googlegroups.com

E. I don't much care what other name is chosen, but I plead for anything but 'global'. Since it should normally have *only* primordials, it is not the EcmaScript global object, so we should not choose a name that encourages confusion.

For concreteness, I suggest 'primordials'.


Under these circumstances, I vote for "B (global) as a reference to the common top-level global object (window at client)".

O.

 

Wes Garland

unread,
Apr 14, 2009, 9:17:30 AM4/14/09
to serv...@googlegroups.com
I think "what's this for?" needs clarification.  Mark Miller's post underscores this.

Personally, I don't like the ideas of modules being able to "reach up" and add arbitrary properties to the global object without the program author explicitly authorizing it.  And the program author can explicitly authorize it with a statement like "const global = this;" at the top of his program.  I don't think it speaks to a security issue or anything, though; I just think it's an unnecessary language feature which will encourage poorly-written programs.   (For example, I see people writing modules which graft their classes onto global because they don't grok require()).

If it is just a container for the standard classes, similar to the frozen standard classes used by the proposed sandboxes, then global is a terrible name.  "primordials", or something, would be far better.  And I'm not sure what the point of that would be either.

Got any use cases?

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

Daniel Friesen

unread,
Apr 14, 2009, 1:55:51 PM4/14/09
to serv...@googlegroups.com
I see no reason to use anything other than B.) global

Use of `global` has already been established. I know jslibs uses it, and
I'm pretty sure there are already a number of other places where global
is already established as the global object. To be honest global may not
actually come from jslibs but may actually be part of spidermonkey.

~Daniel Friesen (Dantman, Nadir-Seen-Fire)

Wes Garland

unread,
Apr 14, 2009, 2:01:39 PM4/14/09
to serv...@googlegroups.com
> To be honest global may not actually come from jslibs but may actually be part of spidermonkey.

It is not. The global variable is unnamed in JSAPI.  If it has a name, it's because you've given it one.  Global doesn't even need to be a generic JavaScript object, you could make it an instance of Date() if you were sufficiently insane.

(and actually, changing global to have a non-standard resolve hook could make certain types on embeddings really interesting; think cross-language glue)

Wes

Mark S. Miller

unread,
Apr 15, 2009, 9:35:49 AM4/15/09
to serv...@googlegroups.com
On Tue, Apr 14, 2009 at 10:55 AM, Daniel Friesen <nadir.s...@gmail.com> wrote:

I see no reason to use anything other than B.) global

Use of `global` has already been established. I know jslibs uses it, and
I'm pretty sure there are already a number of other places where global
is already established as the global object. To be honest global may not
actually come from jslibs but may actually be part of spidermonkey.

IIUC Kris Kowal is not proposing to provide access to the actual global object. If he were proposing that, then I would simply argue that no additional mechanism for providing such access should be provided. If, as I'm assuming, he is proposing something other than the global object, then please name it anything other than "global", or omit it. What problem are we solving?



--
   Cheers,
   --MarkM

Tom Robinson

unread,
Apr 15, 2009, 9:59:30 AM4/15/09
to serv...@googlegroups.com

I'm pretty sure it actually is (effectively) the global object, or at
least that's how it's currently implemented in Narwhal.

Following up on your previous post, the spec doesn't say it should
*only* contain primordials, just that it must contain *at least* the
primordials. Perhaps the spec needs some clarification.

Kris Kowal

unread,
Apr 15, 2009, 2:29:29 PM4/15/09
to serv...@googlegroups.com
On Wed, Apr 15, 2009 at 6:35 AM, Mark S. Miller <eri...@google.com> wrote:
> What problem are we
> solving?

This is an interoperability problem. Narwhal was using __global__,
Hannes used global, Narcissus used GLOBAL. Furthermore, in most of
the implemented loaders, "this" isn't guaranteed to The variable is
only useful in permissive systems where it's used my non-securable
modules to patch the globals to bring them all up to speed with the
standard.

In a secure box, it has the nominal utility of making it possible to
read up to the real globals, behind locals by the same name.

(function () {
var Object = function () {};
Object.prototype = new global.Object();
})();

In a secure box, "global" would be deeply frozen, so the feature does
not compromise security. It however does present a hazard for people
intending to write interoperable modules. We could go the alternate
route and attempt to block all attempts to get a mutable reference to
the global object. Wes Garland's GPSEE loader inadvertently does this
by making the default "this" for functions called as functions (as
opposed to called as member functions) is the module scope object,
which contains only "require", and "exports". Unless Wes has made a
deliberate attempt to expose the true global object with all of its
primordials, and unless scope.__proto__ leads back to it, there is not
way to grab a reference to the "global" object. I believe Helma NG
uses the same strategy of executing modules in fresh contexts with a
context scope begat of the primordial/global. Helma NG compensates by
providing "global" though.

At this point, I posit that if the global object is available, it
ought to have the same name in all implementations. I think the
consensus is that name ought to be "global". I think there's a need
for it in Narwhal. I've expunged most of the GLOBAL references in my
fork of Narcissus since they were silly and non-modular, so that's a
non-issue.

Kris Kowal

Kris Kowal

unread,
Apr 15, 2009, 2:35:09 PM4/15/09
to serv...@googlegroups.com
On Wed, Apr 15, 2009 at 11:29 AM, Kris Kowal <cowber...@gmail.com> wrote:
> Hannes used global, Narcissus used GLOBAL.  Furthermore, in most of
> the implemented loaders, "this" isn't guaranteed to   The variable is
> only useful in permissive systems where it's used my non-securable

Sorry for the incomplete sentence. "this" isn't guaranteed to be any
object in particular by the securable modules proposal, and it
naturally varies form implementation to implementation. In Chiron,
it's the global. In GPSEE, it's the module scope, which just contains
"require" and "exports". I presume it's the same in Helma NG as in
GPSEE from what little I know about that implementation. Furthermore,
(function () {return this})() returns global in Chiron and Narwhal,
but returns the module scope in GPSEE. There is neither an explicit
name for "global", nor a reliable, cross-platform hack.

Kris Kowal

Mark Miller

unread,
Apr 15, 2009, 3:17:35 PM4/15/09
to serv...@googlegroups.com
On Wed, Apr 15, 2009 at 11:29 AM, Kris Kowal <cowber...@gmail.com> wrote:
>
> On Wed, Apr 15, 2009 at 6:35 AM, Mark S. Miller <eri...@google.com> wrote:
>> What problem are we
>> solving?
> [... good explanation of currently popular antipattern ...]

We need to distinguish between paving cowpaths and paving tarpits. We
should not add new standard features whose only uses are bad coding
practices.

> In a secure box, it has the nominal utility of making it possible to
> read up to the real globals, behind locals by the same name.
>
> (function () {
>    var Object = function () {};
>    Object.prototype = new global.Object();
> })();
>
> In a secure box, "global" would be deeply frozen, so the feature does
> not compromise security.

You contradict yourself. On a browser page, the true global object
contains bindings for all sorts of dangerous authority such as
"window" that cannot be removed or made transitively frozen. So the
outer scope available to a module in a secure sandbox must not be the
true global object, but rather an authority-free object such as
transitively frozen[1] primordials.

> At this point, I posit that if the global object is available, it
> ought to have the same name in all implementations.  I think the
> consensus is that name ought to be "global".

I'm very glad to hear we're looking for consensus. The EcmaScript
committee has been an interesting lesson in consensus. Ecma operates
by consensus, which is in a purposely vague gray area between majority
and unanimity. During the >1 year I've been there, we have never
decided anything by vote. A single strongly felt objection has often
been enough to stop us from declaring consensus. Had we operated by
majority, we'd be stuck with ES4 and JavaScript would be doomed. Two
years ago or so, Doug Crockford was the only dissenter -- like the
Henry Fonda character in Twelve Angry Men, As a result, with ES5 and
generally good ideas going into ES-Harmony (probably to become ES6),
despite a committee process, JavaScript looks likely to actually get
better over time.

I also plead with everyone who voted for any spelling of "global" to
publicly retract their vote, in order to withdraw their contribution
to this apparent consensus.


> I think there's a need for it in Narwhal.

That is the critical issue. What is this need?

>  I've expunged most of the GLOBAL references in my
> fork of Narcissus since they were silly and non-modular, so that's a
> non-issue.

[1] Currently, Cajita's primordials allow "Math.random()" and "new
Date()" even though these are necessarily not transitively frozen.
Although these initially seemed mostly harmless, we are reconsidering
this decision.

--
Text by me above is hereby placed in the public domain

Cheers,
--MarkM

Wes Garland

unread,
Apr 15, 2009, 3:23:55 PM4/15/09
to serv...@googlegroups.com
>  There is neither an explicit name for "global", nor a reliable, cross-platform hack.

Following scope.__proto__ probably works in GPSEE, but that's obviously not cross-platform since __proto__ is moz-derived IIRC.

One reliable cross-platform hack which *should* work as-intended is "const global=this" inside a PROGRAM, not a module.

Interestingly enough, this doesn't work exactly as expected in GPSEE, although I don't there could be any programs where that matter.  GPSEE runs modules in scopes, the program module's scope is between the "true" global and the sub-modules' scopes.  I may re-think that particular approach, though -- I'm not happy with having module scopes be children of other modules' scopes, as this may expose some wackiness when the same module is included from multiple other modules.  I'll probably change GPSEE so that all module scopes are direct descendendants of global.

GPSEE's module scopes are also analogous to GPSEE's thread scopes. I'm not crazy about read-write escaping from threads into the global object. Actually, I'm not even crazy about threads with a shared mutable global; I may re-implement with something like a sandbox.

So, ah, where were we? Ah, yes. "global" vs "GLOBAL" -- global wins with me.  Any way you look at it, implementation is absolutely trivial.

I'm still on the fence about whether it's needed, or if its existance will encourage poor programming habits. Can you suggest a couple of problems which can't be solved elegantly without naming global?

Wes

Mark Miller

unread,
Apr 15, 2009, 3:27:38 PM4/15/09
to serv...@googlegroups.com
On Wed, Apr 15, 2009 at 11:35 AM, Kris Kowal <cowber...@gmail.com>

> Furthermore,
> (function () {return this})() returns global in Chiron and Narwhal,
> but returns the module scope in GPSEE.

Note that in ES5-strict code, this returns either null or undefined.
(Each was argued for, but I forget which we settled on. Either are
safe.)

The ES3 or ES5-non-strict standard behavior, of returning the global
object, is indeed one of the worst hazards faced by those attempting
to secure JavaScript. Even when sandboxed code cannot express this
directly, for example by restrictions on use of "this", this behavior
within trusted code makes it abusable, leading to privilege escalation
attacks.

> There is neither an explicit
> name for "global", nor a reliable, cross-platform hack.

Whew. Good riddance.

Daniel Friesen

unread,
Apr 15, 2009, 4:35:05 PM4/15/09
to serv...@googlegroups.com
I plea not a vote, but an argument.
My rationale towards the use of "global" over any other spelling of
"GLOBAL", "__global__", etc...

window, this, self (window.self), exports, require(), const, new,
arguments, ...
Using simple lowercase words for core things has been a longstanding
standard pattern in JavaScript and is even continued on in the ServerJS
spec with things like exports and require();

ALLCAPS is a constant naming tradition that comes from outside of
JavaScript. While it is a nice tradition for naming constants, it's not
really relevant to the global object to warrant using GLOBAL. While we
may use a const declaration to define the global what we are defining
here is effectively "window" given a more generic term relevant outside
of the browser ie: "global" so keeping with the same style pattern as
"window" makes the most sense.

__doubleUnderscore__ is a pattern used mostly as I've seen it by
SpiderMonkey (__defineGetter__, __proto__, __count__, ...) but it is
used mostly in off cases you won't use to often (with the exception of
getters/setters and iteration which I personally use a fair bit). But in
any case, as with the argument above it's not something that coming from
a plain JS background I would expect in the least.

I honestly can't see any real argument for naming the global object
anything other than `global` given that it is the generic equivalent of
`window` which already follows a common style format which many people
are likely to expect.

~Daniel Friesen (Dantman, Nadir-Seen-Fire)

Kris Kowal

unread,
Apr 15, 2009, 5:14:22 PM4/15/09
to serv...@googlegroups.com
Mark and I just had a chat. We agree that "global" is not useful
inside secure sandboxes, and that only things that must work inside
secure sandboxes need to be standardized. That is, "global" is only
useful in platform-specific code for patching up the environment to
look like the standard global environment. To that end, it can be
different in every platform and simply not used in the standard
library. Furthermore, it should not be available in sandboxes.

Kris Kowal

Kevin Dangoor

unread,
Apr 15, 2009, 8:25:47 PM4/15/09
to serv...@googlegroups.com

That makes good sense to me. So, that means that "system" will no
longer be global, but will strictly be a module, correct?

Kevin

Kris Kowal

unread,
Apr 15, 2009, 8:43:35 PM4/15/09
to serv...@googlegroups.com
On Wed, Apr 15, 2009 at 5:25 PM, Kevin Dangoor <dan...@gmail.com> wrote:
> That makes good sense to me. So, that means that "system" will no
> longer be global, but will strictly be a module, correct?

I think that's an orthogonal issue. As far as I know the stances on
that issue are:

Hannes: system should be a module
Ihab: system should be a free variable
Kris: both
* in a secure box, the system module exports should be a copy of the
system free variable.
* in a permissive box, the system module should be available as a free variable.
* that is to say that the system module cannot be a part of the
standard library; it has to be hosted by the platform and conform to a
standard.
Everyone else: tacit so far.

Kris Kowal

Wes Garland

unread,
Apr 16, 2009, 12:54:56 PM4/16/09
to serv...@googlegroups.com
Everyone else: tacit so far. Except Wes.
Wes: system should be a module.

My logic: namespace pollution is always bad, and the name system is bound to be used by something else out there.  The penalty, "const system=require('system');" is simply not enough to justify the downside.   Module load time is a red-herring, module could be statically linked with-compile time symbol resolution (GPSEE does this). Additionally, the consistent interface for exposing new functionality (require everything) means that conformant implementations can be simpler, smaller, and thus have a smaller authoring/debugging footprint.

Kevin Dangoor

unread,
Apr 16, 2009, 1:01:37 PM4/16/09
to serv...@googlegroups.com
On Thu, Apr 16, 2009 at 12:54 PM, Wes Garland <w...@page.ca> wrote:
> Everyone else: tacit so far. Except Wes.
> Wes: system should be a module.
>
> My logic: namespace pollution is always bad, and the name system is bound to
> be used by something else out there.

As long as the name "system" can be overridden then it's not such a
big deal (much like the contents of Python's __builtins__ module). If,
as a module author, I can just do:

var system = 1;

and have system == 1 for the rest of my module, I'm not too worried
about the pollution.

That said, I think I'm leaning toward system as a module. Frankly, I
think use of the system module will largely be behind other,
higher-level modules more often than not.

Wes Garland

unread,
Apr 16, 2009, 9:41:10 PM4/16/09
to serv...@googlegroups.com
> var system = 1;
> and have system == 1 for the rest of my module, I'm not too worried
> about the pollution.

That depends also on modules executing in non-global scopes (which are children of global).

Which, by the way, I'm also in favour of.  Just thought I'd point out that you were, too. ;)

myller

unread,
Apr 17, 2009, 11:19:37 PM4/17/09
to serv...@googlegroups.com
B) global

lowercase words for this kind of stuff has been a JavaScript tendency. __word__ is too platform specific and shouldn't be used.
Anyway, AFAIK, 'global' would be just a non-rewritable object (like window on browser is), so it should be written in lowercase.
--
E. Myller ( www.emyller.net )
Reply all
Reply to author
Forward
0 new messages