Cwa-app-ios: Check one day later uses the same distributed keys, but leads to worse risk status

[AnOtherMuenchner]

I am using Corna Warn App on iOS.

The app did one risk evaluation on 2020-09-17 at 22:52, the next on 2020-09-19 at 00:07.

The log "Begegnungsüberprüfungen" on my phone says that both evaluations have been based on the same key set, downloaded from server (Hashed 905748FDD.... to E7B93E90....). I would suppose, the key sets remain unchanged once published. At least at the first view, the hashes seem to be the same.

However:

• The evaluation on 2020-09-17 had shown that everything is ok and that there are no risk contacts.
• The evaluation on 2020-09-19 led to the result that there is one risk contact with low risk (green).

I am wondering if this can be that the same key set leads to an other result one day later. There cannot be any new keys which lead to this result and the old keys from 14 days ago should have been deleted.

The next evaluation today (2020-09-20) had two new key sets (Hash C586B7... and AD521A27...). Now the app shown two risk contacts with low risk (still green).

---

Internal Tracking ID: EXPOSUREAPP-2868

[AnOtherMuenchner]

Some more information: The exposure checks on 2020-09-17 and 2020-09-19 have been done with iOS 13.7. The last evaluation on 2020-09-20 with iOS 14.0.

The exposure check log always shows a match count of 0.

If you need, I could provide a log of the exposure checks for 2020-09-19 and 2020-09-20.

[ndegendogo]

Sounds interesting. I would like to have a look at your ENF logs, so If you don't mind, please provide the file.

As to my understanding, the "raw" number of detected contacts should be always the same for a given key file. The risk score (red /green) could still change, because the detected contacts are then processed through a parametrized formula.
Also every day not a single key file is processed, but all 14 files of the last 14 days.
And unfortunately, iOS 13.7 has a bug and seems to not (not always?) log detected contacts.
See #1106 and here and here

Disclaimer: I am not one of the devs here, only a user.

Edit: added links.

[AnOtherMuenchner]

@ndegendogo

The bug in the exposure log may be. If this is true then it is not only in bug in 13.7. In 14.0 there is also '0' in the logs.

But this is only one part of my bug report.

The other is: when the same set of published keys is checked one or two days later, the number of found exposures shall not increase, but be at least constant or even decrease.

Because: The old keys at the beginning of the 14-day period should be deleted at the second check. And because we are behind the period, there cannot be any new exchanged and recorded keys inside this perion.

[daimpi]

@AnOtherMuenchner could you share your ENF log here, then we can take a closer look at this 🙂.

[ndegendogo]

@AnOtherMuenchner yes. Exactly this is the reason why I am interested to look at your exposure notification logs.
This file does not contain any sensitive personal data. It is json format / human readable, so you can verify yourself which data it contains: the timestamps of the checks, and the key file identifiers (hash and number of keys), and everybody here gets the same files. And, for iOS <= 13.6.1 also the number of matches per file (this last item could be regarded as potentially sensitive).

What I regard as unexpected from your description: did it really check the same set of 14 files on both days?

What I usually watch on my phone: a 'rolling' set of 14 files. Every day a new file, and 13 same as previous day, and the oldest is retired and no longer checked.

[ndegendogo]

Oh, and which version of cwa app are you using?

[thomasaugsten]

Exposure checks after 02:00 CEST on different days should not use the same 14 day files.

[AnOtherMuenchner]

@thomasaugsten

Here are the two json log file. I had to change their type to "txt" since the upload for json-files is not supported.

ExposureChecks-2020-09-20.txt
ExposureChecks-2020-09-19.txt

Exposure checks after 02:00 CEST on different days should not use the same 14 day files.

The checks have been done on 2020-09-17, 22:52 CEST and 2020-09-19, 00:07 CEST. I did not compare all files, but since the hash codes of the first and the last entry are equal I concluded that the same set of files have been used.

[Ein-Tim]

@AnOtherMuenchner
Do you mean how it is described in #1078?

[AnOtherMuenchner]

@Ein-Tim

I do not know if the packages have been downloaded from server once more or if they had been taken from a cache on the mobile.

I do not mind the performance problem. At the moment, my mobile is fast enough. I am wondering why the second check with same reference data on a reduced recorded key set led to a worse check result.

The obvervation was that exactly the same downloaded key packages have been used for exposure checks. I also do not know if this could be correct because no old package has been deleted and no further package had been published at this time. But in this case, I would suggest the same result of the check or a better.

[daimpi]

@AnOtherMuenchner

The app did one risk evaluation on 2020-09-17 at 22:52, the next on 2020-09-19 at 00:07.

Looking at your log (from the 20th), it says that in between the 17th and 19th an additional update was performed on the 18th:

Timestamp |
--- |
2020-09-17 21:38:56 +0200 |
2020-09-18 22:52:51 +0200 |
2020-09-19 00:07:08 +0200 |

I did find the following package which was checked on the 19th but was not present on the 17th:

Timestamp | Hash | MatchCount | KeyCount
-- | -- | -- | --
2020-09-19 00:07:08 +0200 | 905748FDDC3B77A4F0C3DA3C8FFB4135FECAC18A95450D7DA269F5FD5E1852BD | 0 | 11165

If you look the hash up (link) you'll find that it belongs to a person who uploaded their keys on the 17th (i.e. they were available for download from the 18th on). In your log it also says that a check of this package was performed on the 18th.

The thing which is strange is that the MatchCount is 0 for this package, despite your CWA showing an encounter. This is probably the same issue as https://github.com/corona-warn-app/cwa-app-ios/issues/1106.

[AnOtherMuenchner]

Ok. Thank you. I did not notice that there are two calculations which are only separated by 2 hours. Normally there are at least 24 hours between the updates.

[daimpi]

Normally there are at least 24 hours between the updates.

Yes.

Were those automatic updates or did you trigger them manually? If you trigger updates manually and you want the freshest data I'd recommend triggering your updates at 02:15 CEST. At this time the new daily package containing all the keys from the ppl who uploaded the day before should be available on the server 😉.

[ndegendogo]

@AnOtherMuenchner and if you didn't trigger manually the check on 19 Sept (after only two hours instead of 24+), it might perhaps be related to #1141 - although I did not see any exceptional pattern (overly long delay) before this in your files.

[AnOtherMuenchner]

@AnOtherMuenchner and if you didn't trigger manually the check on 19 Sept (after only two hours instead of 24+), it might perhaps be related to #1141 - although I did not see any exceptional pattern (overly long delay) before this in your files.

I opened the app at this time and this open lead to an update of data.

[daimpi]

I opened the app at this time and this open lead to an update of data.

That's actually quite interesting. On Android a new update is only performed if no update has been conducted on the current UTC day. This means that if an update was performed on day 1 the next update will only happen after 2am CEST on day 2 even if I open CWA before that.

@thomasaugsten is this divergence in behavior between Android and iOS intentional and if not: are you planing to bring the iOS behavior in line with Android?

[heinezen]

Hey everyone,

I've created a Jira ticket (EXPOSUREAPP-2868) for this issue so that the developers are notified and can determine if this bug is related to #1106 or is something new.

Thanks again for your input,
CH

---

Corona-Warn-App Open Source Team

[Ein-Tim]

I think this can be closed, IIUC @daimpi already "solved" this riddle a while ago.

[dsarkar]

@AnOtherMuenchner and community. Thanks for contributing here. We suggest closing this ticket now. Best wishes, DS

---

Corona-Warn-App Open Source Team