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

[Mark S. Miller]

Kevin Reid wrote:
> I've never seen "ocaps" used before.

We needed something short for this paper. Several people found "objcaps" ugly.


> "just those objects that ..." -- I would write this as "just those  
> objects (capabilities) that ..." to reaffirm the equivalence.

Fixed.


> "Solitaire runs with all its user's privileges" -- how about  
> "Windows's Solitaire program"; as this is, it is unobvious what the  
> referent is if one is not familiar with our traditional examples, and  
> not a Windows user.

I decided not to fix this, in order to avoid the misunderstanding that the 
hazard was somehow Windows specific.


> The figure could be improved, I think, by more emphasis on the  
> application-level objects A, B, and C - perhaps a larger label font.  
> Also, have you considered using sans-serif?

The diagrams already use sans serif. I left this alone for now.


> The significance of the numbers in the black circles is not  
> explained, though this might not be necessary.

Not explained.


> "A complete Horton implementation in Java is available from  
> erights.org/download/horton/." -- (a) Personally, I would not omit  
> the "http://" (precision, future-proofing, machine- 
> understandability). (b) Why is the implementation in Java (a non- 
> capability language) rather than E?

(a) The online PDF link is to the full URL.
(b) It now states that implementations in Java and E can be found there. I 
said Java rather than Joe-E because all Joe-E programs are Java programs, and 
many more people know what Java is. The web page at that URL clarifies further.


> "sending a reference to a proxy as the single argument of a message  
> with no return result." -- I first read this as "sending [a reference  
> to a proxy] as ...".

Your first reading was correct, so this ambiguity still needed fixing: 
"sending a proxy reference as the single argument of a ..."


> "Each player expresses Horton-level policy—such as identity-based  
> logging and revocation—by overriding these defaults, as we will see."  
> -- to what does "as we will see" refer to? I see no examples of  
> overriding in this paper (and I think there ought to be; or at least  
> a brief description of how it is feasible).

"as we will see" is gone. Thanks.


> When examining the wrapping and unwrapping, I wondered why this seems  
> more complex than the Den movement protocol; my conclusion is that in  
> the movement protocol Alice and Carol are the same entity, and  
> therefore there is no need to protect S3 against Alice; furthermore,  
> my identities provide unsealers rather than sealers, thus eliminating  
> the fill/provide logic.
> 
> Have you tried making Whos into unsealers and Bes into sealers?  
> Searching for ".seal", every occurrence is passing a resolver-oid  
> callback, which suggests that such a reversal might simplify operation.

I have not tried this. I think it would be an interesting experiment. However, 
Horton currently provides (what I have recently learned is called) "deniable 
authentication". Carol can know at the time to blame Bob for some action; but 
Carol cannot prove after the fact to a third party that Bob took that action. 
In other words, Bob can authenticate to Carol that he's responsible for the 
action; but if Carol tries to tell anyone else that Bob was responsible for 
that action, Bob can deny it.

My worry is that if we reverse the usage of seal vs unseal, that Carol would 
then be able to provide Alice with a box Alice can unseal, which Alice can 
know only Bob could have sealed, making Bob's responsibility to Carol 
undeniable (or at least less deniable) to Alice.


> The indentation mixed with omitted line numbers is slightly  
> confusing; how about giving the line numbers in a different text style?

Done. Also colored to show who is doing what. I think (hope) it helps a lot. 
Thanks!


> Lines 12, 15: No justification is given for the presence of the "t" tag.

Gone.


> Line 19: The noun is "s3slot", but its value is not a slot. This is a  
> dangerous level confusion; it obscures the fact that (26) takes the  
> current value rather than the mutable cell.

Renamed "result".


> Lines 05, 03, 12, 15: p3Desc and getGuts have their related  
> components in the opposite orders.

Fixed.


> It might be worth a note that the variables' names are according to  
> their roles in the diagram, and are not fully general.

I didn't.


> Include URLs for mentions of cap-talk and e-lang?

Easily found by googling, so I didn't bother.

Thanks again!


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

     Cheers,
     --MarkM