Since the earliest vestiges of capability design it has been possible to pass capabilities in messages.
Yet there are some ramifications that have not been described as far as I know.
When you send me a capability parameter P, have I any means of knowing what it means to invoke P other than what you tell me?
I may need better assurance of some critical properties of P.
Invoking P tells me nothing beyond what you tell me about P; I must assume that P replies just as you have programmed it to reply.
Keykos, and earlier systems I think, provide certain means for me to draw some conclusions about P beyond what you tell me.
What I do with P to gain such assurance has many names.
Here are some:
- vetting P
- learning the provenance of P
- verifying P’s authenticity
- examining P
I make no technical distinctions here; each expression has useful connotations.
Means for me to ‘examine’ P seem all to fall into some synergy pattern.
Indeed the ramifications I examine here are parallel to the issues of introducing synergy into the platform.
In each synergy pattern I rely on some other object that I did not get from you to tell me whether I can safely use P.
I pass P to it and it replies yes or no.
Each of these synergy patterns that I have used to solve integrity problems is equivalent to verifying that P is of some particular class, for some ordinary concept of class.
More general patterns are possible and perhaps useful.
Why should I care if you sent me a bad form of P; is it my business that the service I provide to you relies on a defective tool P that you provided to me?
Suppose that I provide a shared, stateful, serially reusable service to some clients and you are one of those clients.
I am obligated to serve my other clients even after you provide me with a faulty parameter.
Here are several reasons I may need to vet P before invoking it:
- P may not return and then I cannot serve other clients.
- If P is something I will store in a B-tree and there is supposed to be an abstracted simple ordering on P like things, then I must know that P plays by the axioms of simple orderings, lest my B-tree fail to function for my other clients.
- If P is to a space bank from which I acquire space to serve you, I may wish, for reasons of abstraction, to conceal from you information that I put into the pages that I buy from P.
If P is an official space bank I can count on concealing such information, even from you who gave me P from whom I bought the pages.
- There are messages to P that contain stuff that I am unwilling to give you.
If I know the provenance of P, I may conclude that it is safe to send such messages.
- There may be some attribute of P that makes it unsuitable for me and that attribute stems from how you got P.
If I can vet P I may be able to describe to you the problem so you can fix it.
This may be something that you can’t do because:
- You don’t have the authority.
- You don’t have the expertise.
There are many other such reasons, yet synergy seems to be at odds to unlimited counterfeiting.
I glean from the examples above two sorts of protection provided by synergy:
- A shared stateful server must serve other clients.
(If the state is not shared between clients, or there is no state, then each client should have its own server instance.)
- Server must send data and capabilities to P that cannot be entrusted to its clients.
I can’t think of other classes of reasons just now.
Computers do many useful things that do not require either of these situations.
We should consider whether it would be useful to provide a program environment without synergy that allows full synthesizability.
I think that the membrane concept bears on these issues but I have not seen it developed well enough yet.
Software technologies are nearly always described in some context of implicit background assumptions.
These pages try to provide that background but they provide little guidance on where to start reading so that you learn the assumptions soon enough.
The discussion above is deep in the Keykos assumptions.
These pages are guilty of that and worse, the background is unconventional.
Describing the E auditors ferrets out many of these assumptions and maybe illuminates some of E
Java auditor class,
Interface Auditor,