Re: Non-Delegatable Authorities in Capability Systems

Thanks again for the clarification.

(This message is being cross-posted to e-lang, since some of its content
is most relevant there. Direct replies accordingly.)

In order to get the paper back onto a solid foundation, while ensuring
it requires as little modification as possible (since it went through
two rounds of review before being accepted), I think the right thing to
do is to define a subset of E that /does/ enforce the (stronger)
non-delegatability-of-returns property and state that we are using that
subset for code examples. Then amend the comments about E enforcing
non-delegatability-of-returns and cite an example like Joe-E instead.

I'm not absolutely convinced that "(delegatable) single-use return
capabilities" is strong enough, since with these, Bob can share in a
manner not equivalent to proxying, since he doesn't get to vet the
invocation that is going to be performed. 

I'm hoping you can help me define a suitable subset of E that does
enforce the stronger non-delegatability-of-returns property, which also
includes the subset of E that we've used currently in the paper (as
described in the Appendix).

The property that I'm after is that, when A invokes B, that B always has
the final say about the results returned to A.

At first glance, it appears that one needs to disallow (at least) the
keywords

method
escape

and stipulate that each vat runs a single turn only (in order to cover
the case you pointed out in which one delegates a resolver and returns
the corresponding promise). 

Would that be enough?

Regarding:

On Mon, 2007-12-10 at 17:16 -0500, Kevin Reid wrote:
> >> Minor comment: I expect that the actual results in a "buggy  
> >> delegator" scenario depend on the exact mechanism used for  
> >> upgrading the buggy program (what level of the system is  
> >> replaced); i.e. the examples, containing no upgrade hooks, are  
> >> unrealistic. Some upgrade hooks might defeat the no-delegation-of- 
> >> future-replies property.
> 
> I'd like to call your attention to this; any upgrade mechanism will  
> either involve some sort of interposition, thus adding a potentially- 
> problematic (depending on its design) layer to the semantics you're  
> concerned with, or will involve restarting a vat with new code, and  
> therefore be necessarily the distributed case.

I see what you mean and agree that the scenario, as currently put, is
totally contrived. That said, the paper is more concerned with whether
one can express non-delegation at all, and (perhaps cowardly) sidesteps
the issue of whether the NDA implementation would be practically
applicable in real software. I tend to believe that perhaps
non-delegation is unnecessary in real software. However, conventional
wisdom tells us that one cannot express non-delegatability in any
capability system. It is this point that the paper is really trying to
challenge.