| Info |
|---|
This is a draft. Master copy of this now in GitHub here: https://github.com/Path-Check/privacy-security/blob/master/documents/privacy.md |
Privacy is one of Safe Path’s our core values, and we aim to provide as much privacy as possible to users of the app.
...
Location data for undiagnosed users never leaves their device (i.e. this is a “decentralized” solution).
It is also encrypted at rest.
It is deleted after 28 days
The user can turn location tracking on & off whenever they like (either using the in-app setting, or their device settings).
...
Data is deleted when a user uninstalls the App.
We believe that this keeps the privacy risks associated with undiagnosed users to the absolute lowest level possible.
...
Sharing location data is always a choice on the part of a diagnosed user, with clear explanations provided about the purposes for which the data will be used.
Location data can only be shared with authenticated Health Authorities that have been approved by Path Check.
Location data is encrypted in transit, and at rest in the Health Authority’s database.
Prior to storage in the Health Authority databases, a Contact Tracer will review all provided data with the diagnosed user, and redact any information that either of them believes could reveal their identity.
Data is only stored in a databased owned and managed by the patient’s own Health Authority. There is no centralized store of location data.
The patient can also request that any other data point recorded is removed, for any reason they may have.
Data is only committed to the Health Authority database once the diagnosed user has given final consent regarding the set of data points stored.
Location data is stored as a set of places & times, with no data relating it back to any individual user, or correlating it to other location data points from the same user.
...
The approach that we take is approximately that outlined in section 5 of this paper as an “Intermediary Implementation” https://arxiv.org/pdf/2003.14412v2.pdf, though with some variations in the detail.
In summary:
Data is published by Health Authorities, to allow Mobile Apps to check locally for matches with “points of concern”.
Prior to publication, each “point of concern” is mapped from an exact latitude and longitude, to a geohash, and a 5 minute time window. This information is then hashed, using a slow consistent one-way hash algorithm, and published in that hashed form-way hash algorithm, and published only in that hashed form.
Each Health Authority publishes their data at a URL that they control, which is stored in an overall database of Health Authorities maintained by Path Check, and passed to the Mobile App when they register for Exposure Notifications from that Health Authority. This URL is not publicly advertised, or shown to users, but it can be easily determined by an attacker.
A Mobile App can assess a given location & time for exposure by computing the same geohash, time-window and hash, and checking for a match against the published data.
However, due Due to the use of a slow hash, it is expensive to check a large set of locations and/or times. And because the hash is one-way, it is impossible to reverse other than by computing the hashes for every possible point in the area & time period covered.
Below we provide details of the implementation, and the reasons for these. We then assess the level of protection that this scheme manages to provide.
Geohash tile size
We use 8 character Geohashes, which resolve to rectangular tiles that are 38m x 19m at the equator, and about 27m x 19m at 45 degrees north.
...
We are fully supportive of Bluetooth as a technology for Exposure Notifications (and are develping another App that exposure tracking and notification. Our Project Aurora[link] uses the Google / Apple Exposure Notifications API, we . We also believe there is an important role for location-based Exposure Notification systems, for the following reasons.
...