[cap-talk] Sensory entry points (start keys) in Gnosis like systems

[Bill Frantz]

David - Sorry I'm so slow about responding. I am in New 
Hampshire where my focus is the maintenance of a 200+ year old 
house and a couple of old spinning wheels. Lets just say my mind 
is focused on the 18th century. And to make it seem completely 
primitive, I'm a WiFi gypsy, moving from hot spot to hot spot 
for my internet connectivity. :-)

On 7/19/10 at 12:18 PM, daw at cs.berkeley.edu (David Wagner) wrote:

>Bill Frantz  wrote:
>>I see I didn't adequately explain myself. These code examples 
>>show the confusion.
>>
>>The sense key provides a system enforced information diode. If 
>>you only have a sense key to an object, you will only get 
>>information from it. You will not be able to send information 
>>to it.
>
>Nitpick: I find it hard to believe that this is the right way to think
>about the definition of "sensory".  Technically, I suspect the formulation
>should be in terms of mutating the object(s) referred to by the sensory
>capability, rather than about sending information.
>
>We send information to sensory/read-only objects all the time.  Consider,
>for instance, a read-only/constant array.  To access the i-th element of
>the array, we send it a message containing the index i.  That constitutes
>sending information to the array object, however, no harm is done,
>because the array indexing operation does not mutate the array object.
>
>This is a minor nitpick.

I think maybe the disconnect is looking at the sensory 
capability as something that would be used by the normal object 
user, instead of a way of connecting the transitively read-only 
methods of an object to the objects state storage.

Let me try to articulate the goals of the design.

   * OS level assurance of the non-mutable nature of the object by
   use of the read-only methods. (The current Gnosis/KeyKOS etc.
   sense key provides for this facility.

   * Composability of objects providing this assurance so the
   read-only facits of an object may make use of the read-only
   facits of objects that object uses in its implementation.


So let our object be A, and its read-only facits are in a 
related object OA. The objects used in its implementation can be 
collectively called B and their read-only facits OB. (I'm about 
to commit ASCII art, and want to keep it simple.)


    OA -----> OB    //Read-only facit side of the OS enforced barrier
    |
    | S
---------------------------------------------------------------------------
    |
    V
    A  -----> B     //Read-write facit side of the OS enforced barrier

The sense key S allows OA to access the storage used by A to 
store its "class variables". It also allows OA to fetch 
capabilities deemed "sensory" from A.

So far this single-pair-of-objects describes what KeyKOS 
supports. What we discussed on July 16 tried to go a bit further 
and give OA a way of accessing B by using B's read-only facits 
contained in OB.

We decided that no important security assurances would be lost 
if we permitted OA to get a factory key (constructor) FOB that 
will create OB through the sense key S. Each instance of B needs 
a separate FOB because each instance of B has its own "class 
variable" storage. A sense key to this storage is a component of 
FOB. Allowing construction of:


    OA -----> OB    //Read-only facit side of the OS enforced barrier
    |         |
    | S       | S2
---------------------------------------------------------------------------
    |         |
    V         V
    A  -----> B     //Read-write facit side of the OS enforced barrier

Where S2 is a different sense key to B's class variable storage.


Please not that OA and OB are first class objects. They can 
receive any kind of parameter, have their own "class variable 
storage" etc. What they can't do is cause changes in A or B 
which are visible to A or B or their callers.

There are a lot of ifs, ands, and buts that I will leave out for 
now in hopes of leaving this overview comprehensible. Please let 
me know if this description makes sense to you.

Cheers - Bill



-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032