News

Check-in-App auf dem Prüfstein: Datenschutzprobleme und Unsicherheitsaspekte am Beispiel der Luca-App

Um den Einzelhandel, die Gastronomie oder auch Kultureinrichtungen und Künstler:innen zu unterstützen und den Menschen Besuche zu ermöglichen, sind die sogenannten Check-in-Apps besonders die Luca-App derzeit in aller Munde. Wir begrüßen diesen Trend.

Gleichzeitig haben wir seit Mai 2020 immer wieder gerade lokale Lösungen thematisiert – auch in den Medien. Wir finden lokale Lösungen deutlich effektiver als nationale Lösungen wie etwa die Corona-Warn-App, die keine Effektivität aufweisen. Unser Forschungsteam beschäftigt sich bereits seit Januar 2020 mit digitalen Kontaktnachverfolgungssystemen.

Wie üblich analysieren wir alle populären Systeme, denn auch diese haben ihre Tücken. Wir haben uns im ersten Schritt die Luca-App genauer angesehen. Uns ging es dabei in erster Linie um die Unsicherheiten und Datenschutzprobleme der Check-in-App.

Wir sind dabei auch die anderen Check-in-Apps weiter und tiefergehend zu analysieren und auf diese Systeme einzugehen. Dazu werden weitere Untersuchungsergebnisse folgen.

Im Folgenden finden Sie unsere ersten Analyseergebnisse zur Luca-App.

Einsatz der Check-in Apps im Indoor-Bereich zur Kontaktnachverfolgung 

Geschäfte, Dienstleister (z.B. Gastronomen, Veranstalter) oder öffentliche Eirichtungen (z.B. Museen) können unter bestimmten pandemiebezogenen Einschränkungen Kunden ihre Dienste anbieten. Typischerweise müssen die Gäste bei einem Besuch ihre Kontaktdaten in Papierformulare eintragen, wobei gleichzeitig das Ausfüllen und Sammeln umständlich und fehleranfällig ist. Digitale Apps oder Online-Dienste können hier helfen. Mit solchen Check-in Apps “checken” die Gäste ein, um Informationen zu ihrem Besuch und Kontaktdaten zu hinterlegen. Sollte sich im Nachhinein ein Gast mit dem Coronavirus infizieren, können die gespeicherten Informationen zur Kontaktverfolgung der anderen Gäste genutzt werden.

Es existieren bereits eine Reihe mobiler Apps oder Web-basierte Check-in Apps wie Gastident, eGuest, Kontakterfassung.de, Smartmeeting, darfichrein.de und die Luca-App. Im Folgenden konzentrieren wir uns jedoch auf die Luca-App, die seit kurzem öffentliche Aufmerksamkeit genießt und lokal wie kommunal bereits eingesetzt wird.  

Die Luca-App

Die Luca-App, intensiv vom deutschen Rapper Smudo der Fantastischen Vier vermarket, wird als einfache und datenschutzfreundliche Alternative zum Ausfüllen von Formularen oder zur Übermittlung von Daten im Klartext an eine Website beworben.

Wir haben erste Sicherheits- und Datenschutzanalysen der Luca-App durchgeführt und diskutieren hier die ersten Zwischenergebnisse.

Wie funktioniert die Luca-App

Bei der Luca-App gibt es vier Hauptakteure: Der Gast, der Dienstleister, das Gesundheitsamt und der Luca-Service-Betreiber. Im einfachsten und häufigsten Szenario wird die Luca-App wie folgt eingesetzt:

  1. Der Dienstleister registriert sich beim Luca-Server und generiert einen QR-Code, der seine URL und ID enthält.
  2. Der Gast muss sich ebenfalls beim Luca-Server registrieren, indem er seine Kontaktdaten wie Telefonnummer, Name und Adresse angibt. Die Kontaktdaten werden gesichert an den Luca-Server gesendet und verschlüsselt gespeichert.
  3. Der Gast betritt z.B. das Lokal und scannt den ausgedruckten QR-Code, der in der Regel am Eingang angebracht ist. Durch das Scannen wird ein Check-in für diesen Gast erstellt, der gesichert an den Luca-Server gesendet wird.
  4. Wird ein Gast positiv getestet, gibt der Gast quasi seine Geheimnisse (kryptografische Schlüssel) an die Gesundheitsbehörde frei.
  5. Die Gesundheitsbehörde fragt den Luca-Server nach allen Check-ins dieses Gastes ab. Anhand dieser Check-ins fragt die Gesundheitsbehörde nun alle Dienstleister ab, bei denen einer dieser Check-ins durchgeführt wurde, und erhält die notwendigen Informationen, um mögliche Kontaktpersonen zu identifizieren.

Einige Unsicherheitsaspekte der Luca-App

Das Hauptziel der App ist, dass kein Akteur allein auf die Kontaktdaten des Gastes zugreifen kann, ohne dass dieser 1) infiziert ist und seine Schlüssel freigibt oder 2) in einem Suchprozess auftaucht. Damit dies geschehen kann, müssen der Betreiber des Veranstaltungsorts und das Gesundheitsamt zusammenarbeiten. Außerdem muss ein Gast seine Schlüssel freigeben, um den Prozess zu starten. Außerdem können Check-ins nicht miteinander und auch nicht mit einem Gast verknüpft werden, wenn sie verschlüsselt sind. Durch die Verwendung von Metadaten, wie z. B. der IP des Gastes, ist es jedoch dem Luca-Service-Operator möglich, Check-ins mit IP-Adressen zu verknüpfen (https://luca-app.de/securityconcept/processes/guest_app_checkin.html#id4). Diese Möglichkeit wird von Luca-Team eingeräumt. Um dies abzumildern, versprechen sie, keine IP-Adressen zu protokollieren.

Das Luca-Team verspricht zudem, eine Reihe von definierten Sicherheitszielen (https://luca-app.de/securityconcept/properties/objectives.html#objective-contact-data) in Bezug auf bestimmte Akteure in ihrem System zu erfüllen. Die Webseite der Luca-App weist jedoch auf mögliche Sicherheitsprobleme hin, ohne die Konsequenzen genauer zu beschreiben.

Ein wichtiges Ziel hierbei ist, dass “die Kontaktdaten nicht-infizierter Gäste nur ihrer eigenen App bekannt sind”. Das wiederum impliziert, dass die Luca-App die angegebenen persönlichen Daten nicht validieren kann, obwohl die Gesundheitsbehörden auf gültige Kontaktdaten angewiesen sind. Um dieses Problem zu entschärfen, bietet die Luca-App eine “Trade-off”-Lösung in Form einer clientseitigen SMS-Verifizierung der Telefonnummer, die der Gast bei der Registrierung eingibt (https://luca-app.de/securityconcept/processes/guest_registration.html#verification-of-the-guest-s-contact-data).

Diese Lösung hat jedoch ein Problem, da der Verifizierungsprozess missbraucht werden kann, indem eine unbegrenzte Anzahl von Konten mit einer einzigen gültigen Telefonnummer registriert wird. Denn es gibt keine inhärent überprüfbare Verbindung zwischen den angegebenen Kontaktdaten und der Telefonnummer, die für die Registrierung der App verwendet wird.

Neben der Smartphone-basierten App-Lösung bietet Luca auch eine webbasierte Lösung (Web-App) für Situationen an, in denen der Gast kein eigenes Smartphone nutzen kann oder möchte. Auch diese Lösung zeigt Probleme im Hinblick auf die Überprüfbarkeit der angegebenen Kontaktdaten. Denn in der Luca-Web-App ist es möglich, durch eine relativ einfache Modifikation des Webseiten-Quellcodes auf der Client-Seite die SMS-basierte Verifizierung ganz zu überspringen.

Abgesehen von den Problemen mit der Verifizierbarkeit der Kontaktdaten, sind auch die gesammelten Check-in-Informationen einem potentiellen Missbrauch ausgesetzt. Das liegt daran, dass Luca mehrere Möglichkeiten bietet, einen Check-in durchzuführen. Die einfachste Möglichkeit ist, dass der Dienstanbieter einen gedruckten QR-Code bereithält, den der Gast scannen kann. Diese sogenannten “statischen” QR-Codes laufen nicht ab und kodieren eine URL, um sich mit der App am Dienstanbieterort anzumelden. Statische QR-Codes sind relativ einfach zu kopieren und zu vervielfältigen, was auch dem Luca Entwicklungsteam bekannt ist, wie sie erklären: “Von Natur aus sind QR-Codes leicht zu fälschen, indem man sie einfach kopiert […] es liegt am Dienstanbieter, sicherzustellen, dass gedruckte QR-Codes nicht physisch ersetzt werden.” (https://luca-app.de/securityconcept/processes/guest_self_checkin.html#authenticity-of-printed-qr-codes)

Ein weiterer Missbrauch ist, dass QR-Codes einfach gescannt werden können und die URL für Remote-Check-ins verwendet werden kann, ohne dass der Gast am Ort des Lokals physisch anwesend sein muss.

Wie bereits erwähnt, wird die Luca-App als digitaler Ersatz für das Ausfüllen eines physischen Kontaktinformationsformulars auf Papier vermarktet. Dementsprechend erwarten die Gäste, dass für diese Lösung ähnliche „Sicherheitsannahmen“ gelten. In der Praxis können die oben erwähnten Probleme im Aufbau von Luca jedoch zu einer Reihe von neuen Angriffsszenarien führen, die eine Manipulation des Gesamtsystems zur Folge haben können.

Im Folgenden beschreiben wir zwei Angriffe:  “Generierung falscher Kontakte” und „Framing von Gästen“ (jemanden etwas anhängen).  

Generierung falscher Kontakte:

  1. Es kann gezeigt werden, dass ein Angreifer die Luca-Web-App nutzen kann, um eine beliebige Anzahl “falscher” Gäste zu registrieren. Das liegt an den bereits erwähnten Problemen mit der SMS-Verifizierung.
  2. Anschließend kann der Angreifer z.B. durch die Stadt streifen und die am Eingang oder an den Tischen üblichen QR-Codes der Lokale scannen und die darin enthaltenen URLs sammeln, die zum Einchecken verwendet werden.
  3. Sobald eine ausreichende Anzahl dieser extrahierten URLs gesammelt wurde, werden diese verwendet, um automatisiert Check-ins für alle “falschen” Gäste an jedem Veranstaltungsort zu erstellen und zwar mehrmals an verschiedenen Tagen. Um solche Angriffe vor den Augen möglicher menschlicher Prüfer besser zu verschleiern, können diese Check-ins in Bezug auf ihre Dauer und die Anzahl der eincheckenden “Gäste” randomisiert werden.

Folge: Sobald gemeldet wird, dass eines der avisierten Lokale von einem infizierten Gast besucht worden ist, erhalten die Gesundheitsbehörden Zugriff auf entsprechende Check-in-Kontaktdaten, die auch die “gefälschten” Gäste-Check-ins enthalten. Dies kann zu einem großen Reputationsproblem des Lokals führen, da für die Gesundheitsbehörden der Anschein erweckt wird, dass viel mehr Gäste das Lokal besucht haben, als es z. B. die Vorschriften zulassen würden. Außerdem würde dies eine hohe Arbeitsbelastung für die manuelle Kontaktverfolgung der Gesundheitsämter bedeuten, da sie viel Zeit aufwenden müssten, um „falsche“ Gäste zu kontaktieren. Erfolgreiche Angriffe könnten möglicherweise auch zu falschen Verbreitungszahlen in der Statistik führen.

Einen solchen, auf physischen Kontaktformulare basierenden Angriff durchzuführen, wäre sehr umständlich und erfordert viele Ressourcen. Durch die Nutzung der Luca-App könnten solche Angriffe leicht automatisiert werden.

Framing von Gästen:

Der zweite Angriff betrifft eine bestimmte Person, wir nennen ihn “Framing von Gästen“.

  1. Der Angreifer beginnt mit der Erstellung eines gefälschten Kontos unter Verwendung der Kontaktdaten seines Opfers.
  2. Wie im vorherigen Angriffsszenario beschrieben, kann der Angreifer dann in einem Zielgebiet umherziehen und Login-URLs sammeln, die aus den QR-Codes von Veranstaltungsorten extrahiert wurden.
  3. Anschließend kann der Angreifer für das gefälschte Konto, das die Kontaktdaten des Opfers enthält, Check-ins in allen vermeintlich besuchten Geschäften erstellen.

Folge: Sobald eines dieser Lokale einen infizierten Gast meldet, würde unser avisiertes Opfer vom entsprechenden Gesundheitsamt kontaktiert werden. Das kann dazu führen, dass das Opfer selbst fälschlicherweise in Quarantäne muss, oder dass der Prozess der Kontaktsuche der Gesundheitsbehörden unnötig komplizierter wird.

Wenn in den Medien weit verbreitete Berichte über eine falsche Verteilung oder unnötige Infektionsmeldungen erscheinen, kann dies außerdem dazu führen, dass das Vertrauen in die Ermittlung von Kontaktpersonen in den Augen der Öffentlichkeit insgesamt sinkt.

Einige Datenschutzprobleme der Luca-App

Im Hinblick auf Datenschutzaspekte lassen sich u.a. folgende Beispiele erkennen:

  • Der Luca-Server kann aus der Zählung der Check-ins ableiten, wie viele Gäste am entsprechenden Ort eingecheckt haben.
  • Der Luca-Server kann die IP-Adresse und Telefonnummer bei der Registrierung eines Gastes (während der SMS-Verifizierung) sowie die IP-Adresse und die Uhrzeit bei jedem Check-in aufzeichnen und zu den Pseudonymen infizierter Gäste zuzuordnen, um diese zu de-anonymisieren. Dies ist möglich, da der Server Zugriff auf die Check-in-Historie von infizierten Gästen erhält, einschließlich der Pseudonyme von Gästen, die zur gleichen Zeit die Veranstaltungsorte besuchen (d. h. die möglichen Kontaktpersonen).
  • Verknüpfung der Check-ins von Gäste-Gruppen durch Metadaten (z. B. IP und Zeit).

Die Ursachen dieser Probleme liegt im Systementwurf z.B., dass die Daten von einem Server gesammelt werden. Auch wenn diese verschlüsselt sind, gibt es notwendige Metadaten, die wiederum Verknüpfungsinformationen liefern. Also, die zugrundeliegende Annahme ist, dass der Luca-Server kompromittiert werden kann oder böswillig ist. Diese Informationsverknüpfungen sind jedoch systeminhärent und stellen somit keine Überraschung dar.

Sicherlich ist es wichtig, dass die Privatsphäre der Gäste unter Berücksichtigung angemessener Datenschutzanforderungen gewährleistet wird. In einer Krisensituation, wie einer Pandemie, brauchen wir jedoch einen sinnvollen Kompromiss zwischen Sicherheit, Privatsphäre und Effektivität. Metadaten können im Allgemeinen mit Hilfe intelligenter Datenverarbeitung miteinander verknüpft werden. Allerdings können diese Gefahren durch eine genaue und durchdachte Risiko- und Bedrohungsanalyse minimiert werden, damit Digitaltechnologien effektiv gegen Pandemie in der Praxis eingesetzt werden können. Das kann wiederum bedeuten, dass der Gast in bestimmten Fällen einige Metadaten über sich (z.B. beim Einchecken in ein Lokal) offenbaren sollte.

Wir hören immer wieder das Argument, dass der Datenschutz die Effektivität eines digitalen Kontaktnachverfolgungssystems verschlechtert. Beispielsweise sei dies der Grund für die Ineffektivität der Corona-Warn-App (CWA): Wenn der Datenschutz teilweise aufgehoben wird, dann kann man eine zentralisierte Lösung einsetzten, die nützliche Informationen über die Entwicklung der Pandemie liefern kann. Aus unserer Sicht jedoch ist der Datenschutz kein Hindernis, sondern eine essentielle Funktion in einer demokratischen Informationsgesellschaft. Eine datenschützende und effektive Digitaltechnologie für Kontaktnachverfolgung benötigt deshalb eine datenschützende Infrastruktur, wobei die App nur eine Komponente davon ist. Eine solche Infrastruktur fehlt im Fall der Corona-Warn-App komplett.

Bisher wurde Corona-Warn-App (CWA) von vielen Wissenschaftler:innen kritisiert. Beanstandet wurden mangelnde Sicherheit und Privatheit sowie die Tatsache, dass die genutzte Kerntechnologie für die Nachverfolgung von Google und Apple stammt, die nun offiziell mehr Daten sammeln können, da die Corona-Warn-App in Deutschland von der Politik unterstützt wird. Daher ist die Aussage, dass die Ineffektivität der Corona-Warn-App am Datenschutz läge fraglich. Gleichzeitig sind Kompromisse nötig.

Contact Tracing by Giant Data Collectors

Together with our collaborators from all over Europe, we have published a critical report focusing on the issues related to the currently predominant contact tracing solution by Google and Apple. The report is entitled “Contact Tracing by Giant Data Collectors: Opening Pandora’s Box of Threats to Privacy, Sovereignty and National Security” and can be downloaded here.

Security and privacy vulnerabilities in the contact tracing approach by Google and Apple

A research team from the Technical University of Darmstadt, the University of Marburg and the University of Würzburg has demonstrated and confirmed vulnerabilities related to data protection and security of the Google and Apple specification for contact tracing apps under real-world conditions. The German contact tracing app developed by Deutsche Telekom and SAP on behalf of the German government is based on this approach. Also the Swiss and Italian contact tracing apps utilise this tracing technology.

Through experiments in real-world scenarios, the research team showed that risks already known on a theoretical level can be exploited in real life using commonly used technical means. This attack allows an external attacker to create detailed movement profiles of persons infected with COVID-19 and, under certain circumstances, identify them. On the other hand, an attacker can also manipulate the collected contact tracing information through so-called relay attacks, which can impair the accuracy and reliability of the entire contact tracing system.

Contact tracing apps on mobile devices promise the possibility of significantly reducing the manual effort needed to identify contact chains of infected persons and increasing the coverage of contact tracing. One of the most well-known suggestions for contact tracing comes from a collaboration of the companies Google and Apple. It is expected that the two US companies will integrate this new approach as a standard functionality into their respective mobile operating systems, Android and iOS. Some countries, including Germany, have already chosen this approach in their national contact tracing app projects.

The starting point for the experiments of the IT security experts from the three universities were previously published reports on possible data protection and security risks of the so-called “Google Apple Protocol” (GAP). The research team tested whether the attacks described on a conceptual level could be carried out in practice. Their experiments showed that GAP is susceptible to user movement profiling and may therefore allow an attacker to de-anonymize infected persons. On the other hand, so-called relay or wormhole attacks are also possible in GAP, which means that attackers can generate incorrect contact tracing data and negatively impact the accuracy and correctness of the overall system.
The research team implemented the attacks using commercially available inexpensive tools such as Bluetooth sniffers (as an app on smartphones or on Raspberry Pis), which can also be used in mobile environments. Since the implementation of the GAP approach is not yet available to the broader scientific community, the research team constructed the attacks based on previously published specifications. The results show that with the help of strategically placed sensors in a certain area, the movements of infected persons, simulated by test subjects in their experiments, could be reconstructed in detail. It was possible to identify sensitive places the test subjects visited as well as possible social relationships between them.

The vulnerability of GAP to so-called relay or wormhole attacks also reveals weaknesses. This attack enables an attacker to collect the Bluetooth IDs generated by contact tracing apps, and to pass them on to more distant locations without being noticed. Among other things, Bluetooth IDs were successfully transmitted between two cities 40 kilometres apart. This could allow an attacker to compromise the contact tracing system as a whole by falsely duplicating information about the presence of infected persons in many locations, which could result in a significant increase in false alarms about the potential contacts with infected persons.
Overall, the research team sees urgent need for improvement in the approach proposed by Google and Apple for contact tracing apps.
A detailed description of the experiments and their results can be found in the full study report.

Tags: , , , , ,

New App version 1.8 Beta available

As of today, a new version 1.8 Beta of the TraceCORONA app is available for download. This updated app version contains several improvements:

  • Multilingual app: English and German UI
  • Improvements in Bluetooth communication
  • Improvements in usability and user interface

You can download the new app version here:

We would be happy if you would take the time to test the app. Instructions on what you can test can be found here.

We would also appreciate any feedback on the app. The best way to send us your feedback is via the user feedback form.

Australian Covidsafe App facing difficulties due to privacy concerns

The Australian Covidsafe contact tracing app has been in use for roughly a month but is now facing criticism according to this news article by The Guardian. The app is following a centralised tracing approach and collects extensive information about their users (for a comparison of tracing approaches in different countries, please see here).

The app was initially marketed by the Australian government as a key requirement for being able to lift social distancing measures. However, according to the article, only one case of successful contact tracing has been attributed to the Covidsafe app so far, in spite of millions of users downloading the app. The justification for performing extensive data collection of such a large user base and the associated significant risks to their privacy seems therefore insufficient in view of the actual benefits the app can provide. In general, tracing apps should be seen as an important complementary measure to increase the coverage of manual contact tracing, but not as the main solution.

Another aspect is that it is not sufficient that users just download the app. They must be willing to actively use it. If using the app is perceived as invading user privacy, many users will simply not use it. As the article discusses, changing the privacy solution of the app later on will be very difficult. It is therefore better to select a decentralised and anonymous tracing solution from the beginning on.

Tags: , , , ,

The Problem with the Apple / Google Tracing Solution

As discussed in the previous blog post, the tracing process should be based on distributed contact verification. In this context, the three most notable tracing concepts proposed so far are the API proposed by Apple and Google, the Swiss-led DP-3T project proposal, and TraceCORONA developed by the Technische Universität Darmstadt, which I represent.

Of these, Apple’s and Google’s proposal is the weakest in terms of privacy properties, as it requires infected individuals to publish all Bluetooth proximity identifiers they have used during the days they may have been infectious to all devices participating in the system. It is thus possible for all applications and entities involved in the system to potentially track the movements (and thus de-anonymise) any infected persons during these days.

The Swiss-led DP-3T project’s design 2 provides better protection for infected individuals, as the local identifiers used by the infected person are only revealed to the background system in this model. Therefore, other users of the system will not be able to misuse proximity identifiers of users for tracking their movements. However, in the DP-3T design 2, it is possible to track infected persons by (mis)using the data stored in the backend system, as all proximity identifiers revealed by infected persons are known to the backend system.

Unlike almost all other proposed tracing models, the TraceCORONA tracing model is not based on frequently changing pseudonymous proximity identifiers, but on strong cryptographic Encounter Tokens that are unique to each encounter between two users. The cryptographic features of encounter tokens are such that even having unauthorised access to information in the backend system, the Encounter Token cannot be associated with the proximity data that devices beacon out via Bluetooth and may be collected with Bluetooth sensors. For this reason, identification of a contact is only possible for the actual devices that were involved in the contact and tracking of infected users is thus not possible even using backend system information. A comparison of the features of TraceCORONA and a detailed comparison with other major tracing application models is available here.

Tags: , , , ,

Risks associated with Tracing Apps with insufficient privacy solutions

The biggest risks associated with contact tracing apps are related to the potential misuse of the information they collect. Compared to many other types of applications, an app for contact tracking inevitably collects an exceptionally large amount of sensitive information about the contacts and relationships between individual users in great detail. In addition, for a mobile application to be effective for its intended purpose, as many citizens as possible should voluntarily install the app and actively use it. Due to this, the system related to the monitoring application will collect a lot of information about the mutual contacts of people – considerably more than any other system currently used by authorities! It is clear, therefore, that the implementation of the system and the monitoring application must be designed such that effective contact tracing can be achieved, while minimizing the exposure of privacy-sensitive user data.

Centralized tracing models, such as, e.g., The TraceTogether solution used in Singapore or the CovidSafe application used in Australia, as well as the PEPP-PT model developed in Germany, do not provide adequate privacy protection for their users in this regard.

These systems are based on an approach in which a centralized back-end system assigns a unique identifier (a pseudonym) to each user’s application, from which frequently-changing pseudonymous proximity identifiers are derived and broadcast over Bluetooth to other nearby devices. The weakness of this approach is that the backend system is able to associate all proximity identifiers of all users with the unique pseudonym of each user. This in turn enables comprehensive monitoring of all users of the system.

By recording proximity identifiers observed by Bluetooth sensors in a number of strategically placed observation points in a given area (e.g. in a particular city), it is possible to track the movements of individual users between observation points and thus collect very detailed movement profiles of individual users.

Although the system does not explicitly collect or record the true identities of individual users, movement profiles based on pseudonymous tracing data make it possible to identify a large fraction of users with high probability. This is mainly because movement profiles are very distinctive. For example, using only the locations of home (main location during the night) and the workplace (main location during the day) make it possible to identify a very large proportion of people unambiguously. Also other possibilities for de-anonymisation have been proposed: for example, it is conceivable that by placing a Bluetooth sensor close to a camera system with facial recognition ability, it is in principle possible to directly associate the proximity identifier beaconed over Bluetooth and thereby the pseudonym used by the system with an identifiable person and thus entirely de-anonymise the person in question.

For reasons mentioned above, contact tracing apps should be based on decentralized identification of contacts. In this model, the backend system does not have information about proximity identifiers of users and is therefore unable to associate them with individual users. Indeed, due to the fundamental problems with the centralized tracing model, the Federal Government of Germany decided to abandon the approach of the PEPP-PT consortium, which it initially supported, and has set clear criteria for the German Coronavirus surveillance application to be based on decentralized contact tracing.

Tags: , , , , ,

Tracing the societal effects of COVID-19

Contact tracing using apps like TraceCORONA is only one part in the puzzle of encountering a disease like COVID-19. It is also important that authorities and policymakers receive timely and representative information about the societal impacts of COVID-19 and its perceptionst in the general population.

A very interesting project in this regard is the Covid19 Impact Survey conducted by our colleagues from Spain. It consists of an on-line survey comprising 25 concise and easy-to-answer questions that can help the researchers to obtain important information about how the disease impacts the life of people in different countries and how people perceive it.

The anonymous survey developed by the Government of Valencia (spanish version) and ELLIS Alicante (non-spanish versions) is available in 12 different languages and can be found here. The privacy policy related to the survey can be found here.

The researchers have also made available a research report related to initial results of the survey as well as a highly interesting overview of response statistics.

Tags: , ,