simple modules

[ihab.awad at gmail.com]

On Mon, Feb 1, 2010 at 10:20 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Feb 1, 2010, at 1:48 PM, ihab.awad at gmail.com wrote:
>> "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.

I will try to explain what I meant by ambient authority in this case.

Assume I am the code of a module, by the 2nd-class proposal, with
access to some module -- call it "fs". This module, being stateful,
contains authority, such as read/write authority to some portion of
the filesystem in my installation.

I now wish to construct an object, running some code, which has no
access to the filesystem. I wish to do so because either or both of
the following is true: (a) this object will eventually contain
untrusted code; or (b) this object does not *need* access to the
filesystem, and I wish to confine it based on least authority so as to
better reason about the flow of authority in my system.

Because any object I create in my Context is capable of gaining access
to the filesystem simply by uttering "import fs", the "fs" authority
is ambient in my Context.

(This reasoning also applies to the case where "fs" has little powers,
but I wish to construct *two* objects which are unable to establish a
mutual communication channel simply by uttering "import fs".)

These patterns *are* precisely what is meant when we talk about an
object capability language. They are precisely what must be supported
by an object capability subset of an existing language.

As I noted in reply to Allen, the 2nd class proposal simply relegates
these patterns to the Turing tarpit.

It is worthwhile to ask whether support for these patterns belongs in
a module system. The 2nd class proposal claims that they are
orthogonal. If the tarpit is acceptably the only place where object
capability programming may happen, they are. Otherwise, they are
simply pervasive concerns that should inform every part of our system
design, much as do other concerns such as ease of use, clarity, and
contribution to runtime performance.

The pervasive concern of the need to program in an ocap manner informs
the module discussion by noting that, where I load a module, I am
delegating to some other code. I wish to modularize *my* code by
reasoning in the large about the effects of the module I am loading.
Part of reasoning in the large about this code is reasoning about the
flow of authority that it may manipulate. This code to which I
delegate is "foreign" to varying degrees: it may be code I wrote 5
minutes ago, or it may be a component from a completely untrusted
author. This quality of foreign-ness is on a continuum; 2 extreme
solutions (easy and loose; difficult and secure) are not adequate to
describe the richness of cases I will encounter. I will delegate
authority to that code in relation to both its need for authority and
my ability to make myself vulnerable to that code -- *including* (and
this is a key point) its unintended consequences and vulnerabilities.

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

... which copy, while a fixed known, contains known unknowns: the
vulnerabilities and unintended consequences I noted earlier.

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

... which brings us to the tarpit.

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

Yep, we both agree on this point.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA