Display of "Tage seit letzter Risiko-Begegnung" is irritating

[vschoech]

Avoid duplicates

• Bug is not mentioned in the FAQ
• Bug is not already reported in another issue

Describe the bug

"Tage seit letzter Risiko-Begegnung" are calculated differently at different times of the same day. It seems that sometimes, in the morning, it calculates 1 less than in the evening. I am 99% sure that the higher number, which is shown later in the day, is the correct one.

Today I took two screenshots to illustrate the issue. I noticed, that there was an update of "infected data" in between the screenshots. Maybe the "morning vs. evening" is actually "before vs. after the daily update"?

Expected behaviour

According to expectation based on communication between humans, the displayed number must not change within one day. Accuracy/unambiguousness is very much desirable, because indicating the wrong day can raise a lot of questions and point into wrong directions (e.g., if one day I was in the office, and the other day I was strictly at home).

Instead of a relative expression of time ("vor n Tagen"), you could as well switch to expressing time in absolute terms ("Am 27. May"). Stating a precise date would probably be less prone to programming errors, and it would be less ambiguous and potentially more helpful for the user.

Steps to reproduce the issue

First of all, you need to register a "Risiko-Begegnung". Then, repeatedly look at the app display over the course of a day. The following screenshots were both taken today, at 7:16 AM and at 10:49 AM, but I noticed the problem already a few times before:

(Screenshot taken 10-Aug-2020 07:15:58)

(Screenshot taken 10-Aug-2020 10:48:56)

Technical details

• iOS Version: 13.6
• Device: iPhone Xr

Additional context

Reported the problem here already:
https://pandemie-forum.de/t/corona-warn-app-technische-probleme-und-updates/600/43?u=volker.berlin

---

Internal Tracking ID: EXPOSUREAPP-2406

[Ein-Tim]

Maybe a very stupid question, but couldn't it be that you had the last encounter at f.e. 8 AM, so before 8 AM only 11 days are shown and after 8 Am 12?
Just a guess without looking deeper into it.

[vschoech]

Without looking into the code, it could be anything.

But even if the bug is as you describe, it is still a bug. If the message says "days", it should be days that are counted. If the app counts hours or milliseconds, the message should say "hours" or "milliseconds". It is not in compliance with general language understanding to lump any consecutive 24 hours together and call it a "day".

I'm trying to make the point that the current behavior is bound to be confusing to normal people (outside the software development bubble). This is irrespective of why it is as it is.

[Ein-Tim]

You're right, also imho the days shouldn't change within one day, just wanted to give a guess why this happens. So or so we need a developer who takes a look at this

[Marco2907]

Hello @vschoech thanks for sharing your input. I will keep this issue to our development community and will give you an update as soon as possible.

Thank you.

Best,
MP

Corona-Warn-App Open Source Team

---

Internal Tracking ID: EXPOSUREAPP-2406

[ir-fuel]

From what I understand there is no real "calculation" going on.

What happens is the following:
once approximately every 24h the exposure check is done. This downloads the new keys and does the internal matching (in the iOS API) of keys with the keys you exchanged. One of the results of this process (which is completely black boxed) is daysSinceLastExposure.

This is the value you see on screen. This value is returned by Apple and in no way related to the time on your device.

Let's say the exposure check runs yesterday at 5am. It detects an exposure 4 days ago. It will show "4 days ago". Until the exposure check runs again it will keep on saying "4 days ago". If the exposure check today runs at 6am (remember, it's Apple that schedules this, so you'll never have it running at exactly every 24h), until 6am it will keep on saying "4 days ago". After the check runs again the value returned by the API will be "5 days ago".

This is the technical reason why it's shown like this.

The obvious (and easy?) solution to this is to just do +1 to the shown "days ago" if the last exposure check ran before midnight.

[vschoech]

Or +1, actually? 😉

[ir-fuel]

No idea what you mean 😇

[daimpi]

This issue will probably also be somewhat mitigated once we get CWA performing multiple checks per day 🙂.

[ir-fuel]

Here is the (untested) solution:

in ExposureDetectionViewController+DynamicTableViewModel.swift

	static func riskLastExposure(text: String, image: UIImage?) -> DynamicCell {
		.risk { viewController, cell, _ in
		
                       // add offsets if not calculated today
			var daysSinceLastExposure = viewController.state.risk?.details.daysSinceLastExposure ?? 0
			
			if let date: Date = viewController.state.risk?.details.exposureDetectionDate {
				let calendar = Calendar.current
				let exposureDetectionDate = calendar.startOfDay(for: date)
				let today = calendar.startOfDay(for: Date())
				let components = calendar.dateComponents([.day], from: exposureDetectionDate, to: today)
				
				if let days = components.day {
					daysSinceLastExposure += days
				}
			}
			
			cell.textLabel?.text = .localizedStringWithFormat(text, daysSinceLastExposure)
			cell.imageView?.image = image
		}
	}

[ir-fuel]

@vschoech also be aware that this value does not represent what you might think it represents.

One might think this is the moment you had your latest high risk exposure, but this is not the case:

The values for this property represent the number of days since the most recent exposure, going backwards. For example, a value of 0 means that the person was exposed today, 1 was yesterday, 2 was two days ago, and so on.
This property is only valid if matchedKeyCount > 0.
The framework computes this property's value across all matching exposures, not just exposures that meet or exceed minimumRiskScore or minimumRiskScoreFullRange.

What this means is, this is the day when you had any exposure, being it low or high risk. So it could state '2 days ago' but the real high risk exposure you had was 5 days ago.

[vschoech]

@ir-fuel Thank you for the additional information! I think that for most practical purposes the actual meaning is close enough to the meaning that people expect when they see the value. Anyway, for those who wonder, it would be nice to have this detailed explanation available in the app, e.g., as part of the page that opens when I click/tap on the green/red indicator box.

[daimpi]

Anke domscheit-berg is also irritated by this behavior and like OP suggests using an absolute date for the time of exposure.

[RubenKelevra]

It's quite bad to not explicitly stating the time frame when the contacts occurred, since this way you could narrow it down how the contact occurred.

Like if you took the bus but it was empty but the app recorded an encounter on a traffic light stop to a passenger in a different vehicle might be a completely different risk case for the user than a meeting in an office at work.

[daimpi]

@RubenKelevra the exact timestamp of an encounter is not exposed by the Exposure Notification Framework (ENF) for privacy reasons afaik. Therefore CWA cannot show an exact time but only the day when the exposure occurred (see here for more details on the response CWA gets from ENF). If you have a rooted android device you can bypass this restriction e.g. with the corona-warn-companion-android though.

[Ein-Tim]

Could this Issue please be moved to the Documentation Repo since it affects both Android and iOS?
(@abro1i @svengabr)

[vschoech]

It's quite bad to not explicitly stating the time frame when the contacts occurred, since this way you could narrow it down how the contact occurred.

@RubenKelevra It's not a bug, it's a feature. The precise time of the encounter is intentionally not given away because you don't want to expose the person that has reported being infected. Anonymity is an important aspect for broad acceptance. If it is easy to trace back who reported an infection, less infections will be reported.

That said, intentionally not giving a precise time frame is not the same as giving a time frame that seems so be precise but is not consistent with other information (which is what this ticket is about).

[RubenKelevra]

I know that there are limits in time resolution, but the resolution which is possible technically should be shown.

Say if the contact is known to be occurred on Thursday, show Thursday - not 4 days ago. And if it's known to be in an 8 hour timeframe on Thursday, show 'between 3am and 11am'.

The current display is just unnecessarily confusing IMHO.

[svengabr]

Hello everyone,

there is already an internal proposal for showing more information regarding risk encounters. We will open a new wishlist entry for this soon to make it more transparent for everyone.

An overhaul of risk encounters information UI/UX was implemented with the app version 1.3.1 which is already available.

[rude78]

Hello everyone,

there is already an internal proposal for showing more information regarding risk encounters. We will open a new wishlist entry for this soon to make it more transparent for everyone.

An overhaul of risk encounters information UI/UX was implemented with the app version 1.3.1 which is already available.

I could not see any improvement in version 1.3.2. Is there an update on this issue.

[Ein-Tim]

@rude78
Since Version 1.3.2 you should see an Information Text if you had Low Risk Encounters.
(Open CWA -> Click the Risk Card -> you will see an Text ("Begegnungen mit niedrigem Risiko") if you had Low Risk Encounters.)

[ndegendogo]

I would also like to understand better how to read this "x Tage seit letzter Risiko-Begegnung".
afaiu you get this as number from ENF call and display as-is. So, please clarify with Apple and Google the following:
How is this "days since last exposure" calculated?
Is it correct understood as time difference between the matching RPI and the time of check?
How exactly is this time difference then rounded to days?

And please be aware that the implementation of ENF might be different between A and G, and ask both of them.

[sssfff]

Wouldn't it be far easier to show the exact date and time of the risk exposure (maybe the last timestamp of the contact with the other token)? It would help the user:
a) to self-evaluate his/her own risk ("ahhh, at this point in time i was in my car at a traffic light, so this may come from the car next to me = low risk" or "ahh I was attending a meeting with 4 other guys = high risk")
b) to get an indication of who (taken from my brain memory) may have caused the exposure warning, and get in touch with these potential spreaders (if known) w/o violating data privacy - this may help in breaking the spreader chains

In case of concerns about data privacy: What exactly are these concerns? No extra data are shared with anyone else, no additional data are collected. As the user is "owning" his/her own tokens and exposure touches with other tokens, this would increase transparency of the user's own data.

[sssfff]

It's quite bad to not explicitly stating the time frame when the contacts occurred, since this way you could narrow it down how the contact occurred.

@RubenKelevra It's not a bug, it's a feature. The precise time of the encounter is intentionally not given away because you don't want to expose the person that has reported being infected. Anonymity is an important aspect for broad acceptance. If it is easy to trace back who reported an infection, less infections will be reported.

That said, intentionally not giving a precise time frame is not the same as giving a time frame that seems so be precise but is not consistent with other information (which is what this ticket is about).

It's quite bad to not explicitly stating the time frame when the contacts occurred, since this way you could narrow it down how the contact occurred.

@RubenKelevra It's not a bug, it's a feature. The precise time of the encounter is intentionally not given away because you don't want to expose the person that has reported being infected. Anonymity is an important aspect for broad acceptance. If it is easy to trace back who reported an infection, less infections will be reported.

That said, intentionally not giving a precise time frame is not the same as giving a time frame that seems so be precise but is not consistent with other information (which is what this ticket is about).

We should re-think this argumentation with "not exposing the infected person" under the current escalating situation. Showing a time window of several hours for the exposure ("x Tage seit Begegnung") could lead to even more rumors and misleading speculations about infected contacts. The ability to narrow down the "suspicious" contact could help to avoid this, and may have other benefits, see: #433 (comment)

[Ein-Tim]

@sssfff Just from the technical side: the ENF does not reveal the exact time an Encounter happened.

[sssfff]

@sssfff Just from the technical side: the ENF does not reveal the exact time an Encounter happened.

I cannot imagine, that there are no technical solutions to bypass this strange limitation ....
And, by the way, there is an API call GetExposureWindows (https://developers.google.com/android/exposure-notifications/exposure-notifications-api#getexposurewindows), which probably does what I have in mind (exact time is not required IMHO, a window of 30 min to one hour should be "good enough" and far less irritating than "vor x Tagen" The new text could be something like "Letzte Risko-Begegnung am 2.11. gegen 18 Uhr (+/- 30 min)"

As a side node from the Google documentation: "Note: We strongly recommend migrating to ExposureWindow mode for enhanced risk calculation functionality."

[daimpi]

@sssfff

I cannot imagine, that there are no technical solutions to bypass this strange limitation ....

There are indeed ways to bypass this limitation, you just have to root your phone to do it 😉

And, by the way, there is an API call GetExposureWindows (developers.google.com/android/exposure-notifications/exposure-notifications-api#getexposurewindows), which probably does what I have in mind (exact time is not required IMHO, a window of 30 min to one hour should be "good enough" and far less irritating than "vor x Tagen" The new text could be something like "Letzte Risko-Begegnung am 2.11. gegen 18 Uhr (+/- 30 min)"

Even exposure window mode doesn't expose timepoints of the encounter which are finer than one day afaik, so this wouldn't work.

As a side node from the Google documentation: "Note: We strongly recommend migrating to ExposureWindow mode for enhanced risk calculation functionality."

Yes, I also hope we see a shift soon there. Here is the respective issue btw: #373

[vschoech]

We should re-think this argumentation with "not exposing the infected person" under the current escalating situation. Showing a time window of several hours for the exposure ("x Tage seit Begegnung") could lead to even more rumors and misleading speculations about infected contacts. The ability to narrow down the "suspicious" contact could help to avoid this, and may have other benefits, see: #433 (comment)

You are walking a very fine line here. If users decide not to use the app, or not to report their infection, the entire effort is in vain. As long as you're not living in a country where government can force people to use certain apps, the decision is theirs, not yours. Thus the users' concerns must be obeyed, whether you agree with them or not.

[sssfff]

We should re-think this argumentation with "not exposing the infected person" under the current escalating situation. Showing a time window of several hours for the exposure ("x Tage seit Begegnung") could lead to even more rumors and misleading speculations about infected contacts. The ability to narrow down the "suspicious" contact could help to avoid this, and may have other benefits, see: #433 (comment)

You are walking a very fine line here. If users decide not to use the app, or not to report their infection, the entire effort is in vain. As long as you're not living in a country where government can force people to use certain apps, the decision is theirs, not yours. Thus the users' concerns must be obeyed, whether you agree with them or not.

Fully agree, that acceptance must not be impacted by unwanted features. On the other hand: Do we have a clear picture about user concerns (i.e. by statistically proof survey, votes or whatever), ore is our view on concerns more based on assumptions, speculations and gut feelings? I just want to ensure, that the app feature is not limited by some assumptions, while the majority of users welcomes the feature request described here.
Following a design thinking approach a version with and another without exact date/time presentation would be offered to user test groups.

[webermike]

Please show Date and Time of later on announced risk contacts, even if this leads to still having a green status.

As such contacts might occur only at shopping or eating in a restaurant, one can reconstruct with Date and Time where one habe been and if shopping or queuing anywhere is the risk reason.

This would enhance the analyse and discussion and avoiding of behavior in the future much, when it ia shown if the risk contact was at 8:00 in the bus ir at 12:00 in the McDonalds restaurant or at work at 10:00 o'clock at a certain date/day.

so it is not about "10 days ago" but about exact time and day.

Thanks for implementing that local showup fast.

[webermike]

Then use the timestamp of the computer. It is important to know if it is in the bus or at lunchtime.

[Ein-Tim]

@webermike See my comment here: corona-warn-app/cwa-wishlist#100 (comment)

[Blackjacx]

act time but only the day when the exposure occurred (see here for more details on the response CWA gets from ENF). If you have a rooted android device you can bypass this restriction e.g. with the corona-warn-companion-android though.

But it would be possible to show the absoloute date for the reported day, without the time component for the reposrted day. This would already help a lot to not have to calculate in mind which day it exactly was. In a friends app there stand "risk encounter 6 days ago" and on the next day it was still 6 days ago, which can be very irritating! Writing the abs day solves this.

[sssfff]

I suggest to raise a feature request towards the creators of the Exposure Notification Framework (Apple/Google) to add the exposure time to the GetExposureWindow() call. While this is implemented, community can still discuss the data privacy impact, and developers can decide about using the new capabilities, or not to use them.

[Ein-Tim]

Version 1.8.0 and above will show the exact date of the last Risk Encounter (see corona-warn-app/cwa-app-ios#1550)

[MikeMcC399]

It should be possible to close this issue.

The blog post https://www.coronawarn.app/en/blog/2020-12-16-corona-warn-app-version-1-9/ (or https://www.coronawarn.app/de/blog/2020-12-16-corona-warn-app-version-1-9/ for German version), referring to the released version 1.9, shows an Increased Risk screen shot with an absolute date "Most recently on 15 Dec 2020" rather than a relative date such as "x days since ...".

[dsarkar]

Dear @vschoech, @Ein-Tim, @sssfff, @ir-fuel, @daimpi, @Blackjacx, @webermike, @MikeMcC399, and community,

Thank you for all the contributions here. As suggested, we will close this issue now.

Best wishes,
DS

---

Corona-Warn-App