Cwa-documentation: When TEKs are missing on the device, wrong TRLs are applied during Diagnosis Key upload

[mh-]

Where to find the issue

This is a bug in both apps (Android and iOS). See also the comment below.

Describe the issue

Normally, the EN framework generates a new TEK each day, and keeps all TEKs of the last 14 days.
But if e.g. the device is switched off for at least one full day, across the 00:00 UTC boundaries, at least one TEK is missing in that list.
When TEKs are missing on the device, wrong Transmission Risk Levels (5, 6, 8, 8, 8, 5, 3, 1, 1, 1, 1, ...) are applied during Diagnosis Key upload.
TRLs should be applied based on the age of the TEKs (in days), but they are applied based on the number of the TEK in the list.
Most of the time, the number in the list corresponds exactly to the age, but not in the case when at least one TEK is missing as explained above.

Suggested change

Apply the TRLs based on the Start Interval of the TEK, not based on their position in the list.

---

Internal Tracking ID: EXPOSUREAPP-1916

[monikaschmitt]

Dear @mh-
Thanks a lot for bringing up this issue. We will get back to you on this as soon as possible.
Kind regards
MS
Corona Warn-App Open Source Team

[Tho-Mat]

Let try if i understand it in the correct way:

Let's have a look on 03-07 11:00 data

risk| day  |count
1 | 26.06. | 15
1 | 25.06. | 15
1 | 24.06. | 15
1 | 23.06. | 20
1 | 22.06. | 20
1 | 21.06. | 20
1 | 20.06. | 20
3 | 27.06. | 15
3 | 24.06. | 5
5 | 28.06. | 15
5 | 25.06. | 5
8 | 01.07. | 20
8 | 30.06. | 20
8 | 29.06. | 15
8 | 27.06. | 5
6 | 02.07. | 20

I can distribute the keys in the following way:

3 Users:

risk|  day   |count
| 6 | 02.07. | 15 |   
| 8 | 01.07. | 15 |   
| 8 | 30.06. | 15 |   
| 8 | 29.06. | 15 |   
| 5 | 28.06. | 15 |   
| 3 | 27.06. | 15 |  
| 1 | 26.06. | 15 | 
| 1 | 25.06. | 15 | 
| 1 | 24.06. | 15 |   
| 1 | 23.06. | 15 |   
| 1 | 22.06. | 15 |   
| 1 | 21.06. | 15 |   
| 1 | 20.06. | 15 |

1 User

risk|  day   |count
| 6 | 02.07. | 5 |   
| 8 | 01.07. | 5 |   
| 8 | 30.06. | 5 |
| 8 | 27.06. | 5 |   
| 5 | 25.06. | 5 |   
| 3 | 24.06. | 5 |   
| 1 | 23.06. | 5 |  
| 1 | 22.06. | 5 |   
| 1 | 21.06. | 5 |   
| 1 | 20.06. | 5 |

The correct values for the last user:

| 6 | 02.07. | 5 |           
| 8 | 01.07. | 5 |           
| 8 | 30.06. | 5 |           
| off 29.06 |               (should be risk: 8)
| off 28.06 |               (should be risk: 5)
| 8 | 27.06. | 5 |           should be risk: 3
| off 26.06 |               
| 5 | 25.06. | 5 |           should be risk: 1
| 3 | 24.06. | 5 |           should be risk: 1
| 1 | 23.06. | 5 |           
| 1 | 22.06. | 5 |           
| 1 | 21.06. | 5 |           
| 1 | 20.06. | 5 |           

@mh-
can you point to the code in android and ios where the risk values are assigned in the wrong way?

[mh-]

@mh-
can you point to the code in android and ios where the risk values are assigned in the wrong way?

Android:
https://github.com/corona-warn-app/cwa-app-android/blob/18cc335780b08935527963e7baefac6cc6fa100b/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/ProtoFormatConverterExtensions.kt#L49
iOS:
https://github.com/corona-warn-app/cwa-app-ios/blob/4521a54efb871cd95a62338ad0740aa290b9fcb5/src/xcode/ENA/ENA/Source/Services/ExposureSubmissionService.swift#L215

In both cases, the TRL profile is applied to the list of keys as it was received from the GAEN framework, without using the day when the key was valid.

[GPclips-zz]

Hello @mh- and @Tho-Mat,

I have reached out to the dev team and we will update you as soon as possible.

Thanks,
LMM

Corona-Warn-App Open Source Team

[Tho-Mat]

@GPclips
I would prefer not to fix this.
Reason:
With the current implementation it is possible to find some unexpected behavior like
https://github.com/corona-warn-app/cwa-app-ios/issues/1097
https://github.com/corona-warn-app/cwa-server/issues/764
https://github.com/corona-warn-app/cwa-server/issues/755
https://github.com/corona-warn-app/cwa-server/issues/723

With the "correct" implementation some of them could not be found.

The current implementation only shifts the risk level of some days to a higher level, so there is no health impact.

[mh-]

The current implementation only shifts the risk level of some days to a higher level, so there is no health impact.

It could also do the opposite, namely label an '8' day as only a '6'. Whether this poses a problem, RKI would be able to assess.
And while this bug might help finding other bugs, intensive automated tests would help even better.

If RKI accepts this bug, then this issue should be closed.

[thomasaugsten]

This problem will be fixed in v1.5

[daimpi]

@thomasaugsten @mh- has this problem been fixed with the release of version 1.5?

[MikeMcC399]

According to @thomasaugsten in https://github.com/corona-warn-app/cwa-documentation/issues/343#issuecomment-701427857 this issue was to be fixed in version 1.5, so it should be possible to close the issue.

We have now reached 1.10.1 of the app and in the meantime major changes have taken place, including the introduction of onset of symptoms and conversion to v2 of GAEN.

[dsarkar]

@mh-, @daimpi, @Tho-Mat, and community,

This issue is considered to be resolved and will be closed now. Many thanks for all your contributions. Best, DS

---

Corona-Warn-App Open Source Team