|
|
|
|
|
|
|
## Tor usage and metrics data:
|
|
|
|
* Correlate Tor metrics trends with other events of interest
|
|
|
|
|
|
|
|
* More accurate (but still safe) ways to count Tor users by country
|
|
|
|
|
|
|
|
* Automated censorship detector just from our metrics data: flag
|
|
|
|
statistical drops in usage from a country, with fewer false positives.
|
|
|
|
|
|
|
|
* Improve "torperf": Track realistic performance through the Tor network,
|
|
|
|
both over time as Tor network changes and over time as realistic
|
|
|
|
website changes.
|
|
|
|
|
|
|
|
* Compare Tor network capacity trends with torperf trends; make some
|
|
|
|
guesses about how they relate.
|
|
|
|
|
|
|
|
* Measure, and track over time, diversity of Tor relay locations.
|
|
|
|
|
|
|
|
* Track general Tor network usage trends (mean/median circuit length,
|
|
|
|
bytes handled, destination ports, requests per second, etc)
|
|
|
|
|
|
|
|
* compass.torproject.org, atlas.torproject.org, etc
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
## Censorship measurement / analysis:
|
|
|
|
|
|
|
|
* Track whether various circumvention tool transports succeed from various locations.
|
|
|
|
|
|
|
|
* Tor's TLS, Firefox's TLS, etc
|
|
|
|
|
|
|
|
* Obfsproxy's transports (high entropy / base64)
|
|
|
|
|
|
|
|
* Skype, Skypemorph, Stegotorus, FTE
|
|
|
|
|
|
|
|
* Packet sizes and volume that match Tor wire patterns.
|
|
|
|
|
|
|
|
* Reverse engineer, and start testing, transports from Ultrasurf, Freegate, etc
|
|
|
|
* Gmail connections
|
|
|
|
|
|
|
|
* Also track throughput achievable by each (e.g. Syria appears to be throttling all TCP connections).
|
|
|
|
|
|
|
|
* Can you, in an automated way, learn what DPI rules are being used on you?
|
|
|
|
Does that help identify what DPI vendor it is?
|
|
|
|
(For the simple version of this question, just consider that you're doing
|
|
|
|
TLS and they're looking for some characteristic of the SSL cert.)
|
|
|
|
|
|
|
|
* A tool that a censored developer can run to discover why their Tor is
|
|
|
|
failing to connect: brainstorm a list of ``things to check'', and sort
|
|
|
|
them by how useful they'd be to check / how hard they'd be to build.
|
|
|
|
|
|
|
|
* Reachability tests of Tor bridge addresses from various countries.
|
|
|
|
|
|
|
|
* Active (normal scanning)
|
|
|
|
* Just TCP connection; or TLS handshake; or TLS + Tor cells
|
|
|
|
|
|
|
|
* Passive: look at usage data that bridges report
|
|
|
|
|
|
|
|
* Indirect / reflector scans
|
|
|
|
|
|
|
|
* Clients self-report what they can / can't reach
|
|
|
|
|
|
|
|
* Analyze usage levels and blocking status of bridges based on what
|
|
|
|
distribution strategy pool they're in (https, gmail, social network).
|
|
|
|
|
|
|
|
* Better support for "Proximax" scheme
|
|
|
|
* Measure how much use each bridge sees
|
|
|
|
|
|
|
|
* Measure when each bridge gets blocked
|
|
|
|
|
|
|
|
* Adapt bridge distribution to favor efficient distribution channels
|
|
|
|
|
|
|
|
* (Need to invent new channels, need more and changing bridge addresses)
|
|
|
|
|
|
|
|
* OONI/Bismark: framework for running tests and automatically publishing
|
|
|
|
the results to a public database.
|
|
|
|
|
|
|
|
* Maintain / expand "censorship timeline": document what has happened in
|
|
|
|
the world so far (anecdotally) so others can analyze trends.
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
## Circumvention:
|
|
|
|
|
|
|
|
* Flashproxy scheme
|
|
|
|
* Better ways of reaching the "facilitator"
|
|
|
|
|
|
|
|
* Scanning-resistance: require users to prove knowledge of some credential
|
|
|
|
(e.g. by Defiance's "address knocking" scheme) before we'll act like
|
|
|
|
a Tor bridge. (Instead, we what? Act like an unconfigured apache?)
|
|
|
|
|
|
|
|
* Write some tools to redirect entire netblocks into Tor bridges, lighting up only the addresses that we want available at that time.
|
|
|
|
|
|
|
|
* Given a large set of address blocks, how should we give out the addresses in them in a way that maximizes their usefulness over time?
|
|
|
|
|
|
|
|
* Better ways to bootstrap handshaking for systems like Tor
|
|
|
|
|
|
|
|
* Secure dissemination of the bootstrapping information
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
## Other:
|
|
|
|
|
|
|
|
* Scanning Tor exit relays for misbehavior / brokenness? |