|
|
Tor PrivCount meeting
|
|
|
Date: 10AM-11AM, 2017-10-14
|
|
|
|
|
|
Agenda:
|
|
|
- Summarize current status of PrivCount (e.g. proposals)
|
|
|
- Develop list of things to do to get PrivCount into Tor (especially next 6 months)
|
|
|
- Who/When/Money
|
|
|
|
|
|
Current status of Tor statistics and PrivCount
|
|
|
- Current Tor statistics have ad hoc privacy methodology
|
|
|
- Different noise methods and collection periods
|
|
|
- Binning (i.e. rounding) used to provide some privacy
|
|
|
- Most statistics are every 24 hours, bandwidth statistics every 4 hours
|
|
|
- Some onion-service statistics have differential privacy
|
|
|
- No aggregation currently, all per-relay statistics
|
|
|
- Current Tor methodology is unsafe
|
|
|
- Bandwidth statistics enable guard discovery attacks
|
|
|
- PrivCount can be used to improve safety of Tor statistics
|
|
|
- Provides aggregation across relays and over time
|
|
|
- Provides differential privacy
|
|
|
- Exists a proposal (#280) for integrating Tor into PrivCount
|
|
|
- Just provides basic aggregation functionality
|
|
|
- No specific statistics
|
|
|
- A set of functions for noise, blinding, and value encryption has been implemented in Tor (not yet been merged)
|
|
|
|
|
|
Who/When/Money
|
|
|
- Network team will spend time getting proposals in place
|
|
|
- Prop. 280 rewrite
|
|
|
- Noise proposal
|
|
|
- Versioning proposal
|
|
|
- Robustness (i.e. protection from outliers)
|
|
|
- Major implementation work should happen February to August
|
|
|
- Tim Wilson-Brown will be helping
|
|
|
- Nick Mathewson is interested in helping
|
|
|
- Tayler may help, especially if there is an overlap with Bandwidth Authority work
|
|
|
- Sponsor Q (NSF) can support work, expires August 2018
|
|
|
- Metrics team has reserved slot to work on PrivCount integration
|
|
|
- Will rely on basic infrastructure being put into place
|
|
|
- L(arge) task reserved for PrivCount work in next 12 months
|
|
|
- iwakeh should be helping
|
|
|
- PrivCount is on roadmap for both Metrics and Network teams, and Funding team will thus be looking for funding for it
|
|
|
|
|
|
Plan for integrating PrivCount
|
|
|
- Who will run the Tally Reporters
|
|
|
- Probably not Directory Authorities (they are overloaded)
|
|
|
- Goal could be for security level similar to Directory Authorities
|
|
|
- Working with Tor Metrics team
|
|
|
- Noise affects how metrics should be interpreted
|
|
|
- Versioning affects what statistics are available
|
|
|
- Robustness can affect what statistics succeeded and thus are available
|
|
|
- Deployment probably involves Metrics team
|
|
|
- Metrics should go through statistics to consider which ones can/should be transitioned to PrivCount
|
|
|
- Consider how noise will affect accuracy of results
|
|
|
- Consider how lack of robustness might affect DoS of results
|
|
|
- Consider which new statistics might now be possible to report safely
|
|
|
- Implementation challenges
|
|
|
- Floating point issues ("On the significance of the least-significant bits" paper, snapping/rounding solution)
|
|
|
- Perhaps use assumptions about integrality of value to simplify sampling properly from desired distribution
|
|
|
- Testing methodology |
|
|
\ No newline at end of file |