Update to 1.5.0 turns 7 day old high risk encounters to low risk

[fabboe]

Since Sunday (Oct 18) I had a five risk encounters shown, last one 7 days ago. High risk. This morning just before updating the app as well.

After updating now to iOS 1.5.0 (iOS 14.0.1 unchanged) there was a new sync and suddenly I have only five low risk encounters.

The high risk encounter was outside of Germany between to German CWA/phones. It was in a country that's not yet listed as participating.

No more high risk. Bug? Feature?

Or was the previous high risk a bug?
I don't think so, since I know the person who entered a positive test and our (actual high risk) encounter matched the previous app information.

1.5.0 touched risk scoring in at least these PRs: #1137 #1060 #1265 #1162

---

ENF logs:

https://pastebin.com/f027GYK1
https://pastebin.com/9mDZiQkz

---

Internal Tracking ID: EXPOSUREAPP-3402

[heinezen]

Hey @fabboe ,

Thanks for reporting the issue. Could you provide the ENF logs for us? This would help us to better investigate your problem.

Thanks,
CH

---

Corona-Warn-App Open Source Team

[fabboe]

Sure: https://pastebin.com/f027GYK1

[daimpi]

@fabboe
Thanks for sharing 🙂.

@heinezen unfortunately it doesn't look like we will be able to learn anything from the log as all the entries have "MatchCount" : 0 i.e. issue #1106 🙁.

[norbertschuler]

I also had the problem that yesterday my app warned me about a high risk encounter (red screen) about 2 days ago, but today after the update the app shows again only low risk encounters (green screen). Unfortunately I have only the export of the matching of today, where all MatchCount values are zero. Is it possible to trigger a match manually or do I have to wait for another test until the app triggers another match tonight?

Yesterday:

Today:

(The technical hotline could not answer the question about the difference between yesterday and today.)

Update: I updated to iOS 14.1 today as well. Curious to see my match results tonight.

[Ein-Tim]

@fabboe
Could you update to iOS 14.1, this should solve the Problem with the 0s in the EN-Log, and share your log again after the first check on iOS 14.1 was done? Thanks!

[daimpi]

@norbertschuler thanks for reporting. Great that you're now on iOS 14.1 👍. Could you also share your EN log here after your CWA sync tonight?

[fabboe]

Updated to 14.1 and it synced right afterwards: https://pastebin.com/9mDZiQkz

Match count now matches number of encounters in app. Hope that helps.

[daimpi]

@heinezen I do think there is something fishy going on here… the sudden change of risk right when updating to CWA 1.5 is a bit too unlikely especially as the number of encounters stayed exactly the same… unfortunately @fabboe number of contacts went now down by one, but right after the update it was still at five…
Take this together with @norbertschuler's report and this just being a coincidence gets increasingly unlikely.

For a coincidence both of them would have to phase out an old high-risk contact and replace it with a new low risk one right at the time when they updated to CWA 1.5, that sounds extremely improbable. It's imho much more likely that something in the risk calculation changed… Question would o/c be whether the new calculation or the old one was working correctly.

I think it would be good to have some devs look into this to get more clarity on this issue.
We will also not be able to deduce much more from the EN logs we can get now b/c all the entries before the update to iOS 14.1 will have 0 matches and the iOS update only happened after the CWA update.

[fabboe]

In theory I have still three more days to phase out of the previous high risk encounter.

Also I asked the high risk encounter whether they removed the positive test result from the app - they didn't.

In the pool of high-risk encounters of the very same positive test there's at least one more such example - turned green.

In these times the risk scoring should become more conservative - not less :)

[daimpi]

I took a closer look at @fabboe's log. Here is a potentially interesting output:

Timestamp	Hash	MatchCount	KeyCount
18.10.2020 13:45	254DA0EF8CE9A49480B686D6E7A26C8B9A5471BEC8B694FD5CF00866D29EAE15	0	16674
19.10.2020 13:52	F9073A1268C72E6C93884F761E27066E9455BCFC0EFDB5068EA8C0BAAF1E098E	0	16674
20.10.2020 13:59	F9073A1268C72E6C93884F761E27066E9455BCFC0EFDB5068EA8C0BAAF1E098E	0	16674
21.10.2020 15:56	F9073A1268C72E6C93884F761E27066E9455BCFC0EFDB5068EA8C0BAAF1E098E	4	16674

I filtered for KeyCount = 16674 as the package with this number of keys today contained the matches. As expected MatchCount is zero for the previous days b/c of the iOS bug pre 14.1.

But there is one interesting observation: the hash for what is highly likely the same package changes between 18th and 19th i.e. the hash for the package changed with the update to CWA 1.5 even though KeyCount stayed the same.

One thing which came to my mind in this context: federation roaming was introduced together with CWA 1.5 could there be some connection?

Also: the hash for the package on the 18th can be found here and as expected is timestamped 2020-10-17. The new hash is not listed there (this actually applies for all the hashes in the log from after the update to CWA 1.5 which I spot checked).

[norbertschuler]

But there is one interesting observation: the hash for what is highly likely the same package changes between 18th and 19th i.e. the hash for the package changed with the update to CWA 1.5 even though KeyCount stayed the same.

I can confirm a change in the hash values for the files with the same amount of key counts between "Timestamp" : "2020-10-21 01:33:30 +0200" and "Timestamp" : "2020-10-20 00:42:00 +0200" and all exposure checks before in my exported file: ExposureChecks-2020-10-21.json.zip

[daimpi]

@norbertschuler thanks for sharing, looking forward to your new log with iOS 14.1 🙂.

[Ein-Tim]

Hey @daimpi

This is the Screenshot of the EN-Log before the Update to Version 1.5.0:

---

And this is a Screenshot of the EN-log after the Update to Version 1.5.0:

As you can see all Hash Names changed and also these are not the same which are shown here...

@thomasaugsten Can you confirm that this Behaviour is planed and that there is nothing which did go wrong with the update?

[ndegendogo]

Can it be a change on the server side? E.g. different risk parameters, or the risk values associated with the keys?

[daimpi]

@ndegendogo

Can it be a change on the server side? E.g. different risk parameters, or the risk values associated with the keys?

At least the config parameters for CWA seem not to have changed. The most recent changes there were conducted mid of September.

[norbertschuler]

My todays matching (on iOS 14.1 with app version 1.5.0 (8)) shows 10 low risk results (one less then before) and still no more high risk in the exported exposure checks, e.g. for the timestamp "Timestamp" : "2020-10-22 03:26:41 +0200" the following file:

        {
          "Hash" : "3908E8EF3DE421C31CD585B8CBAFCEA7D54C21BF94E5E690A477AEE217E8B95A",
          "MatchCount" : 10,
          "KeyCount" : 4814,
          "AppBundleIdentifier" : "de.rki.coronawarnapp",
          "Timestamp" : "2020-10-22 03:26:43 +0200"
        },

which by the way had no match count yesterday at "Timestamp" : "2020-10-21 01:33:30 +0200":

        {
          "Hash" : "3908E8EF3DE421C31CD585B8CBAFCEA7D54C21BF94E5E690A477AEE217E8B95A",
          "MatchCount" : 0,
          "KeyCount" : 4814,
          "AppBundleIdentifier" : "de.rki.coronawarnapp",
          "Timestamp" : "2020-10-21 01:33:32 +0200"
        },

and a different hash the day before at "Timestamp" : "2020-10-20 00:42:00 +0200":

       {
          "Hash" : "668843EBFF9C6F67797D21091C025E117DB8831CD9019B66D9BC82E00F25A0D0",
          "MatchCount" : 0,
          "KeyCount" : 4814,
          "AppBundleIdentifier" : "de.rki.coronawarnapp",
          "Timestamp" : "2020-10-20 00:42:03 +0200"
        },

Here is my exported file: ExposureChecks-2020-10-22.json.zip

[fabboe]

@norbertschuler was your device in Germany during the risk encounters and during the recent matching?

Just to rule out that this is a corner case due to introduction of roaming (my risk encounters were outside of Germany, with another German device). If I recall correctly the roaming prefixes the keys/hashes with a current-country-specific part - this could explain the changed hashes.

[norbertschuler]

@norbertschuler was your device in Germany during the risk encounters and during the recent matching?

In my case I have been in Germany in my home town all the time.

[ndegendogo]

which by the way had no match count yesterday

@norbertschuler on which day did you update to iOS 14.1?
Because previous iOS versions since 13.7 had a bug and did not show the matches in ENF log (json). See #1106 for details

[norbertschuler]

which by the way had no match count yesterday

@norbertschuler on which day did you update to iOS 14.1?
Because previous iOS versions since 13.7 had a bug and did not show the matches in ENF log (json). See #1106 for details

Ok, that's an explanation as I updated yesterday (2020-10-21 after the nightly matching job) to iOS 14.1, so only the ENF log of today is showing match counts.

[daimpi]

@norbertschuler

the package you matched with (pre 1.5 hash: 668843EBFF9C6F67797D21091C025E117DB8831CD9019B66D9BC82E00F25A0D0) contains keys uploaded 2020-10-18 only one day after @fabboe's package. Both are right around the time when the padding multiplier on the server was dropped to 1… and also this is the timeframe when federation roaming was introduced 🤔.

@fabboe the keys from federation roaming look the same as those from the Germany at least once they are distributed by the national servers:

Looked at a downloaded German CWA server key file, there’s no way to distinguish the keys by country.

(via @mh-)

@heinezen I think you can remove the "further input needed" label… We probably now have all the info we can get and need someone familiar with the changes on the server and CWA side to investigate this.

[heinezen]

@daimpi @norbertschuler @fabboe

Yes, looks like the devolopers can take over. Thanks for all the input. It's mirrored to the internal Jira now (ticket ID: EXPOSUREAPP-3402), so the devs can pick it up.

CH

---

Corona-Warn-App Open Source Team

[Ein-Tim]

@fabboe I think we should consider if this Issue can be closed now since I think the number of users updating from version 1.3 to 1.5 isn't very high anymore.
But for sure it's up to you and the Open Source Team to decide (cc @dsarkar)

[fabboe]

The specific issue can be closed indeed. Up to the dev team to decide investigating the underlying problem that might reappear under different issues.