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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
