simple modules

[Brendan Eich]

On Feb 1, 2010, at 9:55 AM, Kevin Curtis wrote:

> Suppose - maybe unlikely - the client platform webcam is exposed to  
> ECMAScript in a HTML5 webapp.

The whole issue of webcam API security is important, but not in es- 
discuss, and not tied to module systems.

I dread the w3c pushing an access-control security mechanism for  
webcam access, because confused deputy attacks and remote webcam- 
jacking are guaranteed. One wants not only the webcam itself, but also  
the images captured using it, to be protected by proxies (http://wiki.ecmascript.org/doku.php?id=strawman:proxies 
) and other new tools used to implement membranes that pervasively  
mediate access. For a start!

More to say on this topic, but not here.

Anyway, modules as separately developed/deployed source units do not  
really come into play here.


> How would this be accessed in a module system:
>
> import modwebcam; // what is this? native code? do i have access to  
> it? via a container/context/global object?

Why does native code matter?

In either module system approach, first-class or second-class, nothing  
prevents a module from conveying authority, which may be unwanted or  
even hazardous. Zero-authority modules and a service registry are as  
far as I can tell advisory, not mandatory (but I haven't seen the full  
proposal yet).

Programmers can do all sorts of powerful things with objects already.  
Module systems as proposed and discussed do not add or subtract  
authority. These are separate issues.


> import JSON; // is this native code?

Why does native code matter here?


> How modules, contexts (global objects) and powerful platform  
> resources/objects/capabilities interact is interesting.

Yes, the Context separation Kris presented last week, which Dave  
advocated here on the list, is a good one. We need a strawman proposal  
on it.


> At the moment platform objects are placed in the global object. In  
> Ihab's proposal access to platform objects are parcelled out via  
> 'parametized modules'. Modules are explicity passed resources at  
> instantiation (i think).
>
> Two type of module: impure modules, which access platform modules  
> (eg xhr, dom, webcam) VS pure modules (in memory calculations).

This "impure" or "platform" vs. "pure" distinction is not enforced, or  
enforceable, under any proposal presented so far. It also has nothing  
to do with second- vs. first-class modules, AFAICT.

It's important to note again that the second-class proposal relies on  
lexical scope for isolation. Importing all exports imports static  
bindings with error on conflict, and you can selectively import (with  
renaming) if you want to control bindings in your own lexical scope.

/be