[cap-talk] Are Guards Ambient Authorities?

Kevin Reid kpreid at mac.com
Thu Oct 8 09:32:43 PDT 2009


On Oct 8, 2009, at 10:19, Grant Husbands wrote:

> Kevin Reid wrote:
>> These are not ambient; they are "well-known".
>
> Fair point. I'd managed to misunderstand "ambient" as meaning
> 'available to all code', but these are fully designated and so aren't
> ambient. My apologies to all.
>
> "Well-known" appears to mean 'part of the set of designated
> operations/objects available to all code by default'.

Essentially yes.

There's another aspect: objects like the integer guard are often hard  
to *exclude*; e.g. I can extract the integer guard from  
the .__getAllegedType() of any object which alleges to have a method  
accepting integer arguments.

>> (It's also debatable whether they're "authorities".)
>
> The way I think of things, and the way I thought OOP/ocap dualism
> worked, all objects are authorities, but that seems to disagree with
> accepted terminology and is also perhaps not useful; I'll try to
> correct my usage.
>
> In terms of objects, are all objects that can access (not necessarily
> mutate) mutable state considered authorities? (This wouldn't seem to
> cover all possible implementations of unsealers/brands, but maybe they
> aren't authorities.)

Anything that reads or writes mutable state is definitely an  
authority. Any sealer or unsealer is too.

I don't know how to classify an object definitively as "not an  
authority". Looking at the case of sealers, perhaps "is not a  
participant in rights amplification" also applies, but is that an  
exhaustive list?

>> In general, *data structure* guards may be well-known; guards for
>> external authorities (and possibly even for internal ones, mutable
>> objects?) should not.
>
> An interesting summary. If I run across code that uses integer guards
> but really only needs some simpler guarantees, though, it sounds like
> I can control the environment the code runs under in order to effect
> laxity, anyway, if I'm brave.
>
> Also, don't most types have some implicit interface contract that is
> not just method signatures, and isn't this part of what guards are
> used to protect?

Yes. Method signatures by themselves are worthless.

In principle, it is possible to use the auditor facility to guard on  
objects obeying some particular contract and yet otherwise be  
arbitrarily implemented. In practice, this is a hard problem (it boils  
down to correctness proofs, so you can do it semi-easily for limited  
programs and not at all for arbitrary programs).

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>






More information about the cap-talk mailing list