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

Crowd-source measurements #131

Open
haveyaseen opened this issue Apr 22, 2020 · 3 comments
Open

Crowd-source measurements #131

haveyaseen opened this issue Apr 22, 2020 · 3 comments
Labels
discussion Topics of interest to the project help wanted Extra attention is needed

Comments

@haveyaseen
Copy link
Contributor

haveyaseen commented Apr 22, 2020

Collect and analyze raw data in a testing phase to make risk calculations more precise.

  • User activities (walking, shopping, talking)
  • Phone location (pockets, out of pockets, in a room)
  • RSSI
  • Device model
  • Percentage of infected users
  • Total amount of users

What do you think? Expert opinions are highly appreciated.

@haveyaseen haveyaseen added discussion Topics of interest to the project help wanted Extra attention is needed labels Apr 22, 2020
@assert-not-singularity
Copy link
Member

assert-not-singularity commented Apr 27, 2020

Checking if someone is talking is very critical in my opinion: This should require the app to have access to the microphone and could make the app less trustworthy to a major part of the user base. If we are communicating that we only collect anonymized IDs via Bluetooth, why do we need access to the microphone?

@haveyaseen
Copy link
Contributor Author

haveyaseen commented Apr 27, 2020

There isn't necessarily a need for microphone access, and I would assume that determining if someone is talking is an entire project itself.

I've been thinking about it a little and I think the user should set this metadata themselves and later send the collected to the server, together with a few random values. This could even be part of the live app when using differential privacy (algorithms like RAPPOR, Encode-Shuffle-Analyze) to randomize the relevant fields.

@joernb
Copy link
Member

joernb commented May 3, 2020

Just some technical thoughts about how to integrate those capabilities into the codebase:

A key question is, wether or not additional measuring capabilities should all become part of the public app or if there will be different versions for different audiences (e.g. a closed testing audience). If there will be different versions, maybe those capabilities can be implemented using build-time feature toggles. Environment variables during the build process could switch certain features on or off. That would allow to build different versions of the app with different capabilities including a version with enhanced measuring for a closed test audience for example. A transparent/public build and deploy pipeline could show the feature toggles used during the build. The feature toggles could be documented (e.g. regarding their potential affection of privacy) to address concerns.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
discussion Topics of interest to the project help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants