What computer manufacturers can learn from farmers

Guest contribution by | 04.11.2019

When I was at school, the milk coachman still drove through the village on horse and cart, stopping at each farmer’s to load the milk cans he had provided. Then we trotted to the dairy in the neighbouring village, only one kilometre away, where the milk was collected and processed. Today a lorry with several thousand litres of tank capacity drives from farm to farm, pumps the milk into the tank and takes it to the central dairy, which is located umpteen kilometres away. In the afternoon, the same truck drives to the filling station, pumps diesel into the tank, and the next day it can take the same tour – or another one with the same purpose. That’s the way it goes day after day. But then there are long faces: with the dairy’s customers because butter, milk and cheese taste like diesel – and with the milk tanker’s driver because the engine no longer runs smoothly.

There is no such thing? – Thank God not in the dairy industry. First the horses were replaced by a tractor, then the milk can by a common tank, and one day the tank was semi-mounted on a tractor. But in another branch of industry this is exactly the situation: in data processing and information technology.

The common cargo hold

The historical development in data processing and information technology was somewhat different from that of milk transport: to stay in the picture, one can imagine that the milk farmer I knew as a child took the oat for his horses in a sack on the milk cart. Note: in a separate container, which could not be confused with the payload, the milk cans. The computers – in figurative terms: the EDP vehicles – not only used the same loading area for payload and equipment in their early days: the memory. In it, the payload – the data to be processed – and the resources – the necessary programs – were only separated from each other by virtual boundaries, namely the respective address spaces.

As the computers were further developed, the horses were gradually replaced by faster tractors, and the payload was also increased, but the separation between payload and resources was not achieved. Okay, to stick to the truth: Once upon a time there was a time when both were separated, this was called “Harvard architecture”, but this remained a short intermezzo. The computers in use today – including their variants, they may also be called controllers or otherwise – have only or still have a “cargo space” that shares the payload and resources.

Attacker advantage

This situation makes it possible for attackers to insert data (payload!) into a computer in different ways, which in reality are programs (resources!). The term for these subordinated resources is malware. It does to the computer what the hacker has told it to do – and that is usually something the user does not want.

What can be done about it? This question now occupies armies of cyber security specialists. The current defense strategies repeatedly prove to be inadequate, because in this scenario the hackers are the innovative party whose new products have to be identified every day by static features or their function.

Anti-virus programs offer inadequate protection here: detection alone, which is already difficult enough, is not enough: an antidote has to be programmed and installed by the user. By then, so much time will have passed that the hacker has probably already achieved what he wanted to achieve.

Repeated warnings to users to do or refrain from certain activities do not always catch on either: for example, messages from false new customers or fake Internet pages for non-IT forensics cannot be easily detected.

The separation of data and software

Anyone who has read this far will have realised that the milk truck represented by our IT equipment urgently needs a second “tank”; one for the data to be processed, the “milk”, and one for the user software, the “resources”. Some thinkers have also discovered that additional “lines” are needed to keep “diesel” and “milk” cleanly separated. Thought leaders have already devised technical solutions for how to deal with this separation of data and user software outside the actual computer, up to and including the description of a cyber-safe use of the Internet.

What consequences are to be drawn – and by whom?

To refrain from consuming dairy products, i.e. digital devices, would probably only be a way out for individuals. For this reason, the focus is on avoiding disruptions in their production and provision. The players who could be in demand here are:

  • First and foremost the manufacturers of the milk transporters, i.e. the computer hardware. But their business models are currently running so well that they are unlikely to be inclined to produce more complex equipment without external pressure. That would be – who wants to forgo profits? – more expensive than competitors’ devices. And give up market share? This is not provided for in the business plans.
  • In the second place, the central dairy’s haulage yard, i.e. the users of the computer hardware. For them it is relatively incomprehensible that they do not demand safe means of production. They may still fall for the flowery promises of salespeople and consultants who may not know any better. Or the lack of better suited components leaves them no other choice.
  • Thirdly, there are the farmers, pardon me, the producers of data. They would like to guarantee the quality of their products, but what reaches the recipient is unfortunately not in the hands of the producers alone.
  • Fourthly, it is the consumers. They also have an interest in ensuring that the products supplied are what they have ordered and not – by whomever – counterfeit goods.

It is a pity that both producers and consumers are often unaware of the context and do not know how to formulate their requirements and to whom they should turn.

So it will probably be a while before the chicken-and-egg problem is resolved as to whether an inadequately worded request prevents the right offer or whether full-bodied offers suppress seriously worded demands.

Then there are also associations, such as the BSI (Federal Office for Information Security in Germany) or Bitkom (Federal Association for Information Technology, Telecommunications and New Media), which are also supposed to represent the interests of consumers. No demands can be heard from them to the hardware manufacturers – not with the required volume and the necessary emphasis.

By the way, the milk truck in this story would not get a sticker from MOT – but isn’t there also a MOT for IT equipment?



Friedhelm Becker has published another post in the t2informatik Blog:

t2informatik Blog: Deficits of the computer architecture

Deficits of the computer architecture

Friedhelm Becker
Friedhelm Becker

Friedhelm Becker was born in 1952. He is married and has three daughters and four grandchildren. After successfully completing his studies in chemistry, he worked for three years in a building materials testing laboratory and then for eight years in the German Armed Forces. He is a retired naval officer.

After retiring from military service, Mr. Becker worked for well-known companies in the computer engineering (Univac, Sperry, UNISYS) and aerospace (Lockheed-Martin) sectors in various applications. Since 1974 he has been working in the field of computer-aided sensor-effector integration without any significant interruptions. Since 2013 he has been the owner of DCB Distribution & Consulting Becker.