Hello dear reader!
It seems that the world is getting so strange that Apple and Google have decided to do something amazing, something I thought it would be a cold day in hell before it happened – they decided to work together. You have probably read about this in the news, they have created what they call the “Exposure Notification” system, which is as useful as controversial in many places. While there are many explanations as to what it does and how, I decided to look into the actual SDKs and give you a more complete picture of how it works.
Overall the idea is the following: Your phone is assigned a unique iD which rotates every so often according to a set rule, this iD is interchanged with nearby devices via bluetooth and timestamped. If a user who has been near enough to exchange iDs with another is tested positive, he/she can use the App to report this unfortunate event and warn others that they may have been exposed to Covid. Lets look at a video made by Google to showcase this:
Why would we need this API in the first place? Well it’s simple, Mobile OSs are very limiting when it comes to this kind of information exchange, specially Apple who directly does not allow this type of bluetooth background mode by default. Therefore, it makes total sense for the two tech giants to actually showcase how this should be done and set the ground rules before it becomes chaos.
So, in a nutshell, this is a what happens:
Right, now that we have a basic idea of how this works we can look at the exposure SDK on Android and iOS . For those of you who are worried about privacy, don’t be, it is very clear that IDs cannot be related to a given person, nor is any location data used (in fact these apps pass a different verification system with strict controls where location permissions are forbidden) and access to any personal information is not used. Of course you are in control of when and for long you share your ID with others.
Reading though the documentation, apart from requesting access to special entitlements needed to send and receive exposure notifications, the API defines two kinds of roles:
- Affected user-When a user has a confirmed or probable diagnosis of COVID-19 (as defined by the Health Authority), the framework identifies them as affected and shares their diagnosis keys to alert other users to potential exposure.
- Potentially exposed user – To assign a user the potentially exposed role, the framework determines whether a set of temporary exposure keys indicate proximity to an affected user. If so, the app can retrieve additional information such as date and duration from the framework.
This solves a great question, since the system is prepared to take into account the duration for which you are exposed to any given user.
Following on we come to a very interesting point, each organism willing to use the system must provide their own server. An EN (Exposure Notification) server, at a minimum, must allow exposure notification clients to:
- Retrieve diagnosis keys so they can check for potential exposures
- Submit temporary exposure keys
The EN server can choose how to implement these capabilities as long as the data that passes to and from the exposure notification client conforms to the data formats this article describes. Google has created a sample server in Go (finally it seems to be using the language it created and promoted but rarely developed in) which can be found on GitHub. This server exposes and API which allows the following:
- Accepting the temporary exposure keys of affected users from mobile devices.
- Validating the temporary exposure keys using the device attestation API.
- Storing the temporary exposure keys in a database.
- Periodically generating incremental files that will be downloaded by mobile devices to perform the key matching algorithm on the mobile device.
- Sending a public key to devices, and digitally signing the incremental files with a private key.
- Periodically deleting old temporary exposure keys. After 14 days, or configured time period, the exposure keys can no longer be matched to a device.
The system is dockerised and ready to run on cloud platforms using known systems (and equivalents) like S3 and PostgreSQL. It will be interesting to see how governments will handle these requirements, since this type of system is probably going to receive a huge amount of traffic.
Anyway, so much for thinking “mobile apps are dead”, as now they are becoming our greatest allies in fighting the worst crisis in recent history. Its a pity that some governments (like the Spanish where I live) have taken so long to actually release this.
Would you like to dive deeper into how it works? Let me know and I’ll prepare a new post!
Hope you are all well and staying safe.
Until next time! Take care!
Pablo Clemente Pérez 