[Discussion] Why is "Matches Count" reduced from 2 to 1 to 0?

[ArgentinaRDX]

Dear all,

I am using "Corona-warn-app" in Germany and have a question about the "matches count" in json file.

For me, the key count "12457" popped up intially on Sep 27 and "Matches count" showed 2. I think it means that I had met 2 confirmed cases someday before and they used one account to confirm the infections (at that time the total exposures for me was 4, together with two other encounters). However, on Oct 1 this "Matches count" was reduced to 1 and the total exposures was also decreased to 3. Then, this morning, the "Matches count" with 12457 is reduced to 0 and my total exposures also becomes 2.

I am wondering what it means with the change of "Matches count"? Does it means that these two cases gradually recovered and then should not be taken into account? Or they misreported? Or some bugs here?

Thanks in advance for your help ;)

Best wishes,

[daimpi]

Hi @ArgentinaRDX,

matchesCount drops as soon as the the encounter which lead to a particular match lies more than 14 days in the past because your phone only retains data for the last 14 days: https://www.coronawarn.app/en/faq/#traceback

[ArgentinaRDX]

Hi @daimpi ,

Thanks for your reply. However, I still have two questions:

1. For me, these two encounters match with the same "KeyCount" 12457. The first match disappeared on Oct 1, the second one drops today. Does it mean that I met this guy twice on two different days, such as on Sep 14 and Sep 16 in the office? I initially thought it means that I had met 2 confirmed cases someday before and they used one account to confirm the two infections.

2. Still considering this "KeyCount" 12457, although the matches have disappeared, the information is still kept here. Does it mean that the information will remain more than 14 days, but the checks of the matching will only be done within 14 days?

Thanks for your help 👍

Hi @ArgentinaRDX,

matchesCount drops as soon as the the encounter which lead to a particular match lies more than 14 days in the past because your phone only retains data for the last 14 days: https://www.coronawarn.app/en/faq/#traceback

[daimpi]

Could you upload your log file here (put it in a .zip archive or rename the ending from .json to .txt) that would make it easier to check :).

[ArgentinaRDX]

Hi @daimpi,

Please see the file as below. Really appreciate for your help ;)
all-exposure-checks.txt

Could you upload your log file here (put it in a .zip archive or rename the ending from .json to .txt) that would make it easier to check :).

[daimpi]

Thanks, I've put your (slightly adjusted) log into EN analyzer and got the following output:

From this I gather that you should have seen the following in your CWA:

Date	Displayed Number of Encounters in CWA
24. Sep (and before)	0
25. Sep	1
26. Sep	1
27. Sep	4
28. Sep	4
29. Sep	4
30. Sep	4
01. Okt	3
02. Okt	3
03. Okt	2

Does this sound plausible to you?

Regarding

1. For me, these two encounters match with the same "KeyCount" 12457. The first match disappeared on Oct 1, the second one drops today. Does it mean that I met this guy twice on two different days, such as on Sep 14 and Sep 16 in the office? I initially thought it means that I had met 2 confirmed cases someday before and they used one account to confirm the two infections.

Assuming both keys were uploaded on the same day, you can in general not reliably know whether you encountered two different persons on two days or the same person, as the only thing which identifies them is their Temporary Exposure Key (TEK), which changes every 24h and is random i.e. meeting person A on day x and Person B on day x+1 looks identical to meeting person A on day x & x+1. In both cases you'd see 2 matches in your log which are reduced to 1 match on day x+15 and to 0 on day x+16.

In your case this entry looks only slightly different:

In this case there are two days between the two encounters. This could mean that this are two different ppl who both uploaded their keys on the Sept 25th or it could also be just one person. The only thing we can say for certain is that the first encounter happened on the Sept 16th and the 2nd on Sept 18th.

2. Still considering this "KeyCount" 12457, although the matches have disappeared, the information is still kept here. Does it mean that the information will remain more than 14 days, but the checks of the matching will only be done within 14 days?

Afaik the matches disappear because your phone matches the keys it downloaded from the server with the Rolling Proximity Identifiers (RPIs) which it recorded from contact with other phones and those RPIs will be deleted if they're older than 14 days, after which your phone will no longer find a match.

Your log always shows what checks have been performed in the last 14 days (each of these days, 14 packages for the previous 14 days are checked, which should yield a total of 196 checks, but it shows slightly more checks b/c of a Google bug: #1020 ^^)

As you can see above the package with "KeyCount" 12457 contains keys uploaded on Sept 25th therefore it will continued to be checked till it's 14 days old i.e. until Oct 09th.

[daimpi]

One thing I found curious in your EN log: your timestamps were in a different format compared to what I'm used to and how they look like in my log. Compare e.g. an entry from Oct 03rd:

• You: timestamp":"2020.10.3 09:40
• Me: timestamp":"3. Oktober 2020, 02:54

Could you let me know

1. Which ENF version you have on your phone? (See here for a description on how to find your ENF version)
2. Which language/country settings you use in Android.

[ArgentinaRDX]

Hi @daimpi,

I check that my ENF is 17203704005, I guess meaning that I am using Version 1.5.

Sorry that this may be a confusion caused by myself. My language setting is Chinese in Android, therefore my corona-warn-app is in English. When I download the log file, the date format is "year-month-day" together with Chinese characters in-between. In order to not confuse you, I replace all the Chinese characters with "." and that's why you see this weird format.

Best,

One thing I found curious in your EN log: your timestamps were in a different format compared to what I'm used to and how they look like in my log. Compare e.g. an entry from Oct 03rd:

* You: `timestamp":"2020.10.3  09:40`

* Me: `timestamp":"3. Oktober 2020, 02:54`

Could you let me know

1. Which ENF version you have on your phone? (See [here](https://www.coronawarn.app/en/faq/#ENF_version) for a description on how to find your ENF version)

2. Which language/country settings you use in Android.

[ArgentinaRDX]

Hi @daimpi ,

Thanks a lot for your detailed explanation! That's really helpful :)

Now I have totally solved my second question and understood part of the mechanism behind. Regarding the posts you shared with me, I think it shows that Google may store 17-day history in my phone (maybe it is a bug, but it is the case for me which can be seen from the log file I uploaded). However, when the app does the exposure checks, it will only compare with the data within 14 days online. In other words, there is always no exposures on the 15th, 16th and 17th day ago in the log file. Is that correct?

One more question about this "14-day": is today excluded? From your analysis, since my first encounter disappeared on Oct 1 and the second one disappeared on Oct 3, it means that my first encounter should be on Sep 16 and second on Sep 18. Satistically it makes sense, however for me, it doesn't. If my memory is correct, I stayed at home for the whole day on Sep 18, so the chance of encounter should be very low. On the other hand, if today is not excluded when counting this "14-day", then my two encounters should be on Sep 17 and Sep 19, which is much more plausible for me. That's why I am curious about how to count this "14-day" ;)

Anyways, many thanks for your help. Have a nice Sunday!

Best,

Thanks, I've put your (slightly adjusted) log into EN analyzer and got the following output:

From this I gather that you should have seen the following in your CWA:
Date Displayed Number of Encounters in CWA
24. Sep (and before) 0
25. Sep 1
26. Sep 1
27. Sep 4
28. Sep 4
29. Sep 4
30. Sep 4

1. Okt 3
2. Okt 3
3. Okt 2

Does this sound plausible to you?

Regarding

1. For me, these two encounters match with the same "KeyCount" 12457. The first match disappeared on Oct 1, the second one drops today. Does it mean that I met this guy twice on two different days, such as on Sep 14 and Sep 16 in the office? I initially thought it means that I had met 2 confirmed cases someday before and they used one account to confirm the two infections.

Assuming both keys were uploaded on the same day, you can in general not reliably know whether you encountered two different persons on two days or the same person, as the only thing which identifies them is their Temporary Exposure Key (TEK), which changes every 24h and is random i.e. meeting person A on day x and Person B on day x+1 looks identical to meeting person A on day x & x+1. In both cases you'd see 2 matches in your log which are reduced to 1 match on day x+15 and to 0 on day x+16.

In your case this entry looks only slightly different:

In this case there are two days between the two encounters. This could mean that this are two different ppl who both uploaded their keys on the Sept 25th or it could also be just one person. The only thing we can say for certain is that the first encounter happened on the Sept 16th and the 2nd on Sept 18th.

1. Still considering this "KeyCount" 12457, although the matches have disappeared, the information is still kept here. Does it mean that the information will remain more than 14 days, but the checks of the matching will only be done within 14 days?

Afaik the matches disappear because your phone matches the keys it downloaded from the server with the Rolling Proximity Identifiers (RPIs) which it recorded from contact with other phones and those RPIs will be deleted if they're older than 14 days, after which your phone will no longer find a match.

Your log always shows what checks have been performed in the last 14 days (each of these days, 14 packages for the previous 14 days are checked, which should yield a total of 196 checks, but it shows slightly more checks b/c of a Google bug: #1020 ^^)

As you can see above the package with "KeyCount" 12457 contains keys uploaded on Sept 25th therefore it will continued to be checked till it's 14 days old i.e. until Oct 09th.

[daimpi]

I check that my ENF is 17203704005, I guess meaning that I am using Version 1.5.

Sorry that this may be a confusion caused by myself. My language setting is Chinese in Android, therefore my corona-warn-app is in English. When I download the log file, the date format is "year-month-day" together with Chinese characters in-between. In order to not confuse you, I replace all the Chinese characters with "." and that's why you see this weird format.

I see, thanks for the additional info 🙂. This means the language setting explains how the timestamp format came to be, as we're both actually on the same ENF version (17203704005 i.e. v.1.7).

I'll forward this info to @felixlen who is the author of the amazing EN analyzer tool which I used extensively above 🙂.

[daimpi]

Hey @ArgentinaRDX

However, when the app does the exposure checks, it will only compare with the data within 14 days online. In other words, there is always no exposures on the 15th, 16th and 17th day ago in the log file. Is that correct?

Yes this is correct.
But we have to distinguish between two different points in time:

• let x be the day at which a infected person who you were in contact with uploads their keys.
• let y be the day at which the encounter with the infected person actually happened

Because of some current limitations (no same-day DKs) x - y >= 1 day

If everything works correctly CWA should hand the packages for the last 14 days [x-13..x] (inclusive brackets) over to ENF on day x+1. This means package x will be checked for the last time on day x+14, but not anymore on day x+15. This is something you can easily verify yourself: all packages are uniquely identified by their hash and you can look up here which hash belongs to which day (for Android hashes you have to remove the escape characters (\) and convert them from Base64 to hex first).

You can e.g. see that the Android EN log hash kFdI/dw7d6Tww9o8j/tBNf7KwYqVRQ19omn1/V4YUr0= belongs to the key package from Sept 17th which means it could be checked for the first time on Sept 18th and the last day it was checked is Oct 1st.

But because the actual encounter always happened before the keys are uploaded, you will always have a time period in which the package is still checked by ENF, but the RPI your phone recorded is already deleted and therefore you see matchCount going to zero.

One more question about this "14-day": is today excluded? From your analysis, since my first encounter disappeared on Oct 1 and the second one disappeared on Oct 3, it means that my first encounter should be on Sep 16 and second on Sep 18. Satistically it makes sense, however for me, it doesn't. If my memory is correct, I stayed at home for the whole day on Sep 18, so the chance of encounter should be very low. On the other hand, if today is not excluded when counting this "14-day", then my two encounters should be on Sep 17 and Sep 19, which is much more plausible for me. That's why I am curious about how to count this "14-day" ;)

I'm not entirely sure tbh. My understanding so far was that RPIs are phased out in the same way as TEKs i.e. when the day of their validity (in UTC time) lies more than 14 days in the past. E.g. a RPI recorded on Sept 15 would still show up as a match on Sept 29, but not anymore on Sept 30 b/c it got deleted at the beginning of Sept 30 (UTC time). But I could be wrong about this. @kbobrowski @mh- do you by chance know how exactly this works?

[ArgentinaRDX]

Hi @daimpi !

Thanks very much for all your answers. I tried to understand them, and all are in such a detail. I really appreciate for all your helps here.

Just want to add one thing about the last point where you are also not so sure. Depending on what my data show and the memory of what I could recall, I guess that it may be based on what time the server update the new keys. For instance, if everyday at 14:00 the server upload all the keys containing all the new information, then within the next 24 hours what we can check are all those keys. If I open my cwa at 10am on Sep 30, the data that will be checked are uploaded on Sep 29 at 2pm which contain the information from Sep 15, 2pm to Sep 29, 2pm (14*24 hours). This is a bit contradicted to your words, however, if we change the time that the server makes the update to midnight, then all match with your answers. However, if they follow the strict rule to delete all the data that are more than 14 days old, then you will be right. Anyways, as I said, I am just curious about it :)

Hope everything goes well with you in this special period! Wish all the best.

Hey @ArgentinaRDX

However, when the app does the exposure checks, it will only compare with the data within 14 days online. In other words, there is always no exposures on the 15th, 16th and 17th day ago in the log file. Is that correct?

Yes this is correct.
But we have to distinguish between two different points in time:

* let x be the day at which a infected person who you were in contact with uploads their keys.

* let y be the day at which the encounter with the infected person actually happened

Because of some current limitations (no same-day DKs) x - y >= 1 day

If everything works correctly CWA should hand the packages for the last 14 days [x-13..x] (inclusive brackets) over to ENF on day x+1. This means package x will be checked for the last time on day x+14, but not anymore on day x+15. This is something you can easily verify yourself: all packages are uniquely identified by their hash and you can look up here which hash belongs to which day (for Android hashes you have to remove the escape characters (\) and convert them from Base64 to hex first).

You can e.g. see that the Android EN log hash kFdI/dw7d6Tww9o8j/tBNf7KwYqVRQ19omn1/V4YUr0= belongs to the key package from Sept 17th which means it could be checked for the first time on Sept 18th and the last day it was checked is Oct 1st.

But because the actual encounter always happened before the keys are uploaded, you will always have a time period in which the package is still checked by ENF, but the RPI your phone recorded is already deleted and therefore you see matchCount going to zero.

One more question about this "14-day": is today excluded? From your analysis, since my first encounter disappeared on Oct 1 and the second one disappeared on Oct 3, it means that my first encounter should be on Sep 16 and second on Sep 18. Satistically it makes sense, however for me, it doesn't. If my memory is correct, I stayed at home for the whole day on Sep 18, so the chance of encounter should be very low. On the other hand, if today is not excluded when counting this "14-day", then my two encounters should be on Sep 17 and Sep 19, which is much more plausible for me. That's why I am curious about how to count this "14-day" ;)

I'm not entirely sure tbh. My understanding so far was that RPIs are phased out in the same way as TEKs i.e. when the day of their validity (in UTC time) lies more than 14 days in the past. E.g. a RPI recorded on Sept 15 would still show up as a match on Sept 29, but not anymore on Sept 30 b/c it got deleted at the beginning of Sept 30 (UTC time). But I could be wrong about this. @kbobrowski @mh- do you by chance know how exactly this works?

[daimpi]

@ArgentinaRDX glad I could help 🙂.

I just heard back from @mh- and he confirmed the RPI schedule I described above on a rooted Android device:

Today (2020-10-07), the earliest RPI in my Android device’s database is from 2020-09-23 00:01 UTC.

This means my statement

The only thing we can say for certain is that the first encounter happened on the Sept 16th and the 2nd on Sept 18th.

should be correct.

Edit: There has been an update regarding this info from the devs.

[ArgentinaRDX]

Hey @daimpi ,

That's great! Thanks again for all your time and help :)

Best wishes,

@ArgentinaRDX glad I could help 🙂.

I just heard back from @mh- and he confirmed the RPI schedule I described above on a rooted Android device:

Today (2020-10-07), the earliest RPI in my Android device’s database is from 2020-09-23 00:01 UTC.

This means my statement

The only thing we can say for certain is that the first encounter happened on the Sept 16th and the 2nd on Sept 18th.

should be correct.

[dsarkar]

Dear @ArgentinaRDX, @daimpi,

Thanks for contributing. Do I understand correctly that this question has been resolved and we can close this issue?

Best wishes,
DS

---

Corona-Warn-App Open Source Team

[daimpi]

Hi @dsarkar,

Do I understand correctly that this question has been resolved and we can close this issue?

yes I would think so, @ArgentinaRDX do you agree? 🙂

[ArgentinaRDX]

Sure! Thanks for your work @dsarkar. Wish both of you all the best! @daimpi

Hi @dsarkar,

Do I understand correctly that this question has been resolved and we can close this issue?

yes I would think so, @ArgentinaRDX do you agree? 🙂

[dsarkar]

Hi @ArgentinaRDX, thanks for the feedback and for contributing here to the community. Your special thanks should go to @daimpi.

Best wishes,
DS

---

Corona-Warn-App Open Source Team

[daimpi]

Some update for anyone coming late to this thread: devs have stated that the RPI deletion schedule doesn't work in 24h chunks as discussed above but rather:

Both under iOS and Android RPIs are not deleted at midnight but by trend after 14 x 24 h.

(via @dsarkar)

[MikeMcC399]

@daimpi

Some update for anyone coming late to this thread: devs have stated that the RPI deletion schedule doesn't work in 24h chunks as discussed above but rather:

Both under iOS and Android RPIs are not deleted at midnight but by trend after 14 x 24 h.

Are you referring to the clean-up job of the Exposure Notification Framework / System?

[daimpi]

@MikeMcC399

Are you referring to the clean-up job of the Exposure Notification Framework / System?

Yes. This is how I understood the dev statement. This implies the number of matches can go down even within the same (UTC) day.

[MikeMcC399]

@daimpi
To fill in about the clean-up job for Android regarding the exposure check history: this runs every 24 hours at a random time. (Related to #1020, which has not yet been addressed by Google, though they are in the process of looking at it.)

[daimpi]

@MikeMcC399

To fill in about the clean-up job for Android regarding the exposure check history: this runs every 24 hours at a random time.

Interesting thanks for the info 🙂. Do you know whether this also applies to the RPI deletion?

[MikeMcC399]

@daimpi

Interesting thanks for the info 🙂. Do you know whether this also applies to the RPI deletion?

No, I don't have any independent information about the RPI clean-up. Sorry!

[vaubaehn]

Hi @daimpi and @MikeMcC399 , thanks for your information.
I understood it like this: RPIs are deleted countinously during runtime of phone, when their age is 14*24 hours.
The exposure log is updated (old entries deleted) only once per day.
Wouldn't that perfectly explain the problems discussed in #1516 and #1210 ?

Let's say 2 exposure checks (with each freshly downloaded DKs) are done during one day, one in the morning and one in the evening. The first exposure check is done in the morning at 08:00am. One match is found from one encounter, that had been 13 days and 22 hours ago (at 10:00am). On opening CWA at 08:05am, it requests the exposure summary from the ENF (after the checks had already run 5 minutes ago), and it shows one match (and so does the ENF log). Then at 10:00am, the RPI that caused the match is deleted from ENF, and so is the ENF's data object of the exposure summary. Then at 10:30am, user again opens CWA, the exposure summary is again retrieved from ENF, now there are 0 matches because of the aged out RPI. But ENF log (history) still shows 1 match from check at 08:00am. Finally, in the evening at 07:00pm, the next regular check is done with fresh DKs. No match is found. On opening CWA at 07:30pm, CWA retrieves the exposure summary from ENF with 0 matches (and accordingly displays 0 matches), while the new entry in the exposure log (history) also states 0 matches. Everything is synchronized again.

Does this sound plausible to you?

[MikeMcC399]

@vaubaehn
I don't know that I can add any value to your scenario. We do know that data is changing during the day and this can lead to changed status displays during the day.

[daimpi]

Hey @vaubaehn sry for the late reply:

[…]Then at 10:30am, user again opens CWA, the exposure summary is again retrieved from ENF, now there are 0 matches because of the aged out RPI.[…]

My understanding so far was that in the old ENF v1 legacy mode (with CWA pre 1.7) this wouldn't work like this but rather that the info (ExposureSummary) which was retrieved with the first check on a specific day was cached by CWA for the rest of the day and not queried each time you open CWA (I could obviously be wrong about this as I didn't look at the code). I asked for clarification on how exactly this number is updated in CWA here but haven't received an answer unfortunately.

If each time CWA was opened a new ExposureSummary query was processed by ENF then that - together with RPIs being deleted after 14*24h - would o/c explain those issues as you said.

[heinezen]

With the switch to ENFv2 in CWA 1.9, this issue has likely become obsolete. Therefore, we will close it.

---

Corona-Warn-App Open Source Team