-
Notifications
You must be signed in to change notification settings - Fork 283
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
[FEATURE-REQ]: geo-hashing of GPS data #806
Comments
I am now quite strongly against 7 char precision, and think it needs to be 8 char (even though 8 char precision depends on GPS accuracy in Safe Paths that we have not achieved yet - see SAF-175). A 7 char geohash in an urban center will cover a dozen or more businesses. See illustrations in here: Even moving to a 30 min detection window won't prevent false positives from people who spent 30 mins in the other 11 or so uninfected businesses. Also, 7 char geohashes reduce entropy by 32x and hence make the hashed data 32x easier to crack - so actually makes privacy worse than the more specific 8 char geohashes. |
For anyone who wants to work on tis please see Jira SAF-268 for a proposed alternate plan of attack. Same basic outcome, but proposing different sequencing to ensure Safe Paths & Safe Places retain compatibility as much as possible during this change. |
Right now we obtain GPS data in raw (latitude, longitude) and store it in the encrypted format (Not sure if PR is merged). Another thing we want to add in this storage is the storage of Geohash of the raw data in 7 bit precision (which is equivalent of the 76m accuracy). For the first pass let's only store one geohash and in subsequent PR we will be storing geohash of the corners or edges of the squares.
See this old PR on how to add geohashes - relevant file diff from the pr
Issue type
Feature request for relatively tighter security.
The text was updated successfully, but these errors were encountered: