wiki:org/sponsors/SponsorF/Year3

Version 11 (modified by karsten, 7 years ago) (diff)

Add expected outcome to item 2.

Phase 1 (February 28, 2013)

MUST DO

  • 1. Nick helps Vinod track Vinod's libevent/Stegotorus bug. [Nick]

The expected outcome of this deliverable is to make significant progress in characterizing the bug, ideally to either say that the bug is in libevent and fix it, or to say that there's no such bug in libevent and to fix the bug in StegoTorus. If a complete diagnosis or fix requires a lot more work than expected, it may be delivered at a later date in year 3.

  • 2. Let directory authorities advertise IPv6 addresses, so IPv6 clients can bootstrap directly into the Tor network without needing a bridge. (#6027) [Nick]

The expected output of this deliverable is a Tor branch that includes a set of initial directory caches with IPv6 addresses for use by clients which cannot talk to IPv4 relays, and code so that these clients correctly restrict their direct connections to nodes with IPv6 addresses once they find out they cannot bootstrap via IPv4.

  • 3. Continue working with the Shadow and ExperimenTor developers to help them improve their ability to accurately simulate Tor networks. And do that for the Deterlab folks too. [Roger, Karsten]
  • 4. Continue working with external researchers (including other groups getting funding, like the NRL group) so their Tor results are more likely to be useful in practice. For example, Aaron Johnson is working on network diversity metrics. Making sure we have enough "support developers" like Sathya will mean our data/scripts are easier for people like Aaron to use. [Roger, Sathya, Karsten]
  • 5. Evaluate, possibly revise, and implement proposal 195 (TLS certificate normalization). (#7145) [Nick, Andrea, Jake, ??]

HOPE TO DO

  • 6. Start 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. (#7137) [Philipp, Runa, many]

The expected outcome of this deliverable is a blog post or technical report sketching out the requirements and the technical feasibility of a user-friendly Tor censorship analyzer based on OONI.

  • 7. Either support the pluggable transport interface that StegoTorus expected us to have (i.e. no longer require transports to be socks proxies), or write up a recommendation for how to interface with Tor correctly if you're in StegoTorus's situation. (#7153) [Nick, Andrea, George; we'll need Zack to explain the current rationale]

The expected outcome of this deliverable is to figure out what the right answer for StegoTorus is and write it up, and if possible and time permits, implement any required Tor changes in a Tor branch.

  • 8. Make Torperf results more realistic -- real web pages average 320KB and contain multiple components. We can track the performance we see fetching a given artificial web page over time, and/or the performance of the Facebook page as it and Tor both change over time. (#7168) [Karsten, Ian, ??]
  • 9. Make further progress on the pyobfsproxy framework, including getting it in use by some actual user somewhere to make sure it's going in the direction we want. (#5614) [George]

The expected outcome of this deliverable is: 1) a working set of instructions for running a pyobfsproxy bridge on Debian; 2) a trial TBB for Windows with pyobfsproxy rather than obfsproxy; 3) research and potentially implement the use of pyptlib in flashproxy; 4) a scriptable integration test suite for pyobfsproxy.

Phase 2 (October 31, 2013)

MUST DO

  • 10. UDP (or other smart transport) as underlying node-to-node transport: have a Tor branch that, when run as a separate Tor network, layers an in-order reliable transmission protocol over UDP packets (or other smart transport) on the wire (ideally with some link encryption like ipsec over that). Be thinking about transition / deployability. [Nick, Andrea, ??]
  • 11. Combine traffic obfuscation (DPI-resistance) with address diversity of flash proxy. (#7167) [David, George, Nick, Andrea, ??]
  • 12. Determine how to safely record and report user statistics for obfsproxy bridges. Then get some statistics up on the user metrics page. [Nick/Andrea, George, Karsten]
  • 13. Write a proposal for N23, and write a patch for N23 that functions correctly. Then simulate it to see how it performs for typical and for really slow client connections. (#4506) [Nick, Andrea, Roger, Rob, Ian]
  • 14. Evaluate alternate scheduling algorithms for choosing which relay to push bytes to (and/or read from) next. Right now we choose fairly between all relays, and maybe choosing weighted by bandwidth (or by which connection recently gave us a cell for a high-priority circuit) is better. (#4585) [Nick/Andrea, Rob, Roger, Karsten]
  • 15. Investigate raising the minimum bandwidth for getting the Fast flag. This involves looking at diversity implications (since we'll have fewer relays), and also at performance implications (since we'll have fewer slow relays, but less capacity). (#1854) [Sathya, Karsten, Roger]
  • 16. VoIP support: make a proof-of-concept push-to-talk VoIP variant for Android that tolerates high latency because users use it differently (e.g. "record an mp3, send it through the network, play it on the other side"). (#5700) [Nathan, ??]

HOPE TO DO

  • 17. VoIP support: pick an existing VoIP client (like mumble), and write instructions for using it over TCP, even though it will be high latency and high variance. (#5699) [Nathan, ??]
  • 18. Improve configuration options and instructions for running private Tor networks in testing and simulation environments. Making TestingTorNetwork smoother and more reliable will be useful for Shadow (Rob keeps running into bugs where his testbed network behaves funny due to TestingTorNetwork), and it would also be useful for the Deterlab folks (who also ran into bugs with their internal Tor deployment). Maybe that's best done by improving Chutney so we can notice problems, or maybe it's best done by embracing Shadow. (#7172) [Nick, Andrea, Roger, Linus]
  • 19. Let users configure a public relay to be their bridge without crashing, since an increasing number of demo scenarios involve picking a public relay as your bridge. (#1776, #7174) [Nick, Andrea]
  • 20. Prototype integration of Defiance's client-side components (qtapp, acs-dancer) into the Tor Browser Bundle, starting with implementing the necessary components of proposal 199 -- unless the modfreedom code is so unlike the expected API that we instead need to recommend changes to how modfreedom wants to interface to Tor. Note: we'll only look at open-source published tools/documents, so while these components aren't open, we won't be making progress here. Nick, Andrea, Mike, Erinn
  • 21. Evaluate SponsorF's plans to stick a normal-looking apache (or better, nginx) server in front of the Defiance Tor component, and compare them to our proposal 203 ("Avoid censorship by impersonating an HTTPS server"). Make any necessary Tor-side changes, and make recommendations on what needs to change on the webserver side. Note: we'll only look at open-source published tools/documents, so while these components aren't open, we won't be making progress here. [Nick, Andrea, George, Roger]
  • 22. Evaluate classifiers for deciding which clients to throttle, and how much, a la Rob Jansen's Usenix Security 2012 paper. Implement a promising approach, simulate a network where everybody does it, and also try it on a real relay. (#5190) [Rob, Roger, Karsten]
  • 23. Patch the Tor Browser Bundle so it starts using Tor's "optimistic data" feature. (#3875) [Mike, Tau]

Project tickets

Open project tickets

Ticket Summary Keywords Owner Component
#7153 Don't require pluggable transport proxies to be SOCKS proxies SponsorF20130228, needs-spec-change, needs-tor-change Circumvention/Pluggable transport

Closed project tickets

Ticket Summary Keywords Owner Component
#3875 TBB's Firefox should use optimistic data socks handshake variant tbb-performance roundtrip MikePerry201304 tbb-bounty SponsorF20131101 tbb-no-uplift mikeperry Applications/Tor Browser
#6027 Directory authorities on IPv6 ipv6, tor-auth, SponsorF20130315, 026-triaged-1, 026-deferrable, nickm-patch, 027-triaged-1-out, pre028-patch Core Tor/Tor
#7137 Build a tool that a censored developer can run to discover why their Tor is failing to connect SponsorF20130228 Circumvention/Censorship analysis
#7145 Evaluate, possibly revise, and then implement ideas for TLS certificate normalization SponsorF20130228 tor-client nickm Core Tor/Tor
#7167 Combine traffic obfuscation with address diversity of flash proxy SponsorF20131101 flashproxy fog asn Circumvention/Pluggable transport