cwa-documentation 🚀 - App is missing information about "Risikobegegnung" with green risk status

Very good to know that it is possible to see this. If this means there is a risk but below the threshold I would still like to know about this as I would in such a case avoid visiting a retirement home, etc, and maybe try to be a bit more careful anyway. But unlike a proper high risk alert, I would not isolate completely or take a test.

MikeJayDee on 26 Jun 2020

👍7

I think this actually documented in https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md:

In the end, a CWA user is notified of an increased risk whenever the risk exposure time calculated as described above amounts to 15 minutes or longer. This notification takes place in the CWA and, at the same time, provides recommendations as to how the user should proceed.

Exposures that result in a lower "risk exposure time" are displayed as well, but not with the red "Higher Risk" label.

mh- on 27 Jun 2020

Dear @hagct ,
Thanks a lot for your question. As @mh- already stated, this ist documented here: https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md:

This part answers your question:
"Several times per day, all active Corona-Warn-Apps download the diagnosis keys released on the Corona-Warn-App server and pass them on to the operating system in batches through an interface. The app checks whether any of these received, recorded rolling proximity identifiers match any of the diagnosis keys. If there is a match, this indicates that the user’s smartphone encountered the smartphone of a person who has uploaded a diagnosis key on the day to which the diagnosis key belongs.

In the next step, the app analyzes all the matching rolling proximity identifiers for each diagnosis key, to estimate how long the exposure lasted in total on the day in question and how close the smartphones were to each other on average during the exposure. The distance is calculated from the measured reduction in strength of the Bluetooth signal, which is specified in dB (decibel). All exposures for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (73 dB attenuation) apart on average (regardless of how long the exposure lasted) are discarded as harmless."

As the question has been answered, I will close this issue here.
EDIT: As you also asked to add this information to the app, I re-opened it. I will keep you posted on this.
Best regards

MS
Corona Warn-App Open Source Team

monikaschmitt on 27 Jun 2020

@hagct

I have the same case and I am very insecure about how I should act now. Despite the explanation of @monikaschmitt it is not yet clear for me.

mrcswb on 28 Jun 2020

Hi @mrcswb ,

we'll add an explanatory example to the risk assessment, soon, that should make this clearer. Until then:

The colleague of @hagct has been near a person that reported as infected
This exposure either lasted too short, was not close enough, or happened too many days back to be classified as being high risk

Hence, the green screen. We (in the CWA community management team) are all not doctors here, so we will not give medical advice. In general, you should follow the advice published by the RKI based on the risk state: https://www.rki.de/SharedDocs/Bilder/InfAZ/neuartiges_Coronavirus/WarnApp/Statusanzeige_niedriges.jpg?__blob=poster&v=2

tkowark on 28 Jun 2020

👍2 ❤1

The problem adressed is different to that shown at RKI and RKI is not very responsive to normal people's questions.
In your example there is 0 "Risiko-Begegnung", whereas there is a number of users, that now have 1 "Risiko-Begegnung", but still are "green". This is counterintuitive to most people. The description below should change to sth like yours above: "One person you have met has been tested positive and told that to the app, but you neither were close enough or long enough nearby to be in high risk of being infected by that person."

dideldei on 28 Jun 2020

👍10

@dideldei
Thanks a lot, that is what I meant. Your description sounds very good: "One person you have met has been tested positive and told that to the app, but you neither were close enough or long enough nearby to be in high risk of being infected by that person." This would make it much clearer.
This would be very helpful! BUT: I'm not sure who is responsible for changing the description, Github or RKI.

mrcswb on 28 Jun 2020

👍1

Text changes of course need to be aligned with the RKI but we will take that feedback with us.

tkowark on 28 Jun 2020

👍3

In the meantime, we also added an FAQ entry to (hopefully) better explain this matter. Please let us know when this description is still not clear enough (https://www.coronawarn.app/de/faq/#encounter_but_green).

tkowark on 30 Jun 2020

👍2

Hello Thomas,

thank you. Is it planned to give the users of the app more information
about the date, duration and distance of the contact? There is a certain
amount of uncertanty because the bluetooth signal is not really meant to
measure distance correctly. So en encounter could have been much closer
and longer, but wasnt recognized correctly because of technical reasons.

Best,

Hartmut

Hartmut Gieselmann
Leitender Redakteur / Managing Editor
c’t – Magazin für Computertechnik
Karl-Wiechert-Allee 10
D-30625 Hannover, Germany
phone +49 (0)511 5352 300
fax +49 (0)511 5352 417
Web: www.ct.de und www.heise.de

Heise Medien GmbH & Co. KG
Registergericht: Amtsgericht Hannover HRA 26709

Persönlich haftende Gesellschafterin:
Heise Medien Geschäftsführung GmbH
Registergericht: Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Dr. Alfons Schräder

Am 30.06.20 um 10:47 schrieb Thomas Kowark:
>

In the meantime, we also added an FAQ entry to (hopefully) better
explain this matter. Please let us know when this description is still
not clear enough (https://www.coronawarn.app/de/faq/#encounter_but_green).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/corona-warn-app/cwa-documentation/issues/344#issuecomment-651652174,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQANQLBVRDE75LFOTFPIPL3RZGRCLANCNFSM4OJG5I6Q.

hagct on 30 Jun 2020

👍6

Hello Thomas, thank you. Is it planned to give the users of the app more information about the date, duration and distance of the contact? There is a certain amount of uncertanty because the bluetooth signal is not really meant to measure distance correctly. So en encounter could have been much closer and longer, but wasnt recognized correctly because of technical reasons. Best, Hartmut
…

Interesting question :-)

mrcswb on 30 Jun 2020

In the meantime, we also added an FAQ entry to (hopefully) better explain this matter. Please let us know when this description is still not clear enough (https://www.coronawarn.app/de/faq/#encounter_but_green).

@hagct
For me, the question remains unanswered why a non-health relevant encounter 1) is called „Risikobegegnung“ and 2) is indicated at all.
The RKI probably has more to say about it, right?

mrcswb on 30 Jun 2020

In the meantime, we also added an FAQ entry to (hopefully) better explain this matter. Please let us know when this description is still not clear enough (https://www.coronawarn.app/de/faq/#encounter_but_green).

Thanks for adding this :-) Sounds a little too technical, but I get it

mrcswb on 30 Jun 2020

I opend a bug because of this misleading information here: https://github.com/corona-warn-app/cwa-app-ios/issues/813

The FAQ you mentioned above does not help at all, as the FAQ within the App points to a totally different website that is missing this information. So I could not find this information.

So for me, two things need to be done for this issue:

1) Change or add additional text that makes the status more clear in this situiation. Some goog examples have already been proposed here
2) Unify the FAQ you mentioned above with the one in the app. Why are there two different FAQs anyway?

benzman81 on 1 Jul 2020

I opend a bug because of this misleading information here: corona-warn-app/cwa-app-ios#813

Since we are already tracking this issue here centrally for both apps, please don't open separate issues in the app repositories. The dev teams cannot fix these by themselves since text changes have to be centrally coordinated with the RKI and UX.

Unify the FAQ you mentioned above with the one in the app. Why are there two different FAQs anyway?

This is already in progress and part of issue corona-warn-app/cwa-documentation#289

tkowark on 1 Jul 2020

👍2

@tkowark I opened the bug in iOS because I couldnt find information about this issue before. I found this bug afterwards. It is pretty confusing with all this projects heren ;-)

benzman81 on 1 Jul 2020

👍2

I just want to add, that the description of „Risiko-Begegnung“ at „Wichtige Begriffe“ is wrong in this case.

302ECD14-60AA-4138-9942-9A65FFD93851

benzman81 on 1 Jul 2020

👍7

I would like to know from what distance and duration on an encounter will appear in the App? For example if I pass by a person in the street who gets a positive test: will I get informed about this as an encounter with low Risk? Will I get informed about the encounters below 10 minutes and/or 8 meters in the app?

rosaminimax on 3 Jul 2020

First, it is quite unlikely that this will be registered in the first place. While beacons are sent 4 times per second, they are only received for 4 seconds every 5 minutes, So only if you happen to be near that person during those 4 seconds could a contact be registered in the first place.

Now my speculation as I haven't followed the protocol and its changes in every detail: I would assume that beacons with very a weak signal are not even stored in the first place. But if a certain signal strength is reached, the beacon would be stored. And in case that person reports herself positive, this would be reported as a risk encounter. In most cases, this would be judged to be not enough to raise the risk level to "increased" - only if certain criteria such as length of encounter, signal attenuation (after someone tests positive, you also know their transmission strength), transmission risk level (a measure of the probability of the person being infectious on the day of encounter) and the days since the encounter taken together suggest a certain probability of infection would the risk level be raised.

Personally, I'd be in favour that even when the alert level remains green, if there was any kind of risk encounter, that the details available to the app would also be made available to the user (day of encounter, length of encounter, signal attenuation (maybe expressed as a likely distance in metres) and transmission risk level) as well with a "more details" button. The app could then also explain on such a screen why that encounter was not considered risky enough to raise the alert level.

If I were to get such an alert, I would probably not go in full quarantine mode, but I would probably try to reduce contacts - especially to risk persons - at least somewhat. I would probably also try to get a test if I only had very light symptoms of a cold or a very light cough. This assumes that these risk encounters would still happen relatively rarely (which I think is highly likely).

MikeJayDee on 3 Jul 2020

👍7

@MikeJayDee Agreed on almost all points.
The only thing where I actually differ is wrt the discarding of low signal strength beacons right within the GAEN framework at recording time: there is already such a variation in signal strength between different Android devices that discarding any of them without taking into account the encrypted metadata (which is only possible after the the sender tested positive) seems unlikely (and this is before even talking about the seemingly fundamental different sending power between Apple and Android cf. corona-warn-app/cwa-documentation#341). See e.g. this graph from the the Singapore TraceTogether team or how Google calculates offsets and confidence levels for different phones.

Taken together with the fact that some Android devices seem to send with really low power, this makes me quite doubtful that a reasonable threshold for discarding beacons at recording time within GAEN - based solely on measured signal strength - could reliably be established. If it was it would probably have to be so low that it anyway keeps >99% of all beacons, and given the small scan window the benefits wrt saving storage would be miniscule. I also didn’t see anything to that effect described in the Google documentation mentioned above.

daimpi on 5 Jul 2020

👍2

Of course when signal-to-noise-ratio gets too low, the advertisement cannot be received anymore;
but on Android, every advertisement that is received during scanning, however low the RSSI, is also stored.
You should be able to see what is received (and the RSSI) with adb logcat|grep ExposureNotification.

mh- on 5 Jul 2020

👍1

The team is now actively working on improving these screens. Hence, we're moving this issue to the backlog repository.

tkowark on 17 Jul 2020

👀3 😕2

daimpi on 17 Jul 2020

👀1

@tkowark

The team is now actively working on improving these screens.

Any news?

akuckartz on 10 Aug 2020

I also received the info about 2 risk contacts (Risikobegegnung) and would highly appreciate information on when the supposed contact happened. If I know for instance that I have been in my car at the given point in time, but was stuck in a traffic jam, I can exclude the risk by using common sense. The information would drastically improve how people behave after having supposed risky contacts but the app still shows low risk level.

So I would really like to have this any time soon as a live feature as I couldn't find any way to access the apps data without rooting my phone or delete the app and the data in the process. (If I try to push a development version, Android warns me that any app data would be deleted in the process.)

prodigy1 on 12 Aug 2020

👍3 👀1

It makes a big difference to know on which day the low exposure event happened. I don’t understand why you are hiding this information from the user.

If it was a day where I was at the gym, then I might know that the phone was in a locker. So the actual risk of exposure might be a lot higher then suggested.

I’m mostly just mad that you’re hiding the information the OS is giving you. How could that have been an acceptable UX decision?

finnp on 15 Aug 2020

👍3

Hi,

I also do not understand it why not more information are provided, especially as the day of contact is according to my understanding provided in case of a high risk. I got such a green risk contact message last week while sitting next to a high risk person and I am worried now. I even regret that i installed the app at all because for the current situation I would at least not be worried. And as the status is green noone is doing a test.

Thanks

sunny3678 on 17 Aug 2020

👍3

One of my contacts now disappeared. That means the contact has been 15 days ago. So after two weeks I know the info the app is hiding from me. Data privacy is no argument here as I am able to find out the date anyway, just with a delay of up to two weeks. Please just display the date of the contact. As a first step I would be very happy with just the day, without the time.

Btw. I got myself tested and am negative. But that was mainly because I also showed symptoms. My doctor said he always has a few risk contacts. For doctors this info could be crucial so they don't infect their own staff..

prodigy1 on 17 Aug 2020

👍2

We’re also starting to see more and more reporting on this paper by Irish researchers (via @pdehaye) which indicates that CWA risk assessment is too conservative. This has been brought up before e.g. here and here.

One clever solution which has been suggested by @kbobrowski is the implementation of a “yellow” risks status for such cases:

Interesting, risk calculation in general feels a bit over-optimized and over-confident (e.g. registering contact but still displaying "low risk" with no notification if risk calculation did not cross the threshold). Perhaps it would work ok if we did not have such significant uncertainties in the system already (very short scanning windows + variability of BLE signal strength). What makes it further worse is that mathematics in "Epidemiological Motivation of the Transmission Risk Level" were probably based on a flawed research paper (related issue: corona-warn-app/cwa-documentation#384).

Maybe a solution which could be considered is to introduce third interim state "possibly increased risk" with yellow card and notification whenever at least 1 key has been matched

Implementing this - together with showing information which is already available to CWA in such cases - would help in two ways:

Users and doctors could make better informed decisions on the basis of more detailed information
Relevant contagious risk encounters which are currently being “missed” (shown as “green/low risk”) like the ones from situations in public transport settings which the Irish researchers documented, would have a much more reasonable “yellow” risk-status assigned to them.

Therefore this would help users and at the same time be a great response to the press coverage mentioned above 🙂.

Are there any major roadblocks which currently prevent this form being implemented and if so: is there anything we as a community could do in order to help?

daimpi on 17 Aug 2020

We’re also starting to see more and more reporting on this paper by Irish researchers (via @pdehaye) which indicates that CWA risk assessment is too conservative. This has been brought up before e.g. here and here.

Concerning the green risk status: has someone else had a look at the current CWA config which is distributed by the CWA servers?

I wrote a small protobuf parser some time ago. Daily dumps of the app config can be found here. The current dump is interesting regarding the attenuation parameters. Can someone make any sense of the given parameters?

minRiskScore: 11
riskScoreClasses {
  risk_classes {
    label: "LOW"
    max: 15
    url: "https://www.coronawarn.app"
  }
  risk_classes {
    label: "HIGH"
    min: 15
    max: 72
    url: "https://www.coronawarn.app"
  }
}
exposureConfig {
  transmission {
    appDefined_1: LOWEST
    appDefined_2: LOW
    appDefined_3: LOW_MEDIUM
    appDefined_4: MEDIUM
    appDefined_5: MEDIUM_HIGH
    appDefined_6: HIGH
    appDefined_7: VERY_HIGH
    appDefined_8: HIGHEST
  }
  transmissionWeight: 50.0
  duration {
    gt_10_le_15_min: LOWEST
    gt_15_le_20_min: LOWEST
    gt_20_le_25_min: LOWEST
    gt_25_le_30_min: LOWEST
    gt_30_min: LOWEST
  }
  durationWeight: 50.0
  daysSinceLastExposure {
    ge_14_days: MEDIUM_HIGH
    ge_12_lt_14_days: MEDIUM_HIGH
    ge_10_lt_12_days: MEDIUM_HIGH
    ge_8_lt_10_days: MEDIUM_HIGH
    ge_6_lt_8_days: MEDIUM_HIGH
    ge_4_lt_6_days: MEDIUM_HIGH
    ge_2_lt_4_days: MEDIUM_HIGH
    ge_0_lt_2_days: MEDIUM_HIGH
  }
  daysWeight: 20.0
  attenuation {
    gt_63_le_73_dbm: LOWEST
    gt_51_le_63_dbm: LOWEST
    gt_33_le_51_dbm: LOWEST
    gt_27_le_33_dbm: LOWEST
    gt_15_le_27_dbm: LOWEST
    gt_10_le_15_dbm: LOWEST
    le_10_dbm: LOWEST
  }
  attenuationWeight: 50.0
}
attenuationDuration {
  thresholds {
    lower: 55
    upper: 63
  }
  weights {
    low: 1.0
    mid: 0.5
  }
  riskScoreNormalizationDivisor: 25
}
appVersion {
  ios {
    latest {
      minor: 8
      patch: 2
    }
    min {
      minor: 5
    }
  }
  android {
    latest {
      major: 1
      patch: 4
    }
    min {
      major: 1
      patch: 4
    }
  }
}

micb25 on 18 Aug 2020

👀1

Hey, I just had a conversation with @micb25 on the topic of green risk-encounters.

My question to the devs (@tkowark @monikaschmitt):

Are the following two statements correct:

During the recording window ENF will record any RPIs as long as it receives them with a signal strength which allows this (i.e. isn't too noisy for recording). I.e. no RPIs are intentionally discarded by ENF when recording.
Any RPI stored inside ENF which matches one of the positive TEKs downloaded from the server will be presented to the user by CWA as some kind of risk-encounter, be it a "low-risk/green" or a "high-risk/red" one. I.e. no match of a stored RPI with a positive TEK will be hidden from the user.

daimpi on 18 Aug 2020

Thanks for the questions. We'll take them to the developers (Monika and I are part of the community team) and get you some definitive answers.

Regarding the second one, the minimum risk score, should lead to the exclusion of encounters below that value according to the risk-assessment document, but as said, we'll clarify again.

tkowark on 18 Aug 2020

Your question does not fully make sense, as what constitutes an at risk encounter involves not only the RPI but also the metadata.

My understanding:

This is unclear to me in situations where there is an attack going on, particularly one where the metadata is tampered with. Some experiments in Ireland have shown that - at some point in time - only the signal with maximal received strength was retained. We signaled this as potentially problematic to Google (opens the door to false negatives/positives) but don't know what they did with that. It is unlikely the German team would know the answer.
iOS makes its own decisions on what to show to users, see corona-warn-app/cwa-app-ios/issues/992, but then again the CoronaWarnApp FAQ says to ignore the iOS notifications.

pdehaye on 18 Aug 2020

@tkowark thanks I'm looking forward to their reply 🙂.
My understanding so far was, that those configured values (like min-risk-score) are only relevant for the encounters which have not yet been discarded:

For the remaining encounters that have not been discarded, a total risk score is calculated for each encounter set, by multiplying the transmission risk score described above by the days since last exposure value, which is derived from the day count since the most recent encounter to the current day.

All encounter sets whose total risk score exceeds a certain threshold (the minimum risk score) are considered to be risk exposures. The other encounter sets are discarded as negligible risk, like the sets that were previously discarded for being too short and/or too distant.

But that the "discarded" encounters would still be shown as "green/low risk" encounters:

All exposures for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (73 dB attenuation) apart on average (regardless of how long the exposure lasted) are discarded as harmless. This is why the Corona-Warn-App can display encounters, but the risk status stays the same.

https://www.coronawarn.app/en/faq/#encounter_but_green (emphasis mine)

@pdehaye thanks for the reply 🙂

I was now just thinking of a situation without any tampering. By "only the signal with maximal received strength was retained" do you mean that
1. for each specific RPI recorded, only the entry for this RPI with the strongest signal is retained, or
2. that when multiple different RPIs are broadcasted only the one RPI which has the strongest signal will be recorded?

The former would only reduce precision, the latter would be pretty catastrophic imho, b/c that would mean that in each ENF recording window only one RPI is recorded, right?

Ah yes those pesky iOS notifications… no one seems to know what's going on with them: https://github.com/corona-warn-app/cwa-app-ios/issues/1011. Imho Apple should just disable them as they seem to cause more confusion than they help… But what I meant was actually only what is presented to the user on the CWA home screen.

To rephrase my question more concisely but less precise: will any encounters be hidden from the user?

daimpi on 18 Aug 2020

For 1., I meant 1.i.

For 2., it can still evolve. Note that it has much more information content that what CoronaWarnApp is supposed to deliver (indeed, CWA will only deliver one, maybe two bits of info).

pdehaye on 18 Aug 2020

For point 1: ok yes that makes sense 😅. Although I'd hope that they have also fixed this by now ^^

For point 2: But shouldn't the risk assessment be done by the respective app and not directly by iOS/ENF? In the sense that iOS just delivers the matches with date, attenuation and duration values to CWA and CWA then decides what to do with them?
That's at least what I understand from the direction Google is moving in with their ENF 1.5: https://github.com/corona-warn-app/cwa-documentation/issues/373

daimpi on 18 Aug 2020

Regarding point 2: I don't think we have clear answers here, at the level of what should be done (before asking who should do it).

Certainly proximity tracing has so far been sold as a process done in the public interest, where people would be notified after the fact that they were at risk, by their health authority.

Another use case is to tell people ahead of time "this region/behavior represents this risk for you" or "you risk of being infected right now is X". This type of information sharing would be much more dicey, both from an epidemiological and data protection perspectives, but this is where we are slipping with the Apple notifications (because not everyone has the app, and there are assortativity effects in society: being 8m away from someone with the app who tested positive correlates with being 2m away from someone without the app who tested positive).

This slippage was previsible, and for me has very high potential and is the real use case of those apps/data fed into the EN framework. It should also be. My vision might be accentuated by the deep failures in Switzerland in that regard.

pdehaye on 18 Aug 2020

@micb25

The current dump is interesting regarding the attenuation parameters. Can someone make any sense of the given parameters?
attenuation {
gt_63_le_73_dbm: LOWEST
gt_51_le_63_dbm: LOWEST
gt_33_le_51_dbm: LOWEST
gt_27_le_33_dbm: LOWEST
gt_15_le_27_dbm: LOWEST
gt_10_le_15_dbm: LOWEST
le_10_dbm: LOWEST

This is consistent with https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/exposure-config.yaml and the explanation here. The "0" values are missing, which is ok, as 0 is the default value in Protocol Buffers.

attenuation:
  gt_73_dbm: 0

The data is read inside the app based on this protobuf file.

mh- on 18 Aug 2020

Are the following two statements correct:

During the recording window ENF will record any RPIs as long as it receives them with a signal strength which allows this (i.e. isn't too noisy for recording). I.e. no RPIs are intentionally discarded by ENF when recording.

Any RPI stored inside ENF which matches one of the positive TEKs downloaded from the server will be presented to the user by CWA as some kind of risk-encounter, be it a "low-risk/green" or a "high-risk/red" one. I.e. no match of a stored RPI with a positive TEK will be hidden from the user.

At the moment, I would say that statement 1 is correct at least for Google, based on my observations (but of course Google is updating that all the time, it may change).

mh- on 18 Aug 2020

👍1

Hello,

I have two Iphones (Iphone SE 2016 / Iphone 8) carrying both permanantly with me.
Both now show 1 / 3 contacts (see attached files) with low risk:

If I interpret the data correctly I had 5 contacts with (most likely) 3 persons (of the data sets with 3940, 3020, 3970 ID counts), one of them 4th August (15 days ago). All contacts were either less then 10 minutes or further than 8 meters away, or the contact was 6 days before the person uploaded its test result (in order to have a lower risk factor than 15). Until they are more than 14 days ago, I can not figure out the dates of the incidents. Since around 1500 people have uploaded their results and I spent most of the time at home the last 14 days, I find the high number of contacts very unlikely. Could this be a bug? Furthermore why don't you simply show the date of contact, since I will find it out anyway after 14 days?

My assumption ist that most signals were either received from outside my flat where people walk by or the results are incorrrect since the probability of having had contact to 3 out of 1500 people in Germany is highly unlikely.

BR.

Iphone_SE_2016_ExposureChecks-2020-08-20.json.txt
Iphone_8_ExposureChecks-2020-08-20.json.txt

Coronawahn on 20 Aug 2020

👍1

Hi,

how do you find out when the contact has been?

Thanks

sunny3678 on 20 Aug 2020

Hi,

how do you find out when the contact has been?

Thanks

When it's more than 14 days ago the Matchcount drops by 1.

Coronawahn on 20 Aug 2020

@Coronawahn I think that "MatchCount" does not indicate that you were in contact with 3 separate people, it may mean 3 distinct Diagnosis Keys, or maybe 3 distinct Rolling Proximity Identifiers. DKs roll every 1 day, and RPIs roll every 10 minutes, it may all come from one person.

I'd assume that likelihood of registering the contact of a person passing by is very small, since scanning happens only every 5 minutes for a few seconds, it was rather someone who was in your proximity for longer time (note that it may happen that contact was registered through the wall).

kbobrowski on 20 Aug 2020

👍1

@Coronawahn I think that "MatchCount" does not indicate that you were in contact with 3 separate people, it may mean 3 distinct Diagnosis Keys, or maybe 3 distinct Rolling Proximity Identifiers. DKs roll every 1 day, and RPIs roll every 10 minutes, it may all come from one person.

I'd assume that likelihood of registering the contact of a person passing by is very small, since scanning happens only every 5 minutes for a few seconds, it was rather someone who was in your proximity for longer time (note that it may happen that contact was registered through the wall).

Thanks, does ist also show new contacts after the person uploaded its test result and presumably went into quarantine? As I understood the person uploads the identifiers (contacts) of the last 14 days - so if no new upload happens, further contacts will not be identified?

Coronawahn on 20 Aug 2020

I agree with @kbobrowski 's comments - leaving aside for a moment what MatchCount counts - but @Coronawahn seemed to deduce there were three contacts from the fact that MatchCount>0 for three separate bundles (ids: 3940, 3020, 3970).

Note that one person's DK can end up in two bundles, because of the last day effect (last day's key is held up before being published). So the true lower bound is _two_ users, to me.

As for what MatchCount counts, I don't know, but the two parallel datasets you are providing are very helpful to better understand it, as they provide data that can be compared.

pdehaye on 20 Aug 2020

Note that one person's DK can end up in two bundles, because of the last day effect (last day's key is held up before being published). So the true lower bound is _two_ users, to me.

Are you sure about this? My understanding is that CWA doesn't do this. The TEK from today will simply not be uploaded, but rather only those up to 13 TEKs from the days before. This "last day upload" seems like something the devs would like to implement at some point, but I don't think this is live currently: https://github.com/corona-warn-app/cwa-app-android/issues/678#issuecomment-650760871

daimpi on 20 Aug 2020

👍2

I was not sure. The Swiss implement it, but I was not sure the Germans do. Now I am, thanks for correcting me!

pdehaye on 20 Aug 2020

Thanks, so what can I deduce from the data set?

Coronawahn on 20 Aug 2020

Well, sorting out your data slightly differently:

"RandomIDCount" : 3940, | "MatchCount" : 1 | "Timestamp" : "2020-08-14 18:15:43 +0200" Iphone SE (2016)
"RandomIDCount" : 3940, | "MatchCount" : 3 | "Timestamp" : "2020-08-15 02:09:25 +0200" Iphone 8
"RandomIDCount" : 3940, | "MatchCount" : 1 | "Timestamp" : "2020-08-15 19:03:52 +0200" Iphone SE (2016)
"RandomIDCount" : 3940, | "MatchCount" : 3 | "Timestamp" : "2020-08-16 02:38:09 +0200" Iphone 8
"RandomIDCount" : 3940, | "MatchCount" : 1 | "Timestamp" : "2020-08-16 20:56:06 +0200" Iphone SE (2016)
"RandomIDCount" : 3940, | "MatchCount" : 3 | "Timestamp" : "2020-08-17 03:16:29 +0200" Iphone 8
"RandomIDCount" : 3940, | "MatchCount" : 1 | "Timestamp" : "2020-08-17 21:28:17 +0200" Iphone SE (2016)
"RandomIDCount" : 3940, | "MatchCount" : 3 | "Timestamp" : "2020-08-18 03:54:25 +0200" Iphone 8
"RandomIDCount" : 3940, | "MatchCount" : 0 | "Timestamp" : "2020-08-18 22:04:27 +0200" Iphone SE (2016)
"RandomIDCount" : 3940, | "MatchCount" : 2 | "Timestamp" : "2020-08-19 04:19:10 +0200" Iphone 8
"RandomIDCount" : 3940, | "MatchCount" : 0 | "Timestamp" : "2020-08-19 22:06:35 +0200" Iphone SE (2016)
"RandomIDCount" : 3940, | "MatchCount" : 2 | "Timestamp" : "2020-08-20 04:59:27 +0200" Iphone 8

"RandomIDCount" : 3020, | "MatchCount" : 1 | "Timestamp" : "2020-08-15 19:03:52 +0200" Iphone SE (2016)
"RandomIDCount" : 3020, | "MatchCount" : 1 | "Timestamp" : "2020-08-16 20:56:06 +0200" Iphone SE (2016)
"RandomIDCount" : 3020, | "MatchCount" : 1 | "Timestamp" : "2020-08-17 21:28:17 +0200" Iphone SE (2016)
"RandomIDCount" : 3020, | "MatchCount" : 1 | "Timestamp" : "2020-08-18 22:04:27 +0200" Iphone SE (2016)
"RandomIDCount" : 3020, | "MatchCount" : 1 | "Timestamp" : "2020-08-19 22:06:35 +0200" Iphone SE (2016)

"RandomIDCount" : 3970, | "MatchCount" : 1 | "Timestamp" : "2020-08-20 04:59:27 +0200" Iphone 8

It seems unlikely that the MatchCount would reflect RPIs: you would have, three times, to have caught just one (and not more), except that your iPhone 8 happened to catch 3 of them that happened to be uploaded in the same bundle.

More likely, MatchCount reflects Diagnosis Keys. If that's the case, and assuming the 3 DKs in the same bundle are from the same person, then you had this encounter at a time that can be very precisely determined (if the 14 days are calculated precisely, because the drop of one DK happened on both phones in close succession), but you also had two further encounters with this same person at least two days later (because the keys are surviving).

However, the main lesson here is how extremely noisy this data is, at least when looking at weak Bluetooth signals: sometimes your SE catches something, sometimes it's your iPhone 8.

pdehaye on 20 Aug 2020

👍2

On the topic whether CWA hides encounters from the user:
ZDF writes:

Doch es gibt noch ein weiteres Problem: Apple-Nutzer klagen, dass sie von ihrem Betriebssystem eine Push-Mitteilung erhalten, ein "wöchentliches Update". In dieser Mitteilung steht oft eine andere, höhere Zahl von Risikobegnung an als in der Corona-Warn-App. Das RKI sagt, in dieser Push-Mitteilung werden auch solche Begegnungen gezählt, "bei denen der Abstand mehr als acht Meter betrug oder die nur wenige Minuten dauerten."

Das heißt: Corona-Warn-App und die Push-Mitteilung des Betriebssystems definieren Risikobegegnungen unterschiedlich. Die Corona-Warn-App zeigt Begegnungen mit acht Metern Abstand gar nicht erst an. Und Begegnungen mit drei Metern Abstand werden zwar angezeigt, verändern aber nicht das Risiko von "niedrig" auf "erhöht". Die Push-Nachricht hingegen zeigt alle Begegnungen an. Auch solche, bei denen der Abstand mehr als acht Meter betragen hat. Wer soll das verstehen?

~I don't think what RKI told them is correct~ I think they misinterpreted what the RKI told them and as a consequence they are actually conflating two issues, namely the iOS notifications - which are confusing but might just be the number of days CWA showed a (green) risk encounter added up (https://github.com/corona-warn-app/cwa-app-ios/issues/1011) - and the way CWA itself determines what counts as a "(green) risk-encounter".
I could o/c be wrong here, so I'm curious to see what the devs will have to say on this topic 🙂.

daimpi on 20 Aug 2020

👀1

Today I also had the push notifications for both phones:
Iphone SE: Dein Gerät hat diese Woche 10 mögliche Begegnungen identifiziert und diese Info mit Corona-Warn geteilt.
Iphone 8: 3 Begegnungen

Since the contacts could have been i.e. me kissing a positive person for less than 10 minutes or a person living in another flat separated by a wall with more than 8 meters distance (which is more likely), the information could mean anything or nothing.

So the app is more or less just uselessly confusing unless it reveals the exact date and time, or at least length and estimated distance of the contact in order to be able to properly evaluate the personal risk.

I think about uninstalling the app since it already screwed up my weekend.

Coronawahn on 21 Aug 2020

This issue was the reason I developed the Warn-App-Companion Android app: https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion
The required detailed information is only accessible to an app that gets root permissions, and not through the official API, so it's not possible for Corona-Warn-App.

But if you have a rooted Android device, you can use the Warn-App-Companion to get details about the "risk encounters":

(Without root permissions, there's also experimental support for the RaMBLE app which collects BLE data and can export it as a database, but I'm not sure how reliably it does the collecting in the background, and what effect that has on the phone's battery.)

BTW, the Warn-App-Companion app is open source and you can also contribute: https://github.com/mh-/corona-warn-companion-android

mh- on 21 Aug 2020

❤1

@mh-

(Without root permissions, there's also experimental support for the RaMBLE app which collects BLE data and can export it as a database, but I'm not sure how reliably it does the collecting in the background, and what effect that has on the phone's battery.)

It seems that RaMBLE is collecting BLE data as long as notification is alive, but on my device it's getting killed after some time. Not sure if this is RaMBLE implementation or if the OS is killing it. Would probably require root again to make it reliable (perhaps as a system app)

kbobrowski on 21 Aug 2020

Regarding the issue of CWA hiding encounters: It seems the RKI actually explained to the ARD journalist, that yes: encounters that are estimated to be further than 8m away would not be shown in any way in CWA not even as "green/low risk" encounters: https://twitter.com/HerrLauck/status/1296762177148391425

This o/c would contradict my point 2 from above

Any RPI stored inside ENF which matches one of the positive TEKs downloaded from the server will be presented to the user by CWA as some kind of risk-encounter, be it a "low-risk/green" or a "high-risk/red" one. I.e. no match of a stored RPI with a positive TEK will be hidden from the user.

@tkowark any update from the devs on this?

daimpi on 21 Aug 2020

👍1

ENF is discarding stored exposures internally based on the configuration of the ENF. Every exposure the CWA received from the ENF will shown in the app as low risk or high risk exposure.

thomasaugsten on 21 Aug 2020

@thomasaugsten thanks for the reply 🙂

What is ENF currently discarding? Only RPIs that are older than 14 days, or something else as well?

daimpi on 21 Aug 2020

ENF is removing RPIs older than 14days from the device.
ENF is filtering matched RPIs based on the configuration provided by the CWA.
The CWA receives the filtered result set and shows alle matches in the app.

thomasaugsten on 21 Aug 2020

👍1

@thomasaugsten thanks again :)

Just to clarify: is this the ENF config file: https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/exposure-config.yaml ?

Does this mean, that any encounter less than 10 minutes (gt_5_le_10_min: 0) would be discarded by ENF and the same for attenuation >73 db (gt_73_dbm: 0) and hence such encounters would not even be shown as "green-/low risk" encounters by CWA but entirely hidden from the user?

Does this mean such encounters don't even show up as a match in the "exposure Log" in the ENF settings?

daimpi on 21 Aug 2020

👍1

All encounters for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (>73 dB attenuation) apart on average (regardless of how long the encounter lasted) are discarded as negligible risk.

https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md

Not sure though whether these are then shown as low-risk encounters..

Coronawahn on 21 Aug 2020

@daimpi We assuming this based one the information provided by Apple/Google. We are not able to make a statement here because we are not own the code or the ENF.
But you can try to verify this in the open source code of the ENF

thomasaugsten on 21 Aug 2020

@thomasaugsten thanks. Let me try to summarize. Regarding my point above:

Does this mean, that any encounter less than 10 minutes (gt_5_le_10_min: 0) would be discarded by ENF and the same for attenuation >73 db (gt_73_dbm: 0) and hence such encounters would not even be shown as "green-/low risk" encounters by CWA but entirely hidden from the user?

Does this mean such encounters don't even show up as a match in the "exposure Log" in the ENF settings?

The answer - according to your current best understanding on how ENF works - would be:
Yes, such encounters will not be shown by CWA or the ENF log in any form.

And consequently the answer to my original question

Any RPI stored inside ENF which matches one of the positive TEKs downloaded from the server will be presented to the user by CWA as some kind of risk-encounter, be it a "low-risk/green" or a "high-risk/red" one. I.e. no match of a stored RPI with a positive TEK will be hidden from the user.

would be:
No: some encounters stored in ENF will be filtered out based on the CWA config file and therefore not be shown to the user.

Is this all correct?

Again: thanks for taking the time to explain all of this ❤️

Btw: would you have a pointer on where to start looking in the ENF source code for this 😅

daimpi on 21 Aug 2020

👍1

@daimpi This is our current understanding yes
iOS not official github
https://github.com/rettichschnidi/ExposureNotification
https://github.com/rettichschnidi/ExposureNotification/blob/master/README.md#advertisement-matching-and-scoring
https://github.com/rettichschnidi/ExposureNotification/blob/2dc4eb3d183142112bd60b7dea44f28becce4baf/Advertisement%20Matching%20and%20Scoring/ENAdvertisementDatabaseQuerySession.h#L34

Google:
https://github.com/google/exposure-notifications-internals
https://github.com/google/exposure-notifications-internals/blob/a0394e69c51aa118f5000b8a2c2f15f1f9aedb7d/exposurenotification/src/main/proto/exposure_result.proto#L35

thomasaugsten on 21 Aug 2020

❤3

@daimpi it might help to think of the fact that it is possible to have multiple apps, all configured differently, matching the data in the database. so for instance @Coronawahn could - on both of their devices - install multiple apps (Swiss, Italian, etc), each with their own criteria and configuration, and deduce further information about the characteristics of the encounters.

pdehaye on 21 Aug 2020

@thomasaugsten what can you say about what is stored on-device, independently of the CWA itself? what thresholds would this use?

pdehaye on 21 Aug 2020

@thomasaugsten what can you say about what is stored on-device, independently of the CWA itself? what thresholds would this use?

I think this has already been answered by @mh- above: all RPIs which are not more than 14 days old are stored in ENF, no thresholds are applied:

Are the following two statements correct:

During the recording window ENF will record any RPIs as long as it receives them with a signal strength which allows this (i.e. isn't too noisy for recording). I.e. no RPIs are intentionally discarded by ENF when recording.

Any RPI stored inside ENF which matches one of the positive TEKs downloaded from the server will be presented to the user by CWA as some kind of risk-encounter, be it a "low-risk/green" or a "high-risk/red" one. I.e. no match of a stored RPI with a positive TEK will be hidden from the user.

At the moment, I would say that statement 1 is correct at least for Google, based on my observations (but of course Google is updating that all the time, it may change).

daimpi on 21 Aug 2020

👍2 ❤1

Looks like the filtering for minimumRiskScore in Apple ENF happens here: https://github.com/rettichschnidi/ExposureNotification/blob/master/Advertisement%20Matching%20and%20Scoring/ENExposureDetectionDaemonSession.m in generateSummary and exposureInfo.

mh- on 21 Aug 2020

👍1

Having exchanged some mails with the CoronaApp-App-hotline for trying to understand what is described as the original problem here I was finally referred to this place here. Now I´m a bit astonished that this problem is known and open for more than 6 weeks meanwhile as it causes quite likely a lot of hotline calls.

The discussion seems to have deviated from the original question. A cause seems that the "what is missing" is a bit misleasing. It is obviously not the detailed risk calculation missing, but an explanation for the average user why his overall risk is low although there were one or more "Risikobegegnungen". Lack of explanation causes them to call the hotline. It was already stated earlier that the App links to a different FAQ that is not explaining the "risk". Why can´t the App itself provide some useful information, when clicking on the link next to the indicated risk? It makes no sense to show exactly the same information again + "wash your hands", which happens now when clicing on that link.

Furthermore, it was reported already July 1st that there is is wrong information in the App. The description/definition of a "Risikobegegnung" is wrong. It is described as a higher risk. But I get the information: "low (overall) risk, 3 Risikobegegnugen of low risk". With this defintion in the App there can´t be any "Risikobegegnungen of low risk". This contradiction caused me to keep the hotline busy, which explained that such contacts of low risk are not as described in the App.

After this I guess that a "Risikogegnung" is any recorded contact with a positive tested Person. So it would be quite helpful to correct the description in the App accordingly. E.g. "Eine Risiskobegegnung ist eine Begegnung mit einer positiv getesteten Person. Ein erhöhtes Risiko besteht, wenn diese Begegnung über einen längeren Zeitraum und mit geringer Distanz bestand. Andernfalls wird die Begegnung als Risikobegegnung mit niedrigem Risiko betrachtet."

As it is not neccessarly obvious why low risk contacts are recorded at all it might be added: "Risikobegnungen mit niedrigem Risiko werden erfasst, da z.B. viele solcher Begegnungen in der Summe ein erhöhtes Risiko ergeben können." Or any other suitable explanation.

Thank you

mf179 on 22 Aug 2020

👍1

Could we get an update from the developers regarding this?
What is the priority of this issue?
I think, how @mf179 writes, some more details inside the App when you have low risk encounters should definitely be included.
Thanks!

Ein-Tim on 22 Aug 2020

We are working on improving the texts but we have to consider a lot of opinions. But there will be text updates in the 1.4 release.
We show low risk exposure to prevent irritation about missing exposure we receive from the ENF. If the number from the ENF and CWA doesn't match you can easily think the CWA is ignoring exposures or is not working correctly.

thomasaugsten on 22 Aug 2020

👍1

I think it is fine to show low risk exposures as it will show much more people that the App works somehow as low risk exposures are probably much more likely to encounter. It might even cause more people to install the App becoming curious to see also some such special indications by the App.
Just that it requires commonly well understandable explantion why there is low risk by low risk exposures and that the explanation can easily be found by any user.
It became obviously already of public interest as there are news arcticles trying to explain what "low risk with low risk exposures" means.

mf179 on 22 Aug 2020

👍3

@daimpi

some encounters stored in ENF will be filtered out based on the CWA config file and therefore not be shown to the user.

~~this seems to be correct,~~ I derived some RPIs based on published Diagnosis Keys and was feeding it to ENF, when the signal was strong (attenuation below cut-off threshold defined in CWA config) then there was 1 contact event in both CWA and ENF log (corresponding to couple of RPIs that matched Diagnosis Key). ~~When RPIs had weak signal strength (above the threshold), no match was displayed in both ENF log and CWA.~~ The same happened also with weak signal (CWA displayed 1 exposure with low risk in this case). Had to correct my experiment since I did not account for certain sanity check inside EN when manufacturing RPIs.

@thomasaugsten perhaps a good idea would be to assign very small but positive weight also to events corresponding to weak signal / short exposure, such that the match would be registered by ENF and the user would be informed about all "low-risk" contact events, at the same time keeping threshold for "high-risk" event practically unchanged. Discarding contact event just based on short registered duration or low signal strength could be too optimistic, given uncertainties in measuring distance with BLE signals. use ExposureInformation to obtain more details about registered exposure and display at least a date to the user. Or bring this functionality to CWA once migrated to v1.5 API, it would be perhaps easier this way.

User can use https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion to display detailed information about encounters:

Corona-Warn-App | Warn-App-Companion
:------:|:------------------------------:|
Screenshot_20200821-175120 | Screenshot_20200821-175842

kbobrowski on 22 Aug 2020

❤3 👍3

@kbobrowski Thanks for your detailed testing ❤️

I agree with you and others here and think it would be better if no encounters were hidden from the user given e.g. the noisiness in BLE distance measurement and aerosolized spread of the virus.

Regarding your suggestion of adding a small but positive weight to those parameters: I'm not sure whether this would help alleviate the current (pre ENF 1.5) situation: if I understand minimumRiskScore correctly the reason that those encounters are hidden is not per se because those parameters have 0 weight assigned - as even matches with risk score 0 would be reported with the default minimumRiskScore (= no minimum) - but the cutoff happens when they fail to qualify for the custom min-risk-score: 11 required by CWA, which they might still fail if the weight assigned is too small.

daimpi on 22 Aug 2020

👍1

We will of course reevaluate the current configuration with the adoption of ENF 1.5 and also take your feedback into account. But please be patient with us because there are a lot of other features and improvements in our backlog.

thomasaugsten on 22 Aug 2020

👍3 🚀2

Did some more tests to see what additional information could be extracted with getExposureInformation() method (which is currently not used by CWA). Was running the same experiment as in https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678644207 but with a fork of CWA where I implemented querying of ExposureInformation.

Corona-Warn-App | Notification triggered by querying ExposureInformation | Warn-App-Companion
:------:|:------------------------------:|:-------------------------|
Screenshot_20200822-222604 | Screenshot_20200822-222529 | Screenshot_20200822-222722

Full information from EN (note that CWA currently only queries ExposureSummary):

ExposureInformation:
  - date: Wed Aug 19 02:00:00 GMT+02:00 2020
  - dateMillisSinceEpoch: 1597795200000
  - durationMinutes: 30
  - attenuationValue: 41
  - transmissionRiskLevel: 6
  - totalRiskScore: 30
  - attenuationDurations: [37, 0, 0]

ExposureSummary:
  - daysSinceLastExposure: 3
  - matchedKeyCount: 1
  - maximumRiskScore: 30
  - attenuationDurations: [30, 0, 0]
  - summationRiskScore: 30

So it would be possible to additionally inform users about exact date (no exact time), duration, distance, and at what transmission risk level interaction with infected person was taking place.

Interestingly it seems that notification is triggered by the call to getExposureInformation(), in the previous experiment I did not receive any notification about exposure. This corresponds to the documentation of EN.

kbobrowski on 22 Aug 2020

👍5

@daimpi

Regarding your suggestion of adding a small but positive weight to those parameters: I'm not sure whether this would help alleviate the current (pre ENF 1.5) situation: if I understand minimumRiskScore correctly the reason that those encounters are hidden is not per se because those parameters have 0 weight assigned - as even matches with risk score 0 would be reported with the default minimumRiskScore (= no minimum) - but the cutoff happens when they fail to qualify for the custom min-risk-score: 11 required by CWA, which they might still fail if the weight assigned is too small.

I think the implementation could also go in the direction of detecting almost even every single exposure by setting very low min risk and other parameters, and then just filter "relevant" exposures to display by filtering the list of ExposureInformation, this is even suggested in the API documentation, although would require major overhaul of current CWA implementation:

ExposureInformation

You can use this information to gauge a level of risk of the exposure to filter out low-risk interactions, such as sub-five-minute interactions with a low signal strength attenuation that occurred 13 days earlier.

kbobrowski on 22 Aug 2020

👍3

From your discussion above it is not fully clear to me whether you consider also the initial problem of this thread and the case I desribed. Let me add some pictures to clarify it. The App seems to show low risk exposures to the users already for long. And I would even have had simply accepted this as overall low risk. Until I read the "definition" of a risk exposure in the App. So to me it is not a problem of showing low risk exposures to the users. It is a problem that it is not explained to the user how it comes to an overall low risk although there are risk exposures and what it means to the user. And more tricky is the current definition of low risk exposure, which contradicts the statement of an overall low risk with "low risk exposures" as the definition says every risk exposure is of high risk. This leaves the user with the question: what kind of exposure did I had? And is this really low overall risk? So the low overall risk with exposures is perhaps more a documentation problem? In addition to clarifying this overall risk case and the definition it would be nice, if you show also for the low risk exposures the day to the user as it might help for avoiding risks in future.

low risk_20200819_161456_de rki coronawarnapp
definition_20200819_161819_de rki coronawarnapp

mf179 on 23 Aug 2020

👍3

Another thought. I understand that it is for the developers more important to avoid a suspicion of hiding information. This is however easily solved by documenting it openly. You may document, for example, "CWA uses platform services for detecting exposures. CWA records only those platform detected exposures that later may become relevant for the overall risk assessment."

Done. Nobody can suspect hiding of info. And it is more in conformance with DGSVO as only necessary information is collected.
So I don´t think that every exposure detected by the platform should also be recorded by the CWA and shown to the user.

The vast majority of the users measures the quality of the CWA by what it is exposing to the users, which also reflects back on the overall acceptance of the CWA. IMHO, the user interface / documentation is poor and should be worked on with higher priority.

mf179 on 23 Aug 2020

👍2

@mf179
I agree with your criticism wrt the “definition” of a risk encounter. This should be adjusted 🙂.

Regarding the other points:

"CWA uses platform services for detecting exposures. CWA records only those platform detected exposures that later may become relevant for the overall risk assessment."

Done. Nobody can suspect hiding of info. And it is more in conformance with DGSVO as only necessary information is collected.
So I don´t think that every exposure detected by the platform should also be recorded by the CWA and shown to the user.

That's not really possible. With "platform services" I guess you mean the Exposure Notification Framework (ENF)? CWA anyway doesn’t record anything, that’s all done by ENF. The ENF has to record all the information and cannot discard anything prematurely, b/c it cannot determine attenuation w/o decrypting the metadata and even exposure duration is difficult due to switching RPIs. All this can only be reliably determined once the RPIs and metadata are decrypted, which can only happen once the person with the corresponding TEK shares their keys after being tested positive (cf. my comment above). In order not to miss dangerous encounters all this information has to be stored inside ENF until it can be decrypted or until it’s no longer relevant for the determination of an infection risk (i.e. after 14 days).

So I don´t think that every exposure detected by the platform should also be recorded by the CWA and shown to the user.

I disagree. As stated above: recording of all encounters by ENF is mandatory / non-optional for technical reasons. When it comes to information presented to the user: my preference would be the "yellow" risk status suggested by @kbobrowski (see my other comment above).
There could actually be 3 states: green/yellow/red. Given the (at least for me) new info that CWA currently hides encounters from the user (Update: turns out, encounters are not hidden from the user after all), I'm not sure whether all encounters should at least get a yellow status assigned, or some - like the ones which are currently hidden - should be presented as "green-/low-risk" encounters.
In any case I wish there was a way for users to get as much information as possible when it comes to any encounter: something like @mh-'s corona-warn-companion-android would be ideal imo, o/c limited to the information that ENF actually exposes i.e. limited to positive matches / no information on non-positive RPIs and coarser information wrt the timeframe of the encounter.
If this is too much information for the average user: just hide some details by default and make them accessible via an “expert mode” which can be enabled in the CWA settings. You could then also have an user adjustable notification threshold, for when the app should actually inform you of an encounter via push (e.g. “any encounters”, “only red encounters” etc…). Maybe the switch to ENF 1.5 is the right opportunity to implement such ideas 🙂.

daimpi on 23 Aug 2020

👍4

Also agree with @mf179 that documentation / wording should be improved, as it may be confusing why risk-encounter is low-risk.

In addition to clarifying this overall risk case and the definition it would be nice, if you show also for the low risk exposures the day to the user as it might help for avoiding risks in future.

This would be possible by querying ExposureInformation. Agree that for low-risk encounters it would be better to display at least a date, as currently user has no idea if low-risk encounter happened yesterday or 2 weeks ago.

Displaying more fine grained information about encounters is an interesting problem as perhaps under GDPR user should have transparent access to all the data and any processing which is conducted over this data, and as @daimpi mentioned all the encounters are processed by the EN framework, regardless of configuration. On the other hand it may reveal too detailed information about the encounter potentially leading to identification of a person who shared Diagnosis Keys with the system.

I think the balanced approach would be to use ExposureInformation to compile text description about the encounter, e.g. instead of:

Low risk: 1 risk exposure with low risk (green card)

(as in https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678644207) user could receive following information:

There was 1 encounter with infected person last Wednesday. It happened over short time (15 min - 30 min) and the Bluetooth signal strength was weak, so it was classified as low risk. (yellow card)

Now the person can infer that it might have happened on the train ride (since it was extended time), and with the knowledge that it was a confined space with strong signal shadowing / interference, may make a decision to take precautions anyway. Or if this person is taking care of people in elderly homes, may decide to take special precautions even if the app is reporting negligible risk.

Similar enhancement for higher risk:

Increased risk: 1 exposure (red card)

There was 1 encounter with infected person last Wednesday. It happened over extended time (30 min - 1 hour) and the Bluetooth signal strength was strong, so it was classified as high risk. (red card)

This should be an improvement over just binary classification (low / high risk), as it allows affected person to adjust response based on individual situation.

kbobrowski on 23 Aug 2020

👍3

Thanks for the explanation, daimpi. So I misunderstood what mismatch you are trying to alleviate. My proposal was basically to document the reason; assuming it was to certain extent intentionally or otherwise given that not everything from ENF is also in CWA. Documenting potential mismatch remains an option. However now it rather looks like you are keen on getting all :-)

Not really matching the subject here another proposal, which might need an own thread, if considered useful. By chance I was in a supermarket when the nearby professional school had a break. Waiting at the cashier together with more than 100 students (hardly any distance, but all with masks) RaMBLE showed me very few devices with CWA. Probably none of the students. To extend the reach of the CWA it might be considered to add some gaming or entertaining effects making it somehow attractive for younger people. Or perhaps some cooperation with social media apps, which could adopt CWA features?

mf179 on 23 Aug 2020

However now it rather looks like you are keen on getting all :-)

Yes, I'd like to at least have the option to get this information in some way, for the reasons mentioned above.
And tbh I'm not too worried wrt privacy, as long as this information is coarse enough (e.g. no exact timestamp of the encounter but only a 24h timeframe provided) and not additionally enriched - e.g. with precise location data which is anyway prohibited by the ENF requirements - I think we will be fine.
But any improvements over the current status quo are o/c welcome 🙂.

Not really matching the subject here another proposal, which might need an own thread, […]

There is a wishlist issue which seems to fit this topic pretty well: https://github.com/corona-warn-app/cwa-wishlist/issues/150 🙂.

daimpi on 23 Aug 2020

👍3

I second this proposal to give more detailed information. I am also in the situation of having been notified that I had a low-risk encounter, only to find out that there are no additional details in the app. The only hints are the log files of the ENA framework, so I have created a small tool to make the analysis of the ENA log files easier. But this requires analysis outside of the app.

However, providing the user with information as proposed by kbobrowski should be the way to go IMHO:

Full information from EN (note that CWA currently only queries ExposureSummary):
ExposureInformation:
  - date: Wed Aug 19 02:00:00 GMT+02:00 2020
  - dateMillisSinceEpoch: 1597795200000
  - durationMinutes: 30
  - attenuationValue: 41
  - transmissionRiskLevel: 6
  - totalRiskScore: 30
  - attenuationDurations: [37, 0, 0]

ExposureSummary:
  - daysSinceLastExposure: 3
  - matchedKeyCount: 1
  - maximumRiskScore: 30
  - attenuationDurations: [30, 0, 0]
  - summationRiskScore: 30
So it would be possible to additionally inform users about exact date (no exact time), duration, distance, and at what transmission risk level interaction with infected person was taking place.

Even if it is decided not to display these information directly in the app, it should at least be made accessible to the user via a log file, also to be DSGVO compliant, as the user possesses these data.

felixlen on 23 Aug 2020

👍5

There seems a preference for keeping the user informed about low risk exposures. The detailed information as above is however too much for an average user. Two modes (normal/expert) as considered by daipi might help. Or creation of a log file for the experts as proposed by felixlen.

The information shown to an average user should be more concise and easily understandable. Not confusing and forcing the user to start some research on what all those parameters might mean. So the info for the average user should basically contain:

the number of low risk exposures and when those were (the day might be sufficient),
an explanation or a link to an explanation why this is still considered low overall risk, and
some guidance for the user what to do following this "low risk warning".

For the guidance I would propose the same what people returning from risk areas with a negative test get: watch for symptoms and take actions when there are symptoms. So perhaps referring the "low risk with exposures user" to https://www.infektionsschutz.de/fileadmin/infektionsschutz.de/Downloads/Orientierungshilfe_Buerger.pdf

There seems some agreement that guidance/info by the CWA need to be updated/corrected. It is however not obvious to me whether and how such a task is adopted. Can somebody shed some light on how that works?

mf179 on 24 Aug 2020

👍1

Some more experiments as to what information can be provided by API, switched to v1.5 exposure windows mode, which does not depend on provided ExposureConfiguration, ~~and interestingly EN did not register any exposure window if the signal was very weak, wonder if there is hard-coded threshold somewhere in EN~~ edit: I repeated the test with real weak signal, instead of tinkering with transmission power, and EN registered this weak signal in exposure window, so perhaps there is no cut-off value for weak signal but rather some sanity check on transmission power value. Which is a good news since also very weak exposures would be registered by EN regardless of configuration

Warn-App-Companion | ExposureWindows
:-----------------------------:|:-----------------------:
Screenshot_20200824-133808 | ExposureWindow{dateMillisSinceEpoch=1597795200000, reportType=1, scanInstances=[ScanInstance{typicalAttenuationDb=44, minAttenuationDb=40, secondsSinceLastScan=120}]}
Screenshot_20200821-171717 | ExposureWindow{dateMillisSinceEpoch=1597795200000, reportType=1, scanInstances=[ScanInstance{typicalAttenuationDb=85, minAttenuationDb=80, secondsSinceLastScan=120}]}

kbobrowski on 24 Aug 2020

👍2 👀1

I did not account for certain sanity check inside EN, corrected my post here: https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678644207.

As to this part of the discussion:

@thomasaugsten
ENF is removing RPIs older than 14days from the device.
ENF is filtering matched RPIs based on the configuration provided by the CWA.
The CWA receives the filtered result set and shows alle matches in the app.

@daimpi
Does this mean, that any encounter less than 10 minutes (gt_5_le_10_min: 0) would be discarded by ENF and the same for attenuation >73 db (gt_73_dbm: 0) and hence such encounters would not even be shown as "green-/low risk" encounters by CWA but entirely hidden from the user?

Does this mean such encounters don't even show up as a match in the "exposure Log" in the ENF settings?

@thomasaugsten
@daimpi We assuming this based one the information provided by Apple/Google. We are not able to make a statement here because we are not own the code or the ENF.

After correcting my experiments it seems that all the encounters, regardless how CWA is configured, would be displayed in ENF log, and in ExposureSummary.matchedKeyCount, so also at least as "exposure with low risk" in CWA (see https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678644207).

I also extracted ExposureSummary and ExposureInformation for this case:

An immediate improvement could be to display also "daysSinceLastExposure" for low-risk exposures, @thomasaugsten do you think it would be possible to include this change? More detailed information is also available for low-risk exposures, even with very weak signal, but it would require querying getExposureInformation()

Another improvement could be to trigger notification also for "low-risk" exposures, as currently user has to actively open CWA in order to get this information, would this be an option?

kbobrowski on 24 Aug 2020

👍4 ❤2

Wow, that's great to know…
Thanks again for your thorough investigation 😊 ❤️

So any matching RPI stored in ENF (no matter the associated duration or attenuation) will currently trigger at least a green-/low-risk encounter in CWA + a match in the ENF log, correct?

daimpi on 24 Aug 2020

👍1

Yes it seems so, even if it was very weak signal for a very short time it should still register in ENF log and get displayed as "low-risk exposure" in CWA. The risk score would be 0 in this case with current CWA configuration, but nevertheless ExposureSummary and ExposureInformation would be available and contain more details about this exposure

kbobrowski on 24 Aug 2020

👍2

Yes it seems so, even if it was very weak signal for a very short time it should still register in ENF log and get displayed as "low-risk exposure" in CWA. The risk score would be 0 in this case with current CWA configuration, but nevertheless ExposureSummary and ExposureInformation would be available and contain more details about this exposure

@thomasaugsten could you maybe confirm those findings by @kbobrowski? 🙂

B/c in this case the the FAQ entry on green risk encounters wouldn't have to change after all…

daimpi on 24 Aug 2020

👍2

Tut mir leid, doch dies ist alles nicht wirklich relevant für das Problem "App is missing information about "Risikobegegnung" with green risk status corona-warn-app/cwa-backlog#23". Es hätte gelöst werden können indem die Nicht-Risikobegegnungen dem Nutzer eben nicht gezeigt werden. Doch das ist offenbar nicht bevorzugt. Nun noch mehr Details zu no-risk-encounters aus dem ENF zu kitzeln und detailierter zu präsentieren hilft weder dem Hauptzweck (Infektionsrisiken aufzuspüren) noch der Masse der Anwender.

"What is missing" sollte präzisiert werden. Der normale Nutzer (z.B. der beschriebene Kollege) will nicht wissen, wie der "risc score berechnet wird", sondern "warum grün trotz Risikobegegnung ermittelt wird" und was er nun tun soll.
Dieses Topic corona-warn-app/cwa-backlog#23 hier sollte in 2..3 Themen aufgespalten werden. In das Problem des mangelhaften Nutzerinterfaces und das Problem noch mehr Details vom ENF zu bekommen und darzustellen. Auch um klarzustellen was "in progress" ist. Letzteres Problem ist für mich eher ein Luxusproblem.

Zum Hauptproblem wo ich immer mehr den Eindruck gewinne, dass dieses nicht ernst genommen wird. Gestern habe ich durch Zufall entdeckt, dass da noch mehr "Beschreibung" in der CWA ist, die alles noch schlimmer macht.
Auf der CWA-Hauptseite steht "Risiko niedrig" ohne jeglichen Hinweis was für ein "Risiko".
Klickt man auf den Link steht darüber "Risiko-Status".
Neu entdeckt habe ich, dass man runterscrollen kann. Niemand erwartet nach allgemeinen Hygieneinfos die für jeden Risikostatus dieselben sind, dass danach noch konkrete Infos kommen. Auch kein Hinweis das noch etwas folgt.
Und die Infos haben es in sich. Da steht das Ganze dann unter "Infektionsrisiko". Innerhalb der Beschreibung kommt dann noch "Infektionswahrscheinlichkeit". Und der geneigte Nutzer soll dann erraten, dass Risiko = Risiko-Status = Infektionswahrscheinlichkeit = Infektionsrisiko ?! VIER Begriffe für ein und dasselbe auf zwei kleinen Seiten!

Beschreibung "niedrig Risiko" ist falsch. Es steht dort "kurze Zeit UND größerer Abstand".

"Infektionsrisiko" Beschreibung unter "Übersicht" ist falsch: die CWA ermittelt auch ein Risiko, wenn keine Begegnung stattfand.
Es sei Infektionsrisiko ist nicht gleich Risikostatus. Letztere werden jedoch gleich nach Beschreibung von Infektionsrisiko gelistet ohne einen Zusammenhang herzustellen.

Unklar warum der Begriff "Risiko-Überprüfung" eingeführt wird. Scheint nirgends benutzt. Und bringt die Frage: wozu Überprüfung alle zwei Stunden, wenn Risiko-Berechnung nur alle 24h stattfindet. Auf CWA-Hauptseite steht "tägliche Aktualisierung" - von was? Risiko-Berechnung ist ein nützlicher Begriff, wird verwendet aber nicht beschrieben.

Beschreibung der Zufallscodes enthält Beschreibungen die nicht signifikant für Codes sind. Zusammenhang mit Risiko-Ermittlung "Begegnungen werden aufgezeichnet" ist nicht erkennbar. Ebenso bleibt der Zusammenhang mit "Begegnungs-Aufzeichnung" konfus. Nicht intuitiv warum der Vorgang des Aufzeichnens von Bewegungen am Ende nur eine Liste ist ?!

Risiko-Benachrichtigung ist falsch weil es eine spezifische Benachrichtigung nicht beschreibt. Gibt es eine in CWA? Und auch falsch weil es offenbar keine gesonderte Anzeige von Begegnungen gibt. Ist dies der fünfte Begriff für "Risikostatus"?

Und auch Beschreibung des grünen Risikos in den FAQs ist nicht eindeutig. Warum werden Nicht-Risikobegegnungen angezeigt, wenn sie verworfen werden? Es sollte evtl. lauten, dass Nicht-Risikobegegnungen zwar dem Nutzer angezeigt werden aber der Gesamtrisikoberechnung verworfen oder besser als unbedenklich eingestuft werden.

Es ist mir klar, dass es für Entwickler die technischen Aspekte wesentlich interessanter sind und Dokumentation eher als lästig empfunden wird. Doch das ist hier der wirklich problematische Aspekt.

Sie sollten damit anfangen die Begriffe auszuwählen, die wirklich benötigt werden. Diese sauber definieren und dann konsistent verwenden. Und auch die Haptik der CWA-Seiten verbessern. Dies alles erfordert keine Koordination mit dem RKI, wie oben einmal angeführt. Es werden keine neuen Begriffe oder Funktionen eingeführt.

Bis auf, dass bei Anzeige mit Begegnungen ohne Risiko zu Selbstbeobachtung auf Symptome statt lediglich auf allgemeine Hygiene hingewiesen werden sollte. Die eine Frage, ob das richtig ist, wird das RKI hoffentlich beantworten können.

mf179 on 25 Aug 2020

😕3

Tut mir leid, doch dies ist alles nicht wirklich relevant für das Problem "App is missing information about "Risikobegegnung" with green risk status corona-warn-app/cwa-backlog#23". Es hätte gelöst werden können indem die Nicht-Risikobegegnungen dem Nutzer eben nicht gezeigt werden. Doch das ist offenbar nicht bevorzugt. Nun noch mehr Details zu no-risk-encounters aus dem ENF zu kitzeln und detailierter zu präsentieren hilft weder dem Hauptzweck (Infektionsrisiken aufzuspüren) noch der Masse der Anwender.

@mf179 Das ist schlichtweg falsch: ein Low-Risk-Encounter könnte z.B. eine Begegnung in weniger als 30 Zentimeter Abstand gewesen sein, die eben nur weniger als 10 Minuten gedauert hat und würde somit durchaus ein Infektionsrisiko darstellen. Genauso könnte es aber eben auch eine Begegnung in 30 Meter Entfernung gewesen sein, die kein Infektionsrisiko darstellt. Des weiteren kann es ein Kontakt in sehr kurzer Distanz und über einen längeren Zeitraum gewesen sein der über die Kalkulation des Risikoscores von unter 15 auf niedrig gestuft wurde, da der Kontakt mehr als 6 Tage vor Upload stattgefunden hat.

Dementsprechend macht es durchaus Sinn, die genaue Zeit, Länge und Distanz bei Low-Risk-Encounters anzuzeigen.

Die App hat die Daten vorliegen und aus Datenschutzgründen sind zumindest Länge und Distanz unkritisch. Auch der Tag lässt bereits jetzt ohnehin leicht feststellen, da ein Low-Risk-Encounter nach 14 Tagen verschwindet.

Coronawahn on 25 Aug 2020

👍6

Tut mir leid, doch dies ist alles nicht wirklich relevant für das Problem "App is missing information about "Risikobegegnung" with green risk status corona-warn-app/cwa-backlog#23". Es hätte gelöst werden können indem die Nicht-Risikobegegnungen dem Nutzer eben nicht gezeigt werden. Doch das ist offenbar nicht bevorzugt. Nun noch mehr Details zu no-risk-encounters aus dem ENF zu kitzeln und detailierter zu präsentieren hilft weder dem Hauptzweck (Infektionsrisiken aufzuspüren) noch der Masse der Anwender.

Hallo @mf179, ich bin deiner Meinung das die Diskussion hier, ein wenig von dem ursprünglichen Thema abgedriftet ist, allerdings war es wichtig sie zu führen damit jeder (den es interessiert) erstmal richtig versteht wie was funktioniert und was dem Nutzer nun angezeigt wird.
Ich bin außerdem nicht deiner Meinung das es nicht hilfreich wäre mehr Informationen aus dem ENF dem Nutzer zu zeigen (auch da es, wie @Coronawahn beschrieben hat, durchaus ein Infektionsrisiko gibt). M.M.n. sollte zumindest bei "Low-Risk Exposures" auch angezeigt werden vor wie vielen Tagen sie war, einfach so wie bei "High-Risk Exposures".
Über Länge und Abstand müsste man dann nochmal reden, das wäre m.M.n. auch sinnvoll für "Low-" sowie "High-Risk Exposures".

"What is missing" sollte präzisiert werden. Der normale Nutzer (z.B. der beschriebene Kollege) will nicht wissen, wie der "risc score berechnet wird", sondern "warum grün trotz Risikobegegnung ermittelt wird" und was er nun tun soll.

Richtig, es sollte in der App verständlicher erklärt werden warum das Infektionsrisiko im grünen Bereich bleibt, obwohl man Kontakt zu einer positiv getesteten Person hatte. Außerdem wären Verhaltensvorgaben, wie bei "High-Risk Exposures" sicherlich auch für "Low-Risk Exposures" sinnvoll (z.B.: Abstand von alten Personen halten, verstärkt auf Symptome achten, etc.)

Zum Hauptproblem wo ich immer mehr den Eindruck gewinne, dass dieses nicht ernst genommen wird.

Naja, das Label "In Progress" ist da, wenn uns trotzdem jemand hier von den Devs ein Update geben könnte wäre das Klasse (@tkowark & @GPclips)

Auf der CWA-Hauptseite steht "Risiko niedrig" ohne jeglichen Hinweis was für ein "Risiko".

Ich finde das sollte eigentlich verständlich sein das bei einer App die vor einem Virus warnt (stark vereinfacht gesagt) "Risiko" das Infektionsrisiko ist...
Sonst gibt es aber auch,
,in der App oben rechts ein Infosymbol, auf dieses kann man klicken und u.a. das wird erklärt (2. Punkt).

Neu entdeckt habe ich, dass man runterscrollen kann. Niemand erwartet nach allgemeinen Hygieneinfos die für jeden Risikostatus dieselben sind, dass danach noch konkrete Infos kommen. Auch kein Hinweis das noch etwas folgt.

Diese Verhaltensinfos sind nur für keine Begegnungen oder Begegnung mit niedrigem Risiko die selben. (Das könnte, wie oben beschrieben, geändert & verbessert werden).
Natürlich ist der Text dort ganz unten etwas schwierig positioniert, hast du einen Vorschlag wo er besser stehen sollte?

Und die Infos haben es in sich. Da steht das Ganze dann unter "Infektionsrisiko".

Wie gesagt, diese App _warnt_ vor Infektionen, da sollte Infektionsrisiko nun kein so unerwarteter Begriff sein...

Innerhalb der Beschreibung kommt dann noch "Infektionswahrscheinlichkeit". Und der geneigte Nutzer soll dann erraten, dass Risiko = Risiko-Status = Infektionswahrscheinlichkeit = Infektionsrisiko ?! VIER Begriffe für ein und dasselbe auf zwei kleinen Seiten!

Auch hier denke ich kann man dem Nutzer schon zutrauen das er das versteht, allerdings gebe ich dir recht das man hier einheitlicher Begriffe verwenden könnte. Da dieser Text aber vom RKI kommt denke ich fast das sich da nicht viel machen lässt...

Beschreibung "niedrig Risiko" ist falsch. Es steht dort "kurze Zeit UND größerer Abstand".

Das stimmt, zumindest ist diese Aussage widersprüchlich dem FAQ. Dort steht: "weniger als 10 Minuten gedauert haben [...] oder bei denen die Smartphones im Durchschnitt mehr als ca. 8 Meter Freiraum [...] voneinander entfernt waren [...]"
Das sollte angeglichen werden.

"Infektionsrisiko" Beschreibung unter "Übersicht" ist falsch: die CWA ermittelt auch ein Risiko, wenn keine Begegnung stattfand.

Das stimmt, dann sagt sie eben das es keine Begegnungen gab und das das Risiko niedrig ist, das versteht der Nutzer schon.

Unklar warum der Begriff "Risiko-Überprüfung" eingeführt wird. Scheint nirgends benutzt.

Die Risiko-Überprüfung findet alle 2 Stunden im Hintergrund statt, dabei werden die heruntergeladenen Positivkennungen von anderen Nutzern mit den Kennungen (=Begegnungen die du hattest) auf deinem Gerät abgeglichen. Daraus wird dann das Infektionsrisiko berechnet.

Und bringt die Frage: wozu Überprüfung alle zwei Stunden, wenn Risiko-Berechnung nur alle 24h stattfindet. Auf CWA-Hauptseite steht "tägliche Aktualisierung" - von was? Risiko-Berechnung ist ein nützlicher Begriff, wird verwendet aber nicht beschrieben.

Warum dieser Prozess alle 2 Stunden stattfindet weiß ich jetzt auf die Schnelle auch nicht (ausser du triffst jemanden nachdem sich derjenige positiv gemeldet hat, das wäre aber unwahrscheinlich...).

Wo findest du den Begriff "Risiko-Berechnung"? In der App konnte ich ihn auf den ersten Blick nicht finden.

Beschreibung der Zufallscodes enthält Beschreibungen die nicht signifikant für Codes sind. Zusammenhang mit Risiko-Ermittlung "Begegnungen werden aufgezeichnet" ist nicht erkennbar.
Ebenso bleibt der Zusammenhang mit "Begegnungs-Aufzeichnung" konfus.

Im "Überblick" steht unter Wichtige Begriffe:

Wenn mann dann weiterliest steht weiter unten die Erklärung für Zufallcode:

Da Nutzer Erklärungen meist von oben nach unten lesen, ist für mich der Zusammenhang zwischen Begegnungs-Aufzeichnungen und Zufallcode durchaus klar und gut erklärt.

Nicht intuitiv warum der Vorgang des Aufzeichnens von Bewegungen am Ende nur eine Liste ist ?!

Was soll es sonst sein wenn keine Liste? Welchen Begriff würdest du benutzen?

Und auch Beschreibung des grünen Risikos in den FAQs ist nicht eindeutig. Warum werden Nicht-Risikobegegnungen angezeigt, wenn sie verworfen werden? Es sollte evtl. lauten, dass Nicht-Risikobegegnungen zwar dem Nutzer angezeigt werden aber der Gesamtrisikoberechnung verworfen oder besser als unbedenklich eingestuft werden.

In diesem Punkt stimme ich dir zu, das FAQ sollte hier verständlicher gemacht werden.

Sie sollten damit anfangen die Begriffe auszuwählen, die wirklich benötigt werden. Diese sauber definieren und dann konsistent verwenden.

Ich finde das die Begriffe durchaus konsistent verwendet und verständlich beschrieben werden.

Und auch die Haptik der CWA-Seiten verbessern. Dies alles erfordert keine Koordination mit dem RKI, wie oben einmal angeführt. Es werden keine neuen Begriffe oder Funktionen eingeführt.

Das ist schlichtweg falsch, soweit ich weiß muss jede Änderung die der Nutzer sieht (also nichts technisches im Hintergrund) mit dem RKI abgesprochen werden.

Ein-Tim on 25 Aug 2020

👍2

Genau, das ist falsch, Coronawahn. Wird aber in der CWA behauptet: "Sie haben ein niedriges Infektionsrisiko, da keine Begegnung mit positiven Personen aufgezeichnet wurde oder sich Ihre Begegnung auf kurze Zeit UND einen größeren Abstand beschränkt hat".
Wie auch viele andere Beschreibungen darin zumindest konfus sind.

CWA kann auch gerne etwas mehr zu Niedrig-Risikobegegnungen anzeigen, solange es allgemein verständlich ist. Es ist jedoch offenbar richtig in den FAQ, dass low-risk-encounters bei der Risikoberechnung als nicht relevant betrachtet werden. Somit ist es nicht so relevant, wenn es nicht klappt, auch jede Niedrig-Risikobegegnung dem Nutzer anzuzeigen. D.h. das ist nicht der Kern des Problems.

Das Hauptproblem bleibt auch damit bestehen. Das mangelhafte Userinterface verunsichert die Nutzer.

mf179 on 25 Aug 2020

Genau, das ist falsch. Wird aber in der CWA behauptet: "Sie haben ein niedriges Infektionsrisiko, da keine Begegnung mit positiven Personen aufgezeichnet wurde oder sich Ihre Begegnung auf kurze Zeit UND einen größeren Abstand beschränkt hat".

Wie auch viele andere Beschreibungen darin zumindest konfus sind.

Du kannst für deiner Meinung nach konfuse Beschreibungen Issues im Documentation Repository öffnen 👍

CWA kann auch gerne etwas mehr zu Niedrig-Risikobegegnungen anzeigen, solange es allgemein verständlich ist. Es ist jedoch offenbar richtig in den FAQ, dass low-risk-encounters bei der Risikoberechnung als nicht relevant betrachtet werden. Somit ist es nicht so relevant, wenn es nicht klappt, auch jede Niedrig-Risikobegegnung dem Nutzer anzuzeigen. D.h. das ist nicht der Kern des Problems.

Vielleicht sagt die App dir zwar das du ein niedriges Risiko hast weil der Kontakt nicht lang genug war oder/und weil die andere Person weit entfernt war, wenn du nun aber z.B. in einem Pflegeheim arbeitest willst du das vielleicht schon wissen.
Außerdem bin ich (und auch viele andere denke ich mal, inklusive du) hier der Meinung das es auf jeden Fall notwendig ist mehr Verhaltenshinweise bei "Low-Risk Exposure" anzuzeigen und außerdem besser zu erklären warum der Risikostatus (in der App) sich nicht ändert

Ein-Tim on 25 Aug 2020

👍2

Ein-Tim, wir reden offenbar aneinander vorbei. Ja, es sollte für den normalen Nutzer ausreichend und verständliche Information sein und eine mehr spezifische Handlungsanweisung dazukommen. Ich sage, für den normalen Nutzer nicht notwendig sind log-file-level infos oder Score-Berechnungen.

Ausreichend und verständlich bedeutet nicht nur hinzufügen, sondern auch korrigieren was widerspricht. Das erzeugt gegenwärtig die Konfusion.

Ich hatte angefangen, deinen detailierten Kommentar zu beantworten. Nicht mehr schön mit den Verschachtelungen. Habe ich dann aufgegeben. Scheint auch nicht mehr erwünscht nach dem letzten Kommentar. Beim Beantworten ist mir jedoch aufgegangen, dass die "wichtigen Begriffe" offenbar versuchen die gesamte Funktion zu beschreiben. Die soll man sich dann wohl aus den Elementen zusammenpuzzeln. Es wäre wohl einfacher und verständlicher, wenn es mehr als Ablauf anstatt als Liste von Begriffen beschrieben würde.

Die (RKI?) Hotline hat mich hierher verwiesen, auf die Frage wo man Korrekturen zu "Risikobegegnungen mit niedrigem Risiko" einbringen kann. Und selber auf den Tagesschau-Artikel als Erklärung verwiesen?! Mittlerweile frage ich mich aber, ob es weiter Sinn macht.

mf179 on 25 Aug 2020

👍2

@mf179

Erstmal: Entschuldige falls meine Kommentare etwas hart klangen, das war nicht meine Absicht und jeder ist hier Willkommen seine Sicht der Dinge zu schildern ❤️👍

Ich sage, für den normalen Nutzer nicht notwendig sind log-file-level infos oder Score-Berechnungen.

Absolut deiner Meinung!
Aber was würde dagegensprechen für Begegnungen mit niedrigem Risiko, neben Verhaltenshinweisen und Infos warum es eine Begegnung mit niedrigem Risiko ist, auch noch die Tage seit der Begegnung anzuzeigen?

Ausreichend und verständlich bedeutet nicht nur hinzufügen, sondern auch korrigieren was widerspricht. Das erzeugt gegenwärtig die Konfusion.

Ich werde mir nachher nochmal deinen obersten langen Kommentar genau durchlesen und sehen was ich für Widersprüchlichkeiten finde, ich konnte dir vorhin nur nicht ganz folgen und fand auf den ersten Blick auch keine.

Beim Beantworten ist mir jedoch aufgegangen, dass die "wichtigen Begriffe" offenbar versuchen die gesamte Funktion zu beschreiben. Die soll man sich dann wohl aus den Elementen zusammenpuzzeln. Es wäre wohl einfacher und verständlicher, wenn es mehr als Ablauf anstatt als Liste von Begriffen beschrieben würde.

Das ist eine gute Idee, das das ganze mehr als Ablauf beschrieben wird anstatt wie jetzt, das könntest du z.B.: hier einbringen.
Außerdem habe ich auch in der CWA-Wishlist diesen Vorschlag zum bessern Verständnis gemacht!

Noch zum Abschluss:
Im Grunde wollen wir ja das gleiche, mehr Infos in der App darüber warum die Begegnung nun jetzt als niedriges Risiko bewertet wird und wie man sich verhalten soll.

Ein-Tim on 25 Aug 2020

👍3

Hallo Ein-Tim, verständlich, dass bei dem Umfang der Kommentare und oft Mehrdeutigkeit der natürlichen Sprache alles nicht immer gleich verstanden wird, wie es gemeint ist. Geht mir auch so.

Können wir vielleicht damit anfangen, klarzustellen was unter dieses Thema hier fallen soll?

Die verbale/initiale Beschreibung des Themas ist: "A colleague got a message form the App "1 Risiko-Begegnung" but the screen says "Niedriges Risiko". I didnt find information, what this exactly means (was the contact longer or shorter than 10 minutes, nearer or farer away than 8 Metres, etc.). The App should give more information about this, because it insecures the users."
Doch das What/Why/Where beschreibt aber eher etwas anderes. Es geht doch vorrangig darum, die Verunsicherung zu vermeiden?

Im Grunde genommen ist es ja bereits beschrieben unter Infektionsrisiko. Nur dass es schlecht zu finden ist und fälschlicherweise sagt: niedrig heißt kurz UND weit weg. Außerdem konterkariert die Definition einer Risikobegegnung es, da danach eine Risikobegegnung immer lang und nah ist. Diese beiden Dinge müssen mindestens in der CWA korrigiert werden, um daraus resultierende Verunsicherung zu vermeiden. And dann kann noch hinzufügt werden was zu tun ist, so man mehr also die schon aufgeführten allgemeinen Hygieneregeln nennen möchte. Auch um Hotline-Calls zu vermeiden.

Das originäre Problem hier ist offenbar ähnlich wishlist #113. Der creator hat Recht. Dort verweist daimpi auch auf wish-list #100 (Show more details about "risk encounters"). Dann kann ja was an zusätzlichen Details hinzugefügt werden soll evtl. dort weiter diskutiert werden. Ich würde es dort ja sogar "in progress" nennen, entsprechend dem letzten Kommentar dort. Nur scheint seit langer Zeit nichts passiert zu sein. Und beim Thema hier geht der Fokus auf "Vermeiden der Verunsicherung von Nutzern"?

mf179 on 25 Aug 2020

Hah, habe mich selber ertappt dabei es nicht richtig zu lesen, Ein-Tim. Es geht darum zu erklären, warum es ein niedriges Infektionsrisiko ist trotz Risikobegegnungen. Der normale Nutzer muss eh darauf vertrauen, dass das RKI oder wer auch immer die Kriterien für die Risiko-Risikobegegnungs-Entscheidung vernünftig setzt. Der will eigentlich nur wissen, dass seine Risikobegegnung eher als Nicht-Risiko bewertet werden. Und das ist derzeit nicht klar genug beschrieben.

mf179 on 25 Aug 2020

Hah, habe mich selber ertappt dabei es nicht richtig zu lesen, Ein-Tim. Es geht darum zu erklären, warum es ein niedriges Infektionsrisiko ist trotz Risikobegegnungen. Der normale Nutzer muss eh darauf vertrauen, dass das RKI oder wer auch immer die Kriterien für die Risiko-Risikobegegnungs-Entscheidung vernünftig setzt. Der will eigentlich nur wissen, dass seine Risikobegegnung eher als Nicht-Risiko bewertet werden. Und das ist derzeit nicht klar genug beschrieben.

Das kann Dir aber weder das RKI noch die App sagen, ob die Begegnung tatsächlich ein niedriges oder hohes Infektionsrisiko war. Entscheidend ist Deine persönliche Einschätzung und dazu brauchst Du eben zusätzliche Informationen, wie Zeitpunkt, Länge und Entfernung.

Hieraus kannst Du dann unterscheiden, ob Du z.B. zum Zeitpunkt im Auto oder in der Wohnung warst, und hier ein Signal durch eine Scheibe oder Mauer empfangen hast, oder ob Du in einem öffentlichen Verkehrsmittel neben jemandem saßt.

Ein Low-Risk-Encounter könnte z.B. eine Begegnung in weniger als 30 Zentimeter Abstand gewesen sein, die eben nur weniger als 10 Minuten gedauert hat und würde somit durchaus ein Infektionsrisiko darstellen. Genauso könnte es aber eben auch eine Begegnung in 30 Meter Entfernung gewesen sein, die kein Infektionsrisiko darstellt. Des weiteren kann es ein Kontakt in sehr kurzer Distanz und über einen längeren Zeitraum gewesen sein der über die Kalkulation des Risikoscores von unter 15 auf niedrig gestuft wurde, da der Kontakt mehr als 6 Tage vor Upload stattgefunden hat.

Dementsprechend macht es durchaus Sinn, die genaue Zeit, Länge und Distanz bei Low-Risk-Encounters anzuzeigen.

Die App hat die Daten vorliegen und aus Datenschutzgründen sind zumindest Länge und Distanz unkritisch. Auch der Tag lässt sich bereits jetzt ohnehin leicht feststellen, da ein Low-Risk-Encounter nach 14 Tagen verschwindet.

Coronawahn on 25 Aug 2020

👍3

Coronawahn, jeder der genauer reinschaut weiß, dass die zugrunde liegenden Daten und somit auch die Entscheidungen mit gewissen Unwägbarkeiten verbunden sind. Von mir aus können zu jeder niedrig/hoch Risikobegegnung gern mehr Details gegeben werden. Wie gesagt, das wurde unter wishlist #100 bereits mit gewissem Wohlwollen aufgenommen, ist dann aber offenbar versandet. Und wer es ganz genau wissen will nimmt dann wohl RaMBLE und den Warn-App-Companion.

Mein Problem, das von wishlist #113 und der Tagesschau bleibt immer noch das "niedrige Risiko durch Risikobegegnungen mit niedrigem Risiko". Der Begriff/Text an sich ist verwirrend und an anderer Stelle schreibt die App, dass es nur Risikobegegnungen mit hohem Risiko gibt. Ergo fragt sich der Nutzer, ist die Beschreibung falsch? Oder, stimmt es am Ende das niedrige (Infektions)Risiko nicht.

Ich möchte jetzt eigentlich nur noch, dass was von der App angezeigt wird stimmig ist und diese Verunsicherung genommen wird.

mf179 on 25 Aug 2020

Mir ist diese Wortklauberei ehrlich gesagt ziemlich egal, denn wenn ich eine Info bekomme wie z.B.

eine Risiko-Begegnung am XX.XX.XXXX (um XX:XX Uhr), mit X Meter Abstand und einer Länge von X Minuten

brauche ich keine weitere Erklärung.

Coronawahn on 25 Aug 2020

👍3 👀1

Mit dem Ändern des Issue #413 auf einen Aspekt der Diskussion hier willst du offenbar die Diskussion verschiedener Aspekte innerhalb dieses Issues hier entzerren. Das ändert jedoch nichts daran, dass die Issue-Beschreibung hier mehrdeutig ist.

Ich würde diesen Issue hier schließen. Und auf "Show more details about "risk encounters" wishlist#100" verweisen. Dort ist der Aspekt den manche hier als Hauptproblem ansehen eindeutig als Ziel beschrieben. Alternativ kann die Issue-Beschreibung hier klar auf diesen Teil reduziert werden. Womit die Diskussion hier einen besseren Fokus bekommt und dann auch klarer wäre, was "in Progress" ist.

mf179 on 27 Aug 2020

👍1

Hi everyone,

I can give you some insights what is going on right now regarding this topic.

A proposal was made to introduce a third color besides red and green but finally dismissed by the RKI to avoid confusion.
So red and green will remain the only two colors as a state for risk encounters.
However, an upcoming update will add more information for the users regarding Low-Risk-Encounters.

The final texts are being reviewed and translated for the app localizations at the moment.

I agree with @mf179 to close this issue here. Lets continue the discussion in the related issues if required.

Best regards,

ABB

Corona-Warn-App Open Source Team

abro1i on 27 Aug 2020

👍1

Hi @abro1i

Until now the backlog repo was the place to track what is being worked on. So this issue is not just overlapping with others, this issue should be about what is in development. Normally these issues are closed when the feature is available. Are you handling this differently now?

Best Regards,
Christoph

cfritzsche on 27 Aug 2020

👍4

Thanks for the update, abro1i.
Are you sharing somewhere how you will define "Low-Risk-Encounters"?
I´m asking as the FAQ declares those as harmless/unbedenklich and so the term should better not include the word "risk".
Some more details under https://github.com/corona-warn-app/cwa-documentation/issues/416

To address cfritsches concern, it could be closed with a reference to wishlist#100, which covers "more info about risk encounters".

Ein-Tim opened new issues for some other aspects of the discussion so far that could also be referenced. So I would assume nothing is lost. But separated into better managable aspekts. It might become quite some discussion when trying to clarify the issue description of this issue here. So I think closing with giving the references is the better appraoch.

mf179 on 27 Aug 2020

Sorry for the confusion, closing this issue was a mistake. We just wanted to share the latest updates at this point.

svengabr on 27 Aug 2020

👍3

Thanks for the update 🙂
Do you have some more information to share on what exactly this "more information" which will be available to users with low risk encounters entails?

In https://github.com/corona-warn-app/cwa-wishlist/issues/100 it's been suggested to make "day, duration and attenuation info" available, will we see any of those?

Btw, just out of curiosity: is this change coming together with a switch to ENF 1.5, or is it independent of it? 🙂

Edit: one additional question: is this change currently targeted for a CWA 1.3 release or after that?

daimpi on 27 Aug 2020

👍1

Hi everyone,

here are the first drafts of text changes. Please be aware that this is not final and might change.

Be aware that the RKI always makes the final decision.

Best regards,

ABB

Corona-Warn-App Open Source Team

abro1i on 28 Aug 2020

🚀2 👍2

Was about to link my issue but I see github has some bot there. (The one where @daimpi mentioned this issue)

I admit I read through only about a third to half of the discussion in this issue and want to underline what others requested here:
Add more information. It is f*ing annoying to get the weekly report which is more forward then the CWA in giving me at least a hint but then be without info from the CWA (as the encounter was just old enough to be out of the last 14 days "ringbuffer" today).

I didn't get a notification from the CWA about the low risk encounter which I would have expected with more information. Also at least the date and the assumed distance and length of the exposure would be fine. That there is no exact time out of privacy reasons I understand, but I should at least be able to think: "Oh damn, that was the day I was sitting in a train and now I have an hour of exposure" or "That was just someone passing by on the street possible a few meters away from the signal strength".

irieger on 30 Aug 2020

👍3

@irieger

Add more information. It is f*ing annoying to get the weekly report which is more forward then the CWA in giving me at least a hint but then be without info from the CWA (as the encounter was just old enough to be out of the last 14 days "ringbuffer" today).

You can see what is planed for low risk encounters on the screenshots from @abro1i above.

That there is no exact time out of privacy reasons I understand, but I should at least be able to think: "Oh damn, that was the day I was sitting in a train and now I have an hour of exposure" or "That was just someone passing by on the street possible a few meters away from the signal strength".

@svengabr already stated here that they are not going to include more information about when/where/etc. the Low-Risk encounter happened due to privacy reasons.

Ein-Tim on 30 Aug 2020

You can see what is planed for low risk encounters on the screenshots from @abro1i above.

This screenshot show exactly zero additional information or am I missing something? It is just more verbose with what is already known but maybe not clear to many users. And it is still green and mostly looking like it seems to look now in the status field others shared here with low risk encounters?

@svengabr already stated here that they are not going to include more information about when/where/etc. the Low-Risk encounter happened due to privacy reasons.

A link to slack which requests a login doesn't help here. There is a very good idea about adding a expert mode by @daimpi btw. at https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678768765 ...

Can anyone build and run the CWA locally or does it only run/install with a special developer account flag?

irieger on 31 Aug 2020

@irieger CWA has "expert mode" aka "device for testers", but to access it you need to compile "device for testers" flavor of CWA and then locally suppress whitelisting inside EN framework with: https://github.com/kbobrowski/en-i13n

1 | 2 | 3 | 4
|:--:|:---:|:---:|:---:|
| | |

Perhaps easier way is to use Warn-App-Companion to display all the details about the encounter: https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion

Both methods would require rooted Android device.

As for the slack, you can join with this invite link: https://join.slack.com/t/covidapps/shared_invite/zt-gmgl4l13-E4Xcn1ZfPFsPz6V_KjROCg

kbobrowski on 31 Aug 2020

👍3

This screenshot show exactly zero additional information or am I missing something?

As I said before, for "Low-Risk Encounters" they won't add more information because of data protection.
But they are adding an better explanation for "Low-Risk Encounters", see this screenshot

A link to slack which requests a login doesn't help here. There is a very good idea about adding a expert mode by @daimpi btw. at https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678768765 ...

Oh, I'm sorry, didn't know that slack instant requires a Login.
He said:

I was just being told that there wont be any more information shown due to privacy concerns. [...]

Ein-Tim on 31 Aug 2020

Both methods would require rooted Android device.

Doesn't help me then. I'm using iOS and if I had Android, it would be without play services...

As for the slack, you can join with this invite link: https://join.slack.com/t/covidapps/shared_invite/zt-gmgl4l13-E4Xcn1ZfPFsPz6V_KjROCg

I don't plan on joining another Slack. Slack sucks and having to register for every channel/group you want to join is dump. Why was IRC, which is open to so much clients, abandoned by so much open source projects in recent years?

irieger on 5 Sep 2020

I also vote for adding at least the day, on which a low risk encounter was detected. For me now it also displays a low risk encounter, and I would like to know which day this was. because with my personal memory of that day I could assess for myself, in which situations I was. Then I could decide if I should now be VERY careful, or maybe if I´m sure, that there was no close or long contact, that there is really no increased risk.

Showing the day of the encounter would give people more security.

I don´t get the point, why showing this information would be a data privacy issue. Could someone please explain this?
Yes, you could maybe construct some theoretical "attacks", but the question is, is this realitistic? And how much effort would a person need to do to really track people? I guess it is very, very unlikely taht his happens. So, is it a good tradeoff to block this feature because of a highly unlikely misuse? Can someone from the Developer team elaborate on that?

mss1010 on 5 Sep 2020

👍9

@mss1010 Opinions on this vary, that’s why I made https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion which could help you if you use a rooted Android device.
RKI has a different opinion, they want to show details only when absolutely necessary, and in “green” state they don’t regard it as necessary.

mh- on 5 Sep 2020

👍1

I don´t get the point, why showing this information would be a data privacy issue. Could someone please explain this?

I would also like to understand this point. In case of a red warning the app shows how many days ago the last contact was (at least on this screenshot). Why is this not a data privacy issue?

In case RKI decides to not show additional information on a low risk encounter, I would recommend to not show low risk encounters at all. At the moment people are confused and headlines like this are for sure not promoting the app. The users that are not deleting the app after such a strange and useless warning (I already know some users), will anyhow just ignore it. So what is the value of it?

Even when seeing 20 low risk contacts, I'm sure nobody would see the urge to do something. If the pure number of contacts is seen as a threat, I would rather expect that there is some kind of risk rating behind which will also take the number of risk contacts into account and turn into a red warning if appropriate.

But there might be a fundamental question behind this topic: Does RKI think the users of the app are mature enough to interpret the data from the app? Then show as much information as possible to them (at least in some kind of expert view). In case they think too much information just confuses the users of the app, switch to a simple green/red scheme and remove low risk encounters completely. Everything in the middle will just create confusion and will harm the reputation of the app.

esscue23 on 5 Sep 2020

❤1 👍1

RKI has a different opinion, they want to show details only when absolutely necessary, and in “green” state they don’t regard it as necessary.

In this case, please completely remove low risk encounters (see my previous post for an explanation).

esscue23 on 5 Sep 2020

Privacy is never about 0 or 1, it’s about trade-offs. And for “red” state, RKI thinks that informing the warned user is more important than protecting the warning user from the (extremely unrealistic) possibility of being identified.
For “green” state, they see different weights in this trade-off.

mh- on 5 Sep 2020

@mh- Is this just an Assumption or do you know for sure that the RKI is thinking like this (I know the Text from Slack, but this was just a Assumption afaik)?

Ein-Tim on 5 Sep 2020

@Ein-Tim just an assumption, but I’m quite certain about this.

mh- on 5 Sep 2020

👍2

@mh- Tbh me too but I opened this Issue in the Wishlist to get a final anwer about this.

Ein-Tim on 5 Sep 2020

@mh-

And for “red” state, RKI thinks that informing the warned user is more important than protecting the warning user from the (extremely unrealistic) possibility of being identified.

I would assume this is the thinking of the RKI, at the same time hoping that RKI is aware that in case of "red" state "days since last risk-encounter" is not decisive, as it is in fact number of days since any contact. If a person had "red" encounter and then got a random single ping with very weak signal from a person that later reported as infected, then "days since last risk-encounter" would display days since this "green" contact. "X Tage seit letzter Risiko-Begegnung" is not strictly correct wording here.

If RKI wants to extract some useful information in case of higher risk, then probably ExposureInformation should be used instead, as from this the true date of the encounter can be extracted. Especially because this information is used in the process of categorizing the contact, according to this document ("z.B. Aufenthalt in einem kleinen Club zur gleichen Zeit wie ein dem Gesundheitsamt bekannter Fall kann Kontakt der Kategorie I zur Folge haben."). But we also know that RKI wants to be in control of the notifications, and querying ExposureInformation would automatically trigger notification about the contact directly from Play Services, so I guess this is why it was not implemented.

kbobrowski on 5 Sep 2020

👍3 👀1

The App should give more information about this, because it insecures the users.

After analyzing the risk calculation it is possible to make a simple backwards calculation to get more information about the scenario when the app escalates an exposure with low risk to the user (lets call this the _problematic contact_). In the following, I want to share my finding that could be interesting for people who wants to know what a "low risk" contact is and how the application decided if it is "low risk" or "high risk".

Information & Backgrounds

Based on the documentation (Risk Score Calculation and Risk Assessment) your _Total Risk_ value have to exceed the threshold of 11 and can be at most 40. Due to the current expose config it means that this _problematic contact_ was in the last 0-14 days with an attenuation between 0 and 73 dB (distance between ~0-8 meters) and at minimum 10 minutes long with a transmission rate between 3-8.

Furthermore, the _Combined Risk Score_ have to be in [0, 15[ (see Risk Score Classification) to get the low risk status. Therefore, the resulting formular for one positive low risk contact is as follows:

x := Total Risk Score – [11, 40]
y := Exposure Score
z := Combined Risk Score – [0, 15[

z = y * x / 25

Results

After playing around with this and looking at the edge cases, some things follow from this:

It is possible that the _problematic contact_ has a high transmission risk level (x=40, so it could be very infectious). If so, the average distance was more than 1.5 meters and the maximum contact time was 18-19 minutes
If the _problematic contact_ has a lower transmission risk level (x=11), the contact time can be up to ~34 minutes in an average distance less than 1.5 meters or up to ~68 minutes in an average distance greater than 1.5 meters
The range in days between the _problematic contact_ and the days until upload consent granted is 1-6 days

To sum up, you get a low risk notification if your CWA app identifies a contact with a positive COVID-19 person that took place in the area of 1-6 days when the positive test result is granted and it was between 10-68 minutes long in a range between 0-8 meters, depending on the transmission risk level.

mhellmeier on 6 Sep 2020

👀1

@mhellmeier I like your approach. However, while I don't know exactly where the difference comes from, I have to report that I got a "green" notification of 1 low-risk encounter when my Android device had scanned only exactly 1 RPI at 100dB attenuation.
Details about this are here and here.
(Not sure if you have already joined this Slack channel or want to do that, here would be an invitation link.)

mh- on 6 Sep 2020

However, while I don't know exactly where the difference comes from, I have to report that I got a "green" notification of 1 low-risk encounter when my Android device had scanned only exactly 1 RPI at 100dB attenuation.

@mh- I am not an expert on this, but it sounds strange because every contact greater than 73 dB should be irrelevant due to the current gt_73_dbm: 0 setting in exposure-config.yaml.

Perhaps the threshold of 11 for the _Total Risk_ isn't relevant for the low-risk notification!? I don't know, but I am sure that some of the SAP members can help us with this.

mhellmeier on 6 Sep 2020

@mh- @mhellmeier ExposureSummary.matchedKeyCount is not affected at all by CWA configuration, and CWA will report "low risk encounter" whenever this value is greater than zero. gt_73_dbm: 0 and any other risk-score thresholds have no effect here, single RPI (even with > 73dB attenuation) will result in matchedKeyCount = 1, and low-risk encounter in CWA. See https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-679231707

kbobrowski on 6 Sep 2020

👍4

We got an official statement from the Robert Koch Institute:

German

Als Herausgeber der Corona-Warn-App bedankt sich das Robert Koch-Institut für die vielen Rückmeldungen zur Risikostatusanzeige auf dem HomeScreen. Diesem Dank schließen wir uns als Entwicklerteam der App an. Nach Abwägung aller Argumente und in Abstimmung mit dem Bundesministerium für Gesundheit hat das RKI entschieden, die zweistufige Risikodarstellung (grün und rot) beizubehalten.

Die App muss möglichst einfach und allgemeinverständlich in der Anwendung sein. Durch die Unterscheidung von niedrigem und erhöhtem Risiko können den Nutzerinnen und Nutzern auf ihren Risikostatus abgestimmte Handlungsempfehlungen gegeben werden. Die zusätzliche Anzeige von Begegnungen, die bestimmte Kriterien erfüllen, erhöht die Transparenz. Für alle diejenigen, die sich mit der Risikobewertung und ihren Parametern eingehender beschäftigen möchten, haben RKI und Entwicklerteam detaillierte Beschreibungen auf GitHub zur Verfügung gestellt.

Die Texte in der Corona-Warn-App werden wir unter Berücksichtigung Ihres Feedbacks weiter anpassen. Mit einem anstehenden Update werden wir weitere Erläuterungen zum besseren Verständnis der angezeigten Risikobegegnungen geben. Zudem wird geprüft, ob mit einem späteren Update eine Risikobegegnungshistorie in der App dargestellt werden kann.

Auch zukünftig werden wir Anregungen und Vorschläge zur Verbesserung der Corona-Warn-App aufgreifen, diskutieren und, soweit sinnvoll und möglich, umsetzen. Wir freuen uns, wenn Sie sich weiter mit konstruktivem Feedback beteiligen.

English

As the publisher of the Corona-Warn-App, the Robert Koch-Institute as well as the development team would like to thank you for the many feedbacks on the risk status display on the HomeScreen. After weighing up all arguments and in coordination with the Federal Ministry of Health, the RKI has decided to keep the two-level risk display (green and red).

The app must be as simple and generally understandable as possible in its application. By differentiating between low and increased risk, users can be given recommendations for action based on their risk status. The additional display of encounters that meet certain criteria increases transparency. For those who want to take a closer look at risk assessment and its parameters, RKI and the development team have provided detailed descriptions on GitHub.

We will further improve the texts in the Corona-Warn-App and we will continue to listen for feedback of the community. With an upcoming update, we will provide further explanations to help you better understand the risk encounters displayed. In addition, we will check whether a later update will allow a risk encounter history to be displayed in the app.

In the future, we will continue to take up, discuss and, where reasonable and possible, implement suggestions and proposals for improving the Corona Warning App. We would be pleased if you continue to contribute with constructive feedback.

Further text improvements are being introduced in the upcoming hotfix release 1.3.1.

RC1 of 1.3.1 is already available:
https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.3.1-SNAPSHOT-RC1
https://github.com/corona-warn-app/cwa-app-ios/releases/tag/v1.3.1-RC1

Since the decision from the RKI is final, I will close this issue now.

Best regards,
SG

Corona-Warn-App Open Source Team

svengabr on 10 Sep 2020

😕1

We got an official statement from the Robert Koch Institute:

German

Als Herausgeber der Corona-Warn-App bedankt sich das Robert Koch-Institut für die vielen Rückmeldungen zur Risikostatusanzeige auf dem HomeScreen. Diesem Dank schließen wir uns als Entwicklerteam der App an. Nach Abwägung aller Argumente und in Abstimmung mit dem Bundesministerium für Gesundheit hat das RKI entschieden, die zweistufige Risikodarstellung (grün und rot) beizubehalten.

Die App muss möglichst einfach und allgemeinverständlich in der Anwendung sein. Durch die Unterscheidung von niedrigem und erhöhtem Risiko können den Nutzerinnen und Nutzern auf ihren Risikostatus abgestimmte Handlungsempfehlungen gegeben werden. Die zusätzliche Anzeige von Begegnungen, die bestimmte Kriterien erfüllen, erhöht die Transparenz. Für alle diejenigen, die sich mit der Risikobewertung und ihren Parametern eingehender beschäftigen möchten, haben RKI und Entwicklerteam detaillierte Beschreibungen auf GitHub zur Verfügung gestellt.

Die Texte in der Corona-Warn-App werden wir unter Berücksichtigung Ihres Feedbacks weiter anpassen. Mit einem anstehenden Update werden wir weitere Erläuterungen zum besseren Verständnis der angezeigten Risikobegegnungen geben. Zudem wird geprüft, ob mit einem späteren Update eine Risikobegegnungshistorie in der App dargestellt werden kann.

Auch zukünftig werden wir Anregungen und Vorschläge zur Verbesserung der Corona-Warn-App aufgreifen, diskutieren und, soweit sinnvoll und möglich, umsetzen. Wir freuen uns, wenn Sie sich weiter mit konstruktivem Feedback beteiligen.

English

As the publisher of the Corona-Warn-App, the Robert Koch-Institute as well as the development team would like to thank you for the many feedbacks on the risk status display on the HomeScreen. After weighing up all arguments and in coordination with the Federal Ministry of Health, the RKI has decided to keep the two-level risk display (green and red).

The app must be as simple and generally understandable as possible in its application. By differentiating between low and increased risk, users can be given recommendations for action based on their risk status. The additional display of encounters that meet certain criteria increases transparency. For those who want to take a closer look at risk assessment and its parameters, RKI and the development team have provided detailed descriptions on GitHub.

We will further improve the texts in the Corona-Warn-App and we will continue to listen for feedback of the community. With an upcoming update, we will provide further explanations to help you better understand the risk encounters displayed. In addition, we will check whether a later update will allow a risk encounter history to be displayed in the app.

In the future, we will continue to take up, discuss and, where reasonable and possible, implement suggestions and proposals for improving the Corona Warning App. We would be pleased if you continue to contribute with constructive feedback.

Further text improvements are being introduced in the upcoming hotfix release 1.3.1.

RC1 of 1.3.1 is already available:
https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.3.1-SNAPSHOT-RC1
https://github.com/corona-warn-app/cwa-app-ios/releases/tag/v1.3.1-RC1

Since the decision from the RKI is final, I will close this issue now.

Best regards,
SG

Corona-Warn-App Open Source Team

Hi,

Does this mean there will be no more information such as date of contact for green contacts?
This is a pity as I am now considering to remove the app as it is not helping but only worrying....

Thanks

sunny3678 on 10 Sep 2020

👍2

The app is definitely helping, in case you had a high risk encounter. The message from RKI about low risk encounters is: Do not worry about these.

mss1010 on 10 Sep 2020

👍3

Please show Date and Time of later on announced risk contacts, even if this leads to still having a green status.

As such contacts might occur only at shopping or eating in a restaurant, one can reconstruct with Date and Time where one habe been and if shopping or queuing anywhere is the risk reason.

This would enhance the analyse and discussion and avoiding of behavior in the future much, when it ia shown if the risk contact was at 8:00 in the bus ir at 12:00 in the McDonalds restaurant or at work at 10:00 o'clock at a certain date/day.

so it is not about "10 days ago" but about exact time and day.

Thanks for implementing that local showup fast.

webermike on 5 Nov 2020

@webermike

Date: Pleasese see #188 and https://github.com/corona-warn-app/cwa-documentation/issues/433

Exact Time: Not possible, Data Protection, the exact time of an Encounter is not revealed to CWA by the underlying API.

Ein-Tim on 5 Nov 2020

Did some more tests to see what additional information could be extracted with getExposureInformation() method (which is currently not used by CWA). Was running the same experiment as in #23 (comment) but with a fork of CWA where I implemented querying of ExposureInformation.

Corona-Warn-App Notification triggered by querying ExposureInformation Warn-App-Companion

Full information from EN (note that CWA currently only queries ExposureSummary):
ExposureInformation:
  - date: Wed Aug 19 02:00:00 GMT+02:00 2020
  - dateMillisSinceEpoch: 1597795200000
  - durationMinutes: 30
  - attenuationValue: 41
  - transmissionRiskLevel: 6
  - totalRiskScore: 30
  - attenuationDurations: [37, 0, 0]

ExposureSummary:
  - daysSinceLastExposure: 3
  - matchedKeyCount: 1
  - maximumRiskScore: 30
  - attenuationDurations: [30, 0, 0]
  - summationRiskScore: 30
So it would be possible to additionally inform users about exact date (no exact time), duration, distance, and at what transmission risk level interaction with infected person was taking place.

Interestingly it seems that notification is triggered by the call to getExposureInformation(), in the previous experiment I did not receive any notification about exposure. This corresponds to the documentation of EN.

Hello, in the data got via ExposureInformation, there is a timestamp: "date: Wed Aug 19 02:00:00 GMT+02:00 2020" Is this the date of the query or of the exposure, and if the latter, is the time-of-day of any significance or just "dummy"? - Thx.