-
Notifications
You must be signed in to change notification settings - Fork 14
Make Low Risk Exposure display optional #181
Comments
I like your suggestion to keep this feature as opt-in for "power users". |
I was also presented with the information "Low Risk / 1 exposure with low risk" some days ago and even with my technical knowledge of how CWA works, I was still made nervous. If it had told me when this exposure occurred, I might have been able to think back and perhaps reconstruct where I was and what environment I had been in, maybe then thinking about avoiding the situation in future. The information about low risk exposure is non-actionable. I was already abiding by AHA guidelines (Abstand halten, Hygiene beachten & Alltagsmaske tragen). I didn't change my habits based on the new status, so it did not help me. |
Hello @my-tien, thanks for sharing your idea. I have created a JIRA-Ticket and assigned it to the responsible person. Thanks, Corona-Warn-App Open Source Team |
@GPclips @hermesmar Thank you. What is the process after moving the issue to JIRA? Will you keep us updated here? |
@my-tien Yes, by mirroring the issue to Jira it will get tracked by the developers and be discussed with the RKI. Any updates regarding your request will be made available here by the developers or the community team. CH Corona-Warn-App Open Source Team |
@my-tien regarding OP:
I understand your request and the motivation behind it and in an ideal world I'd agree. Unfortunately there is at least one big problem I see with "hiding" those green encounters by default in the real world, let me try to explain: The team from Ireland got even worse results in a real-world tram setup: Conclusion:
i.e. basically all infectious exposures were misclassified as green encounters. Or see this issue on "Impact of shadowing underestimated". As you're familiar with https://github.com/corona-warn-app/cwa-backlog/issues/23 you probably know that there was a suggestion to introduce a yellow risk status for such cases, potentially in combination with an "expert mode" which would show additional details on such encounters, and allow you to configure the threshold for notifications. To quote @kbobrowski:
In a scenario with a yellow risk status and an expert mode + maybe additionally somewhat wider attenuation bucket sizes I'd feel much more comfy even if the default setting would be to hide yellow encounters. Unfortunately this idea has since been rejected by the RKI 🙁. This means we're left with all the problems mentioned above and under such circumstances I'm personally feeling much more comfortable with the idea that some users will get irritated by "non-actionable" information than I am with accepting that the significant share of false-negative encounters will not even provide a slight nudge (e.g. to take hygiene measures especially seriously) for users who left their settings on "default". |
I personally would even go further and say: If there would be one risk class, with more Information, like Date and Time (maybe even the Location) everybody would know where he/she has been and what he/she has done and everyone could make his own Risk assesment.... I know that it is nearly impossible (from technical side [ENF don't expose exact Time or even location] or from data protection) that this will be implemented like ddescribed above, but I still think that the Idea of having the App do a Risk Assecment for the User hast to be overthinked... |
How can an average, nontechnical user (like my mother ... ) make his/her own risk assessment if the app presents a lot of numbers - and that's it? |
While I do agree, that the distinction is quite noisy and the parameters governing this separation are currently not set optimally, I wouldn't go that far. Having some kind of default actionable distinction/information provided to you by the app is probably still an important function for the vast majority of users (like @ndegendogo's mother 😉). And I think even a binary distinction could in principle be made to work quite well, with some parameter tweaking + some additional info in case of any encounter (at least as an option). And while I personally would be happy if ENF exposed exact timestamps for encounters, I can also understand why Google/Apple don't want to do this out of fear of privacy violations and therefore only expose timestamps coarsened to daily intervals. Back in August we had some discussion on exactly this topic on Gitter.
I don't really know that much about other apps, but SwissCovid has also a binary distinction afaik. And my guess would be that this is probably the case for most ENF apps. |
@ndegendogo What is more reliable? (But reading @daimpi's comment again, I think the best would be an Expert Mode and a Normal Mode)
On the second thought, you (and @ndegendogo) are both absolutely right, the most users will need a Assesment done by the App...
Yeah, I also think so, but looking at f.e.: this Twitter Thread reporting that 2 phones from the same person show different Risk "Classes" because one of them was in a bag, this leaves a bad taste and also makes me uncomfortable thinking about my latest and first green Risk Encounter, since my phone is nearly always in my bag...
Thanks for the hint 👍 |
Thanks for all your replies. We can talk about the shortcomings of the Bluetooth service all day. I am well aware of the Ireland study. But what percentage of the population do you assume to be knowledgeable enough about these limitations to make an informed decision? The problem doesn’t go away simply by showing some cryptic low exposure notification. If the expert user feels confident enough to react to the low risk exposure notification, they should also be knowledgable enough to turn it on. The number one priority for design decisions atm should be to increase the user base or at least not to shrink it. |
@my-tien thanks for your reply 🙂
That's not entirely true though, is it? We can currently distinguish three different states in CWA:
And (2) now even has it's own dedicated explanation text which differs from (1) since CWA 1.3.1.
As I said above: imho even a binary color coding could work quite well with some adjustments, I'm not insisting on three colors:
Regarding
I'm all for showing more information to the user (cf. #178, #100) instead of "just some cryptic encounter", and I don't expect the average user to really understand all the limitations that come with any (red or green) encounter. But even in it's current form seeing a green encounter can provide a little nudge to the user, reminding them that the app is working and at the same time calling attention to the hygiene rules which the user should follow especially thoroughly in this case.
In general I agree o/c that higher uptake is an important goal. But it's "just" an instrumental goal in service of the terminal goal: to stop the virus from spreading by breaking chains of infection. And given the current shortcomings of CWA I've described above (mainly the low recall- / high false-negative-rate) I'm afraid that exactly this terminal goal of breaking chains of infection would be compromised if we were to hide green encounters by default. As I said above: if those shortcomings were addressed, I'd feel much more comfy with the idea of hiding green encounters by default. |
If i remember correctly RKI wanted to hide green encounters, but in case there is a green encounter ENF will include this information in weekly summary and in exposure logs, which would be confusing for the user - why there is information about encounter in ENF but not in CWA. I think this is the main motivation of showing green encounters in CWA at all |
well - the new ENF implementation since iOS 13.7 does no longer show these matches. I hope they did not intentional hide this for a similar reason, but that it's 'only' a bug that they will fix. And, yes, I agree, this kind of inconsistency is very confusing and irritating. |
On Android CWA 1.3.1 the string Given that it was decided to continue to show this green low-risk encounter, the text does at least now say, "You do not need to worry". I can understand the logic mentioned by @kbobrowski in #181 (comment) that if a match is showing up in the ENF exposure logs it somehow needs to be dealt with visibly by CWA. Requesting somebody not to worry may however not stop somebody worrying! |
@MikeMcC399 so you think this is not clear enough? What are you missing? |
@ndegendogo Luckily I have not had any more encounters and I'm happily seeing "No exposure up to now" on my phone at the moment. 😃 |
So, today I got my "red" notification. It shows 6 encounters, and latest is 3 days ago. And: yes, tomorrow I will follow the recommendations and get advice from the health authorities (Gesundheitsamt) how to proceed. |
@ndegendogo |
@MikeMcC399 Thanks! Actually, I tried the 116117 today, but the number was completely congested ... after ~1/2 hour I got the line, but at that moment my connection broke down ... |
Dear @GPclips @heinezen @JoachimFritsch , what is the current status of this enhancement request? I think @my-tien made a very good point when she/he says that the information about the low-risk encounters make some users nervous without any need and that this behavior of the app is at risk of shrinking the user base. I know two persons which consider uninstalling the app because of the frequent low-risk encounters. While such a reaction might not be rational, it is very human. Therefore, the implications of these "notifications" about low-risk encounters should be considered. Hiding the low-risk encounters per default is in my opinion a good solution to this problem. Thank you for your great work on the app! |
That's an argument for improving the display of high risk contacts, not for displaying the low risk ones. Actually I think your problem reveals a major flaw of the app, and if the issue doesn't exist yet you should open one. |
There is an Issue for this: corona-warn-app/cwa-documentation#422 |
@Ein-Tim actually, corona-warn-app/cwa-documentation#422 is a slightly different topic. Example 1: lets assume, I have a red 3 days ago, and a green 5 days ago. Then it will show red (correct), and tell me: "2 risk encounters" (although only one was high risk), "last was 3 days ago" (which is again correct). Example 2: now lets assume, I have a red 5 days ago, and a green 3 days ago. It will show red (again, correct), and tell me: "2 risk encounters" (wrong as above), "last was 3 days ago" (although the high-risk was 5 days). Example 1 is focus of this ticket. |
Related requests which would alleviate the situation: |
Actually, no. I wasn’t even aware of the ambiguity problem you talk about. Although it’s an important problem, I think you should rather discuss it in the linked issue, or – if you feel it doesn’t belong there – in a separate issue. This ticket focuses on the usefulness of the low risk encounter for the broader public in general. Let’s keep the discussion here on topic. |
From my own experience, I can report that reporting that you have had one or more low risk encounters, but you don't know when it happened, causes many people to panic and/or brood a lot about when and where it happened. |
Since CWA 1.9.1 and the switch to version 2 of the ENF/ENS very low risk encounters are now dropped by the App and not shown to the user. Thus, the number of low risk encounters shown to the user dropped heavily. |
Hm, what is the difference between low and very low lisk encounters? |
Those very low risk encounters were even under the CWA defined limit for low risk encounters, so they were never supposed to be shown to the user. |
I've never seen a "very low risk" message before. |
Yes. They were all just green. You could not tell whether such a green encounter was a "1-second contact" at large distance, or "just below the threshold to red". |
@my-tien which contains links to: There is also another blog post Risk calculation under Exposure Notification Framework Version 2 with helpful explanations. You can read the second blog post together with lecture slide 18. The slide shows an example of an encounter which is dropped because it does not meet the criteria of attenuation less than 73dB (assumed equivalent to closer than 8m distance) for more than 10 minutes of a 30 minute window, combined with a transmission risk level (TRL) of 3 or more. If the criteria are not met then this is labelled a "non-risk encounter" according to the explanation in the blog. According to https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md "each dB value is associated with a particular distance".
|
Avoid duplicates
Current Implementation
The app shows low risk exposures and suggests the same behavior as in the case of no low risk exposures.
Suggested Enhancement
Hide low risk exposures per default as these can unnerve insecure people to a degree that leads them to uninstall the app. But add an option to turn it on.
Reasoning
I live with a woman in her 60s who received a low risk exposure notification. She was extremely upset by this and checked the app every day since then, hoping that the notification had vanished.
She consulted with me, both of her sons and several friends about this and also read up on it herself.
After all this she was still insecure. She did not understand why a low risk notification is shown when no precautions need to be taken.
Saying that its purpose is transparency, so that people can decide for themselves if they want to be extra careful, did not help. She simply didn’t know how she should decide to be extra careful or not.
When she first brought up the idea of uninstalling the app because it made her anxious, I was able to talk her out of it. But several days later the notification was still there, creeping her out. She made the final decision to uninstall.
Her problem is clearly not a lack of information on the status, rather too much information combined with too much own responsibility and too little confidence on the topic.
Here’s another less anecdotal argument:
Although transparency is a good thing if I can make informed decisions based on it, it is not useful in and of itself. Since time, duration and location of the exposure are not shared due to data protection, there is no information to base a decision on. Hence, the transparency serves no purpose.
If there are reasonable decisions one could make based on the notification alone, such as Refrain from meeting old people or Don’t go to work, they’d be the same for all low risk exposed people and could therefore be added to the behavior guidlines in the app.
Apparently this isn’t the case, so I don’t see the purpose of displaying the exposure at all.
Expected Benefits
Keeping insecure people from uninstalling the app while satisfying the transparency wishes of other people at the same time.
Internal Tracking ID: EXPOSUREAPP-2834
The text was updated successfully, but these errors were encountered: