Make increased risk notifications more fail-safe

[Ein-Tim]

Prologue

I wrote with multiple users (both on iOS as well as on Android) on Twitter who told me that they did not receive a push notification, although they had a high risk contact.
They all discovered this high risk contact "by accident" because they opened the app.

Current Implementation

It seems like there is a chance that the risk check "detects" a high risk and the status in the app changes accordingly, but the push notification which should be send to the user isn't sent.

Suggested Enhancement

Make the high risk notifications more fail save, improve the background task which schedules them, add additional logging to investigate the issue, etc.

Expected Benefits

Users really receive the (promised!) push notification if they were in close contact with a later positive tested person.

Additional information

Feel free to discuss here and bring up ideas why the high risk notifications aren't sent sometimes and share your ideas how to improve this.

[MikeMcC399]

@Ein-Tim
This is possibly related to the notifications setting and display of its status.

corona-warn-app/cwa-documentation#611

[Ein-Tim]

@MikeMcC399

That's a good hint, thank you! I'll ask the users whether they have this setting active or not.

[thomasaugsten]

To analyze the situation we need more information about the Mitteilung settings, the used OS version.
The ENF log to see when the exposure check with the risk was done and when the user opens the app.

[Ein-Tim]

@thomasaugsten

Notification are active everywhere (CWA settings as well as iOS settings), it was on CWA 2.8 and under iOS 14.7.1.

I think the problem isn't the one case here, there were min. 5 Twitter users with very different environments which told me this. This issue isn't a bug report but rather a request to make sure that the notifications work correctly in different scenarios and to improve their stability.

However, I'll ask the next Twitter user with this problem for the information you requested.

[thomasaugsten]

iOS calls the app minimum once per day to reactivate the background job which is normally triggered every 4h. This is the highest priority an app can get on iOS. On mobile data 1x per day and on wifi every 4h runs a risk check. When you open the app a risk check will executed this can lead to a risk card without a notification.

[Ein-Tim]

@thomasaugsten

The case you mentioned (open app & risk check is carried out) wasn't what happened to the Twitter user, he told me the app was in the background (not swiped away from the app switcher) and after he opened it it instantly showed him the red risk card.

[MikeMcC399]

@Ein-Tim
Would you like to change the word in the title to "fail-safe"? The word "save" doesn't fit here.
https://dictionary.cambridge.org/dictionary/english/fail-safe

[Ein-Tim]

@MikeMcC399

You're absolutely right, thanks (:

Changed the title.

[pkreissel]

@Ein-Tim This could also be caused by the fact that CWA checks for risk status when you open the app. So if you open the app just right before the notifications-job would have run anyways then you will see the risk status as red, but won't receive a notification.

[ndegendogo]

@pkreissel Yes. And here a deeper analysis of the ENF/ENS log would give more insights. It would show at which time the new risk encounter was discovered: just now, or some time before?
Although, with iOS this analysis must be done by the user himself, because this information is suppressed from the exported ENF log (not sure about Android current behaviour)

[Ein-Tim]

@thomasaugsten

Only today 3 users reported missing high risk notifications... I really wonder what's going on here. Aren't they send instantly if the app detects an high risk encounter?

2x Android & 1x iOS user.

[thomasaugsten]

It's sends immediately but depending on the device setups a detection can also only runs once per day

[Ein-Tim]

@thomasaugsten Okay... So there's probably no way to really improve this from our side... Sad...

[Ein-Tim]

With more and more users receiving increased risk warnings, more and more report that the app does not send them a push notification.
Is there really no way to improve this?
The problem here isn't that no background risk checks are done, but that an risk check which detects an high risk encounter does not trigger the push notification reliably!

[thomasaugsten]

If the device has enoug background time to do a risk check then the user will receive a notification. I think the user opens the app manually before the next background check and sees then a warning without notification. You can easily check this with the exposure check logs of the OS. Where you can see the timestamps and the number of matched keys

[Ein-Tim]

@thomasaugsten I will investigate the next case I see a bit closer, as you suggested!

[Ein-Tim]

@thomasaugsten

So, here we go: https://twitter.com/cedhoyer/status/1462013717541965830?s=21
I asked whether the app did update in foreground, he said no, the update took place at 08:14, where the user still slept.
He did not get a high risk notification & only saw the increased risk because he opened the app.

Are you sure this can't be improved in any way?

[thomasaugsten]

But we still need more information in this case. What device and what are the notification settings when the user is a sleep. A exposure check log is also helpful topfet sure the 8:14 check was really the red warning check

[Ein-Tim]

I asked for the requested information.

[ndegendogo]

A exposure check log is also helpful topfet sure the 8:14 check was really the red warning check

As far as I understand, the exported ENF file (Edit: for iOS) does no longer contain the number of matches.
Only the user himself can see this information if he looks at the ENF log file.

@Ein-Tim if possible, try to guide this user through his ENF logs... and actually, this will still be hard to prove univocally, because there might be other matches that cwa ranks as green or as negligible ...

Edit: @Ein-Tim if possible try to find out first if the user has iOS or Android - because, as @MikeMcC399 points out correctly, this has an impact on the details of implementation and trouble-shooting ...

[MikeMcC399]

@Ein-Tim

This wishlist item has become more of a bug report and troubleshooting thread. The mechanisms, tools and troubleshooting steps available are different in iOS and Android, so I would suggest opening two separate bug issues, one in iOS issues and the other in Android issues.

For instance, I don't know if the comment:

As far as I understand, the exported ENF file does no longer contain the number of matches.

from @ndegendogo was referring to iOS or to Android. Certainly in Android the exported Google COVID-19 Exposure Notifications > Exposure checks > Export exposure checks does include the field "Number of matches", although it will not tell you if CWA then judged this to be a "red" or a "green" exposure.

[ndegendogo]

@MikeMcC399 sorry, I was indeed not aware that this ticket is for both systems.
Yes, of course, my comment applies especially to iOS (for Android I simply don't know).

[Ein-Tim]

@MikeMcC399

As I myself, am not affected by this bug, it's hard for me to open an issue with sufficient technical details in the specific repositories.
This issue is meant to be as general as possible, as the Twitter reports show us that there is indeed a problem & that the developers should take a look at it & improve the high risk notification.

I often asked users on Twitter for more information, however, most are not willing / don't have the technical ability to provide the information (even with step by step guides I sent them).

So, if I should ever have enough information to create a bug report, I will definitely do so.

Have a nice evening!

[Ein-Tim]

I consider this as fixed/implemented and I'll close this issue now.