How it started
It began as a different idea in the COVID-19 Global Hackathon. It's now matured into a full blown contact tracing app that makes no sacrifices on effectiveness vs privacy.
The problem
Contact tracing is the method of tracking down all those people an infected person has interacted with to warn them they may be at risk. They can then take action to prevent the virus spreading further.
The leading solution right now is a decentralized model that anonymously tracks Bluetooth pings between users. But there's issues with this approach.
- It's slow, once someone is diagnosed, you have to wait for them to share their data before others can be warned.
- It's slow. A device has to download a large data set and crunch it locally to see if the user is at risk, the user might not know if they are at risk for many hours and in some cases up to a day.
- Can't cross boundaries As a workaround to the above point, some solutions are only downloading data for a small geographic region. This means if an infected use travels from one region to another, the infection chain will not be tracked.
- It's not really decentralized. Infected user's data is shared with a central authority, and the central authority shares the data publically, this is arguably more risky than keeping the data private on the server.
- It can't warn you about areas, e.g. if you visited the same location 20 minutes after a virus carrier was at the same spot.
- It's unreliable. Bluetooth isn't battle tested to be used for this sort of thing. Whereas GPS is.
How we solve it
We use a centralised model, but we decentralise the encryption of the data.
What does that mean?
We use multiple servers that are responsible for encrypting the user's data. No single server gets the full picture. When the data lands on the central server, it can only check for hash collisions to see if users are at risk. No personal or location information can be determined.
What benefits does this approach have?
We can warn people who are at risk very quickly. We can also instantly contact trace those who have not been in direct contact with a virus carrier but have been in contact with those who are at risk. It may be the case that Bluetooth tracing is simply too slow to stop a future outbreak, with this method we can dial up and down to what degree we contact trace in order to tackle different situations as they develop.
Tech stack
We picked technologies that scale well, the server is powered by a noSQL database and runs on AWS lambda (but could be easily ported to locally run hardware or another provider), this means its capable of scaling up and down without limitation.
The mobile app is built with React-Native, which means we have a ready to go solution for both Android and iOS.
Hackathon plans
We aim to complete the following.
- Be feature complete, remaining features to do this weekend
- Write the algorithm that marks users as at risk
- Build the salt server implementation
- Health authority integration to verify positive diagnoses
- Fix bugs, ensure the feature set is solid
- Create awareness
- Make connections with those who can find value in using the tech
Future plans
Getting in touch with health authorities and governments to find an area to trial the solution. Then perhaps roll out throughout the EU if it proves an effective tool. With this concept it has potential for each EU member state to have its own salt server, which ensures no specific authority has overall control of user data and each member state plays its part in keeping data private.



Log in or sign up for Devpost to join the conversation.