[E-Lang] Authority -- what is its dual?

[Mark S. Miller]

At 09:52 AM 10/19/2001 Friday, Marc Stiegler wrote:
>-- Immutable objects do not carry authority. However, access to immutables
>may be authorities. For example, access to the immutable picture of the spy
>we have in bin Laden's inner circle is a powerful authority, not one to be
>handed out lightly :-)

Given that we here mean "transitively immutable", I think this is correct.  
However, it's hard to make precise.  A transitive immutable, once 
made, is timeless.  It has whatever information it has, and if it's willing 
to give it to you at anytime, then it's willing to give it to you at all 
times.  So a spy picture conveys no authority, and neither does a ConstList 
holding that spy picture, even though it gives "access to the ... spy ...
picture".  So this can't be what we mean.

Rather, something that will give you access to a picture at a later time but 
not at an earlier time, would convey authority.  But this would mean it 
changed behavior, and so is not transitively immutable.  So we can simply 
stick with "transitively immutable" as our definition without needing to 
address "giving access to ...".

Note that an unresolved promise is not (yet) immutable, so an object holding 
such a promise is not (yet) transitively immutable.  A far reference is not 
immutable, since it can break.  Only near and broken references may be 
considered immutable.


>--  The Vector class does not convey authority. There can be, however,
>classes for which access to the class is an authority even though the class
>itself is pure computation, akin to the immutable photo above. My example is
>the Perfect Stock Predictor program, which, when fed the state of the stock
>market for the last month, perfectly predicts the state of the stock market
>a month from now. The people who create the Perfect Stock Predictor program
>would consider it a tragic loss if authority to access it were conveyed to
>outsiders, since the Perfect Stock Predictor can only predict stock in the
>absence of a second Perfect Stock Predictor user :-)

Both of these examples are really about secrets.  By my (possibly peculiar) 
definitions, secret bits are transitively immutable, and so don't convey 
authority.  Again, perhaps "authority" is the wrong word.  Saying they don't 
convey authority *doesn't* mean that we don't need to protect them.  I'm
just trying to make clear what protections are meaningful and possible.

The motivating example: When an emaker is imported, it is evaluated in the 
universal scope.  This scope should only provide objects that convey no 
authority. The emaker may also name any instance of any literal datatype as 
if these were all names in the universal scope, like "3", in order to obtain 
access to a 3.  None of these are 'deniable'.  Explaining the rationale of 
what is or is not deniable is my purpose in using the term "authority".

Are the bits which constitute the spy picture deniable to an emaker?  
Clearly not.  The emaker may already contain a literal integer that encodes 
the spy picture, or it may guess it.  If it doesn't know it and can't guess 
it, but if another emaker is on the CLASSPATH accessible to it through the 
import__uriGetter, then it may import that other emaker and (if the other 
emaker is willing), obtain the picture from it.

This raises a thorny issue: Does the import__uriGetter itself convey 
authority, or is it transitively immutable?  It is currently exactly as 
immutable as the CLASSPATH, which is often a really bad answer.  When one is 
running a packaged E application, the entirety of the CLASSPATH may be 
contained in one immutable *.jar file, in which case it truly is immutable 
and we're not yet in hot water.

OTOH, in a development environment, a developer replaces, renames, deletes, 
and inserts entries on the CLASSPATH willy nilly.  The import__uriGetter 
conveys the authority to sense such activity, and is given out in a 
non-deniable fashion to all emakers.  Although I can't figure out why this 
is a problem in practice, it's obviously a fatal problem in theory, so we 
still need to figure out what to do about this.  Dean's transformer has 
teased these issues apart some, and so is a start, about which more later.

I know you're especially interested in design of a module system for E, so 
help here would be most appreciated.


>-- A very interesting and difficult example to think about--a good
>challenge, if you will--is to think about the uri string that represents a
>capability [...several good paragraphs about this issue...]

Yes, another secret, but an important one to think especially hard about for 
the reasons MarcS explains.  For more on this, see 
http://www.erights.org/elib/capability/dist-confine.html .  The SturdyRef / 
Introducer separation was motivated by this observation of Norm's.



        Cheers,
        --MarkM