wiki:org/sponsors/SponsorF/Year1

Version 28 (modified by karsten, 6 years ago) (diff)

Name changed from sponsors/SponsorF/Year1 to org/sponsors/SponsorF/Year1

Definitions

Year 1: 1 December 2010 - 30 November 2011.

Phase 1 = 1st six months of project year 1.

Phase 2 = 2nd six months of project year 1.

Tasks without dates are assumed to be due end of phase.

Category A (highest priority): aka must do

  1. Support camouflaged transport

Phase 1

  • proposal for modular transport spec (before Dan's class starts; approx. 3/15). Roger, Nick, Tom. (#2758)
  • proof-of-concept transport plugins (for team use; not required for use by user in country): Nick, Tom, Steven
  1. Hooks / Support for Rendezvous SponsorF

(Needs better definition before Tor would know what work, if any, needs to be done.)

  1. Metrics Karsten, Tom.

Phase 1:

  • problem statement for DNS/ftp reflectors to measure bridge reachability (#2531)
  • problem statement for entropy-of-network analysis (#2530)
  • get bwauth and torperf data up on metrics.tp.o (#2394, #2534)
  • put bridge pool assignments on metrics.tp.o (#2537)

Phase 2:

  • analysis of passive bridge reachability data
  • analyze bridge churn (#2794)
  • write a censorship detector (similar to the consensus health checker) that analyses bridge stats as soon as they come in and sends early warnings about country-wide blocking events Tom, Nick? (#2718)
  1. Performance/scalability

Phase 1

  • a "comparison of datagram tor designs" analysis (May 1). Steven and others (#1855)
  • microdescriptor roll-out for client-side (May 1) Nick (#1748)
  • Bandwidth authority improvements Mike, Aagbsn, Tomb?
    • Better tracking for measurement feedback (#1976, attempt by June 1; succeed by Nov. 1)
    • Upgrade to new SQLALchemy release (#2391, June 30)
    • Help Aagbsn understand system, write spec (#2861, June 30)
    • Set up a 5th scanner (June 30)

Phase 2:

  • a "why else is tor slow" draft (Nov. 1) Roger
  • analysis for increasing the set of guards (Nov 1)
  1. Community

Phase 1:

  • meetings with sri, tor talk for stanford, interact with isi, interact with red team Roger, Mike (#3034)
  • write up research task summaries, and bibliography recommendations, for dan's class Roger (#2535)

Phase 2:

  • interact with red team and other teams All

Category B (lower priority): aka shall do

  1. Bridge user/operator usability

Phase 1

  • analyze security tradeoffs from using a socks proxy vs a bridge (#2764, #3292)
  • libevent2 working for windows bundles? (June 1) Erinn (#2007, others?)
  • bridge-by-default bundles (June 1) Erinn (#1538)

Phase 2

  • assess options for preventing relays from enumerating bridges. Analyze security of bridge users using guard-flagged relays for their middle hop, or of bridges forcing an entry guard as an extra hop.
  • bridgedb spec (#1606)
  • analyze FC paper proposing adaptive bridge address distribution
  • bridge users can remember bridges across restarts
  • tor integrates upnp / pmp for port forwarding without Vidalia?
  • bridges on ipv6

Category C (lowest priority): aka should do

  1. Cleaning up better (only if funded or volunteers found)
  • browser-level, solvable by torbutton
  • OS-level: provide SRI guidance on bundle usage
  1. torbutton, chrome/mobile Mike, Nathan?

Phase 1,

Phase 2:

  • Fork Firefox 4 for Tor Browser Bundle
  • CSS Font fixes
  • CSS media query/resolution fixes
  1. Cloud experiments Runa

Phase 1:

  • perform experiments on cloud providers, e.g., using the change-my-IP interface (does it work? what does it cost? other interesting issues) (#3033)
  1. Tor maintenance

Phase 1:

  • put out a tor 0.2.2.x stable release Nick, Roger (#3032)

Phase 2:

  • eliminate tls renegotiation Nick, Roger
  • proposal to support alternate crypto ops backward-compatibly Nick, Roger, Tom