PrivCount makes Tor relay statistics more secure. It secure aggregates and adds noise to Tor relay statistics, which makes it much harder to identify individual tor users from their network usage. PrivCount uses differential privacy to ensure that the final statistics hide individual users' activity.
PrivCount makes Tor relay statistics more secure. It secure aggregates and adds noise to Tor relay statistics, which makes it much harder to identify individual tor users from their network usage. PrivCount uses differential privacy to ensure that the final statistics hide individual users' activity.
== Background ==
## Background
=== Proposals ===
### Proposals
* [https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with-shamir.txt Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)]
*[Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)](https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with-shamir.txt)
* [https://gitweb.torproject.org/torspec.git/tree/proposals/280-privcount-in-tor.txt Proposal 280: Privacy-Preserving Statistics with Privcount in Tor] (Superseded)
*[Proposal 280: Privacy-Preserving Statistics with Privcount in Tor](https://gitweb.torproject.org/torspec.git/tree/proposals/280-privcount-in-tor.txt)(Superseded)
=== Notes ===
### Notes
* [wiki:org/meetings/2018MexicoCity/Notes/PrivCount Mexico City 2018: PrivCount In Tor Status]
*[Mexico City 2018: PrivCount In Tor Status](./org/meetings/2018MexicoCity/Notes/PrivCount)
* [wiki:org/meetings/2018MexicoCity/Notes/PrivCountTechnical MexicoCity 2018: PrivCount In Tor Technical Workshop]
*[MexicoCity 2018: PrivCount In Tor Technical Workshop](./org/meetings/2018MexicoCity/Notes/PrivCountTechnical)
* [wiki:org/meetings/2018Rome/Notes/PrivCountInTor Rome 2018: PrivCount In Tor Explanation]
*[Rome 2018: PrivCount In Tor Explanation](./org/meetings/2018Rome/Notes/PrivCountInTor)
* [wiki:org/meetings/2018Rome/Notes/PrioritiseStatisticsForPrivCountInTor Rome 2018: PrivCount In Tor Statistics Priorities]
*[Rome 2018: PrivCount In Tor Statistics Priorities](./org/meetings/2018Rome/Notes/PrioritiseStatisticsForPrivCountInTor)
* [wiki:org/meetings/2018NetworkTeamHackfestSeattle/privcount Seattle 2018: PrivCount In Tor Planning]
*[Seattle 2018: PrivCount In Tor Planning](./org/meetings/2018NetworkTeamHackfestSeattle/privcount)
* [wiki:org/teams/NetworkTeam/PrivCountInTor/PrivCountResearchRetrospective July 2018: PrivCount Research Retrospective]
*[July 2018: PrivCount Research Retrospective](./org/teams/NetworkTeam/PrivCountInTor/PrivCountResearchRetrospective)
== Next Steps ==
## Next Steps
Optimise for "simplest possible decisions at first" so that we can deploy it.
Optimise for "simplest possible decisions at first" so that we can deploy it.
* need to design api for allocating noise using an optimisation method that aaron created. for that we need an action bound and estimated value. the estimated value is not a security parameter; the action bound is
* need to design api for allocating noise using an optimisation method that aaron created. for that we need an action bound and estimated value. the estimated value is not a security parameter; the action bound is
* See https://github.com/privcount/privcount/blob/master/privcount/statistics_noise.py
* See https://github.com/privcount/privcount/blob/master/privcount/statistics_noise.py
...
@@ -59,27 +59,27 @@ Optimise for "simplest possible decisions at first" so that we can deploy it.
...
@@ -59,27 +59,27 @@ Optimise for "simplest possible decisions at first" so that we can deploy it.
* if we ran privcount on all our current statistics, how many of them would we not be able to collect anymore because it's not possible to add sufficient noise.
* if we ran privcount on all our current statistics, how many of them would we not be able to collect anymore because it's not possible to add sufficient noise.
=== Cryptography ===
### Cryptography
* Should we do a multi-level thing for the signing keys? That is, have an identity key for each TR and each DC, and use those to sign short-term keys?
* Should we do a multi-level thing for the signing keys? That is, have an identity key for each TR and each DC, and use those to sign short-term keys?
=== Configuration ===
### Configuration
* How to tell the DCs the parameters of the system, including:
* How to tell the DCs the parameters of the system, including:
- who the TRs are, and what their keys are?
- who the TRs are, and what their keys are?
- what the counters are, and how much noise to add to each?
- what the counters are, and how much noise to add to each?
- when the collection intervals start and end?
- when the collection intervals start and end?
=== Transmission ===
### Transmission
* What to say about persistence on the DC side?
* What to say about persistence on the DC side?
* How data is uploaded to DCs?
* How data is uploaded to DCs?
=== Aggregation ===
### Aggregation
* How the TRs agree on which DCs' counters to collect?
* How the TRs agree on which DCs' counters to collect?
