One is currently discussing (in Germany) the use of a corona tracking app to warn people who have had contact with infected people. The biggest challenges seem to come from data protection. How long would it take to develop such an app in this community open source with B4X? ;-)
Here are my thoughts:
purpose
The app can warn contacts of an infected person so that they can no longer infect others, even without symptoms. It therefore protects the contacts of an infected person's contacts.
Tracking
The app starts as soon as you leave the house, creates a random ID and sends signals via Bluetooth Low Energy (BLE). It also continuously registers all BLE beacons from apps from other devices in the area. If a beacon with high signal strength (short distance) persists for a certain period of time (from 15 minutes), new IDs are generated in both devices, then exchanged with each other and saved in the internal app database. Even without this exchange, the IDs are changed at irregular intervals.
Checking
Before the start of tracking, the check is carried out. For this purpose, all IDs of people who have already been diagnosed as positive are downloaded. If you have been in contact with one of these IDs, this means that you could be also infected. So you can stay at home straight away.
Positive diagnosis
If an infection is found, the app upload the saved IDs. This only affects all of your own IDs that have been exchanged with contacts in the past few days. The authorization feature can be activated by doctors and qualified persons in their app version using codes assigned by the admin. To completely obscure contact networks, additional pseudo-IDs can be mixed randomly between the real IDs.
Regional narrowing of the data
Usually People are only traveling regionally, it may make sense to e.g. indicate the first two digits of the zip code. The upload and download of the IDs then refer to the specified regions.
Admin / server
In the case of central data acquisition, the admin (assignment of rights for positive diagnosis) should not also receive the access rights to the database, but the roles should be splitted, e.g. RKI + another position. Also the database itself (server) could also be split into several independent ones, e.g. depending on the IDs values.
Summary of data protection measures
Only contact IDs with the appropriate contact intensity are saved at meetings. Neither time, location nor other additional information is necessary. Data can be deleted after x days. This pseudonymous data is only loaded to a server in a random order with additional, randomly supplemented pseudo-IDs in the event of an infection. Several independent sub-servers from different providers are also possible. Your own ID in the app is (regularly) changed.
Thoughts about traffic
Calculation example: With 10,000 registered new infections per day with an average of 5 registered contact events (including pseudo events for data obfuscation), 50,000 new ID entries would be created on the server every day. If stored for about 5 days, 250,000 IDs would be delivered when checking. It makes sense and is sufficient to use 32 bit integers for IDs, since the chance of false alarms due to ID repetitions is low and justifiable. When checking, 1 MB of data would be delivered. With widespread app use, up to 10,000,000 checks per day should be possible. The server load could be divided by the mentioned server splitting.
Here are my thoughts:
purpose
The app can warn contacts of an infected person so that they can no longer infect others, even without symptoms. It therefore protects the contacts of an infected person's contacts.
Tracking
The app starts as soon as you leave the house, creates a random ID and sends signals via Bluetooth Low Energy (BLE). It also continuously registers all BLE beacons from apps from other devices in the area. If a beacon with high signal strength (short distance) persists for a certain period of time (from 15 minutes), new IDs are generated in both devices, then exchanged with each other and saved in the internal app database. Even without this exchange, the IDs are changed at irregular intervals.
Checking
Before the start of tracking, the check is carried out. For this purpose, all IDs of people who have already been diagnosed as positive are downloaded. If you have been in contact with one of these IDs, this means that you could be also infected. So you can stay at home straight away.
Positive diagnosis
If an infection is found, the app upload the saved IDs. This only affects all of your own IDs that have been exchanged with contacts in the past few days. The authorization feature can be activated by doctors and qualified persons in their app version using codes assigned by the admin. To completely obscure contact networks, additional pseudo-IDs can be mixed randomly between the real IDs.
Regional narrowing of the data
Usually People are only traveling regionally, it may make sense to e.g. indicate the first two digits of the zip code. The upload and download of the IDs then refer to the specified regions.
Admin / server
In the case of central data acquisition, the admin (assignment of rights for positive diagnosis) should not also receive the access rights to the database, but the roles should be splitted, e.g. RKI + another position. Also the database itself (server) could also be split into several independent ones, e.g. depending on the IDs values.
Summary of data protection measures
Only contact IDs with the appropriate contact intensity are saved at meetings. Neither time, location nor other additional information is necessary. Data can be deleted after x days. This pseudonymous data is only loaded to a server in a random order with additional, randomly supplemented pseudo-IDs in the event of an infection. Several independent sub-servers from different providers are also possible. Your own ID in the app is (regularly) changed.
Thoughts about traffic
Calculation example: With 10,000 registered new infections per day with an average of 5 registered contact events (including pseudo events for data obfuscation), 50,000 new ID entries would be created on the server every day. If stored for about 5 days, 250,000 IDs would be delivered when checking. It makes sense and is sufficient to use 32 bit integers for IDs, since the chance of false alarms due to ID repetitions is low and justifiable. When checking, 1 MB of data would be delivered. With widespread app use, up to 10,000,000 checks per day should be possible. The server load could be divided by the mentioned server splitting.