> >> -- The case where Bob changes his mind later is dealt with by Bob passing
No, he cannot. Tittle is not a pointer that can be discarded. No
matter what Bob does he still holds the title. Regardless of how
sincere he was when he gave everything to mallet, he can still get it
back just by asking, and proving that he is Bob (which though
sometimes difficult is not logically impossible even for programs).
Of course his power is IMPLEMENTED my means of third parties. In
theory title was who owned the land "in the eyes of the king"
> >> Mallet not the direct capability to the land but a revocable proxy. Mallet in
> >> any case must assume that his is what Bob has done because it is not possible
> >> for Bob to prove otherwise.
> >Exactly. If Bob cannot pass the title to Mallet, it is not
> Actually, Bob *can* pass title to Mallet if he wants to (assuming he has it to
> pass in the first place, of course). What he can't do is prove to Mallet that
> he has done so. Mallet can't know that he now has exclusivity (even if he
> actually does), because Bob can't prove that he has discarded his copy of the
> pointer. It is for this reason that we introduce a third party (the "title
> company") when we want to effect an exclusive rights transfer.
No, he cannot. Tittle is not a pointer that can be discarded. No matter what Bob does he still holds the title. Regardless of how sincere he was when he gave everything to mallet, he can still get it back just by asking, and proving that he is Bob (which though sometimes difficult is not logically impossible even for programs).
Of course his power is IMPLEMENTED my means of third parties. In theory title was who owned the land "in the eyes of the king"(the only eyes that mattered). But even the king could not revoke it once he declared it irrevocable. The power of ownership of land was not implemented as a secret encryption key, just the opposite. It was posted publicly. Any single title agency could be bribed, blackmailed, or assassinated, but if EVERYONE agreed to oust Bob he was too far gone anyway.
> >Can capabilities express non-transferable powers or not? If we can
> >have a power that can only be exercised by a particular actor, and
> >that actor is the recipient, that is a non-transferable power. I was
> >taking it as given that capabilities were by definition transferable.
> Actually, we are making a more radical claim, which is that non-transferable
> powers do not exist. Because capabilities do not allow you to express the idea
> of non-transferable powers, they are, in our opinion more in line with
> reality. Since ACLs *can* express the idea of non-transferability, they permit
> (indeed, encourage) the expression of fraudulent security promises.
I understood this from the beginning, but was giving you the benefit of the doubt. That is indeed a radical claim, it's false, but it is radical. As the maker of a radical claim, I assume you know where the burden of proof lies? Given the ease of finding counter examples, I don't think you can possibly prove that without making so many assumptions (for instance by restricting your definition of "power" to mean "secret", of course you can't keep someone from passing a secret to someone he can communicate with) that the claim becomes practically meaningless.
> The reason this is a problem is because the boundaries around an actor are not
> well defined
> Capabilities cut through this by saying
> that it is the actual behavior of the objects that needs to be controlled and
> that questions of "who" are irrelevant.
Saying doesn't make it so. "Who" IS relevant even when it's hard to pin down. Neither acls ("who" is all that matters) nor pure capabilities ("who" doesn't matter at all) capture all the things I want to do. Nor does either capture all the things I CAN do.
What's needed is something like "targeted capabilities". They would be transferable powers that can each only be used by a particular set of actors. Of course defining what we mean by an actor could be difficult, but I can see examples where it wouldn't be a person. Does anyone know of any security related task that can NOT be described in those terms?