COVID-19: Centralised, decentralised, or both?
There is currently a debate raging between two camps with radically different views on how to compute the infection risk.
DP3T, Apple and Google have opted for a decentralised design. The infection risk is computed independently on each users' devices, and the traced contacts never leave their phone.
France, Germany, and the UK opted for a centralised approach, sending traced contact data to a remote server. This design allows for more flexibility. The computation can be updated seamlessly, while the decentralised design would require millions of users to update their phones' app.
Centralising comes at a cost to the user: privacy, and consent. Once traced contacts are uploaded to a remote server, users cannot be guaranteed with certitude that their data will not be leaked by a rogue cloud engineer, sold to a third party or extracted by a hacker. Data could be used for something they did not consent, or worse, used for mass surveillance.
Some say that cloud servers can be protected, that data centres are fully secured with guards 24/7, cameras, dogs, and so on. Practically, different levels of organisational protection exist. Nevertheless, those are not technical protections. Securing physical machines is very different from securing data on a machine connected to a network.
Secretarium uses secure hardware to protect data even from someone with physical access to the machine. Data is encrypted and secure at all times; network transfer is encrypted; memory is encrypted; even CPU caches are encrypted. No-one in the human world can access the data, even Secretarium's engineers. Only the secure hardware can, in an encrypted context, in the machine world using only the code it is programmed to run.
Because secure hardware cannot be tampered with, it naturally decentralises control. Because data is encrypted, it can respect privacy and consent even if data is centralised. Secretarium's approach allows using the power of centralised data and security of decentralised control.