Cwa-wishlist: Epic 4: Missing User Story to optionally notify secondary contacts

[cfritzsche]

What

Under Epic 4, include a new user story E4.03:

As an app user, if I am exposed to the virus, I want to optionally notify secondary contacts, so that I can warn them before more time passes waiting for my test result.

Why

The Imperial College study outlining the usefulness of Contact tracing apps and Christian Drosten in his podcast talked about the importance of having the option to „skip one hop“ and directly notify secondary contacts as soon as the primary contact gets notified about a contact to an infected person. In certain circumstances (test centers overloaded or take too long), this could save critical time. They even went so far to say in exponential spread, this could be enabled by default to help stop overloading health care infrastructure.

Relevant quote: „The simple algorithm can easily be refined to be more informative — for example, quarantining areas if local epidemics become uncontrolled, quarantining whole households, or performing second- or third-degree contact tracing if case numbers are rising, which would result in more people being preemptively quarantined.“

Where

New User Story under Epic 4 (Exposure)

How

See comment below

---

Internal Tracking ID: EXPOSUREAPP-2167

[egandro]

Yes - please describe this in the documentation in great details how this will be done.

Assume the following events on our device:

| ID | Date |
| ------------- |:-------------:|
| 17 | 2020-06-21T18:25:43-05:00 |
| 25 | 2020-06-21T18:25:43-05:02 |
| 93 | 2020-06-22T19:25:43-05:00 |

With a decentralized concept - how can we contact the network of ID 93.

How will this be done without mirroring ALL data of ALL devices to a central server?

Please explain this in every detail in the document!

[cfritzsche]

I don’t think a complete contact network is required. The notification to the secondary contact can only come from the primary contact (who has recorded its IDs) once she gets the notification herself. Of course you could imagine notifying tertiary contacts from the secondary contact user who is notified etc. Each user only „knows“ his close contacts and the notification has to pass from hop to hop through those users.

[egandro]

I don’t think a complete contact network is required. The notification to the secondary contact can only come from the primary contact (who has recorded its IDs) once she gets the notification herself.

So you don't know what you don't know? (this is trivial but you will see my point)

Lets assume our ID (e.g. 100) gets marked as positive.

We need to alert the network of 100 in the range of [t1; today].

1. How does the server (oh it's getting central here!) gets the network of 100?
2. How to we access the other devices? e.g. 17, 25, 93? The server (oh central again here!) knows where 17, 25, 93 ist?

With 2) the server (it's central again) gets the list of IDs of the devices?

Do you trust the server not querying for "all" IDs?

I personally DON'T :) Maybe just one query / 14 days signed with a RKI key.

However: SAP / Telekom - please explain this in very very great detail in your documents.

[cfritzsche]

You don’t need a central server. Alice has seen Bob on May 1st. Bob has seen Charlie on May 3rd. Charlie has seen Dora on May 5th. Alice finds out she’s positive on May 6th. Bob is notified. Bob chooses to notify his contacts directly (without his test). Charlie gets the notification. And so on..

[MalteJ]

Secondary contact tracing is currently out of scope.
We are working on a proposal concept that allows the community to suggest new features or new/different architectural concepts.
Until we have set this up, you are free to discuss the topic here in this issue.

[Ryuno-Ki]

How does Bob get notified? There's no permanent connection between Alice's and Bob's device, is there?

[MalteJ]

@Ryuno-Ki

How does Bob get notified? There's no permanent connection between Alice's and Bob's device, is there?

Until we have published our architecture docs, please have a look at the DP3T and Apple docs to get an understanding of the general concept:
https://github.com/DP-3T/documents
https://www.apple.com/covid19/contacttracing/

[egandro]

... Bob chooses to notify his contacts directly (without his test).

How does Bob do that? Bob just collected a bunch of IDs when he went to S-Bahn/U-Bahn during the past 10 days in Munich, Berlin, Stuttgart.

A list of 5000 IDs.

How does Bob "know" who is ID 17 and ID 1414?

Please explain.

[cfritzsche]

... Bob chooses to notify his contacts directly (without his test).

How does Bob do that? Bob just collected a bunch of IDs when he went to S-Bahn/U-Bahn during the past 10 days in Munich, Berlin, Stuttgart.

A list of 5000 IDs.

How does Bob "know" who is ID 17 and ID 1414?

Please explain.

Bob doesn’t need to know who are the IDs. He just sends his own IDs from the days after he met the infected person. Charlie gets Bobs IDs and realizes he is a secondary contact.

[egandro]

... Bob chooses to notify his contacts directly (without his test).

Bob doesn’t need to know who are the IDs. He just sends his own IDs from the days after he met the infected person. Charlie gets Bobs IDs and realizes he is a secondary contact.

Please READ what I wrote about that :) if Bob sends the 17, 1414, ... to a centralized server. Then you have centralized data xDDD.

Which is an anti design goal.

[schauder]

I found the comic explaining the basic concepts rather helpful.
https://raw.githubusercontent.com/DP-3T/documents/master/public_engagement/cartoon/en/shortened_onepage.png

[ddroescher]

Please READ what I wrote about that :) if Bob sends the 17, 1414, ... to a centralized server. Then you have centralized data xDDD.

Yes, please read the comic.

That is why the system works with anonymous beacons. All the backend server knows are the beacons of potentially infected people (no metadata attached, randomly generated every few minutes). Only with the help of this server other users can then check their collected beacons for infections without ever sending their own.

[s-martin]

... Bob chooses to notify his contacts directly (without his test).

How does Bob do that? Bob just collected a bunch of IDs when he went to S-Bahn/U-Bahn during the past 10 days in Munich, Berlin, Stuttgart.

A list of 5000 IDs.

How does Bob "know" who is ID 17 and ID 1414?

Please explain.

Please have a look at https://github.com/DP-3T - the protocol is explained in detail there.

[bernd96]

... Bob chooses to notify his contacts directly (without his test).

How does Bob do that? Bob just collected a bunch of IDs when he went to S-Bahn/U-Bahn during the past 10 days in Munich, Berlin, Stuttgart.

A list of 5000 IDs.

How does Bob "know" who is ID 17 and ID 1414?

Please explain.

The TU München and the IT Consortium work with an very similar approach to D3PT, but added the possibility of 2nd-order tracing (see DCTS)

Main idea:
Lets have a chain Alice - Bob - Charlie. Alice is tested positiv with COVID-19. Bob get a message he met an infected person and get the possibility to "inform" his contacts -> he marks his ID as "contact-infected" and sends it to the server.
Charlie pulls bunches of IDs from the server. The app compares the "infected" and "contact-infected" IDs with the apps contact list - and finds a match: Charlie met Bob, who is marked as "contact-infected".

[egandro]

Charlie pulls bunches of IDs from the server.

WON'T happen :)

That implies centralized data - OR - at some point a server doing a "SELECT *" on the device

[ddroescher]

That implies centralized data - OR - at some point a server doing a "SELECT *" on the device

You do understand that the device itself is able to initiate the request and upload data to the backend server at the user’s behalf instead of the requirement to allow access from the backend server to the device? It is very much possible to do contact-infected-tracing with this concept.

A decentralized concept does not contradict the ability to share your anonymized data with other users with the help of a central backend. As long as the scope is narrow and always a user-based-decision.

And yes, there is a huge opportunity to abuse this technology if we do not look close enough. That is why we are here. This is a good start.

[egandro]

You do understand that the device itself is able to initiate the request and upload data to the backend server

Yes I understand this. So the server knows our IP, the timestamp and a list of all IDs our device knows. If this can be done for secondary contacts it can be done for the whole network :)

Which is a privacy violation :) 3rd party gains access to sensitive information that was a design goal to avoid such a senario.

[egandro]

You do understand that the device itself is able to initiate the request and upload data to the backend server at the user’s behalf instead of the requirement to allow access from the backend server to the device? It is very much possible to do contact-infected-tracing with this concept.

In your scenario also a trolling attack is very easy!

Let's assume a troll puts a cell phone in a big rail way station. It will collect IDs of "a lot of" people.
If an ID gets triggert (as we collected in hotspots - that is possible) - a troll will simply post all IDs to the server.

Lets make the scenario even worse. Lets use 100 phones and fake all of our own IDs to the same ID. So we gain even more IDs as fake tracked contacts that can be trolled as secondary contacts.

Happy new world.

Edit: Cloning an Android phone is as simple as copying 2 Files (Device ID, IMEI(s), BT Mac, WIFI Mac, ....)

Edit2: I personally think - even as mentioned somewhere here - a cheap Arduino ESP32 with Wifi and a BT adapter ($3-5) can be used as a bridge to contact a fake server trolling an App.

[ddroescher]

So the server knows our IP, the timestamp and a list of all IDs our device knows. If this can be done for secondary contacts it can be done for the whole network :)

The difference is that you choose to submit your data voluntarily, this is not done automatically – with all privacy connotations that this holds.

In your scenario also a trolling attack is very easy!

The DP-3T concept does not allow everyone to claim that they are infected. This has to be done with authorization by the specific Gesundheitsamt. Here are some proposals regarding this. Not sure what the plan is for this implementation.

[egandro]

The DP-3T concept does not allow everyone to claim that they are infected. This has to be done with authorization by the specific Gesundheitsamt.

I am still talking in the context of 2nd gen contracts. In this case "some" inquery from the server is required to the devices "Hey, wie learned that ID 2 might had a contact to an infected - give me your list of contacts ID 2" and - by trolling you receive a list with valid IDs that the fake Device with ID 2 met.

This is very very easy to implement and needs to be considered before this Bug corona-warn-app/cwa-documentation#16 can be fixed.

Spoofing devices can be done with ESP32+BT or Watches or BT speakers, etc. most of them use Linux or Arduinos.

[ddroescher]

I am still talking in the context of 2nd gen contracts.

Why would the upload be different for 2nd gen contacts? There can be a reasonable process to handle this in a similar fashion.

[bernd96]

You do understand that the device itself is able to initiate the request and upload data to the backend server

Yes I understand this. So the server knows our IP, the timestamp and a list of all IDs our device knows. If this can be done for secondary contacts it can be done for the whole network :)

Which is a privacy violation :) 3rd party gains access to sensitive information that was a design goal to avoid such a senario.

The server never knows the list of IDs our device knows. The only IDs listed on the server are infected ones, and - if implemented - the IDs of the contacts of the infected IF they decide to share them (after authorization). I think it is very good that you try to find weeknesses, but i think it may be recommended to read the concepts of D3PT (or DCTS for 2nd-order-tracing).

There are of course some design flaws and some pitfalls during implementation of the concepts, lets find them together :)

[Monikae]

I understand the notification of direct contacts works like this: The doctor / lab / health authority (Gesundheitsamt) gives the user a TAN, which can only be used once, like those for financial transactions, together with the positive test result. The user uses it to upload all her keys of the last 14 (21?) days to the server as confirmed positive. Other users regularly ask the server if any of the keys they have heard in the last 14 or so days have been stored as confirmed positive, the requests are only answered, not stored. The server never has contact lists. Push notifications are not possible.

To shorten the time to inform possibly infected people because one already becomes contagious oneself approximately on the day when one’s infector gets the first symptoms and runs to a testing facility (what Drosten mentioned), especially when labs become overwhelmed, I see three options, which can be combined, and I don’t think the third one will be enabled:

1) Have a different kind of TAN (or the same kind of TAN but a separate status “waiting for test result”) that is given to the user when the swab is being done. The user can choose to upload her keys to the server with this TAN, the other users requesting information will get the info “one of your contacts is waiting for the test results” instead of “one of your contacts is infected”. One could give the option or make it mandatory that the lab can change such “pending results” statuses to “infected” or “not infected” … if they are able to make this match, I have to reread to understand if there is a connection between the TAN and the keys.

2) If one gets the information “one of your contacts is infected” in the app one can be offered the option to “upload my keys with status ‘had confirmed contact’” without requiring a TAN. This would also not be open to abuse.

3) One could let users have the option to “upload my keys because I have started to cough and got a fever, but can’t get tested, yet”. This is of course open to abuse. Users should have the option not to be notified of such low-confidence information, when their app gets it from the server. Possibly also for the other two.

[cfritzsche]

Thanks for the suggestions @Monikae.

The main goal of this user story would be to shorten the time before notification to enable faster self-quarantine and help stop the spread. Another goal would be to take load off the testing facilities in an exponential pandemic phase by allowing pre-emptive self-quarantine before test results come back.
It would aid both goals if the second-degree exposure notification could also be used for third-degree exposure notification etc., effectively cutting off the entire cluster from further spread. I will not list third- and fourth and nth-degree separately in the remaining answer to enhance readability.

Still, the second-degree exposure notification should not be abusable- it should be prevented that users can be flooded with them since they would just ignore such notifications henceforth.
Also, reflecting the design choices (central vs. decentral) that were decided in setting up this project, we probably don't want a central party to know contact networks.

To shorten the time to inform possibly infected people because one already becomes contagious oneself approximately on the day when one’s infector gets the first symptoms and runs to a testing facility (what Drosten mentioned), especially when labs become overwhelmed, I see three options, which can be combined, and I don’t think the third one will be enabled:

1. Have a different kind of TAN (or the same kind of TAN but a separate status “waiting for test result”) that is given to the user when the swab is being done. The user can choose to upload her keys to the server with this TAN, the other users requesting information will get the info “one of your contacts is waiting for the test results” instead of “one of your contacts is infected”. One could give the option or make it mandatory that the lab can change such “pending results” statuses to “infected” or “not infected” … if they are able to make this match, I have to reread to understand if there is a connection between the TAN and the keys.
2. If one gets the information “one of your contacts is infected” in the app one can be offered the option to “upload my keys with status ‘had confirmed contact’” without requiring a TAN. This would also not be open to abuse.

While I think that a different kind of TAN or teleTAN for "waiting for test result" shortens the time till notification and could be one solution, I don't understand how the second step of converting the exposure keys from "waiting" to "positive" would go about without another TAN. Without a TAN, it would be easily abused. I don't think creating a TAN upon positive test is a big issue as the verification server does that already in the process as described today. I am just confused by your statement.

1. One could let users have the option to “upload my keys because I have started to cough and got a fever, but can’t get tested, yet”. This is of course open to abuse. Users should have the option not to be notified of such low-confidence information, when their app gets it from the server. Possibly also for the other two.

I fear this would be both very unspecific (lots of people have cough) and also skipping all those without symptoms. I have a similar idea though that couldn't be abused.

1. The health authority could, through portal and verification server, create a teleTAN of a new type which allows one user to upload her keys as second-degree exposure. The user could get this information and option as part of the info once she gets the first exposure notification and call the health authority (as she normally would anyway). Using the teleTAN she receives, she could upload her keys, preventing abuse.

Of course, lots of people could claim to have received an exposure notification and call the health authority. Still, the hurdle for an attacker speaking to an actual person is quite high. In Logbuch Netzpolitik 343, Thomas Lohninger reports that the austrian app merely has an information about abuse of the exposure notification being a crime, and that has stopped any abuse so far.

To make this process more seemless and have better protection against abuse, I see a fifth option building on 4. that would need to be enabled by Google and Apple.

1. Apart or within the rolling proximity identifier, the users phone sends a secret. This secret is recorded on other users phones when in close enough contact for long enough. When uploading the diagnosis keys after positive test, the user also uploads these secrets. But the secrets stay on the backend and are not published. Now our user getting the exposure notification can request a TAN for uploading second-degree exposure keys sending the secrets he recorded during the contact.

While this would be safer and require less interaction with the health authority, it could allow the backend to know who met whom. Diagnosis key uploads would no longer be independent, only authorized by a positive test, but would build a network connected through the contact secrets. Maybe there is a smart solution I have not thought of, but I guess this central knowledge would not be wanted by the project or accepted by the rightfully suspicious users. On the other hand, the health authority will probably learn all these contact graphs over time anyway, as it needs to manually trace contacts. If somebody in the team likes this idea, they could raise it to Google/Apple.

To summarize, I see these currently feasible options (numbers as above):

1. Waiting-for-test-TAN
2. Second-degree teleTAN through health authority

Of the two, 1 still requires a TAN from the doctor or lab where I leave the swab, introducing delays when infrastructure is overloaded, for every hop from first- to nth-degree contact. 4 only has the health authority hotline as bottleneck but is a little easier to abuse.

Because of these complexities (and the test and health infrastructure currently not being overloaded), I understand that this is not part of the viable scope. I would hope that it gets added in a future release though, as it would be a critical advantage in a new exponential phase.

[cfritzsche]

Christian Drosten mentioned this topic in his podcast today at time 46:50.

A new study from Gabriel Leung has found that effective control of the epidemic is most effective when contacts in a cluster are isolated before the diagnostics is finished.

The most important public health measures therefore are likely to be case identification followed by rapid and parallel (e.g. before contacts are confirmed as cases) contact tracing and quarantine.

Drosten said the science study quoted above already speculated about an option to skip the positive test as pre-condition of exposure notification in the app. And that this option will have to be selected for the app to help effectively control clusters.

I understand that there is now significant pressure to release an app in great quality and security in June and that this feature will not be in there. But I hope that it will be taken up soon afterwards.

Out of the options discussed in the comments above, the second-degree teleTAN through health authority probably fits this context, as it would hand information of this exposure to the health authority (if so chosen by the user) and have them decide if the user was in a typical cluster setting (gym, school, office, bar etc.) before or not.

PS: Great background read on the role of clusters in this pandemic, also recommended in the same podcast episode: Case clustering emerges as key pandemic puzzle.

[corneliusroemer]

@MalteJ wrote this more than a month ago, above:

Secondary contact tracing is currently out of scope.
We are working on a proposal concept that allows the community to suggest new features or new/different architectural concepts.
Until we have set this up, you are free to discuss the topic here in this issue.

I was wondering: Is there any progress on the proposal concept?

Now that the app is out there, it's maybe a good time to start thinking forward towards making it more useful.

[tkowark]

As we now have the cwa-wishlist repository, we'll move this issue there and let users further comment and vote on it using the thumbs up emojis.

[HeiDasGri]

The main issue is to speed up the warning process. A typical timing will be like this:

• 0h :Person X is infected but doesn't have symptoms yet. I am sitting next to this person in a train for several hours
• 24h: Person X get symptoms (RKI: "höchste Infektiosität am Tag vor dem Symptombeginn")
• 48h: Person X is going to be tested
• 54h: Person X get its test result and immediately upload all keys
• 54h - 76h: The keys are aggregated on the server on daily base
• 54h - 98h: my app is warning me on daily base
• 72h - 120h: I am becoming dangerous for other people (RKI: Interquartilsabstand: 3–5 Tage)

looking at this timing, the warning of the App does not always receive me in time to protected my family members. On the other hand, the warning is early enough for my family to be quarantined by health authority. Taking a look at the current process, there a several way to speed up everything. It is now time to optimise processes and algorithm.

Step1

The most Important feature, which do not change the user story at all, is mentioned here:
corona-warn-app/cwa-backlog#2

Step 2

The next thing I propose to introduce is to eliminate the delay caused by testing. Here I thing we need to make some general differentiation before:

• Case A: I get a positive test result (we already handle this case as infected)
• Case B: I have had a close contact to an infected person and will therefore make a test. I am potentially infected (not handled today by the App)
• Case C: I am paranoid or like to scare other people but I am not infected at all. I am doing all kind of tricks, to issue a fake warning. (This case is already handled today due to a missing test result)

The problem here is to handle case "B" without opening Pandora's box for case "C". Here an health authority or the existing hotline needs to make checks and then provide the same pin like I receive for a positive test. Doing so the processes are all the same. I upload my keys and other users might receive a warning, but much earlier as before.

Step 3

Within step 2 we have the disadvantage, that after a negative test I am not able to revoke the uploaded keys. Also a warning caused by an potential infected make no differences to a more seriouse warning due to positive test. Thus we need to differ in the whole process chain two kinds of keys. The keys issued from infected peoples and the keys issued from potential infected people.

When issuing the keys without a positive test result, the app provides me two different ways:

• I can confirm my corona case later on by a posive test result
• I can revoke all emitted keys due to a negative test result

On server side both kind of keys are provided. Keys of potential infected people might be deleted later on or be transferred to the keys of infected people later on.

On client side a new kind of yellow warning might occurs. "You have had contact to a person which fears to have been infected. Keep calm, avoid contacts, and wait a view days, the status will be updated after this person has received a test result"

[cfritzsche]

Thanks @HeiDasGri. I think for your scenario the yellow and green notification scheme implemented by the Austrian app would work. https://futurezone.at/apps/neue-stopp-corona-app-die-wichtigsten-fragen-und-antworten/400953755 Unfortunately I could not yet find details on how they do it, maybe using distinct values in the exposure risk score, as proposed by Google.

Apart from the "I have symptoms" semantic, the yellow warning could also be used for "I got a red warning but don't have a test result yet". Both help to speed up the process.

[daimpi]

Just as a heads up: the yellow color is currently proposed for notifying when contacts occurred, but risk status remains green: https://github.com/corona-warn-app/cwa-app-android/issues/899#issuecomment-663475550

[cfritzsche]

OK, that will be a challenge UX-wise to show the additional details about encounters below the threshold and on top explain that the encounter was with someone who doesn't have a positive test yet.

[HeiDasGri]

For me labelling both cases with yellow colour seams to be ok. It indicates that there currently is no high risk, but that something has happens which should be considered. I am sure someone with colour yellow will read careful, why this happens. I recommend, not to use to many colours. Mapping to traffic light colour is something, everybody can understand.

[bullipirat]

For secondary contacts, I would think this could be implemented even in the de-centralized setup. For example, if I receive a red high risk notification from the app, I could share and upload this (automatically or manually) as a sort of "possible positive test result", so that my close contacts get a warning.