Changes between Initial Version and Version 1 of org/meetings/2017Montreal/Notes/PrivCount


Ignore:
Timestamp:
Oct 14, 2017, 10:41:45 PM (23 months ago)
Author:
alison
Comment:

added notes

Legend:

Unmodified
Added
Removed
Modified
  • org/meetings/2017Montreal/Notes/PrivCount

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