simple modules

[Brendan Eich]

On Feb 1, 2010, at 1:48 PM, ihab.awad at gmail.com wrote:

> On Mon, Feb 1, 2010 at 9:21 AM, Sam Tobin-Hochstadt  
> <samth at ccs.neu.edu> wrote:
>> That's only the case if X, Y, and Z provide access to their internal
>> state via the bindings they export.
>
> The problem is not defending the integrity of X, Y and Z. The  
> problem is this:
>
>  import X as ...;

In the proposal, the ... is the name of a first-class object you can  
use to reference exports from X. If X exports f1 this form does *not*  
bind f1 lexically in the importing scope.

So

   import "X" as X;
   import "Y" as Y;
   X.f1();
   Y.f2();

would be a minimal example of the importing code, if I am reading  
between the lines correctly.


>  function f1() { /* operate on the authorities of 'X' */ }
>  function f2() { /* operate on the authorities of 'Y' */ }
>
> In this fashion, I cannot limit, via lexical scope, that f1 operates
> on X but not Y, and that f2 operates on Y but not X.

What exactly do you mean by "operates on X but not Y"?

In the proposal, and reading between your example's lines slightly  
(again I'm assuming X exports f1, Y exports f2), f1 is statically  
scoped to X, f2 is statically scoped to Y.

So there is absolutely a lexical scope barrier between X and Y that  
prevents f1 from operating on Y's unexported variables, and vice versa  
for f2 and X.


>> ... if I import jQuery to add some simple bit of functionality to  
>> my homepage,
>> I almost certainly want to give it access to all of the things I  
>> have access to.
>
> "Giving <something> access to all of the things I have access to" is
> _the_ problem that leads to excess authority, the separation of
> designation from authorization assuming ambient authority, and
> confused deputy vulnerabilities.

No, *allowing* an importer to bind static variables to the exports of  
a given module does not *create* ambient authority. It is an explicit  
action by the importer based on a module identifier resolved to a  
specific module. There's no ambient. The imported module exports  
exactly f1, and nothing else.

People do this all the time, it is often a necessary step when getting  
started prototyping with modules (say, when you create both importer  
and exporter at once), and it is often the end-point too.

If the module identifier and resolution machinery you've wired up make  
the importer vulnerable to more names being added over time, then  
"don't do that":

* either use a specific external-linkage identifier (often to *your*  
jquery.js, which you copied from a fixed version once and never  
updated),

* or use the other forms of import to get only the bindings you want,  
or a first-class reflection of the module from which to access just  
the exports you want.

Nothing here creates ambient authority as I understand that phrase.


> Put another way, in the following:
>
>  http://wiki.ecmascript.org/doku.php?id=harmony:harmony
>
> there is the goal:
>
>  "Support a statically verifiable, object-capability secure subset."
>
> How does your proposal subset down this way?

Far be it from me to speak for Sam, but I was involved in codifying  
this Harmony goal, and I see no conflict at all so far.

But let's not put the cart before the horse. The subset is not the  
set. If the subset excludes the import "X"; form, allowing only import  
"X": f1; or import "X" as X; forms, then we are done. First, though,  
let's get back to what you meant above by "operates on X but not Y".

Again, objects have authority and functions operate on entities. It's  
not the case that f1 can get at Y's lexical scope, or f2 at X's. This  
is key to the proposal.

/be