Open corneliusroemer opened 4 years ago
similar to corona-warn-app/cwa-app-android#518
Dear @corneliusroemer , we discussed this with the dev team, and there currently is no way of doing this from the application end. Sending and receiving Beacons is handled entirely by the ENF and there is no way for the app to provide the information you want to present.
As it affects both apps, I'll move this issue to the documentation repository and label it as backlog. If the ENF API provides the information at one point, Product Management and the UX team can re-evaluate if and how to display this information.
Thanks @tkowark for discussing this.
One thing that might have got lost, if I'm not wrong you are in charge with the server of exposed keys. So you could provide information of how many exposed keys have been received. This of course doesn't really test core functionality.
That beacons are sent by the phone can be tested by other phones with apps such as this: https://play.google.com/store/apps/details?id=com.davidgyoungtech.beaconscanner
So at least the sending part can be verified.
There are very many good points made in https://github.com/corona-warn-app/cwa-app-android/issues/518 which was canonicalised to this issue.
Anyone reading this discussion here should check out 518, too.
Interesting showcase: https://twitter.com/merlinchlosta/status/1273293511803244546 (sadly in German). I would really like to see a feature like this. For a heatmap, GPS is needed, therefore this maybe is better to be implemented in an additional separate app. Maybe this is something other (open source) developers can develop, does not need to be done by SAP / Telekom. For the CWA app, for me, the live accumulated number of received beacons from other devices would be enough (to monitor the functionality). This should be possible even if the API does not support it (yet), just by monitoring Bluetooth directly.
Dear @corneliusroemer and all other contributors that proposed a similar idea,
thank you very much for your proposal.
To give the community a space for discussing new feature ideas or enhancements that might not be taken up immediately by the development teams, we created the cwa-wishlist repository.
This idea is one of these feature ideas or enhancements. Consequently, we will move this issue to this repository and allow the community and you to further refine it, discuss pros and cons, and evaluate alternatives.
The issue will not be closed in this repository to ensure long-term visibility. All issues in the cwa-wishlist repository will be discussed with our contracting entities. They will decide whether they will be implemented or pursued further. As soon as we have any updates, we will let you know about the details.
Best regards, TK Corona-Warn-App Open Source Team
Please consider this feature request from the perspective of human psychology and public relations. Even users without technical expertise would like to be able to see that the app fulfills its purpose. Then they will be ready to recommend it to others.
It would be optimal if two users could press a button to check whether their two apps had exchanged beacons. Instead of this some other type of reliable information may help.
Bitte sehen Sie dieses Anliegen auch unter der Perspektive der menschlichen Psychologie und der Öffentlichkeitsarbeit. Auch Nutzer ohne technischen Sachverstand möchten sehen können, dass die App ihren Zweck erfüllt. Dann werden sie sie auch weiterempfehlen.
Optimal wäre es, wenn zwei Nutzer auf Knopfdruck prüfen können, ob ihre beiden Apps Beacons ausgetauscht haben. Stattdessen kann aber auch eine andere Art verlässlicher Information helfen.
@hatzfeld Sadly, this is a really bad idea regarding public trust and safety concerns. As of right now, the app has no permission to communicate directly with the bluetooth interface of the device (Which is a good thing in many ways). To implement such testing/verification method, the app would need to access the Bluetooth interface directly, but even if the user could check if basic beacon discovery works, it wouldn't give any information about the status of the EN framework (database, risk calculation, etc.). This is not possible to implement looking at the basic design of the framework.
A little update: The threshold to make keys available for download is now reached. You can now see the total number of keys that are downloaded from the server in the settings app:
@tens0rfl0w Wo finde ich denn die Settings App? Oder ist das nur für iOS?
What does Matched Key Count
mean exactly in this screen? Are those the keys that have been found on the server and on my device (= are a match) or are those all keys on my device that have been compared (matched) with the server keys? Or something entirely different?
I'm aware that the wording here is nothing we can control, but I'm curious …
@bennokress Da Du Swift Entwickler bist, meinst Du wohl iOS. Habe Android.
@bennokress This is the total number of keys that have been found on your phone and on the server (=Matched). So if the number is greater than 0, you have been exposed to a person that has marked himself as infected.
On a similar note (not sure if I should create a separate issue), can CWA (in my case on Android) see/query from the API whether beacon sending is actually supported by the phone? I read that the Samsung Galaxy SIII (i9300) supports receiving beacons, but not sending them (I can definitely confirm the not-sending issue, as I don't see any Beacons with a BLE scanner) However, I see no indication of that fact in the app.
We got more Feedback on this matter via Email:
Using the CWA now for 14 days, I would like to offer you a user request: Please let the CWA breathe !
Which means that I would like to see from the outside that BLE is actually trying to sample for BLE beacons. That it is alive.
Due to privacy considerations, that user information should be just "scanning", just ONE BIT wide. Please DO NOT DISPLAY whether or not that BLE scan returns any result. For Privacy ! From a software-debugging perspective I would like to see more information displayed of the scanning result. But for the purpose of CWA, it is sufficient to just enhance the trustworthiness of CWA by displaying "scanning" in a low-frequency pulsating graphic symbol, like your blue ((o)) to the right of "RISIKO-ERMITTLUNG-AKTIV". But only after the scanning function of android/iOS returns without error. No more information, no result please to the user. For Privacy !
Just let it breathe ! Breathing frequency of human adults is approx. 12 /min.
A little update: The threshold to make keys available for download is now reached. You can now see the total number of keys that are downloaded from the server in the settings app:
I have a Samsung Galaxy J5 and i can't confirm to see the number of keys submitted:
I got from corona-warn-app.opensource@sap.com the information that this is a bug. Could tens0rfl0w please inform on which device/ which OS he got the right values?
Up to yesterday I thougt hat the App collects only contacts for 14 days. I think that is not right, kindly ask to comment or confirm. The number of checks is correctly mentioned on my mobil. It seems every day the check is done per day. Means it star wit 1, next day it is 2 (including yesterday), then 3 (actual day plus days before) etc. After 14 days there is the figure 105. After it still increases afterwards. Means I have the impression at day 15 it drops the check from day 1, but that contacts have been checked at day 2 till 14, too. My impression ist hat therefore the contacts were checked for a period of 28 days. Is that correct?
I fully join the view that the functionality of the CWA is only confirmed if the user can see that contacts are properly stored!! And I want to extend that it should be possible to see the collected contacts by given date and time, best if a list can be opened that shows last contact first and decrease. I hope that the day will come when that happened.
Two days ago there was an update of my android system. After that now I can see the number of provided key counts, too. However, there are some surprises were I think that can be still bugs:
CWA 1.1.1 prioriesed background activity is on, but check happens only when opening the app
Googles COVID-19-Benachrichtigungen is on, indicating for example today 235 checks within the last 14 days. However, opening that -and i feel happy with this new feature- there is at the menu the possibility to export the stored date (as the list on the screen is not sorted by dates like at Apple IOS the only way to understand something. After transferring *.json file (with www.aconvert.com/document/json-to-ods/) I was now able to see data in calculation sheet. However, instead of 235 there a 100 only checks. Earliest check date was 20.7. ; as we have now 27.7. that doesn‘t mean last 14 days. Also if you check the dates on the mobile screen you will not find something before 22.7. Yesterday it was starting at 19.7. I assume a bug, that either only 100 checks (7 days a 14 hash’s plus 2 from first day) are stored or only shown / exported.
-If I understood it right each hash should remain for 14 days. However, with the update of the android system there was partly an interruption or change of hash values.
I have up to now 16 hash's with indicated number of key counts (means 3 days). Numbers vary from 200 to 1375. All are dividable by 5, does that sound reliable? If signal change every 10 minutes 1375 contacts would means either 10 contacts for 23 hours or 100 contacts for app. 2,3 hours. I don’t believe that !!
I will now check what happens when I have more then 24 hours my mobile at home without any contact to another device with CWA. If then the number of key counts is not zero the CWA app will be deleted from my mobile.
My mobile was 2 days only at home with no contact to another mobile with CWA. I got keyCounts 595 and 1790. From my point of view nothing related to the new feature related to CWA is reliable. For my it's game over now.
These key counts are the downloaded keys, i.e., the ones uploaded by infected users. Unless you have matched keys or "abgeglichene schlüssel" greater than zero, you have not been in contact with infected users.
The 100 entries in the exposure checks list are a known limitation in both iOS and Android, and we'll work with the to fix that (https://github.com/corona-warn-app/cwa-app-android/issues/941).
This information is now also explained in the FAQ: https://www.coronawarn.app/de/faq/#keys_matches
If it is true that the key counts are the number of keys uplaoded by infected users then I think more clarification is required. In case the app works for more then 2 weeks then at each day 14 hashs are checked. But for each hash -at the same day- you get different numbers of key counts (for me they vary at 29.7.2020 between 345 and 1790). How could that be? Info from micb25.github.io/dka/ for the same day 29.7.20: Geteilte Diagnoseschlüssel von positiv getesteten Personen (geschätzt) = 458 täglich gemeldete Diagnoseschlüssel (inkl. fingierten Schlüsseln) = 2290
My personal main interest is to get information which contact data were detected and stored at my mobile (min. information how much per day, preferable with date and time and -as Google needs that info anyhow- location). I assume (and hope for data safety) that for my phone I am the only one who can check that data. But I need -and demand- Information how to get the information! For my understanding that is the only way to proof the proper functionality of the CWA.
Currently, there is no way for the app to get this information. It is not provided by the Exposure Notification Framework and also not shown in the according systems dialog.
The 14 hashes per day are the files for the last 14 days. So, there is a file containing the keys for yesterday, the day before, etc. Since each user that reports as infected uploads the keys of their last 14 days of tracing, this can lead to varying numbers of keys per days. https://www.coronawarn.app/de/faq/#multiple_exposure_checks
Does that mean that a 5 days old hash is checked against the downloaded keys of infected persons; as indicated the same amount of keys as 5 days ago (as each hash shows the same number all the time)?
The hash belongs to the downloaded file (as these should not change anymore after the respective day is over). Hence, the same file should be checked every day for 14 days against the collected RPIs. This is necessary since the risk assessment also takes into account, when an encounter occurred (https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md) and therefore this needs to be re-evaluated every day to determine the risk score.
As I understand for every 24 hours app will check 14 times for the exposures, So there will be 14 hashes. I observed with one particular Hash there was a one matched key count where the provided keys were 4.835
Next day I could see same hash number and same number of provided keys but no matched key count.
How it could be possible?
Your phone stores encounters for 14 days and deletes encounters that are older than that. So that most likely means that you had the encounter with the person with this particular diagnosis key in the hash file 14 days prior to the day where the number of matches drops from 1 to 0.
Okay. But still app shows one exposure with low risk. Why is like that.
Your phone stores encounters for 14 days and deletes encounters that are older than that. So that most likely means that you had the encounter with the person with this particular diagnosis key in the hash file 14 days prior to the day where the number of matches drops from 1 to 0.
Okay. But still app shows one exposure with low risk. Why is it like that? . If it is 14 days prior it should not say exposure right?
Hash is created for the keys from the server or for the local stored keys?
Since 14. October it seems to me that there is only one hash per day exchanged. Why? Instead of an improvement (wish that number of OWN recorded contacts were shown) the information content is even worse. For seeing the daily numbers of downloaded keys only https://micb25.github.io/dka/ (Diagnoseschlüssel) remains. Great success; compliment.
@Peter-Einhausen Could you share a screenshot from the screen where you see that "only one hash per day is exchanged"
Are you using iOS or Android?
@Peter-Einhausen
Since 14. October it seems to me that there is only one hash per day exchanged. Why?
You're on Android, right? This observation is probably due to the different way CWA 1.5 handles the key handover to the Exposure Notification Framework (ENF). Instead of handing over 14 separate packages potentially DoS'ing ENF and causing timeouts, CWA 1.5 under Android now submits all packages in one batch (cf. PR 1088, PR 1150).
Although 14th Oct seems a bit early as CWA 1.5 only became available on the play store on Oct 19 🤔.
Confirmed, 14.10. is a typing error. Up to 19.10. each day 14 hashs, till 20.10. only 1. Confirmed, I use Android. Screenshuts attached.
The next versions will contain some statistics (https://github.com/corona-warn-app/cwa-app-ios/pull/1807 & https://github.com/corona-warn-app/cwa-app-android/pull/2043).
Motivation
There is currently no way as far as I know, to verify properly that the app is really sending and receiving tokens in all situations, e.g. when phone is on Battery Saver, Sleep mode etc.
Since the app was tested only on a small subset of devices in a small subset of use case, it's necessary to be able to verify by the interested public at large that the app is doing its job properly under all circumstances and report bugs when this is not the case.
Suggestion
Please add a way to see communication logs under settings in some sort of way. For example, a time stamp every hour with summary info on how often beacons were sent and how often beacons were read (not how many were seen, just to check that it's running properly). In addition, it'd be good if the logs mentioned if connection to the server is working as expected.
I feel very unsure about whether the app is doing its job properly. In normal usage, many possible bugs are not visible at all. Since one doesn't expect to be positive or be in contact with other positive people.
Internal Tracking ID: EXPOSUREAPP-5018 (statistics overview) Internal Tracking ID: EXPOSUREAPP-2136