You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 16, 2020. It is now read-only.
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?
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Collect and analyze raw data in a testing phase to make risk calculations more precise.
What do you think? Expert opinions are highly appreciated.
The text was updated successfully, but these errors were encountered: