Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stats/charts of encounters over time? #3

Open
rhodes73 opened this issue May 21, 2020 · 3 comments
Open

Stats/charts of encounters over time? #3

rhodes73 opened this issue May 21, 2020 · 3 comments
Assignees
Labels
wontfix This will not be worked on

Comments

@rhodes73
Copy link

Is there any reason not to display stats/charts in the app about encounters over time to encourage social distancing?

Keeping stats on encounters should be straight forward to implement and might help people to get a feeling for how well they are distancing themselves from others. One could even gamify it like fitness apps that count steps or calories against goals people set for themselves.

I’m not familiar in detail with the technology used for the tracing apps and the state of this project, and therefore might overlook a lot of issues here, but I’m curious to learn if this would be a useful feature or if it is even planned already.

@maerki
Copy link

maerki commented May 27, 2020

This is not possible due to technical limitations. This information is not exposed by the Exposure Notification frameworks of Google and Apple, therefore we cannot add it to the UI.

With our original proximity tracing implementation, more data would have been available. But even then, we removed this information after the first prototypes because of several reasons:

  • The focus of the app is and should be purely to notify users if they might have been exposed to COVID-19
  • There is no technical concept of "contact" or "encounter" (and it cannot exist by design to ensure privacy). The only value that's possible to show is a counter of BLE-handshakes and this is very hard to understand for users.
  • The revealed information can be confusing or problematic, leading to more problems than it would solve, especially privacy issues.
  • Our UX tests showed that the information did not increase trust in the system, a clear signal like the "Tracing activated" message and an animated header was enough to ensure that the app is working correctly

@rhodes73
Copy link
Author

@maerki Thanks for the detailed response. Makes sense that it's not possible if this data is not exposed by the Exposure Notification frameworks.

What I meant with an "encounter", is what you more accurately call a BLE-handshake. I could not agree more that actual contacts should never be tracked for privacy reasons.

I also agree that stats about BLE-handshakes can be slightly misleading, e.g. there is no way to remove duplicate encounters coming from the device of a family member one is in frequent contact with. However, assuming keys/ids are changed only a couple of times an hour and duplicate keys are discarded when counting, the number of false positives would be rather low compared to the true positives one would for example trigger by walking into a crowded shop or restaurant. It could still be very interesting to look at the derivative of this data with respect to time or to relatively compare counts between two days or different times of day. People know what times of the day they are in contact with their family or work colleagues they meet every day and can then assess the corresponding stats differently. This data should always remain in the user's hands of course. It cannot necessarily be compared in absolute measures between any two people anyway, because people have very different social interactions depending on their jobs etc. This could be a feature for power users and people that care about more transparency.

@beckm-ethz
Copy link

It would still be nice to have a chance to verify that the tracing is active. Not everyone has access to a spectrum analyzer for the 2.4 GHz band, to verify that two phones using the app are actually talking to each other. I agree that this might not be necessary for the final release, but in the pilot version, it would be nice to have some diagnostic output. Not that e.g. some manufacturer-specific energy saving feature interferes with the tracing, making the "Tracing activated" message pure fake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants