[cap-talk] Delegating Responsibility in Digital Systems: Horton's "Who Done It?"

[Mark S. Miller]

Charles Landau wrote:
> In Figure 1, there are two rectangles labeled "Bob". Are these two 
> different objects? If not, did you make separate boxes just to avoid 
> a tangle of arrows? It's a little confusing either way.

All rectangles labeled "Bob" are the same object: Bob's Who. Likewise for 
Alice and Carol. Yes, we did this to avoid to avoid a tangle of arrows. We 
should probably explain this in the text.


> makeproxy does not seem to use its first parameter.

Oops, I hadn't noticed that. It's an artifact related to your next question. 
Thanks for catching this!


> What if B happens to have a getGuts method and A says b.getGuts()? It 
> appears that P1 won't forward that. I can see how to fix this, but 
> your simplified code doesn't do it.

Yes, we simplified this away. The actual Horton code also protects the 
boundary between (for example) Alice's Horton-aware objects (P1,P2) and 
Alice's app objects (A). For P1 to get P2's guts without enabling A to get 
P2's guts requires rights amplification. Their shared access to BeAlice is the 
basis for their mutual amplifiability. But by simplifying away this issue, we 
also simplified away the need for the beMe parameter of makeProxy.


> It isn't clear what the purpose of the "t" in p3Desc is.

It records what kind of encoding record is being used here, so that the 
decoder knows which decoding method to use. It corresponds to the "tracked(" 
text in the graphic. Since this simplified code only uses one kind of encoding 
record, we could get rid of it. But by keeping it, this specialized code can 
still be said to be speaking a subset of a more general protocol. Hmmm. I'm 
not sure what to do here either.


> I'm hoping the answer to most of these questions is that you had to 
> oversimplify to cram this into five pages, and these questions are 
> answered in the Java code, which I haven't read.

Yes. But the paper should be self contained without reference to the Java code.


> There's a fair amount of calling between the mutually suspicious 
> Alice, Bob, and Carol. As previously discussed (around 
> http://www.eros-os.org/pipermail/cap-talk/2006-December/006278.html), 
> there's no guarantee that these calls will return soon, if ever. For 
> example, Carol has the ability to delay forever the message from A to 
> B. In the absence of Horton, Carol is limited to delaying anyone who 
> *invokes* C, but not anyone who merely *passes* C around. I doubt 
> there's any way around this without something mutually trusted. In 
> some concurrency models (KeyKOS/EROS/CapROS), the lack of a guarantee 
> of a return will be a problem.

The Horton code in the paper is a purely sequential program, so any object 
that gets control can loop and delay everything else forever.

The actual Horton-on-Joe-E/ref_send uses communicating event-loop concurrency 
with promise pipelining, as in my thesis. In place of an s3slot variable and a 
fill function, the actual Horton uses a promise/resolver pair. Once S1 gets 
the deliver message, it initiates the activity that will eventually construct 
P3, but promptly sends to Bob a foo message with a promise for P3 as argument. 
I think the resulting Horton-mediated system is no more delay vulnerable than 
the non-mediated system would be, though we haven't really analyzed this yet. 
Also, the resulting Horton-mediated system enforces E-Order even though the 
underlying ref_send system only guarantees FIFO.

Do you think a clarification of this point is needed in the paper?


> At line 03, P1 calls an arbitrary capability passed by A. It might be 
> wise for P1 to use a primitive such as MyCap? to ensure it is talking 
> to another proxy.

We had something like this in an earlier draft, but removed it for lack of 
room to explain it. It's fair to say that this paper focuses only on 
protecting Alice, Bob, and Carol from each other. The actual Horton 
implementation additionally protects Alice's Horton objects (P1,P2) from her 
app objects (A).

If there's something short to say that helps clarify this knot of issues, I'd 
love to include it.


> "reflection", "reflective" - a term I'm not familiar with; did I 
> sleep through language class?

Reflective invocation:
   In Smalltalk,       #perform:
   In Lisp and Scheme, apply
   In Java,            Method#invoke()
   In E,               E.call()

Reflective reception:
   In Smalltalk, #doesNotUnderstand:
   In Scheme,    (lambda args ...) # note the lack of parens around args.
   In Java,      Proxy/InvocationTarget
   In E,         match <pattern> { <expr> }

Before Java called this "reflection", I don't believe earlier languages used 
this term for the above concept. Lispers used to use the term "reflection" for 
something else. But since Java, the above constructs are now all examples of 
reflection.

Would someone care to say, in a non-language-specific way, what it is that the 
above examples have in common, i.e., what reflection has come to mean?


> References: Is it customary to not give URLs for papers that are 
> available online? I'm far from any library; if it isn't online, I 
> don't read it.

For space reasons, I gave URLs only for papers not available by other means. 
Please let me know of any which aren't readily found by Google searching.


> skyhunter.com/marcs/SecurityPictureBook.ppt - would you please make 
> this available in a non-proprietary format?

Try <http://erights.org/talks/efun/SecurityPictureBook.pdf>

Thanks!

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM