-
Notifications
You must be signed in to change notification settings - Fork 2
Home
The main goal of this project is to provide the general public with the ability to get vaccination appointments in their area. This is done in a way that is as privacy preserving as technically possible while still providing an easy to use interface.
In order to achieve this, we use end-to-end encryption between end users and vaccination sites. Unlike traditional web applications, most of the encryption is done directly in the web browser. While we assume that the server can be trusted to supply the user with no malicious code embedded in the web site, and that all communication between client and server is encrypted and verified via TLS, the server itself does not see any data that isn't needed for it's operation. Information like booking codes, that only the vaccination site needs to see, is encrypted directly in the users browser and can only be decrypted by the vaccination site where the appointment is made.
The code is organized in three main parts.
This is the application server written in Go and backed with a Redis database. It's main job is to facilitate asynchronous communication between all actors of the system.
This Typescript library is meant to run in the browser, using the API of the server and tending to all cryptography that is meant to be performed by the client. It provides a higher level API for front end developers.
The front end written in Typescript. It is responsible for everything that's displayed in the browser.
In order to understand how the different parts of this system work together, it is helpful to look at the different actors and their roles. What follows is a rough description deliberately glossing over some of the details.
Looking for an appointment can be done anonymously. As long as no appointment is actually booked, no credentials are needed.
At some point a user obtains a token from the server. This can be used to book an appointment at a vaccination site. The user is also supplied with a 16 character secret they can user to restore their session, access their booking details and cancel their booking. The first four characters of this secret are also the booking code for the user to authenticate them when they visit the vaccination site in person.
Every vaccination site is given a provider account in the system. The provider has several keys that are signed by an administrator role we call "mediator". The provider supplies a public key that can be used by the user to encrypt booking data so that only that specific provider is able to decrypt it.
Most data from a provider, like their open appointments and their address, are publicly available, but are signed by the provider so users are able to verify the origin of that data.
The mediator is an administrative role in the system. They verify the credentials of newly created provider accounts and, if that is successful, sign their public key. Only data from verified providers is visible to users. Providers that are not yet verified are called "unverified" or "pending".
Unlike users and providers, the mediator keys are not generated by the mediator itself, but provided and signed by the root key. The root user currently has no web interface but uses only cli tools.
The Root public key is openly available. So every user can verify that there is a signature chain from root to mediator to provider for every appointment and address they see.