If a first test is positive, there may be a second test to verify the result.
This second test may be negative then.
In this scenario, there should be a mechanism (maybe again TAN based) to withdraw a warning issued based on the first test result.
Does it have to be TAN based? What about the server communicates those as diagnoses keys, but withdrawn? But I guess the API does not support such, since the DTKs or Diagnoses keys of those with match may not be accessable
This could become confusing if a user happens to have been warned about multiple independent contacts within a short time interval: they could then be infected from one contact while another withdraws their warning.
Has anybody thought at all yet about user interaction and intended behvior in the case of multiple overlapping warnings?
Technically this would result in a lot of calculational overhead.
Withdrawal Token
With every exposure key the client would need to upload a withdrawal token. This withdrawal token is basically a hash of a random number, the withdrawal secret. An exposure key is valid as long as the withdrawal secret of the corresponding withdrawal token is not known publicly.
Google/Apple libraries
When the gapple libs detect an exposure the app gets no info which exposure key is connected to this exposure. Therefore you cannot check for a withdrawal of this specific exposure key. But you know the batch of keys, that has resulted in an exposure notification. So the client would need to watch for a withdrawal of a key of this batch and then recheck this batch for exposures.
Technically this is possible, but this would result in a lot of lines of code to be written and additional traffic between backend and clients.
If at all we should do this in a second step and not for the first release to not endanger our time to market.
But an important question is: How many tests are repeated at all? And what are the chances that the second test is negative? Afaik when a PCR test indicates an infection this is very reliable. There are very few false positives, but significantly more false negatives.
According to this article the rate of false positives is 0,2%. If every second person who has been tested positive repeats the test, we are talking about 0,1% mistakenly uploaded exposure keys.
So this feature would allow to withdraw max. 0,1% of the uploaded exposure keys.
The additional complexity in code as well as in UX is not justified by the amount of mistakenly uploaded exposure keys.
Most helpful comment
Technically this would result in a lot of calculational overhead.
Withdrawal Token
With every exposure key the client would need to upload a withdrawal token. This withdrawal token is basically a hash of a random number, the withdrawal secret. An exposure key is valid as long as the withdrawal secret of the corresponding withdrawal token is not known publicly.
Google/Apple libraries
When the gapple libs detect an exposure the app gets no info which exposure key is connected to this exposure. Therefore you cannot check for a withdrawal of this specific exposure key. But you know the batch of keys, that has resulted in an exposure notification. So the client would need to watch for a withdrawal of a key of this batch and then recheck this batch for exposures.
Technically this is possible, but this would result in a lot of lines of code to be written and additional traffic between backend and clients.
If at all we should do this in a second step and not for the first release to not endanger our time to market.
But an important question is: How many tests are repeated at all? And what are the chances that the second test is negative? Afaik when a PCR test indicates an infection this is very reliable. There are very few false positives, but significantly more false negatives.
According to this article the rate of false positives is 0,2%. If every second person who has been tested positive repeats the test, we are talking about 0,1% mistakenly uploaded exposure keys.
So this feature would allow to withdraw max. 0,1% of the uploaded exposure keys.
The additional complexity in code as well as in UX is not justified by the amount of mistakenly uploaded exposure keys.