[modules] Global Free Variable

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

B.)

Hannes

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: [email protected]
blog: http://www.BlueSkyOnMars.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

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.

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

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

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

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.

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.

That is the critical issue. What is this need?

[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

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.

Whew. Good riddance.

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

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

Kevin

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

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.