Notification system

[cankisagun]

Background: This tool is a privacy preserving voluntary COVID-19 self-reporting platform for contact tracing. Users share their (encrypted) location history and test status, get a notification if you have been in proximity to higher risk locations.

Detailed explanation: Users who opt in for the notification system, should receive emails (or other forms of notification like text) if they are found to be in a high risk area. The notification should prompt the user to visit the application website (individual reporting screen) to get details on high risk locations the user has been to

To-do's:

• [ ] Assess different email notification alternatives
• [ ] Implement an email notification system

[cmalfesi]

How the notification system can get the list of encrypted id users with high risk? Will be an endpoint to query on the API Server? will be a query per id or a list of all infected ids?

[cankisagun]

@cmalfesi as I see there are 3 ways to do it, only the first one offers enough privacy

1. Notifications to be triggered by MongoDB. MongoDB knows the last time a user queries (logs-in), so we can setup a trigger (email) on MongoDB side to prompt the user to sign back in. This way user would check every time t (24 hours) to see if there are new high risk interactions. This will not leak any information. Probably the easiest way / what we want to implement first

2. Notification is shown on the webpage, if the user is logged in. This provides high privacy b/c the enclave directly communicates with the client, where the data can be decrypted locally. However the usability is low. I think there's value to add this as a default option (all users would have this when they login to their profile) - this is not currently possible b/c we don't have public/private key that's persistent like we do in blockchain use-cases

3. Email notification: This requires the backend to receive user_ID's from the enclave and then pass them to an email server. At this point there's a data leakage. Email server and the back-end knows which users are at risk. However this is much more usable than option 1. If we are building for this, then we require users to opt-in to notifications and communicate the privacy risks. This can be handled on the UI level. However even in that scenario, the data structure inside the enclave must include info about opt-in (out of scope)

[cmalfesi]

@cankisagun I see and understand the option. I think it is possible a combination of the options 1 and 3. I will think about it on my side a little more and check some options and combinations of cloud services that we can use to make it secure. I will draw an architecture plan so we can discuss it better through a graphic example.

[cankisagun]

@cmalfesi a good way to communicate Option 1 can be the following: "In the last 24 hours, X many users have submitted data to the system, log back-in to check whether you've had any high risk interactions"

[cmalfesi]

@cankisagun @ainsleys

I have researched and analyzed different user cases regarding Options 1 and 3 and here I share my vision about how we should proceed.

Analysis

Option 1

"Notifications to be triggered by MongoDB. MongoDB knows the last time a user queries (logs-in), so we can setup a trigger (email) on MongoDB side to prompt the user to sign back in. This way user would check every time t (24 hours) to see if there are new high risk interactions. This will not leak any information. Probably the easiest way / what we want to implement first"

User story

• Day 1: User A load locations and result Negative
• Day 1: NS does not send email
• Day 2: User B load locations and result No tested
• Day 2: NS does not send email
• Day 3: User C load locations and result Positive
• Day 3: NS send email to all users except the Positives

Negative - We could send thousands of emails every 24hs if we have a lot of users and reports per day (spam problem) - If there are several infected reports every day, users every day will receive an alert and have to login and check

Positive - This provides high privacy - Enclave is queried when the user is logged

Option 3

"Email notification: This requires the backend to receive user_ID's from the enclave and then pass them to an email server. At this point there's a data leakage. Email server and the back-end knows which users are at risk. However this is much more usable than option 1. If we are building for this, then we require users to opt-in to notifications and communicate the privacy risks. This can be handled on the UI level. However even in that scenario, the data structure inside the enclave must include info about opt-in (out of scope)"

I think this option is more secure and have better performance. Here my vision of the way to apply this is the next.

Architecture

User story 1- User sign up and sign in to the Frontend. Load the test result and locations 2- Register and validate the user and return the encrypted UserId and save the results data with UserId 3- save data of the new user and validate login 4- Enclave returns the individual report with "matches" 5- Fronted returns to the user the information of "matches" 6- Send the high risks users list to NS. Here we could implement 2 options: - Opt 1: Once a day NS GET the list of users id against Enclave API Server - Opt 2: Every time that Enclave receives a "positive", search "matches" and POST the list to the NS.
7- NS query the email through the user id and sends an email informing about the high risk of possible contact and ask him to login and check.

In step 6, we have to think about what is better to do, both options I think are ok.

Components description

Backend API
    Endpoints
        POST: Sign Up 
        POST: Login
        GET: GetEncryptedUserId   (only return it for logged user)
        POST: ReportTestResult (GET is not available)
    Security
         - It does not share tes results information, only let save data
         - Users can login once at a time.
         - Google user only can be validated session 


DB (MongoDB)
    Collections 
        User
        Reports
    Security
        It's only accessible from the Backend and NS.
        DB should be built into a secure cloud service

Notification System (NS) (Private server)
    Endpoints
        GET: userEmailbyId
    Security
        - No external access allowed
        - Only could receive requests from Enclave API Server
        - We could use internal or external email service because emails will send only notifications requesting to users to login into the system, will nos share sensible information.

API Server - Enclave (It process, save and "matches" the risks by contacts and locations)

I believe we can proceed with Option 1 for the MVP, but it'll better to apply Option 2.

[cankisagun]

@cmalfesi thank you for the detailed description. Let @ainsleys and I think about this. This is a part where it's helpful to get feedback from partner apps.

I would like to highlight that for Option 3 to work, we need to add notification information into the SGX b/c we only want opt-in users to receive email / have their information be shared with the email server