An architecture design for tracking COVID-19 proximity that incorporates privacy

gistfile1.txt

Backend publishes 2 APIs

1. Fetch Near-to-Infected list
    Near-to-Infected list entry consists of:
    - userIDs that have been near to an infected person
    - Time when the userID was near an infected person
    This can be a static text file that gets updated when E-2 happens.
2. Append Near-to-Infected list
    This is going to be called when a person was diagnosed as positive.
    See E.

App does:

A. Always:
A-1. Advertises a BLE service
    BLE service has a read characteristic that returns the app's userID.
    BLE service has a write characteristic that lets other apps write their userIDs into (*1)
    Why not use iBeacon? (*2)
A-2. Scans for the same BLE service

B. When the app detects an BLE peripheral that advertises the service:
B-1. The app records:
    - The userID from the read characteristic response
    - Time
    - Location of *this* phone
    and does *not* send this to backend.
B-2. The app writes into the write characteristic that the BLE peripheral provides. (*1)
B-3. (Same as C-1)

C. When the app becomes active
C-1. If the app's own userID is older than X seconds, app generates a new userID in the phone
C-2. The app stores it's history of userIDs that it generated

D. When the app receives a silent push notification
D-1. App fetches the infected list from backend, and check if the history of userIDs of this app is included in there
    Which means, that I have been near to an infected person.
    TODO This has to be trustworthy too. Backend signs Near-to-Infected list and app verifies using known public key ?
D-2. If it was included
    TODO: Instruct user to stay at home and monitor yourself, be able to export your own location data to provide to medical personel after consent.

E. When the user knows that "I got infected" in a hospital
E-1. Tells the backend:
    These are all the userIDs and times that I was in proximity with.
    TODO: How to make this information trustworthy, maybe doctor should sign it? 
E-2. Backend appends the Near-to-Infected list with the provided information
E-3. Backend sends a silent push notification to all apps so that they can refresh the Near-to-Infected list

---
Notes
*1 We want to maximize the communication opportunity between iOS and Android apps, including when both are operating in the background.
iOS has a limitation that it cannot advertise a service in the background in a way that is discoverable by Android phones.

> All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW9

Which means, Android apps cannot discover iOS apps that are advertising in the background. iOS apps have to discover Android apps.
And when iOS apps discover Android apps, iOS apps should write their userID into the write characteristic that Android app provides. This way both iOS and Android apps can know each other's userIDs without involving a central server.

*2 Why not use iBeacon?
> Apps that use their underlying iOS device as an iBeacon must run in the foreground.
https://developer.apple.com/documentation/corelocation/turning_an_ios_device_into_an_ibeacon_device

We cannot expect people to run an app in foreground all the time when they get near to other people.
This has to run in the background.
https://developer.apple.com/documentation/corelocation/turning_an_ios_device_into_an_ibeacon_device