This is a feature comparison matrix of different classes of contact tracing projects (both applications and physical devices), produced by different projects from around the world in different stages of maturity. These initiatives come from vastly different cultural backgrounds and serve different goals, meaning they have a wide range of design goals: some solutions aim at supporting self-diagnosis and guidance or even just a private contact diary, while others are meant for country-wide symptom reporting, proximity alerts, exposure notification or scientific use cases such as geophylogenetic modelling. And they may have to meet different legal requirements in the context in which they are to be used. These different design goals obviously result in vastly different engineering decisions, which may or may not be portable to other classes of solutions. However, mapping the problem and solution space across all of these projects is no doubt helpful - there is a great deal to be learned from how other projects autonomously tackle the same or similar issues.

How to use this feature matrix

The overview below allows to compare the various features/properties of these proposed projects (there is a separate overview of protocol properties for the underlying shared protocols). Each horizontal row represents a feature or property, while each column represents a project (an actual application or device). An application with the same name for another platform may or may not be seen as a individual project, depending on the amount of platform-specific code and dependencies. 

Certain attributes have a negative connotation, these marker buttons are demarcated by the color red. Others are linked to desired or positive features, demarcated by the color green. And yet others are neutral, these are blue. When you hover over a marker button, you will see an explanation of the attribute it is linked to.

If a certain property is not yet known, it is shown as a blue button with a question mark. If you want to help out, click on such a blue button. This brings you to a new page where you can edit the data. Look into the project documentation in question and fill out the missing information you can find. Please provide a proper reference just below it, so others can easily verify your findings. Thanks for your help!

How editing works

You can edit the features and properties below by clicking on them and in the following screen click the edit button in the top right. This will take you to an editing environment where you can change information, preview your edit, add a summary of what you changed and more. Note that these edits take place in a staging environment. This means that your additions and changes are first reviewed by our editors before the information is updated on the wiki.

StopCovid Simmel BlueTrace Corona-Warn-App CoronaMelder COVIDSafe ProteGO Safe Immuni

1.1.0 on Google Play store and 1.1.1 on App Store



Android: 1.0.0, iOS: 1.0.4



Android 1.3.0 &  iOS 1.3.1


Within the project, coordinated by Inria, the members of the StopCovid project team are involved in their field of expertise:

  • Inria : coordination and transmission protocol, privacy-by-design;
  • ANSSI : cybersecurity 
  • Capgemini : back-end architecture and development;
  • Dassault Systèmes : SecNumCloud qualified sovereign data infrastructure;
  • Inserm : health models;
  • Lunabee Studio : development of mobile applications;
  • Orange : application distribution and interoperability;
  • Santé Publique France : integration and coordination of the application in the global strategy of contact tracing;
  • Withings : connected objects.

Fraunhofer Institut
Healthy Together
Robert Koch Institut

Dutch Ministry of Health, Welfare and Sport (VWS) in cooperation with the Dutch public health authority (GGD)

Australian Government

Ministry of Digital Affairs (Poland)
GovTech Polska


Bending Spoons S.p. A

Source code Repository (specifically the nl-covid19-notification-app repositories)

Open Source x x x
Other primary sources of information

Overview of source code for StopCovid app components and documentation ->

Repository of the underlying protocol ROBERT ->

Protocol specification, white paper and other technical documentation ->

Scientific resources about underlying protocol ROBERT ->

Original requirements document (in Dutch):



Dataflow description

Our proximity tracing scheme relies on an App installed on each mobile phone, supported  by a back-end server. In a such distributed architecture, two considerations are important    (1) where the data are stored and (2) where the status of the user (at risk or not) is verified. In our scheme, the data to be stored is shared between the App and back-end server. The   data collection of proximity contacts is performed and stored locally on each App.
This proximity contacts are never revealed to the server except when a user is diagnosed  COVID-positive. In this specific case, upon agreement from the user and authorisation from  the health authority, the App shares, anonymously, with the server the proximity  contacts that it has collected during the estimated contagious period, typically the last 14  days. This data is used by the back-end server to compute an exposure risk score for each of the individuals, defined as anonymous identifiers, who have been in contact with this  infected user. Users periodically probe the server to know whether their risk score indicates  that they are at risk. As a result, users only learn one bit of information from the  server (“at risk” or not “at risk”). They don’t get any information about other users and, in  particular, they don’t learn who potentially exposed them. The back-end server only maintains the list of exposed users (through anonymous pseudonyms as no personal information are maintained on the server) with their risk scores. These risk scores can easily be adapted according the evolution of the pandemic or the evolving knowledge of the epidemiologists on the COVID-19 virus.


Users can voluntarily download the app from the Apple App Store or Google Play. The user registers to use the app by entering a name, age range, mobile number and postcode and will receive a confirmation SMS text message to complete the installation of the app. On the basis of this information, an encrypted reference code is generated for the app on that phone.

COVIDSafe uses Bluetooth® to look for other devices that have the app installed. It takes a note of a contact when it occurs, by securely logging the other user’s encrypted reference code. The date, time and proximity of the contact are generated on the user’s phone, and the phone model is also noted. This information is then securely encrypted and stored on the phone. Your location is not recorded.

This information is securely encrypted and stored on the phone.

The app uses a rolling 21-day window to allow for the maximum 14-day incubation period of the coronavirus, and the time taken to confirm a positive test result. The rolling 21-day window allows the app to continuously note only those user contacts that occur during the coronavirus incubation window. Contacts that occurred outside of the 21-day window are automatically deleted from the user’s phone.

The encrypted close contact information on your phone is not accessible by anyone, including you. If you are diagnosed with the virus, you will be asked to consent to upload your close contact information to a highly secure information storage system. The uploaded information enables state or territory health officials to contact the user and close contacts to provide advice on actions they should take to manage their health.

This cycle continues if a user of the app who was a close contact subsequently tests positive.


TEK and RPI generation. Every 24 hours, the Mobile Client generates a new TEK (Temporary Exposure Key) and stores it locally. The Mobile Client derives RPIs (Rolling Proximity Identifier) from the TEK via a cryptographic hash function. Every RPI is associated with a subinterval of the 24 hours of a TEK’s validity. Using a cryptographic hash function makes it practically impossible to derive a TEK from an RPI.

RPI exchange. Mobile Clients use BLE to continuously broadcast the RPI associated with the current subinterval of the 24 hours, and collect RPIs from Mobile Clients they were Exposed to. The received RPIs are stored locally, together with the timestamp of the event and the Attenuation.

TEK upload. When a user tests positive for SARS-CoV-2, a Healthcare Operator will ask them whether they wish to dictate the OTP (One Time Password) they can locate in the App. If so, the Healthcare Operator inserts the OTP provided by the user into the HIS (Health Information System), and the HIS forwards the OTP to the OTP Service. This operation authorises the App to upload to the Exposure Ingestion Service the TEKs generated over the previous 14 days.

TEK Chunk publishing. On a regular basis, the Exposure Ingestion Service creates TEK Chunks containing the TEKs that have been uploaded since the last TEK Chunk creation. The Exposure Reporting Service makes the TEK Chunk available publicly.

Exposure Detection and notification. On a regular basis, the Mobile Clients download the new TEK Chunks (A set of TEKs uploaded by Mobile Clients of users tested positive for COVID-19 in a specific time window), verify whether any TEK Matches the RPIs received and stored locally by the Mobile Client over the previous 14 days, and compute an Exposure Detection Summary. This includes summary information on Exposures to the TEKs within the TEK Chunk. It also includes the maximum Total Risk Score across these Exposures, if any. If at least one Exposure has occurred and the maximum Total Risk Score is above a certain threshold, Exposure Info is computed for each Exposure and the user is notified that they may be at risk, then provided with a recommendation of what to do.

Intended scope/Function Symptom reporting Self-diagnosis Proximity Alert Exposure notification Geo-restrictions/geo-fencing Contact diary Honeytracing Symptom reporting Exposure notification Symptom reporting Exposure notification Exposure notification Symptom reporting Exposure notification Self-diagnosis and guidance Self-diagnosis Exposure notification Self-diagnosis Exposure notification
Related Apps and components








Type of approximation/scanning technology bluetooth Bluetooth Low Energy Near-Ultrasound Bluetooth Low Energy Bluetooth Low Energy Bluetooth Low Energy bluetooth
Client Side Protocol(s) ROBERT DESIRE BlueTrace Apple-Google TCN DP-3T Apple-Google Apple-Google
Based on a tracing standard x x
Epidemiological evidence ? ? ? ? ? ? ?
Open Source licenses

The source codes of the StopCovid project are published in 2 forms: In a public code deposit. In this case, they are published in MPL 2.0,   unless otherwise specified in the file headers. Snapshots of the code of certain components including development are not open to contributions. In this case, they are published under an ad hoc license, which does not allow them rebroadcast (in original or modified form), or their exploitation. To avoid misunderstanding the exact license is specified in the file at the root of the code of each component.

CERN-OHL-1.2 -
Apache-2.0 -



GNU General Public License v3.0

Other software used in the project but not authored by ProteGO Safe team:

Apache License 2.0


Proprietary components

Submission Code Server Client API - This component specifies the client API of the Submission Code Server.

Submission Code Server - This component provides the following services: Generation of short and long codes: for health professionals (laboratories, doctors...) and verification and code consumption by the server side of the StopCovid platform.

? ?

Proprietary components used are the OS and the Exposure Notification API. The rest of the Android and iOS apps is open source and includes some third-party open source libraries.

Back end is open source ( and runs on Microsoft Windows servers (proprietary) in Dutch data centre.

? ? ?
(Software) Patents ? ? ? ? ? ? ?
Platforms android5+ android6+ ios Simmel android6+ ios iOS android5+ android6+ ios
Requirements Smartphone Smartphone Google Play Services Smartphone
App Store

Not yet available, but would be downloadable from the Apple Store and Google Play Store.

None (Google Play)



Apache 2.0

Component: Kotlinx Coroutines
License Text URL:
Source Code:

Component: Timber
License Text URL:
Source Code:

BSD 3-Clause

Component: Android Scanner Compat Library
License Text URL:
Source Code: 

Apache 2.0

Component: Truth
License Text URL:
Source Code:

EPL 1.0

Component: JUnit 4
License Text URL:
Source Code:

LGPL 3.0

Component: Zohhak
License Text URL:
Source Code:


Component: Mockito
License Text URL:
Source Code:

Component: Mockito Kotlin
License Text URL:
Source Code:

Component: Robolectric
License Text URL:
Source Code:

Circuit Python for Simmel -




? ?

Build environment ?



? ?

Android: Android Studio or Gradle Wrapper

iOS: Xcode 11.5 and Brew

Reproducible builds ? ? ? ? ? x
Update transparency ? ? ? ? ? ?
TUF update security ? ? ? ? ? ?
Dedicated Threat Model ? ? ?

(in Dutch:)

? ?

No formal threat model deliverable.

Third party Security Analysis

? ?


No available report.

Known Vulnerabilities ? ? ?

One known but not disclosed yet (as of 31 Aug 2020):

? ?

No exploitable vulnerability we are currently aware of.
A known shortcoming is the lack of signature of files that are hosted on the CDN, which we are planning to implement in a future release.

Strongly Encrypted Local Storage x ? x ? x x
Recenty system security flaws. Is the application dependent on system level software that has had critical vulnerabilities in the last 12 months)? ? ? ? ? ? ? ?
Data Privacy Impact Assessment ? ? ?

? ? ?
Third party reports on privacy considerations


? ?

Dutch Authority on Personal Data advice to government:

Manifest group:

? ? ?
Protection for minors and incompetents

? ? ? ? ? ?
Complete Runtime Control of the Hardware x ? x ? ? ?
Availability not restricted to Traceable Account Holders x x x x x
Does Not Require Third Party Account(s) x x x x x
Use of device specific identifiers x x ? x ? ? x
No Telemetry / Tracking x x x x x
Required OS permissions ? x ? x ? ?
Use of OS permissions ? ? ?

Apps do not have access to contacts, location etc. Apps do have access to Exposure Notification API. User can opt to share Exposure Notification TEKs. This requires explicit user consent.

? ?
Location (Android only).
On Android devices, Location needs to be on at the operating system level to detect nearby devices, although the A/G Framework’s documentation explicitly states that it does not actually use location data. This may be quite confusing for the user, but unfortunately it is outside of the Android App’s control. Please note that the Android App will not request the Location permission, nor will it have access to location data. However, Location needs to be activated at the operating system level for the A/G Framework to work properly.

Stores Geolocation History x x x x x x x
Time-constrained operation (will cease to work by itself at a given end date) ? x x x
Plausible Deniability ? x x ?
Explicit consent required for data sync ? ? ?
Bluetooth Anonymity x x x x
BroadCasts Wifi MAC Address x x x x x x x
Broadcasts Static Bluetooth ID x x x x x x x
Shares only anonymous attributes x x x x x
Selective data upload/Data redaction ? x x x x
Does the application expose the social graph of individuals? x x x x x x
Potential exposure of the user addres book or recent contacts x x x x x x x
Uploads Identity x x x x x x x
Uploads Phone Number ? x x x x x x
Activation Via Insecure Media x ? x x x x x
Uploads Geolocation History ? x x x x x x
Uploads Wifi MAC Address ? x x x x x x
Uploads Bluetooth ID x x x x x x x
Adequate protection against exposure of the IP Address of users ? x x x x x
Relevant legal publications

? ?

? ? ?
Relevant technical publications

? ? ? ? ? ?
Multi-Lingual ? x x x ?
Accessibility Certification reports (Web Content accessibility guidelines or equivalent) ? ? ?

? ? ?
Privacy-friendly Assistive Technology ? x x x x x x
Data Hosting ? ? ? ?
Back-end technology in use ? ? ?

? ?

If there is a property missing, please contact us through one of the communication channels or leave a comment below.

Created by Jos van den Oever on 2020/05/19 23:10
XWiki 11.10.3