Trusting Objects

Most sorts of object are designed to be used by a single user or program. All of the caps to such an object are held by one protection domain or a few with high mutual trust. Other sorts provide functions which serve to coordinate between diverging interests. We call those shared objects here.

When divergent interests are involved one player is presumably concerned that the other not corrupt the shared object, lest that object corrupt him. The code defining a shared object needs to take care to be insensitive to malformed messages from either side.

For unshared objects this problem is not so severe as in the client domain makes all of the messages to the server. Ordinary programming practice includes “don’t send message with undefined semantics”. It is good practice to define semantics to all possible message as this prevents messages without semantics. This is good only it test cases probe corner case semantics. This may be expensive but not usually. In any case the client has only himself to damage by crafting unshared objects.