simple modules

[Sam Tobin-Hochstadt]

On Mon, Feb 1, 2010 at 4: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 ...;
>  import Y as ...;
>
>  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.

I'm confused about the problem here.  It seems like this is the case
in both your proposal and Kris' proposal as well:

In Emaker style:

var x = (import 'x')({});
var y = (import 'y')({});

function f1() { ... }
function f2() { ... }

or in CommonJS style (even more directly):

var x = require('x');
var y = require('y');

function f1() { ... }
function f2() { ... }

In all three systems, it seems like the right thing is to explicitly
parameterize `f1' over an object providing the capabilities of X, and
`f2' similarly.  Perhaps I've misunderstood how this would work in
Emaker-style?

>> It has been my experience that most of the isolation needed between
>> modules can be accomplished by lexical scope.
>
> See above.

Here is where I think there's an important difference between the
style of isolation you want for different modules in the same software
product (maybe both written by me, but in separate areas of
functionality) and the style you want for really untrusted code, such
as code for ads on the web, or the program being edited in an editor,
or student programs in an auto-grader.  For the former, we could
simply divide the module into two, one with `f1' and the other with
`f2'.  For the latter, something much stronger is necessary - the code
shouldn't even be able to name the functionality that it shouldn't
get.  But supporting the latter requires the sort of explicit
configuration that's a very hard sell in the general case, especially
for many of the use cases of EcmaScript.

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

Unfortunately, it's also really convenient.  In an Emaker-style
language, libraries might develop the convention that everything takes
a free variable called 'dom', which gives access to the whole DOM.
That wouldn't be a good way to write secure code, but it would take
less thinking on the part of authors.  There's nothing that's going to
force people to use the system in a secure way.

> there is the goal:
>
>   "Support a statically verifiable, object-capability secure subset."
>
> How does your proposal subset down this way?

The same way that other scope and name management tools, such as
`function', do.  The strawman provides a way to program without having
the mutable global object on the scope chain, and with lexical scope.
Those both seem perfectly compatible with the subset.  It also
provides a name resolution mechanism, which resolves names to bits of
code - this is common to all of the proposals.  As in the other
proposals, there needs to be a mechanism for restricting this
mechanism, and I think we all have something similar in mind for how
that should work, based on what Kris described.
-- 
sam th
samth at ccs.neu.edu