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

A

-g.

B

Ondrej

2009/4/14 Kris Kowal <cowbertvon...@gmail.com>:

B.)

Hannes

B

B.) global

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
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

On Apr 13, 2009 11:01 PM, "Kris Kowal" <cowbertvon...@gmail.com> wrote:

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

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

O.

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

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)

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

On Tue, Apr 14, 2009 at 1:55 PM, Daniel Friesen
<nadir.seen.f...@gmail.com>wrote:

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

On Tue, Apr 14, 2009 at 10:55 AM, Daniel Friesen
<nadir.seen.f...@gmail.com>wrote:

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

On Apr 15, 2009, at 6:35 AM, Mark S. Miller wrote:

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.

On Wed, Apr 15, 2009 at 6:35 AM, Mark S. Miller <erig...@google.com> wrote:

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

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

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

On Wed, Apr 15, 2009 at 11:35 AM, Kris Kowal <cowbertvon...@gmail.com>

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.

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

    Cheers,
    --MarkM

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)

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

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

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

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

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.

Wes

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

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.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

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. ;)

Wes

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