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
The current app has a couple of shortcomings in terms of privacy. Both of these involve the server potentially being able to (attempt to) identify people and patterns, even though the design is anonymous in theory. If whoever controlled the server wanted to, there are a couple ways they could try to violate people's privacy.
Network analysis. The current design generates a graph of interactions, which the server has full access to. Even though these are anonymous in theory, some network analysis coupled with IP address logging could in theory compromise privacy.
Identifying COVID-19 positive patients by IP address. Because users are allowed to self-report through the app, the server to track the IP address associated with network requests to report positive status. This could potentially be used to identify people.
I believe there are simple fixes for both of these issues.
First, we need to abandon the concept of generating a graph of interactions. This means we can no longer trace potential chains of transmissions past the first degree, but this should be fine. One degree is most likely enough.
Second, we should not allow users to directly report their status through the app. Instead, they should be able to export their checkpoint history to a JSON file, which can be then sent to their doctor via encrypted email, in the case that they have a positive test for COVID-19. Their doctor can then upload these to the server on their behalf; now, the IP address should just trace back to a public computer at a clinic, rather than the patient's device. (This also takes care of the issue of users lying about their status; only authorized personnel would be allowed to upload exposed checkpoints.)
Third, user devices should not request individual checkpoint statuses from the server, as the server could infer from these requests which checkpoints belong to which IP addresses. Instead, each device should download the entire database of exposed checkpoints over the last X number of days (ie the ones that are still relevant). If this database grows too large, it could be split into chunks based on the first character or 2 of the checkpoint id. This would reduce the amount of data a device would need to download while still preserving anonymity.
This essentially just requires some pretty simple rearchitecting of the backend. The user experience should stay unchanged, except for the part where users self-report. The self-report button would be replaced by a download button.
The text was updated successfully, but these errors were encountered:
This has now been done on the v2 branch. You can get all of the source code there. It is functional as an MVP and addresses the concerns above.
I will not deploy a live demo of this for now, but if you are interested in setting this up in your community, please feel free to reach out. I would definitely recommend using v2 for real-world use cases due to the added privacy protection.
The current app has a couple of shortcomings in terms of privacy. Both of these involve the server potentially being able to (attempt to) identify people and patterns, even though the design is anonymous in theory. If whoever controlled the server wanted to, there are a couple ways they could try to violate people's privacy.
I believe there are simple fixes for both of these issues.
This essentially just requires some pretty simple rearchitecting of the backend. The user experience should stay unchanged, except for the part where users self-report. The self-report button would be replaced by a download button.
The text was updated successfully, but these errors were encountered: