The problem of trust

February 26, 2017 by Lucian Mogosanu

The concept of trust is as simple as it is deeply problematic. Let us first define it:

a : assured reliance on the character, ability, strength, or truth of someone or something

b : one in which confidence is placed

and the remaining definitions are more or less similar.

Human societies are built on trust, and thus the ability to place trust in others, be they things or others of their kind, is a fundamental quality of the Zōon Politikon. In fact nowadays we trust so many things and so many people that this trait has become implicit in our way of life. We must bear in mind however that trust is inherently asymmetrical, so that the trusted needn't give his entruster one iota of trust in return -- if we were able to quantitatively appreciate trust, which as far as I know we do not.

When trust as a whole is broken or otherwise disappears by some other means, society collapses and war ensues. That is not to say that lack of trust (or distrust) is necessarily a cause of war; after all it is not that Genghis Khan didn't trust the peoples he conquered, but that he conquered them first and foremost because he could. Lack of trust is also not a problem in and of itself -- (too much) trust is, especially when it is not accompanied by verification.

Since I am an engineer by formation, I will use the closest example I have available to formulate the problem of trust: let us imagine that we are the last remaining men on Earth and that we wish to build an advanced technological artifact, say, a high-performance numerical computer. Now, how do we go about making that?

The approach of n-societies1 builds the state of the art in computers by using large computer-factories relying on complex chains of dependencies. This works principally because large numbers are readily available on both ends of the chain; on one end lies the cheap overworked labour; on the other lie fat worms who are able to take in the end product in big quantities. This approach works for now, but it has the major disadvantage that it is fragile because of its multiple interdependent points of failure; in other words, it is disadvantageous because of its incompatibility with our previously enunciated scenario.

The approach of small societies, numbering as few as one individual, does not exist yet, a fact which is somewhat disquieting.

Let us further imagine then that we had readily available synthesizers to help us in our endeavour, along with enough knowledge of hardware and software to allow us to build a system from scratch. At this point we will have eliminated trust2 in other hardware and software developers, who at the point of our post-apocalyptic scenario are long gone anyway.

But this is not done yet, because now we have to trust the device printing our chips either in terms of design-to-implementation correctness or of lack of subtle malicious behaviour3. Ideally we would use the printer to make our own hardware printing device, but this is necessarily incomplete, as demonstrated by Gödel. In other words we cannot trust that the nth order printer-of-printers will not replicate the same incorrect or malicious behaviours in their lower order creations.

The naïvely correct approach would be to start by placing our trust in the laws of physics, which we know to manifest in a specific way according to common sense4 scientific experiments. From here we can use fire to refine iron to make tools that help us make tools, and so on until we are able to build the tools necessary to build computing machines of a satisfactory performance. The viability of this approach has been demonstrated by history; however, given the time required to put it in practice, this might not the right approach from a pragmatic point of view.

Assuming that the scarce society in our thought experiment still contains leftover technology from our n-ancestors, an honest enough avenue would be to employ common sense combined with existing tools as means to verify existing systems. This is in itself a hard problem, since there is no general method to this verification, and I doubt there will ever exist one5.

Fundamentally this thought experiment reduces the problem of trust to the question of trading off between outsourcing and independence. I have no doubt that there are people who at least believe they have the answer to this problem; however, history seems to show that in general there is no stable point of equilibrium to balance the two situations.

One lesson we can take away from all this, though: knowledge is never ever to be outsourced, for it is the primary prerequisite for the ability to verify.


  1. This term is borrowed from the definition of "slave empires" in Trilema's Republican Thesaurus

  2. And moreover, dependence

  3. At the time of writing, this is a problem worthy of consideration, as illustrated in Yang et al., "A2: Analog Malicious Hardware", published at the 2016 IEEE Symposium on Security & Privacy. 

  4. Common sense is used here merely as a device to put a halt to the "turtles all the way down" phenomenon described previously. 

  5. I have actually thought about this. Stay tuned. 

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.

4 Responses to “The problem of trust”

  1. [...] the reader's keen eye might have noticed, we're running into a multi-layered bootstrapping problem: V and GNAT require themselves in order to press and build respectively; and furthermore, vtools [...]

  2. [...] piece technology if he controls not only its product, e.g. the spear, but also the entire bootstrapping process that makes said product possible1, e.g. the materials and the skills required to build a spear. [...]

  3. [...] TLS and PKI preloaded, because that's what his masters told him. I wonder if he understands that implicit trust, not "centralization", is the primary driver behind this wreckage. I also wonder if he understands [...]

  4. [...] supports whatever it is you're trying to do. This layer alone comes with a pretty serious set of problems, since as of yet no one knows how to bake ICs without spending a fortune on masks4. FPGAs are [...]

Leave a Reply