Protection from Coronavirus Silent Carriers
A new application allowing to alert people having had contact with a person infected with Coronavirus shared as an open source
We are a group of programmers from Polish office of Sigma Connectivity that have developed an open source application that would allow a fast and safe system of alerting people who have had contact with an infected person. We share this as an open source but the application would need to be employed by public authorities to ensure an effective functioning and to avoid scams and false alerts. Only if downloaded by the majority of people, it can carry on its functions, hence the application requires support of public authorities.
The goal is to use technology to keep on quarantine only people who may carry the virus instead of the whole society. This will allow us to get back to the normal life and help to protect the Polish economy.
The application is an automated system of tracking and alerting all people who were in contact with a person that was tested positive for Coronavirus, without involving any institutions and without disclosing personal data.
Problem
Once a test confirms that a person is infected with Coronavirus it usually takes about 4 or 5 days to identify, alert and quarantine all people who were in contact with the carrier. It requires loads of effort and excellent cooperation between the patient, medical staff and relevant institutions. It requires an infected person to recall all people that they were in any form of interactions — family, shops, service points etc. This is very difficult if not impossible. In the meantime, people that have had contact with an infected person might have got infected themselves and contaminate others. This contributes to fast spread of the virus because at its early stage the illness is symptomless, so the carrier is not aware of its problem and spreads the virus. Our goal was to find a fast and easy to use system alerting all people that might have been in contact with a person tested positively.
The inspiration came from brilliant Singapore idea and their governmental application TraceTogether. Unfortunately, we couldn’t find the details and the code. Lacking of the transparency is what the western societies afraid and don’t favor. Our intention is to inform people about a risky event from the past only for their sake. We convince people to use the system by elevating the intrinsic motivation.
Solution
The application that we have created offers a solution where a person that has had a contact with a patient tested positively is alarmed automatically by the previously downloaded application. To succeed, it requires to be downloaded by a vast amount of people. The system, however, does not store, use or disclose any personal users’ data.
How does it work?
The application takes advantage of the Bluetooth Low Energy (BLE) — which is used by smartphones / application to send signals between them. Basically, this system remembers which other phone was physically close and therefore is able to fast track any close human contact with an infected person.
Once a person is tested positively, he/she should be obliged to push a notification to all other users — before the message is posted to the network, a medical staff must confirm it with a single-use code in their application. The application based on algorithm immediately alerts all people that were in close distance (range) with the infected person and sends relevant warning information.
The conclusion we made after doing a feasibility study for Android mobiles. The reader can find the description below. We also publish the source code of the draft application.
Data collected
Time and length of contact between devices — we, humans, don’t remember the exact time of contact with other people because it’s useless information for our brain. On the other hand it’s quite trivial to keep this information in the database. Effective infection is proportional to time of contact with a virus.
Distance — Infecting is inversely proportional to distance between persons. BLE measures the signal strength which is not the same as the distance. As the signal strength depends on the environment conditions (presence of walls, rain etc.), it would be interesting to check its similarity to virus propagation. Unfortunately this value terribly fluctuates between different devices used for testing. Hence, even though the time/distance ratio looks theoretically perfect, by now we focus on the time measurement.
Unique identity (UID) — the devices must have an ID which can be noticed and saved by nearby devices during each encounter. Since hashing is infeasible to recover, we suggest keeping ID as a hash of MAC address and a long single shoot random number. Significant advantage of such approach is privacy because there is no way to identify the patients on any level of data exchange and collecting.
Notify all about the infected
While one person gets sick the system must send its UID to all participants. In other words the infected person must push the button “my UID is the carrier”. Even if we get millions of users, implementation of the confidential push-notify to all of them is simple. The tricky part is how to prevent user from notifying about being carrier accidentally and how to prevent risk of deliberate criminal actions related to spreading of panic. Hence there is a need to cooperate with the medical staff who are the only ones granted with the permissions to send the UID to the network. Presumably, it can be done in many ways — one of them is that the patient shows its UID as a QR Code and the doctor reads it using its version of the application. This aspect needs to be futher analyzed and developed.
The most important action right after pushing a notification, takes place on each mobile. All applications having its own list of encountered UIDs during the last few days, compare the newly fetched identification with the owned list. If a contact was found, the algorithm estimates probability of infection based on time and distance and instructs the user accordingly.
In short, putting into use of the system makes sense only in cooperation with the medical entities. It relates to the moments of pushing notification and also the final instructions and probability estimation must be reviewed/specified by virologists.
Technical Considerations
BLE scanning and broadcasting
We found only one approach to BLE broadcasting and scanning which satisfies these:
- It runs while the phone dozes
- It’s low power, i.e. it doesn’t drain the battery significantly
The solution is based on a foreground service which works like a background service except it displays a notification with an icon of your choice to indicate that your app is running in the background. This approach must be taken otherwise all devices with Android 8.0+ won’t allow to run the scanning while OS dozes. First, we start a service being in a main class which derives from AppCompatActivity()
Next, Service() which was already started must show the required notification
Before the advertiser starts for a first time we must generate the random UID. Later on we take the most significant bits only since payload is 8 Bytes long.
Like it was mentioned earlier the advertiser is able to beam and scan while the device’s screen is locked but it requires to set a filter. The goal is to scan for its own group of IDs instead of collecting all BLE devices around.
How to decide whether the user could be affected is not decided yet. Here is a proposition of the simplest approach
Notification of the network
Firebase Cloud Messaging service
Sources on GitHub
If you like to dig into the code then jump to GitHub
Client:
Authority app:
Firebase scripts:
