Skip to content
Snippets Groups Projects

brainstorming

Last edited by Alexander Færøy

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?

Comments

    Please register or sign in to add a comment.