This section should be merged with (p3,do) and that section updated.

Standard Creators

For a particular type of object there are the builder {inventor} and requestors. A requestor is a person or program that has need of a new object of the invented type.

The factory is the preferred way of bringing new objects into existence. As a new type of object is invented a new factory for that object is created.

The inventor creates the factory. When a requestor wants a new object of that type he invokes the requestor's key to that factory to produce the object. A few keys are returned that provide access by the requestor to the new object.

Factories provide privacy between the builder and requestor.

Normally the builder cannot see the state of the object and the requestor cannot see the implementation of the object.

Failures of objects
Factories can also be used to bring failures of objects to the attention of the builder.

Some objects may be set up so as to notify the object builder directly of an internally discovered failure. In other cases the internally discovered failure may cause the notification of the requestor of the object.

Failures discovered by the requestor can also be brought to the attention of the inventor via the factory.

If I have a program that I value and you have data that my program could help you with and you don't want me to see the data what shall we do? I do not want to send you my program, perhaps because I want to charge for it and I don't trust you to tell me how much you use it. You don't want to send me the data because it is proprietary.

In this case I make a factory, install my program in it, create a requestor's key for the factory and send that key to you.

You may determine that the key I sent you is indeed a factory. You will also want to determine that there are no unwarranted holes in the factory {(discr)}. A warranted hole might, for instance, be a capability for my program to keep your processed data safe over long periods of time by tape backup operations. The tape backup system would have to vouch for the fact that it won't reveal your data to me.

There are three interests that are served by factories. The requestor wishes to be provided with some service. A security officer wishes to insure that the requestor does not divulge the secrets that may, in fact, be the object of the service. {Commonly, the security officer is the requestor.} The inventor wishes to make is service available while protecting the nature of the algorithms and data upon which it is based.

We examine the interests of these three in turn and explain the factory from his point of view.

To requestors of new objects

Requestors for new objects must hold a key requestor's C to a factory for that type of object. The call is "C(n;SB,M,W==>c,rs;X,Y,Z)" where n >= 0. SB must be an official space bank and M must be a meter. The other argument and returned values depend on the object's type.

Pitfalls for Requestors

When one calls a requestor's key he expects in return an object that is structurally incapable of stealing his secrets {structurally discreet}. The requestor must be careful not to introduce leakage paths himself.

It is necessary for the requestor to provide a meter. If this meter has a keeper, the requestor has just provided the opportunity for the object to call that keeper {if the kernel were to support explicit meter calls}. In the following scenario this is serious:

The Scene

Suppose that users X and Y write .programs x and y. They have both been installed in factories. A requestor's key for y is a component of x's factory. Both X and Y hold requestor's keys to both factories. Neither X nor Y trust the other.

Y requests an x object passing a meter M. x runs and requests a y object passing M {the only meter that x has}. x proceeds to place information proprietary to X in the object maintained by y {perhaps the x object is a record collection}.

Scenario One

Y causes M to be exhausted {but valid}. y is running under M and thus implicitly calls M's keeper. At this point M's keeper holds a restart key to the domain executing y. This restart key is passed to Y who uses the domain creator key available from the y factory to open up the domain that executes the y .program. But this domain also now holds information proprietary to X.

Scenario one can be prevented by deimplementing the ability to retrieve a domain key from the domain creator key and restart key.

Scenario Two

y now calls M, reaching M's keeper and passing information from y that is proprietary to X. M's keeper, alas, is a program created by Y who forwards the information to Y.

Scenario two can be prevented in one of the following ways:
We can chose not to implement explicit calling of meters keepers {current strategy},

We can change x to create a new meter depending on M without a keeper loyal to Y.

We can establish a "no-call" bit in a meter key to thwart explicit calls and change x to turn on that bit in the copy of M that he passes to the y object.

We can establish the "no-call" bit and change the factory logic to turn on this bit, thus avoiding any extra effort to avoid obscure security problems.

More General Scenarios
A requestor gets an object from a sufficiently discreet factory but provides that object with a key K ostensibly for one purpose but which can be used by the object to export the requestor's secrets.

If K is a segment this can be prevented by putting it behind a segment node created by the requestor.

{security}To people with secrets to keep and who need to use objects.
Background
In Gnosis, as in other operating systems, it is possible to endow a program with the ability to send data that it processes to a location chosen by the designer of the object. In Gnosis, unlike most other systems, it is also possible to ensure that this has not been done. Such a program, when it serves you, is unable to disclose your data or anything that depends on your data to anyone but you. Factories are the supported standard way of ensuring this.

One's trust of some data processing facility will depend on many considerations. We distinguish here between trusting the facility to provide the right answers, and trusting the facility not to disclose the information in an unauthorized way. We are concerned only with the latter here.

When we say that a secretary is discreet we may mean that the secretary is trustworthy to keep and work on secret information. We use "discreet" and "discretion" to evoke those connotations.

When you are presented with a factory you may verify that it is indeed a factory and that it as discreet as your application requires. Factories are immutable {(p1,immut)}.

The factory mechanism provides the sort of protection that would be achieved by putting a computer in a closed room, putting an untrusted program into it along with the secret information. There are wires leading from the computer to systems known by you. You may not be convinced that the answers are correct but you may feel sure that only those in the room and those known systems will be able to see your information and the answers. The discretion is an indication of what systems there are wires to.

Who to Trust

When you keep your secrets within Gnosis you are trusting {among programs} the Gnosis kernel and some programs that run in domains upon whose correct functioning the factory's logic depends. These latter programs are called the factory's integral regime. Noteworthy among these are the space bank and its transformer, the domain creator and its creator and the factory program itself.

As computing facilities are built of simpler facilities {recursively} the holes of an object are inherited from the holes of its component objects. As a consequence of the factory rules, the discretion of a factory can not exceed the discretion of any of its components. Furthermore it is possible to compare the discretion of two factories. If a factory is proffered which is claimed to be discreet, one may compare it to a factory that is already owned and trusted.

How do these holes originate? When someone invents a service and is unwilling or unable to conform to the strictures of creation by pure factory logic he inserts a hole into the factory. This action is known to the factory logic.

The inventor must convince you, by logic or persuasion beyond the scope of factory design, that his exception {hole} is acceptable to you. When he has done this he provides you with the factory that resulted from the exemption.

You may now insert this factory into your "standard test factory" against which you test all factories with which you trust your secrets. Not only can you now use his products but you can use products built indirectly from his products.

When a factory is called to produce an object, that object will initially be as discreet as the factory.

Within an institution there will be factories of discretion deemed sufficient for particular purposes.

To the inventors of new object types {new data types}
The inventor should bear in mind that potential users of his objects may be concerned about the discretion with which the objects will treat their information. This concern can be allayed by use of factories. It is possible for those users to discern the degree of this discretion.

The code necessary to support a new object comes in three parts: Factory creation, object initialization and object execution. Normally this factory is created just once. {There is now in the WOMBKEEPER program a mechanism to create the factory for primordial programs.} A new {empty} factory is acquired. Components necessary for the creation of new objects are assembled and installed in the new factory. These components must be of three categories, factory requestor's keys, sensory keys {(p2,sensory)} and holes.

The discretion of the objects depends on the discretion of the factory requestor's keys that are installed in the new factory. (hole) tells you how to about discretion rules.

Holes in factories

A .hole is some key held as a component in some factory that the logic of factories cannot vouch for. These .holes may become part of the objects produced by the factory causing the objects to be less discreet than otherwise. We say that factory A is at least as discreet as factory B iff all of A's .holes are .holes of B.

See (infact) and (prim-hole) on the origin of holes.

If more than 16 components that are factories are required in a factory then auxiliary factories are recommended. Such a factory holds 16 components and will return one of them upon request. Such a factory has nothing to hide. To this end we provide the "fetcher" type of factory that makes this action fast.

If the object to be created in response to a call on the requestor's key is complex and consists of many domains, we encourage the builder to incorporate surveillance and debugging logic as an integral part of the object. This logic might be in its own domains some entries to which might be designed for the requestor. These entries are of no special interest to the design of the factory.

If logic within the object discovers a logical fault there are two scenarios: notify the requestor via a route established early in the life of the object, or notify the builder {if the object is not too discreet}. In this case we might invent a protocol for the builder to contact the requestor. We now have no such proposal.

If the requestor {user} of the object suspects a failure of the object he may be able to call a surveillance entry for a report on the object's status. This is of no interest to the factory.

If the requestor decides that he would rather trust the builder and potentially betray his secrets than to lose the use of the object, the requestor can send his object handle {gate key or segment key} directly to the builder who can disassemble it with the "get factory's domain keeper" operation on the builder's key.

If it is necessary to install a DDT over .program before the first instruction:

The requestor passes a special meter key M as the meter argument to the requestor's key.

M is a meter key to a valid empty meter kept by MK, a program loyal to the requestor.

Just as .program is about to run, it traps to MK providing MK with a restart key E to the domain that is about to execute .program, whereupon the requestor passes E to the builder who is now in a position to debug the domain that is expected to misbehave.

Just as the object may be designed to support a security policy that discriminates among various keys to the same object, the object builder should publish and follow policies as to what repair services he will provide. When the builder receives a repair request he must not only protect his own secrets, he may be responsible for protecting secrets of the original requestor of the reportedly broken object. The object may not broken, it may merely be correctly refusing to provide data to the complainer who is not the original requestor.

As with familiar objects, Gnosis objects may become obsolete. If a new model becomes available a factory with the same domain builder as the older factory might be equipped to replace the old object with a new one. This is akin to a field upgrade.

For some objects, such as record collections, there is no need for the new factory to have the same domain creator as the old.

If we wish to allow someone to use the system, to solve problems and perhaps to develop programs we may wish, at the same time, to limit his ability to send data that he is controlling to other users. {The DoD sometimes requires this.} If we provide a factory whose yield is a user environment then we can control the extent of his ability to send information to others by the discretion of the factory that produced his environment. Such an environment should be nearly standard so as to provide commonality of the user support systems that run therein.