Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Optional Personal Logging of Location of Exposure #199

Closed
jangtze opened this issue Oct 6, 2020 · 5 comments
Closed

Optional Personal Logging of Location of Exposure #199

jangtze opened this issue Oct 6, 2020 · 5 comments
Labels
feature request A new feature proposal for the app

Comments

@jangtze
Copy link

jangtze commented Oct 6, 2020

Feature description

Add an option to allow users to ...

  • either permanently
  • or temporarily ( by time-out selection / by store until leave this place / you name it )
    ... use the devices location data (via WiFi / GPS / whatever is shared by the device) to store where IDs have been recorded.

Benefit

  • low effort logging
  • identification of risk locations / meetings
  • possibility to warn app non-users whilst keeping high privacy

Problem and motivation

As a user of the CWA I have tried to convince people to also install the app. Talking to different groups it seems to me that there are three main reasons or hesitations why they do not want to use the app:

  1. privacy concerns
  2. disregard of the dangers of the virus
  3. lack of benefit / features of the app

to 1) Even though some of these persons do use smartphones / social media / more concerning services, I could not convince them. This leads me to the conclusion, that either my persuasiveness is insufficient, the actual reasons were others or they can not possibly be convinced. Which does not change if this feature would be added.
to 2) Similar to 1: hard to persuade.
to 3) I can not argue with that, because I agree. As many other feature requests show, the app could be more beneficial in order to attract more users ( compare #138 #196 #77 #70 ). This is especially true as one argument is, that too few people use it to be really effective.

Whilst I would prefer automated solutions like using

... I see this proposal to be easier to implement as a first step and adding functionality on top of #196 (which to my understanding is being considered [1] ). We would get a low effort logging which enables app users to actively contribute even with many non-users. Thereby I mean users could identify the place of exposure and warn other non-users. Whilst this would theoretically allow easier identification of users please consider following scenario:

Scenario

Sports events inside or outside with only few users of the app. One non-symptomatic person has contact to (infects) several people, is later tested and warns others.
[With this feature] If one of the warned gets even just a rough location information, can quickly identify where the contact happened and forward the information to someone responsible in the club. Then the future i.e. training sessions can be temporarily canceled and possibly infected can be warned.
[Without this feature] If there is no location information, the aforementioned cannot be done as quickly and another i.e. training session could be held, where the infected further spread the disease.

At the point when the whole sports club is getting shut down after authorities identified it, the same possibilities of identification apply anyways.

notes

[1] at the starting time of writing this that comment was not present yet I hope this is not seen as duplicate now.
[1] Same applies to #198. Though, I would like to adress the privacy concern comment there:
The positional information could only be visible if one received a warning including such IDs.

@jangtze jangtze added the feature request A new feature proposal for the app label Oct 6, 2020
@daimpi
Copy link

daimpi commented Oct 18, 2020

@jangtze I'll quote my reply from here:

your current proposal is not feasible within the ENF and CWA framework. If you have an Android device you can get this functionality by using corona-warn-companion in RaMBLE mode though.

@jangtze
Copy link
Author

jangtze commented Oct 18, 2020

@daimpi Thank you for your reply. However, I am not suggesting saving every ID / key with time stamps and locations; even though that implementation would easily allow for such feature.

I am asking for a connection of location logging functionality with the IDs in rough time periods (I checked briefly and at least apples ENF description mentions periods - be it days).

Nonetheless I thought about ways to maybe allow shorter time periods than whole days. Please consider these:

  1. The CWA in the current form must be able to receive the IDs more than just once per day, is it not? Then one could save the list of IDs at the start time (triggered by user or arrival at new location), after and get the difference. Is this feasible? How frequently can one check the ID-list?
  2. In case the internally stored list can be read out only once per day. Couldn't the CWA save the bluetooth keys itself then? They are neither particularly secret nor only detectable by the framework. Obviously, then compare location-IDs in case risk encounter-IDs are found.
    (To me as an amateur this kind of logging seems to be possible even for third parties or non-officials; except for the comparison to risk-IDs)

@daimpi
Copy link

daimpi commented Oct 18, 2020

@jangtze

  1. The CWA in the current form must be able to receive the IDs more than just once per day, is it not? Then one could save the list of IDs at the start time (triggered by user or arrival at new location), after and get the difference. Is this feasible? How frequently can one check the ID-list?

I assume you mean rolling proximity identifiers (RPIs)?
Recording/sending and matching RPIs is done by the Google/Apple Exposure Notification Framework (ENF) not by CWA.
CWA doesn't come into contact with the RPIs, they're all (intentionally) handled within ENF.

Additionally: ENF based apps (like CWA) are not allowed to request location permissions by Google/Apple.

  1. In case the internally stored list can be read out only once per day. Couldn't the CWA save the bluetooth keys itself then? They are neither particularly secret nor only detectable by the framework. Obviously, then compare location-IDs in case risk encounter-IDs are found.

The stored RPIs cannot be read (unless you have root) by you or CWA. ENF is fully responsible for handling those and CWA is only getting the final results handed over via the API.

(To me as an amateur this kind of logging seems to be possible even for third parties or non-officials; except for the comparison to risk-IDs)

Yes, an external app can record the RPIs (at least under Android) and do their own matching, this is exactly what the corona-warn-companion app uses in RamBLE mode 🙂.
CWA cannot do this because this is not allowed for ENF apps by Google/Apple. See this thread for further discussion on this topic.

@jangtze
Copy link
Author

jangtze commented Oct 21, 2020

@daimpi ... well, that is a bummer.

[...] Recording/sending and matching RPIs is done by the Google/Apple Exposure Notification Framework (ENF) not by CWA. [...]

Yes, I did not know the official terms "Rolling Proximity Identifier (RPI)" and "Temporary Exposure Key (TEK)" (glossary). Neither did I know that CWA actually has no access to the list of RPIs. But the provided link states it more clearly than what I found on Apples description page.

Quote from the API-page on what the app should do:

  • Provide the files with the diagnosis keys and associated metadata (following the file format) from your internet-accessible server to Google Play services.

  • Retrieve keys from the on-device data store and submit them to your internet-accessible server after one of the following conditions is present:

    • A user has been confirmed by a medical provider to have tested positive.

    • A health authority authorized a user-initiated self-report based on symptoms (if your app supports this use case).

    In both situations, the user must provide consent before the keys are provided to the app.

To this point I thought CWA would handle the comparison and thus have access to local keys at any time it wants.

Additionally: ENF based apps (like CWA) are not allowed to request location permissions by Google/Apple.

Same; did not know about that. Thank you for the clarification.
Seemingly the big-data monopolies don't even share with governments #tinfoilhat ;)


In my humble opinion this is a bad, too restrictive design by Apple/Google assuming 100% adoption. I mean even if a population of a country (not malignant governments) wanted such access in order to track foci of infection (which this suggestion was not about!), it was not able to, officially. And especially considering the ease of doing that anyways with solutions similar to the companion you mentioned.

Moreover, the "Exposure Notifications Express"-update would seemingly render the CWA unnecessary?

Not having to develop such Apps as CWA and Apple/Google kind of "forcing" users to adoption is not a bad thing, but after everything I learned from your replies all the good ideas to improve on the functionality are fundamentally not feasible.

No offence, maybe take from this to pressure a bit on Apple/Google.
Once again, thank you for your replies and I suppose this can be closed.

@daimpi
Copy link

daimpi commented Oct 21, 2020

@jangtze glad I could help 🙂

In my humble opinion this is a bad, too restrictive design by Apple/Google assuming 100% adoption. I mean even if a population of a country (not malignant governments) wanted such access in order to track foci of infection (which this suggestion was not about!), it was not able to, officially. And especially considering the ease of doing that anyways with solutions similar to the companion you mentioned.

I sympathize with your sentiment there. Otoh having such tight restrictions in place guarantees that certain privacy standards will be met at least wrt the app/ENF system. Tbh I haven't thought enough about the implications which certain relaxations would bring to have confident opinions on this matter in either direction though.

Moreover, the "Exposure Notifications Express"-update would seemingly render the CWA unnecessary?

Again: I haven't looked enough into this but one thing which CWA has over ENE is the digital transmission of testresults from the labs, which I think is quite useful 🙂

Once again, thank you for your replies and I suppose this can be closed.

You're welcome. As the author you can close this issue yourself if you want 🙂.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature request A new feature proposal for the app
Projects
None yet
Development

No branches or pull requests

2 participants