App is missing information about "Risikobegegnung" with green risk status

[hagct]

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.

What is missing

Information about the calculation of the risk score in the app

Why should it be included

more information for the end users, so he can make a decision, what to do next.

Where should it be included

in the app and also in the dokumentation on Github.

---

Internal Tracking ID: EXPOSUREAPP-2055, EXPOSUREAPP-1971

[MikeJayDee]

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.

[mh-]

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.

[monikaschmitt]

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

[mrcswb]

@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.

[tkowark]

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

[dideldei]

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."

[mrcswb]

@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.

[tkowark]

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

[tkowark]

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]

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>.

[mrcswb]

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]

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]

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

[benzman81]

I opend a bug because of this misleading information here: corona-warn-app/cwa-app-ios#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?

[tkowark]

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.

2. 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

[benzman81]

@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]

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

[rosaminimax]

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?

[MikeJayDee]

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).

[daimpi]

@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. #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.

[mh-]

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.

[tkowark]

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

[daimpi]

Related: corona-warn-app/cwa-wishlist#100

[akuckartz]

@tkowark

The team is now actively working on improving these screens.

Any news?

[prodigy]

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.)

[Ein-Tim]

@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.

[irieger]

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?

[kbobrowski]

@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

[Ein-Tim]

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. [...]

[irieger]

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?

[mss1010]

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?

[mh-]

@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.

[esscue23]

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]

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).

[mh-]

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.

[Ein-Tim]

@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)?

[mh-]

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

[Ein-Tim]

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

[kbobrowski]

@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.

[mhellmeier]

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.

[mh-]

@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.)

[mhellmeier]

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.

[kbobrowski]

@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

[svengabr]

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

[sunny3678]

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

[mss1010]

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.

[webermike]

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.

[Ein-Tim]

@webermike

Date: Pleasese see #188 and #433

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

[dominiklenne]

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.

[mh-]

@dominiklenne as you can see, it is set to midnight UTC, which is not the actual time of the exposure. The ENF does this on purpose.

[dsarkar]

FYI corona-warn-app/cwa-wishlist#178