[cap-talk] NDAs

[Toby Murray]

On Mon, 2009-06-08 at 11:22 -0700, Mark Miller wrote:
> On Mon, Jun 8, 2009 at 1:32 AM, Toby Murray <toby.murray at comlab.ox.ac.uk> wrote:
> > Hence, I argue that NDAs can be built on any capability system in which
> > objects have access to a good source of randomness.
> 
> I think the fundamental non-delegatable permission your analysis
> relies on is the right to receive messages sent on a given reference.
> In systems like Coyotos, Flat Concurrent Prolog, Mach, Joule, or
> ToonTalk, channels have two ends (ports, whatever). One represents the
> right to place messages into the channel. The other represents the
> right to receive (or be invoked by) messages that have been placed
> into the channel. Either may be sent in messages, thereby sharing (or
> transferring) the right to directly send ot receive. Joule has both
> direct references and channels, but it is externally indistinguishable
> whether one holds a direct reference or the send side of a channel.
> 
> I do not think you analysis applies to such systems.

Suppose we have an NDA, whose subject (i.e. the object it gives
non-delegatable authority to) is Bob and target (the object that NDA
gives Bob non-delegatable authority to invoke) is Carol. Then I agree
that if NDA has a reference to the send port of a channel, to which Bob
has the receive port, then NDA won't work correctly. NDA needs a direct
reference to Bob for this to work. However, so long as NDA does have a
direct reference the pattern above (with nonces etc.) should work just
fine. Systems without direct references are problematic, however.

Just to clarify, in Flat Concurrent Prolog, I'm guessing that these
channels are unbound dataflow variables. Presumably, like in Oz, one is
able to construct "read-only" references to a variable that do not allow
the holder to bind the variable but to merely wait on its binding or
read the value to which it has been bound.

Cheers

Toby