Show more details about "risk encounters"

[mh-]

Current Implementation

Currently only the number of days since the last "risk encounter" are shown.

Suggested Enhancement

A list of all "risk encounters" as provided by the GAEN API should be made available to the user. This should include all the available information (which isn't much, but includes the day, duration and attenuation info).

Expected Benefits

With this additional information, users who receive a warning (or even without a warning, a number of risk encounters > 0) will understand better how much they are affected.

---

Internal Tracking Id: EXPOSUREAPP-2099

[mathiaswohlfarth]

The keyfact in a monitoring program ist a control of the reliability. I am working in a datacenter, developing applications to monitor the health of machines. "all ok" alone is never excepted by the operators. Additional information is required to see the application is working correctly. This is controlling the control. Without this feature people cannot trust the application. I had an event with some friends of mine, and we tried to look at the app to see our contacts (anonymous of course), but nothing is found. So the suggestion to show day, duration and attenuation info is highly recomended and shouldn't be not to much work. Up to this I assume the app ist not working correctly, even though error messages are not shown.

[DGrothe-PhD]

In my opinion, the day, duration and the time on that day of risk encounter are crucial information in some cases, consider the following case:

• Your parents haven't got a smartphone. You've spent some time with them in a restaurant, then afterwards, you went shopping on your own. So the time of risk encounter may decide if your parents were at risk, too.

[mh-]

I would like to add that my request is about making those details visible to the user which are made available by the Google/Apple Framework to the app.
Exact time is not made available to the app, nor is any detail made available for any contacts who do not upload their keys after obtaining a teleTAN. This was decided by Google/Apple for privacy reasons, and if someone thinks Google/Apple should change this, they’d better contact Google/Apple directly.

[tens0rfl0w]

I totally agree with your enhancement request, this would be a valuable feature.👍🏽

Should be considered as a „on next“ feature.

[treysis]

I had an event with some friends of mine, and we tried to look at the app to see our contacts (anonymous of course), but nothing is found.

This would only work if one of your colleagues tested positive AFTERWARDS.

[Ulenrich]

I am interested in more detail information about risk encounters. Also low risk encounters, for example riding on a bus for only 3 minutes where there was an infected person.
But I know of possible data security issues with more detailed risk description: I possibly could guess the name of a person I know, who is infected, if I get multiple risk descriptions of the risky encounter. But nevertheless another argument PRO details:
Gedankenexperiment: I get an info about a risky encounter on a day I know I have been often there on the same location with ever the same people (Kleingartenverein for example). The info tells me the day was 3 days ago. I know I have been 14 days ago there with the exact same people also. I am positively thinking that I have gotten the infection 14 days ago at the location, because I am young and healthy and I now guess I am through the infection without having had symptoms. I further on will think I am immune and not a thread to others nor CoVid-19 is any thread for me in the future.
Why shouldn't I think like that if I am simple minded ?

[DGrothe-PhD]

@Ulenrich In your Gedankenexperiment you should let yourself get tested. And if an infection circulates in a regularly meeting group it may be the other way round, that you infected the other guy. And you may also have been infected a week ago by a person on the bus or in that Kleingartenverein who doesn't own a phone. By myself, I would also cancel parties if I had any symptoms. During lockdown I was able to guess even without the app.

[daimpi]

Related issue: https://github.com/corona-warn-app/cwa-documentation/issues/344

[yanosz]

Two things to have in mind:

1. Accuracy

Deriving the the distance based on the RSSI in a BLE setting is very unrelaible. Doing so praticially requieres a controlled lab enviroment in a calibrated setting. Having a smartphone in a jacket or not does have bigger impact on the RSSI, than a distance of a few meters - by far. This is a very active area of research. Typically, positioning is assisted by different attributes such as fingerprinting, machine learning on time series, etc. (https://scholar.google.com/scholar?hl=de&as_sdt=0%2C5&q=BLE+indoor+positioning) - for fieldtracks.org we came to the conclusion, that BLEs accuracy is binary: Either you have a contact or you don't have a contact. There is no in between. Deriving a distance is bogus. From a pandemic point of view, the environment (e.g. indoor / outdoor), stable aerosols or not appears to be relevant. When not knowing the timing of an encounter people cannot check the enviroment (e.g. using googls location history) and can hardly asses the individual risk. (E.g. was there just somebody passing my window, while I was at home alone?, was there somebody sitting just right beside me, while I was taking the tram for 10 minutes?)

2. Privacy.

The App is not desgined to provide contacts in a non-interactive-zero-knowledge proof of knowledge (NIZK, c.f. zcash) way. The protocol provides information on an encounter (timing, signal level), that is way more than just a single bit bit, i.e. "There is an encounter" (from an information theory point of view). Altough somebody could consider to implement a system using NIZKs, the app is not. In consequence people could possible be blamed for being infectious afterwards - medical records are considere to be sensitive information. Providing privacy (i.e. "Informationelle Selbstbestimmung") requires informing the users about the actual data processing. That is - in the most simple setting: Presenting it in a nice way. However, the app does not. The app hides information from the user. I consider this to be a privacy violation.

[treysis]

@yanosz

1. This is why the app/API isn't calculating distance based on RSSI alone. Furthermore, the API transmits RPIs every ~250 ms, but it only receives every ~5 min for 4 s, iirc.

2. Data processing is laid out and documented and you opt in by installing the app. By your argumentation, smartphones in general would be a privacy violation. Furthermore, the design of the app is limited by the API. The app simply cannot give you the statistics that you ask for.

[yanosz]

1. The point is to display the timestamp of the beacon received event. That doesn't have anything to do with RPIs, transmission times, etc. Just do timestamping, when a beacon is received by the app. When an RPI is classified as infectiosous, the corresponding received intervals have to be shown.

2. If the API cannot provide timestamps, than the API is bogus and there's a requirement for utilizing (i.e. developing) another one.

[treysis]

1. Beacons ARE RPIs. The app doesn't receive beacons, the API does. The app never learns anything about received beacons. And no, if you would give the timestamp, you would be able to identify with who you might have been in contact at that time and thus it would expose his identity.

2. Nothing happens outside of the API with the beacons. Yes, maybe die API should/could tell some statistics. But this was done intentionally: the more information you offer, the easier it is to use this information for malicious actions. There are really many things you can do just with simple statistics. I believe it is more privacy-preserving not to expose this information.

If you want to see beacons in your surrounding, just use one of the BLE scanner apps. Then you can do all the timestamping you want.

[yanosz]

1. Its the other way around RPIs are beacons (e.g. iBeacons are beacons but do not use any RPI techniques). As you already outlined, you can receive beacons using arbirtary applications. Identifying exposures is realistic and users should be aware of this sitatuation. As a requirement, the app should illustrate the situation by showing the corresponding data, hence educating them.

2. No API is set in stone - and as you said, using 3rd apps are able to provide the functionality as discussed. Hence, it is possible to integrate this functionality into this app - just alike. And yes, it is outside the current API.

[treysis]

This still needs API change. CWA cannot scan the surrounding, because it doesn't - and CANNOT - have location permissions. Either you use a 3rd party app, or you need to press Gapple to adjust the API. Which they will not do, because the statistics would allow de-anonymization of users.

And why wouldn't users be aware of it? The app is sending via Bluetooth. If you install the app, you know that you start transmitting data via Bluetooth?!

[yanosz]

I guess, that we can agree, that such functionality has breaking API changes, that's fine. Still, it can be implemented (you've already suggested, what kind of Apps do so), when using a different API. Pushing Google or Apple boils down to regulatory and is not a technical concern.

The technical solution would be not to rely on Googles / Apples API, write a custom API component, bundle it with the application and have google and Apple exclude it from power saving restrictions, etc. Having google / apple accepting the App then also boils down to regulatory issues, i.e. laws.

And why wouldn't users be aware of it? The app is sending via Bluetooth. If you install the app, you know that you start transmitting data via Bluetooth?!

Due to a lack of visualization.

[treysis]

Google can't just exclude apps from power saving restrictions. This is up to the OS. Since you won't get manufacturers to release OS updates for older devices, going the way of Google with the PlayServices was the best approach. Yes, it would be nicer to be able to do it without Google, but that's just not feasible.

Due to a lack of visualization.

Make a pulsating element, like in the SwissCovid app. If you're transmitting, you're transmitting. You can't really be more specific about that, can you?

[yanosz]

1. You can require Google by law to distribute a certain app. That's not a technical limitation.

Make a pulsating element, like in the SwissCovid app. If you're transmitting, you're transmitting. You can't really be more
specific about that, can you?

No, the content of sent and received beacons is still hidden from the user.

[tens0rfl0w]

@treysis A pulsating element when tracing is active has been added and will be included in the next minor version.
See here for the PR adding that feature: corona-warn-app/cwa-app-ios#821

@yanosz If an app doesn't meet the Play Store requirements, then no, you cannot encounter this with any application of law.

[treysis]

Well, if Google was willing, they could implement it though. The question is still if that would change anything. As far as I understand this wouldn't give the app sufficient rights. And Google cannot change that. That can only be changed by upgrading the OS. And this is up to the manufacturers and they won't support this for older devices, making the whole concept of the app even less effective.

[yanosz]

@tens0rfl0w ... so you're saying, that this 68.000.000 € project, which has federal attentation cannot result an a law, requiring google and to modify its API? So, this country is paying 68.000.000 € for a simple GUI + backend for an already existing API without any option to change its technical framework?

... IMHO people should considere hiring a new software architects, then.

[treysis]

Ehem, Germany isn't the only country accessing the API.

[tens0rfl0w]

@yanosz Please see this link.

A new API specification has been formed and will be rolled out soon (1.5). This newer version allows for much more freedom in the processing of the data stack and can give the app much more information about the actual data than before.

And no, the German government will not form a law that tells software manufacturers how and what to implement in first party APIs, that would be a little bit over the top.😅

[yanosz]

Ah - 1.5 is:

ExposureWindow (...)
day | Day of the exposure, using UTC, encapsulated as the time of the beginning of that day.

Welll, that's not quite accurate. So, the suitable work around remains to have an additional beacon scanner.

Minding the costs of 68.000.000 € and the having https://play.google.com/store/apps/details?id=net.alea.beaconsimulator for free in the app store (hint: it scans and beacons, too), this is a strange project.

[treysis]

Again, you cannot implement a beacon scanner inside CWA. This requires location permission. With location permission, the app is not allowed to access the API. This is to prevent any exposure tracking app to create location profiles of its users. This is a privacy-aware design-choice!

[yanosz]

Again, you cannot implement a beacon scanner inside CWA. This requires location permission. With location permission, the app is not allowed to access the API.

Well, one could have this project having two apps, one accessing the API, one accessing the regular BLE API. One could OpenSource both, having verifiable builts and make sure, that no such location tracking takes place.

Well, one could argue, that an alternative app, not having the play store dependencies for google runs on lineageos, even with google services disabled. One could argue, that 68.000.000 € are enough to sustain both ones.

Well, one has argued, that exluding false positives / false negatives is vital for the acceptence of the application (https://www.schneier.com/blog/archives/2020/05/me_on_covad-19_.html) - further information on encounters help to do so.

[SebastianWolf-SAP]

Additional/related questions from corona-warn-app/cwa-app-android#896:

• Is there a time which should set the Risiko-Begegnung timer to zero after 14 days as well?
• Did the friend had another Risiko-Begegnung in the meantime/overlapping time? (But then he should have seen 2 Risikio-Begegnungen, right?)
• Will the Risiko-Begegnung stay with 1 as a counter for longer than 14 days? Maybe unlimited?
• How to differentiate if there was 1 other/new Risiko-Begegnung overlapping with a timer which sets the "old" value to zero? -
• Would be good to see a difference if how many values are really "new" / different from "old" (Does this make sense? The use case with an tiny time slot resetting the old count to 0 and having a new risk could be very low I guess)

[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.

[MikeJayDee]

Time is not supported by the API. Date could be shown in principle.

[ndegendogo]

Date could be shown in principle.

@MikeJayDee yes, the 'timestamp' of the 'youngest' encounter is available at the API with day granularity; exactly the number that is now shown in cwa.

[webermike]

Hello, what? For sure an app and a computer and - so should - an api can add a time stamp on hourly or better exact basis.
Just use the app to add to the ID and regular time stamp into the db. Thanks. It is important to know if the contact was at bureau desk, at lunchtime or within the bus. Ideally also add a notepad where users add names in a textfield, which generates anl list as history with all manually added names
Mike at date time
Simon at date time
Etc. Then users can Look up the List of contacts in case for each last 14 days.

[Ein-Tim]

@webermike

This is even more impossible.
The ENF (made by Apple & Google (SAP/T-Systems do not have any influence on this)) does not reveal the number of not positive contacts. It also would be impossible because the Bluetooth beacons which your Handy sends and receives from other Handys are changing every 15 Minutes, so you never know if this is a new person or just the same person with a changed beacon.

Since the scanning is done by ENF and CWA doesn't broadcasts/receives anything it is impossible for CWA to

add a time stamp on hourly or better exact basis

This must be added by Google/Apple to the ENF. And that this happens, I think (at the moment), is very unlikely.

[webermike]

When my machine adds a beacon string to the database, for sure my machine can add an exact time stamp. The positve person just needs to announce all the beacons of its own over the server. Done.

[Ein-Tim]

@webermike
Yes this would be possible but this is nothing what can be influenced by SAP/T-Systems because the underlying API doesn't work like this.

CWA itself gets only this information handed over by the ENF: https://github.com/corona-warn-app/cwa-backlog/issues/23#issuecomment-678692630

Even if it would be possible: The RKI denied to show more information about green Risk Encounters.
But you still could, this would also be very helpfull to keeping track, open a new Issue which requests this.

[mh-]

@webermike CWA has to use the Google/Apple Exposure Notifications API (otherwise the whole setup wouldn't be possible at least on iPhones, and would be extremely battery consuming on Android).
So you would need to convince Google to change this.

(Good luck with that...) A more practical advice for you would probably be to use this app: https://play.google.com/store/apps/details?id=com.contextis.android.BLEScanner

[Ein-Tim]

@svengabr
Reading your statement form here again I can only repeat what @daimpi stated here. This Issue (the OP) is not about changing any colors or intorducing a new risk card but only about showing more details about risk encoutners.

Could you (the team) please clarify with the RKI if they generally reject to show more Informations about Encounters or if they would theoretically show some more Details f.e. the date of Low-Risk Enocunters, etc.
Thanks!

[rvbaer]

@Ein-Tim & @daimpi
Thanks for pointing out to #100

When #100 was closed by RKI we had around 1900 cases per day.
At that time it was correct to have only limited information as likelihood of exposure was low and capacity of laboratories was high. In addition hardly anybody wore FFP2 mask.
Now we have more than ten time as much cases and the ratio exposure / lab capacity has changed totally from 10th September. And walking through a supermarket around 30% of shoppers wear FFP2 mask

RKI has to consider to give out more information to prevent user from either ignoring the information or overflowing the Lab test capacities.

[daimpi]

@rvbaer I'll mirror my answer from here:

I agree that it would be nice to have the warn-app-companion (WAC) functionality provided by CWA. But this is not possible currently b/c Bluetooth access is not allowed for ENF apps by Google/Apple (see above for further discussion on this topic). But even if CWA could access BT: this could only work on Android devices as iOS is filtering out all the BLE signals containing rolling proximity identifiers (RPIs) already on the OS level. So nothing except for the Exposure Notification Framework (ENF) which is directly integrated into iOS can even see them.

And even under Android this hypothetical "direct CWA recording" would probably end up being quite unreliable, as many manufacturers implement "energy optimizations" which kill background apps all the time.

[rvbaer]

@daimpi I'll mirror may answer from #251

@daimpi
Thanks for the background on why something is possible with warn-app-companion (WAC) & RaMBLE but not with an integrated App.

I understand that pressing the "export database" button in RaMBLE and the import button in WAC is okay for Google in Android. But for Google it is not okay not have an integrated App with the same functionalty.
Sounds strange but obviously these are Google's rules - which are as a consequence also strange.

I am still convinced that it is worth the effort to fight for a better app which supports the users by giving time and location of critical enncounters. Such an improved App would
A) reduce the number of people who want a test without a need
B) reduce the number of people who do not bring themself in quarantaine after the App alarmed them

Such a feature would thus simply increase the "quality"

Especially now with the high exposure risk the RKI should join and also fight for this improvement.

[dsarkar]

FYI #178

[OlympianRevolution]

I still believe both the duration and attenuation should be displayed.

These are available via the ENF and would let people judge their risk better. They could discern different cases: eg. one of my neighbors (large attenuation >12 hours), likely bus rides (20m), likely high risk restaurant (2hrs short range). This change would not affect fundamental privacy since all of this information is already available to technically savvy users and provided by the ENF.

Since currently some people have permanent high risk status, this would let them judge their risk better and democratize access to information that is already available to users like me to protect those around them while reducing the need for frequent PCR tests.

[mh-]

I still believe both the duration and attenuation should be displayed.

These are available via the ENF

@OlympianRevolution The duration that ENF will return seems to be arbitrarily limited to max. 30 minutes, because of Apple's / Google's opinion on how the reporting user's privacy could be preserved in this context - see https://developers.google.com/android/exposure-notifications/exposure-notifications-api#getexposurewindows

The time will be randomly cut between 15 and 30 minutes: https://developers.google.com/android/reference/com/google/android/gms/nearby/exposurenotification/ExposureWindow

If the observed duration from one DK was longer, they split it into multiple windows and return them in a shuffled order. So if you met a reporting user for 2 hours, you will get the information from ENF that you had at least 4 encounters that day, each between 15 and 30 minutes length.

Still pretty confusing, so I will not yet retire https://github.com/mh-/corona-warn-companion-android

[OlympianRevolution]

VIa the ScanInstances List there should be more information.
I would be happy with even an approximate total time and mean distance even if it cannot differentiate between 4 people 14 minutes or one person for one hour.

Thanks for the Warn-App-Companion @mh- ! I use it all the time to judge risk and functionality. It is one of the reasons I think it is unfair and hypocritical to prevent normal users from having more information on the encounters, when it is possible for us to know all the details.