Perhaps the factory was the first type to provide a comparison operation between objects of the type. This introduction to the factory defines “discreet” in terms of a set of holes. For discreetness fewer holes are better (more discreet). There is an order on a factory that accepts a key to another factory which queries the first as to the relative merits of the second. The paranoid factory user invokes the first factory (that he has prior reason to trust) proffering a second factory. The first factory performs a set inclusion test on the respective hole sets and replies firstly whether the proffered factory was indeed a real factory, and if so whether there are holes in the proffered factory that are not in the first factory.

Several points about this pattern are significant here:

• The paranoid needs to test whether any key that purports to designate a factory is indeed a factory. This requires that the paranoid hold a key to a factory that he already trusts.
• The paranoid has probably already a hole policy in place and holds a capability to a factory with those holes. Only the rare programs that discriminate between degrees of confinement will deal with more than one level of factory discretion.
• The holes of a factory are inaccessible to the user of a factory. The user need not have access to the holes that he trusts for discretion.
• Setting a discretion policy can be done by creation and dissemination of a factory. The follower of a policy need only test via this factory capability.
• If the user holds some keys that he would trust as holes, he may create a factory with those holes and ask it whether some other factory has more.
• If the user wants to test whether a factory has only holes that are in either factories A or B, then he creats a new factory and installs A and B as requestor keys in the new factory. The requestor’s key to the new factory now provides a tester for this new criterion.