| 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 wll 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.
In order for For other Safe Paths users to be able to receive exposure notifications, without sharing their own location data, this data needs to be made accessible to other Safe Paths users. We do so in a manner that allows the Safe Paths app to detect matches on specific locations and times, while making it difficult (though not impossible) for anyone to actually view the set of locations and times that represent these “points of concern”. For details on how we do this, see below.
...
Keeping uninfected users' data on their phones
Redaction and anonymizaton anonymization of data before storing or publishing.
...
The approach that we take is approximately that outlined in section 5 of this paper as an “Intermediary Implemetation” Implementation” https://arxiv.org/pdf/2003.14412v2.pdf, though with some variations in the detail.
In summary:
Prior to publication, each “point of concern” 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 only in that hashed formform.
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.
...
This results in a match area of around 1660 sqm at the equator, 1200 sqm at 45 degrees north, so qpproximately approximately the same area as a 2om radius circle, but with a slightly less predictable shape.
...
Since the space of locations and timestamps for a given Health Authority is realtively relatively small, it has low entropy, and the overall level of protection we can provide against brute force attacks is limited.
...
The main purpose of this article is to present our approach to data privacy. However some of the points raised here may raised broader concenrs concerns around effiacacy efficacy of location-based exposure notifications.
...
Why not just use Bluetooth for Exposure Notifications?
It is true that BuetoothBluetooth-based Exposure Notifications promise greater accuracy than location-based exposure notifications, and avoid some of the privacy concerns that we have described on this page.
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.
...
Using FHE, we have a design that would require every single comparison of data points its data set against a given point of concern to require consultation with a key server, in order to determine whether there was in fact a match.
...