Centralized, decentralized - no matter

Print

Is it coming now, the corona app, which allows contacts and infection paths to be traced more quickly in the event of illness with the SARS Cov2 virus? For a long time there was a dispute about the architecture. Where will the data be stored? Centrally at an authority or provider. Or decentralized on the user's end devices, as demanded by data protectionists? As is often the case when there is a bitter dispute about something, there is a danger that the view for the decisive questions is lost. The so-called halo effect of Behavioral Finance sends its regards. Other attributes of the app are in our opinion much more decisive!

And one of these other, underestimated attributes is certainly the question of whether its use is "voluntary". Federal Minister of Health Spahn has now promised us such voluntariness. So everything is okay? No, because his statement about voluntariness refers to a compulsion to install. Yes, this will be optional. But what Mr Spahn is not saying is that this app may decide in a few weeks' time whether you can go to a restaurant or visit a swimming pool. Admission only for "certified" App users. A killer feature, like a "sesame open-your-face", would quickly make the app a voluntary must-have. So whether the government offers us voluntary use or not is secondary. What is decisive is which extended use the app will get.

Just as misleading is the question of whether the data is stored centrally or decentrally. There would even be good reasons for centralized storage. After all, what happens to the valuable contact data of users in the event of accidental uninstallation or device loss? Irretrievably lost or in the possession of thieves. With central storage, the data would be safe from loss.

The only thing that matters is whether the data is cryptographically encrypted on the end device in such a way that nobody can decrypt it on the server alone, without the user. Such procedures have long been common practice today, for example with password managers, and they ensure that the data is secure, even if the central server is hacked.

Conversely, decentralized storage does not protect my privacy either, if, for example, in the event of an infection, I have to submit my data to the authorities in a form that would allow them direct access to my ID and, if necessary, the IDs of my contacts. Because then relatively few "disease alarms" would suffice to unmask entire networks - just as illegal money flows can be reconstructed today if only a few Bitcoin Wallet IDs are known.

Which brings us to the next question, namely how exactly my contacts are notified should I fall ill. So I imagine that I have tested positive for Corona. Who informs my network? Do I do it myself (if so, who prevents jokers from faking an illness to scare their fellow men?) or does the health authority require access to my mobile phone? Or how should that work?

In the case of decentralized storage, I can only imagine a procedure like the one used for the encryption of e-mails, for example. There one works with a 2-way encryption (e.g. following the example of PGP) using a private key and a public key. The public key uniquely identifies me in the system, but only if the private key is known, one could view the entire "database". My movement profile in concrete terms would remain anonymous, but my public key would be known by all contact persons of mine.

The public health department itself also stores its own public key in all apps. With this key the app can check that "cases of illness" are not only transmitted by the user, but only with the authorization of the office and thus pranks and joke alarms would be prevented.

In case of illness, I would send my public key to the public health department, which the department would then encrypt using its own private key and broadcast it to all app users. The apps of the others would then be able to look up the presence of my public key in their database.

This would indeed guarantee a secure privacy according to the current state of technology. The algorithms used in PGP and similar procedures cannot be cracked as of today, but in a few years time this could be different. But this form of privacy has nothing to do with the question of centralized or decentralized storage.

And whether or not the government misuses such an app to "control access to certain freedoms" is not decided here either. The decisive factor would be whether the authorities order such electronic access controls. The technology would be there to extend such a thing to any application. And we all know that if something is possible and easy to implement, the temptation to do so is insane.

Addition dated 29.04.2020

When people are under pressure, they tend to focus on short-term, immediately relevant issues. Long-term strategic plans are thus often ignored or "overridden". This can be read about under the term "myopic loss aversion" or "short-term loss avoidance" in Behavioral Finance theory. Investors know this effect all too well when it comes to limiting portfolio pain and losses in a crash, even though the strategic commitment is to stick to your investment plan and buy when stressed.

This effect also plays a role in the question of the Corona App. Wasn't the EU determined to stand up to the tech heavyweights, especially in the US? Hadn't the healthcare market in particular been identified months ago as an undecided playing field where the EU wanted to score points with "data protection at European level"? Was it not the dream of many politicians to build a "European IT champion"?

All these nice strategic plans have been flushed down the toilet in the last few days, when they gave in to the pressure of a completely misguided "centralized/decentralized" discussion and have now opted for the quickly available concept from Apple and Google. What sounds logical and in questions of the Corona-App perhaps really promises a somewhat faster solution in the short term, is an elementary mistake in the long term. This is already clear today when you consider that Apple and Google decide whether we in Europe may use the data, for example, anonymously for research purposes (answer: no). And anyone who really believes that these US giants would protect the privacy of users is making a fool of themselves. This will work just as well as with transaction data, which is tracked on Google Maps, for example. If you contradict the tracking in the privacy settings, you will lose a substantial part of the mobile phone functions. But Google itself had to admit that you can still continue writing in the background.

The providers of the two most important mobile phone operating systems will deeply network the new app with their operating systems. Thus, in a few months / years, one should not be surprised that certain functions of the device will only be available if one gives up some privacy in the health data. Voluntarily of course. And the fact that the data is linked to the Apple or Google ID can be considered secure.

What is really fatal, however, is that this app will probably become the starting point for a more comprehensive health app. In this country, people are already dreaming of such an app becoming the central repository for health certificates (and thus having exactly the killer features I mentioned above) or the central repository for all human health data. Today, with the Corona app it is already determined that it will be Apple and Google who will sit in the front row again. And Europe can forget its last hope of becoming a European "champion".

Let's stay vigilant in the interest of freedom and civil liberties. Big brother is watching you.

We use cookies and third-party services that store information in the end device of a site visitor or retrieve it there. We then process the information further. This all helps us to provide you with our basic services (user account), to save the language selection, to optimally design our website and to continuously improve it. We need your consent for the storage, retrieval and processing. You can revoke your consent at any time by deleting the cookies from this website in your browser. Your consent is thereby revoked. You can find further information in our privacy policy. To find out more about the cookies we use and how to delete them, see our privacy policy.

I accept cookies from this site.

EU Cookie Directive Module Information