Keykos Data Abstraction from 5000 Feet

Here is the view of data abstraction as seen by the casual Keykos programmer. The factory is a sort of keykos object. A particular factory produces objects that can’t steal the secrets that you tell it. When you join the system you get a factory F and trust its quality however much you trust the operator of the machine that you are using. When someone, who you may not trust proffers a new factory F2 for your consideration, perhaps because it purports to provide useful objects, you send F2 to F with a query: “Is this a factory?”. If it is you can invoke F2 and try out these new objects, O2, by sending your secrets to O2 knowing that O2 cannot steal them (copy them out of the system). O2 can remember those secrets for subsequent processing. O2 and O3 both created by F2 cannot converse unless you introduce them to each other.

You can call F2 to get O2 but you cannot see the code that defines the behavior of O2. Nor can you see the capabilities that it holds except to know that those capabilities do not suffice to steal your secrets. In particular O2 may hold capabilities for other factories. The programmer who produced the factory is also unable to see your secrets; recall that you have no reason to trust him; just because he writes code that seems useful does not mean that he does not want to steal your secrets. Consider Derwent.

Suppose O2 seems to misbehave, perhaps due to a bug in the code defining O2. Who can debug it? One option is to narrow down the problem by finding data that provokes the bug but does not include your proprietary secrets. Call F2 getting O3, tell O3 your cleansed situation, and send your capability for O3 to the owner of F2. The F2 owner has retained a capability to open objects from his factory but not without a capability thereto. The owner can thus open O3 and see the insides, which shows his code in the compromising situation.

If the factory produces objects with a complex internal data structure such as a B-tree implementation, then two such B-tree objects may know how to compare their internal states efficiently or do such operations as tree union. One of the capabilities allowed to the yield of a factory is the ability to open a sibling, (object from the same factory) but only given a capability to that sibling. Thus if a client has built two abstracted B-trees, he can efficiently call for their union. The confined code cannot do this union until it is presented with the capability for a sibling object.

It is critical to note here that whoever created F2 is called the “factory builder” but the builder does not define the behavior of the factory. The builder requests of the “factory creator” a new unsealed factory, to which the builder can pass in components that suffice to build the confined objects. Factory logic ensures that none of these components suffice to steal the state of the objects produced by the factory. When the builder is done he seals the factory and gets a requestor’s capability to the factory. He can pass this cap around to his potential clients, such as you. The “O2” above is a requestor’s key.

There was in the 370 version a package for a PL/I programmer to avoid many of the details described here to build factories. These programs could rely on other functionality provided by factories.

In short you trust factory logic to protect your secrets from exfiltration. You trust the factory definer but not the factory builder. There is just one definer but many builders. You trust the builder for a source of objects that get the right answer to your queries.

There is a long expired patent on the factory.
History and more factory details

At a deeper abstraction these objects are composed thus.