|
|
Session notes from Fri, 24 Mar, 13:30: What could metrics and measurements look like in 5 years?
|
|
|
|
|
|
GATHER DATA
|
|
|
* Deploy multiple ways to measure each thing (e.g. number of users), and analyze why they differ.
|
|
|
* Graph analysis of circuit build failures and find network partitions.
|
|
|
* Evaluate other GeoIP sources than MaxMind.
|
|
|
* Add GeoIP data update mechanism, possibly after analyzing how often relays receive new GeoIP data right now.
|
|
|
* Add client measurements: number of clients, number of mobile clients, mobility of clients, types of applications run by clients; without necessarily measuring on clients directly.
|
|
|
* Separate the metrics module/process for metrics collection from the Tor daemon.
|
|
|
* Automatically test if bundled bridges still work and tell the Tor Browser people.
|
|
|
* Include Internet path measurements to and from Tor relays: performance, ASes traversed, countries on the path, etc.
|
|
|
* Use the Tor process to record circuit build failures and detect partition attacks.
|
|
|
* Look for rate limiting after a higher bandwidth. Might indicate rate limit confirmation.
|
|
|
* Detect possibly benign anomalies: client using many guards simultaneously, uploading many descriptors to an HSDir, etc.
|
|
|
* Measure abuse committed with Tor: port scans, SSH bruteforce attempts, exploitation of server vulnerabilities, copyright violations, etc.
|
|
|
* Detect and report many types of attacks (bandwidth DoS, circuit building attacks, TCP packet spoofing, etc.)
|
|
|
* Secure statistics aggregation with privacy guarantees (e.g. PrivCount).
|
|
|
* Detect flood of HS descriptors per HSDir, look for disagreement between HSDirs.
|
|
|
* Collect more types of benchmarks in OnionPerf (realistic web page models, etc.)
|
|
|
* Plan for alternative Tor implementations and how they might not report statistics.
|
|
|
|
|
|
USE DATA
|
|
|
* Users can create and share visualizations of Tor network data without writing a single line of code.
|
|
|
* Create an automated system to detect anomalies in the Tor network (censorship, Sybil attacks) without all the false positives and in almost real-time, and automatically identify real-world events that they correlate with.
|
|
|
* Include OONI data in queries together with metrics data.
|
|
|
* Use OONI data on censorship and compare with detection data.
|
|
|
* Use database for Onionoo that allows looking back in time.
|
|
|
* Allows users to annotate events and provide annotations on website as "community-provided content".
|
|
|
* Document what Tor network data exists and how it's being processes and analyzed: reproducible metrics.
|
|
|
* Visualize Tor's security with respect to different adversaries.
|
|
|
* Look for spikes in circuits created by guards.
|
|
|
* Make all statistics robust against single false reports by relays or bridges. |
|
|
\ No newline at end of file |