Cwa-wishlist: 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.

1. 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: https://github.com/corona-warn-app/cwa-app-ios/pull/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 https://github.com/corona-warn-app/cwa-app-android/issues/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)

[marianschmidt]

I think the current implementation makes sense for the average user (simplicity and easy understanding) and from a privacy perspective.
However, the current implementation is forgoing a lot of potential of the app for health experts, i.e. helping the health authorities in making sensible decisions. Consider the following situation: I am a doctor/nurse using the CWA and suddenly have a low risk encounter and my status is green? Tomorrow at work I would see 50+ high risk patients for who a corona infection could be deadly. In this situation (for risk assessment) it might be crucial to know:

• date of risk encounter

• duration and estimated distance

Maybe a solution would be to have an additional module of the app targeted towards health authorities (Gesundheitsämter) that could access the additional information from the app for me and give a more detailed individual recommendation how to behave in this specific (low risk, potentially high impact) situations - also taking into account the current status of the pandemic in my region. I guess it would make sense to tell this doctor/nurse to get tested and stay at home, if there is low transmission going on in my region, but it would not be a suitable solution, if I already have a shortage of medical staff.

I would suggest this to be discussed with RKI in order to use the information from the app in a better way than it can be currently done. A second level of access to the data underlying additional data privacy regulations might make sense.

[francescacoo]

I just want to add that you might miss potential app users due to this (I do understand there are privacy concerns).

I personally worried for a low risk contact until it disappeared in the log and I could trace what I have done that day (I still don't know exactly, but I know I haven't been in a closed space/public transport//didn't talk to anyone for long or without a mask, so I hope it was a really far away/very short contact).

I have just spoken with 3 friends, working and moving in the city, they all not use the CWA because it would just increase their anxiety. It's a small set for a survey :) but on 4 people I have asked to, 3 are not using it for this exact reason.

And I do not wish myself to go through the same doubts/anxiety I had this week for the notification :)
(I do trust the calculations, but I can't trust they are 100% so I would prefer to be able to do also my own assessment or to be not shown at all the notification if it's so irrelevant)

[kherpel]

Please discuss this wishlist item with RKI. For me as a user this is a basic requirement for the app.

Right now it shows risk encounters with low risk without any additional information like day, duration or calculated distance. I do not understand why this information is then shown at all. Any AHA rules must be applied with or without these risk encounters so there is no difference for handling both status on my side.

Right now this information without any context just results in unease. We might see a surge of cases in autumn/winter and I would expect to show a much higher counter, e.g. "10 risk encounters with low risk". If I would know this happens always around the time I was shopping or taking a train + was on 10 different days it would give much more context then just the basic number. Without this context it will only result in anxiety resulting in users stopping to use the app.

[mathiaswohlfarth]

On my app (Android) I can't see any counters. Only hints to wash hands. Please tell me were I can find counters. Is there a different app for Android and IOS?

[kherpel]

On my app (Android) I can't see any counters. Only hints to wash hands. Please tell me were I can find counters. Is there a different app for Android and IOS?

It is only shown when matching tokens were found: Screenshot_20200909_130734_de rki coronawarnapp

[mathiaswohlfarth]

Keeping the information in the dark, might be a hint to hide, that the app is not working correctly (no or only a few contacts are stored).

[daimpi]

@mathiaswohlfarth do I understand you correctly, that you'd also want to get information on how many non-positive contacts you had? This is not possible for privacy reasons: https://github.com/corona-warn-app/cwa-wishlist/issues/124#issuecomment-660121125.

But if you have a rooted Android device you can circumvent some of those limitations with @mh-'s corona-warn-companion-android 🙂.

[mathiaswohlfarth]

Counters give no information about privacy. but they give the possibility to check functionallity: having a contact lets increase the counter - the app is working. If not the app is not working. I don't believe it is working. I have been a programmer. I know the business. Its better to wash hands.

[daimpi]

Ok, so you only want this as a functionality check, to see whether RPIs have been recorded?
I'll quote @mh-'s comment:

You should be able to see what is received (and the RSSI) with adb logcat|grep ExposureNotification.

(but afaik you also need root for this).

Other than that there is no option for CWA to do this, as non-positive RPIs are not exposed by the Exposure Notification Framework (ENF) to the app: https://github.com/corona-warn-app/cwa-app-ios/issues/678#issuecomment-646686363

[mathiaswohlfarth]

poor design ... and root does not fit with privacy

[treysis]

@mathiaswohlfarth No, this was done intentionally for privacy reasons by Google. CWA cannot change this, if Google doesn't change it.

[svengabr]

We got an official statement from the Robert Koch Institute:

German

Als Herausgeber der Corona-Warn-App bedankt sich das Robert Koch-Institut für die vielen Rückmeldungen zur Risikostatusanzeige auf dem HomeScreen. Diesem Dank schließen wir uns als Entwicklerteam der App an. Nach Abwägung aller Argumente und in Abstimmung mit dem Bundesministerium für Gesundheit hat das RKI entschieden, die zweistufige Risikodarstellung (grün und rot) beizubehalten.

Die App muss möglichst einfach und allgemeinverständlich in der Anwendung sein. Durch die Unterscheidung von niedrigem und erhöhtem Risiko können den Nutzerinnen und Nutzern auf ihren Risikostatus abgestimmte Handlungsempfehlungen gegeben werden. Die zusätzliche Anzeige von Begegnungen, die bestimmte Kriterien erfüllen, erhöht die Transparenz. Für alle diejenigen, die sich mit der Risikobewertung und ihren Parametern eingehender beschäftigen möchten, haben RKI und Entwicklerteam detaillierte Beschreibungen auf GitHub zur Verfügung gestellt.

Die Texte in der Corona-Warn-App werden wir unter Berücksichtigung Ihres Feedbacks weiter anpassen. Mit einem anstehenden Update werden wir weitere Erläuterungen zum besseren Verständnis der angezeigten Risikobegegnungen geben. Zudem wird geprüft, ob mit einem späteren Update eine Risikobegegnungshistorie in der App dargestellt werden kann.

Auch zukünftig werden wir Anregungen und Vorschläge zur Verbesserung der Corona-Warn-App aufgreifen, diskutieren und, soweit sinnvoll und möglich, umsetzen. Wir freuen uns, wenn Sie sich weiter mit konstruktivem Feedback beteiligen.

---

English

As the publisher of the Corona-Warn-App, the Robert Koch-Institute as well as the development team would like to thank you for the many feedbacks on the risk status display on the HomeScreen. After weighing up all arguments and in coordination with the Federal Ministry of Health, the RKI has decided to keep the two-level risk display (green and red).

The app must be as simple and generally understandable as possible in its application. By differentiating between low and increased risk, users can be given recommendations for action based on their risk status. The additional display of encounters that meet certain criteria increases transparency. For those who want to take a closer look at risk assessment and its parameters, RKI and the development team have provided detailed descriptions on GitHub.

We will further improve the texts in the Corona-Warn-App and we will continue to listen for feedback of the community. With an upcoming update, we will provide further explanations to help you better understand the risk encounters displayed. In addition, we will check whether a later update will allow a risk encounter history to be displayed in the app.

In the future, we will continue to take up, discuss and, where reasonable and possible, implement suggestions and proposals for improving the Corona Warning App. We would be pleased if you continue to contribute with constructive feedback.

Further text improvements are being introduced in the upcoming hotfix release 1.3.1.

RC1 of 1.3.1 is already available:
https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.3.1-SNAPSHOT-RC1
https://github.com/corona-warn-app/cwa-app-ios/releases/tag/v1.3.1-RC1

Since the decision from the RKI is final, I will close this issue now.

Best regards,
SG

Corona-Warn-App Open Source Team

[kherpel]

@svengabr : I'm not an app developer but the changes in the 1.3.1 RC do not look like they are providing a solution for this issue. I can only see text changes but nothing about providing the additional information, correct?

According to the statement this wishlist item is going to be evaluated for a later update:

In addition, we will check whether a later update will allow a risk encounter history to be displayed in the app.

Is this part tracked in another issue?

Thanks and kind regards,
Kristian

[daimpi]

I don't think this issue should be closed, as it targets improvements which seemingly haven't been ruled out by the RKI as @kherpel mentioned above:

In addition, we will check whether a later update will allow a risk encounter history to be displayed in the app.

[mathiaswohlfarth]

It is the typical way of business: get the (tax) money, then keep the customer busy. A wishlist is a good idea. Then "thank you - we will do it later" is the same as "Do Nothing". I think nothing more will happen here.

[daimpi]

@svengabr @mtb77 could you either confirm that the request for more information on exposures has been declined or else reopen this issue? B/c just from the statement posted above this is not clear to me.

[svengabr]

@daimpi unfortunately at the current point in time, I don't have any additional information from the RKI regarding this issue.

[daimpi]

@svengabr

unfortunately at the current point in time, I don't have any additional information from the RKI regarding this issue.

Thanks for the update 🙂.
In this case: could you keep this issue open until we get more info from the RKI?

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