[E-Lang] draft statement of consensus

[Jonathan S. Shapiro]

hal@finney.org wrote:
> 
> Jonathan S. Shapiro, <shap@eros-os.org>, writes:
> 
> > Within capability systems, the issue is that there should be no way I
> > should receive authorities without knowing about it. The reason this
> > matters is that if I receive authorities without knowing about it, I
> > might be tricked into using them in a way I did not intend because I
> > mistakenly believe that the capability slot I invoked held some
> > authority I understood.
> 
> Can you really guarantee in a capability system that you won't receive an
> authority without knowing about it?  How can you know how much authority
> is granted by each capability you are given?  What if one of them grants
> more authority than you expect?


Hal:

These are good issues, but they are separate issues. The first step is
to know that the capabilities you *do* have don't get exchanged out from
under you. Once you have stability you can worry about what they mean.

Certainly a program can share capability state (via nodes or pointers
embedded in objects), but implicit in the very notion of sharing is that
the shared state may change. That is: you have correctly set
expectations.

The case I am concerned about is that there are many systems where I
ship you a message containing capabilities or descriptors, and the
"helpful" operating system goes and sticks them in descriptor slots for
you -- sometimes reusing those slots. The point at hand is that the
operating system should not be doing this binding for you, and that as a
programmer you would sometimes like to be able to say:

	I know that this program accepts no
	capabilities from other parties, and
	consequently that it cannot transfer
	them unintentionally.

The best place to head off such unintentional transfer is at the point
in the code where such authorities are (non)received. If you don't have
them, you are free to mismanage them safely. :-)


Jonathan