Browse code

Dropping task priority and alphabetising

It has always irked me that we had a task 'priority'. Who decides these
priorities? Against what? Sure I think that stem projects are the most
important thing since the discovery of pepperjack cheese but does that really
mean I should label my projects as 'ultra super omega-purple level important'?

Dropping the priority from task ideas and sorting everything alphabetically.

Damian Johnson authored on 14/11/2012 07:26:37
Showing 1 changed files
... ...
@@ -787,68 +787,11 @@ meetings around the world.</li>
787 787
     
788 788
     <ol>
789 789
     
790
-    <a id="improveTorbirdy"></a>
791
-    <li>
792
-    <b>Improving TorBirdy</b>
793
-    <br>
794
-    Priority: <i>High</i>
795
-    <br>
796
-    Effort Level: <i>High</i>
797
-    <br>
798
-    Skill Level: <i>Medium to High</i>
799
-    <br>
800
-    Likely Mentors: <i>Sukhbir, Jacob</i>
801
-    <p>
802
-    TorBirdy is Torbutton for Thunderbird, Icedove and related Mozilla mail
803
-    clients.
804
-    </p>
805
-    <p>
806
-    TorBirdy is under active development and is available from <a
807
-    href="https://trac.torproject.org/projects/tor/wiki/torbirdy">our wiki</a>
808
-    and <a
809
-    href="https://addons.mozilla.org/en-US/thunderbird/addon/torbirdy/">mozilla's
810
-    addons site</a>.
811
-    </p>
812
-    
813
-    <p>
814
-    The goal of this project is to improve TorBirdy by:
815
-    </p>
816
-    
817
-    <ul>
818
-      <li>
819
-        Writing a Thunderbird patch to plug known leaks. We have already <a
820
-        href="https://bugzilla.mozilla.org/show_bug.cgi?id=776397">submitted a
821
-        patch to Thunderbird</a> but we anticipate there will be much more work
822
-        required before it is accepted, possibly involving rewriting the entire
823
-        patch; this appears trivial, but it is not, as we are proposing a
824
-        completely new privacy-safe message-ID header generation algorithm for
825
-        Thunderbird.
826
-      </li>
827
-      <li>
828
-        Implementing a JavaScript HTTP proxy (see the <a
829
-        href="https://trac.torproject.org/projects/tor/ticket/6958">ticket</a>)
830
-      </li>
831
-      <li>
832
-        Auditing TorBirdy for leaks and for use with other add-ons (as an
833
-        example see its <a
834
-        href="https://trac.torproject.org/projects/tor/ticket/6319">ticket</a>)
835
-      </li>
836
-    </ul>
837
-    
838
-    <p>
839
-    A student undertaking this project should have some C++ and JavaScript
840
-    development experience. Previous experience with Firefox/Thunderbird
841
-    extension development is a plus, but not required.
842
-    </p>
843
-    </li>
844
-    
845 790
     <!--
846 791
     <a id="auditTBB"></a>
847 792
     <li>
848 793
     <b>Audit Tor Browser Bundles for data leaks</b>
849 794
     <br>
850
-    Priority: <i>High</i>
851
-    <br>
852 795
     Effort Level: <i>High</i>
853 796
     <br>
854 797
     Skill Level: <i>Medium</i>
... ...
@@ -872,86 +815,154 @@ meetings around the world.</li>
872 815
     -->
873 816
     
874 817
     <!--
875
-    <a id="firewallProbeTool"></a>
818
+    <a id="orbot-userInterface"></a>
876 819
     <li>
877
-    <b>Develop a fully automatic firewall-probing system</b>
878
-    <br>
879
-    Priority: <i>High</i>
820
+    <b>Build a better user interface for Orbot</b>
880 821
     <br>
881
-    Effort Level: <i>Medium to High</i>
822
+    Effort Level: <i>Medium</i>
882 823
     <br>
883
-    Skill Level: <i>High</i>
824
+    Skill Level: <i>Medium</i>
884 825
     <br>
885
-    Likely Mentors: <i>Robert Ransom, Jacob</i>
886
-    <p>We would like to have a fully automatic firewall-probing system for
887
-    blocking systems with no long-term state (i.e. firewalls that can
888
-    examine each connection, but do not change their behaviour for future
889
-    connections based on the traffic they have seen).</p>
890
-    <p>Ideally, volunteers would only need to set up one or more test servers,
891
-    and run the probe client program on a publicly accessible computer
892
-    behind the firewall.</p>
893
-    <p>The test tool should:</p>
894
-    <ul>
895
-    <li>generate packet captures on both ends (and send them out to the
896
-        extent possible),</li>
897
-    <li>cycle through all the SSL configurations we might want to test
898
-        through a censorship device, and</li>
899
-    <li>also test some other protocols to see whether they are allowed
900
-        through the firewall (IMAP and other mail protocols, BitTorrent,
901
-        DTLS, etc.).</li>
902
-    </ul>
826
+    Likely Mentors: <i>Jake</i>
827
+    <p>Improved home screen to show confirmation of connection (via a TorCheck
828
+    API call), better statistics about data transferred (up/down), number of
829
+    circuits connected, quality of connection and so on. The &quot;Tether
830
+    Wifi&quot; Android application is a good model to follow in how it shows a
831
+    realtime count of bytes transferred as well as notifications when wifi
832
+    clients connect. In addition, better handling of Tor system and error
833
+    messages would also be very helpful, include use of standard Android
834
+    operating systems notifications. The addition of a wizard or tutorial
835
+    walkthrough for novice users to explain to them exactly what is and what is
836
+    not anonymized or protected would greatly improve the likelihood they will
837
+    use Orbot correctly. All of this should work on the range of screens and
838
+    device types now offered for Android, from 2&quot; phone to 10&quot;
839
+    Tablet.</p>
903 840
     </li>
904 841
     -->
905 842
     
906 843
     <!--
907
-    <a id="orbot-torbutton"></a>
844
+    <a id="armClientMode"></a>
908 845
     <li>
909
-    <b>TorButton for Mobile Firefox 4 or Custom Browser on Android</b>
910
-    <br>
911
-    Priority: <i>High</i>
846
+    <b>Client Mode Use Cases for Arm</b>
912 847
     <br>
913 848
     Effort Level: <i>High</i>
914 849
     <br>
915
-    Skill Level: <i>High</i>
850
+    Skill Level: <i>Medium</i>
916 851
     <br>
917
-    Likely Mentors: <i>Jake</i>
918
-    <p>Initial work has been done on implementing a proxy-setting add-on for
919
-    Firefox on Android (see <a
920
-    href="https://github.com/guardianproject/ProxyMob">ProxyMob</a>), but a
921
-    full port of TorButton needs to be done (dependent upon Firefox 4 port of
922
-    TorButton). The other approach is to implement a custom &quot;Tor
923
-    Browser&quot; based on Firefox or Webkit browser. See <a
924
-    href="http://code.google.com/p/torora/wiki/Android">Torora</a> for progress
925
-    on this so far.</p>
852
+    Likely Mentors: <i>Damian (atagar)</i>
853
+    <p><a href="<page projects/arm>">Arm</a> is a Tor command line status
854
+    monitor on *nix environments (Linux, Mac, and BSD). It functions much like
855
+    top does, giving a CLI overlay of Tor's bandwidth usage, connections,
856
+    configuration, log, etc. Thus far its design has been geared for Tor relay
857
+    operators. However, this doesn't need to be the case. This project would be
858
+    to expand and simplify arm to make it useful for Tor's client users
859
+    too.</p>
860
+    
861
+    <p>This would include UI design, experimenting, and a lot of python
862
+    hacking. Here's some ideas for client functionality arm could provide:</p>
863
+    
864
+    <ul>
865
+      <li>A panel for client connections, showing each hop of the user's
866
+      circuits with the ISP, country, and jurisdiction where those relays
867
+      reside. Other interesting information would be the circuit's latency, how
868
+      long its been around, and its possible exit ports. Some of this will be
869
+      pretty tricky and require some experimentation to figure out what
870
+      information can be fetched safely (for instance, scraping rdns and whois
871
+      lookups could give hints about a relay's ISP, but we'd need to do it on
872
+      all Tor relays to avoid leaking our connections to the resolver).</li>
873
+      
874
+      <li>Options to let the user request new circuits (the &quot;New
875
+      Identity&quot; feature in Vidalia), select the exit country, etc.</li>
876
+      
877
+      <li>A panel showing Internet application and if their connections are
878
+      being routed through Tor or not (giving a warning if there's leaks).</li>
879
+      
880
+      <li>The status of the bridges we're configured to use (ie, are they up?).
881
+      This would include adding control port functionality to Tor for <a
882
+      href="https://trac.torproject.org/projects/tor/ticket/2068">ticket
883
+      2068</a>.</li>
884
+      
885
+      <li>A one click option to set Tor to be a client, relay, or bridge. The
886
+      goal would be to make it trivial for users to voluntarily contribute to
887
+      the Tor network.</li>
888
+      
889
+      <li>Menus as an alternative to hotkeys to make the interface more
890
+      intuitive and usable for beginners (<a
891
+      href="http://gnosis.cx/publish/programming/charming_python_6.html">example</a>).</li>
892
+      
893
+      <li>Look at Vidalia and TorK for ideas and solicit input from the Tor community.</li>
894
+    </ul>
895
+    
896
+    <p>
897
+    More information is available in the following sections of arm's dev notes: <a href="https://trac.torproject.org/projects/tor/wiki/doc/arm#ConnectionListingExpansion">Connection Listing Expansion</a>, <a href="https://trac.torproject.org/projects/tor/wiki/doc/arm#CircuitDetails">Circuit Details</a>, and <a href="https://trac.torproject.org/projects/tor/wiki/doc/arm#ClientModeUseCases">Client Mode Use Cases</a>
898
+    </p>
926 899
     </li>
927 900
     -->
928 901
     
929
-    <!--
930
-    <a id="obfsproxy-new-transports"></a>
902
+    <a id="compassRefactoring"></a>
931 903
     <li>
932
-    <b>New and innovative pluggable transports</b>
904
+    <b>Compass Refactoring</b>
933 905
     <br>
934
-    Priority: <i>High</i>
906
+    Effort Level: <i>Medium</i>
935 907
     <br>
936
-    Effort Level: <i>High</i>
908
+    Skill Level: <i>Medium</i>
909
+    <br>
910
+    Likely Mentors: <i>gsathya, karsten</i>
911
+    <p>
912
+    Compass was first designed to be a cli app and then hacked into a web app.
913
+    The codebase needs to be refactored such that the main processing code is
914
+    separated from the display functions(probably into separate files) and made
915
+    modular so that adding more features (<a
916
+    href="https://trac.torproject.org/6612">#6612</a>) is easy. For example, the
917
+    main processing logic could be in compass.py, whereas print_groups() and other
918
+    display related functions could be part of a separate cli.py; web.py would also
919
+    have to modified to make use of this new modular code. Bonus points for adding
920
+    features to compass(<a href="https://trac.torproject.org/6619">#6619</a>, <a
921
+    href="https://trac.torproject.org/6612">#6612</a>, <a
922
+    href="https://trac.torproject.org/6728">#6728</a>).
923
+    </p>
924
+    </li>
925
+    
926
+    <!--
927
+    <a id="orbot-optimisation"></a>
928
+    <li>
929
+    <b>Core Tor mobile optimisation</b>
930
+    <br>
931
+    Effort Level: <i>Medium</i>
937 932
     <br>
938 933
     Skill Level: <i>High</i>
939 934
     <br>
940
-    Likely Mentors: <i>asn, Steven</i>
941
-    <p>Not-very-smart transports like ROT13 and base64 are nice but not super
942
-    interesting. Other ideas like bittorrent transports might be relevant,
943
-    but you will have to provide security proofs on why they are harder to
944
-    detect and block than other less-sophisticated transports.</p>
935
+    Likely Mentors: <i>Jake</i>
936
+    <p>
937
+    The existing port of Tor to Android is basically a straight
938
+    cross-compile to Linux ARM. There has been no work done in looking at
939
+    possible optimizations of Tor within a mobile hardware environment or on
940
+    mobile networks. In addition, a number of additional Android OS APIs are
941
+    available (such as wireless network status) that could be taken
942
+    advantage of.
943
+    </p>
945 944
     
946
-    <p>The whole point of this project, though, is to come up with new
947
-    transports that we haven't already thought of. Be creative.</p>
945
+    <p>
946
+    It should be noted, that even without optimisation, Tor is handling the
947
+    mobile network environment very well, automatically detecting change in
948
+    IP addresses, opening circuits, etc, as the device switches from no
949
+    coverage to 2G, 3G or Wifi constantly as it changes position. However,
950
+    this observation of &quot;very well&quot;, is just based on user
951
+    experience, and not any detailed study of what exactly is happening, and
952
+    what threats might exist because of this constantly changing network state.
953
+    </p>
948 954
     
949
-    <p>Bonus points if your idea is interesting and still implementable
950
-    through the summer period.</p>
955
+    <p>
956
+    Finally, the build process needs to be moved to the Android NDK from the
957
+    custom GCC toolchain we are now using, and compatibility with Android
958
+    2.3 and 3.x Honeycomb OS need to be verified.
959
+    </p>
951 960
     
952
-    <p>More bonus points if it's implemented on top of obfsproxy, or if your
953
-    implementation has a pluggable transport interface on top of it (as
954
-    specified <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt">here</a>).</p>
961
+    <p>
962
+    For more information see the <a
963
+    href="https://svn.torproject.org/svn/projects/android/trunk/Orbot/BUILD">Orbot
964
+    build documentation</a>.
965
+    </p>
955 966
     </li>
956 967
     -->
957 968
     
... ...
@@ -960,8 +971,6 @@ meetings around the world.</li>
960 971
     <li>
961 972
     <b>Defensive bridge active scanning measures</b>
962 973
     <br>
963
-    Priority: <i>High</i>
964
-    <br>
965 974
     Effort Level: <i>High</i>
966 975
     <br>
967 976
     Skill Level: <i>High</i>
... ...
@@ -978,232 +987,572 @@ meetings around the world.</li>
978 987
     </li>
979 988
     -->
980 989
     
981
-    <a id="limitCapabilities"></a>
990
+    <!--
991
+    <a id="firewallProbeTool"></a>
982 992
     <li>
983
-    <b>Run With Limited Capabilities</b>
984
-    <br>
985
-    Priority: <i>Medium to High</i>
993
+    <b>Develop a fully automatic firewall-probing system</b>
986 994
     <br>
987 995
     Effort Level: <i>Medium to High</i>
988 996
     <br>
989 997
     Skill Level: <i>High</i>
990 998
     <br>
991
-    Likely Mentors: <i>Nick (nickm)</i>
992
-    <p>
993
-    Many modern operating systems give a running program the ability to drop
994
-    capabilities that it no longer needs, and other ways for a program to run
995
-    pieces of itself in a sandbox with diminished privileges.
996
-    </p>
997
-    
998
-    <p>
999
-    We'd like to do this with Tor, to improve its resistance to attacks.  The
1000
-    easiest areas to address would be on systems like <a
1001
-    href="https://lwn.net/Articles/475361/">recent Linux kernels</a> that make
1002
-    it easy to drop or restrict the set of syscalls that a program can invoke.
1003
-    That's a great project, but probably not big enough for an internship just
1004
-    on its own.  For that, we'd want to make progress on at least multiple
1005
-    platforms, or look into refactoring Tor into pieces that need more
1006
-    privileges and pieces that don't with an eye towards sandboxing them
1007
-    differently.
1008
-    </p>
1009
-    
999
+    Likely Mentors: <i>Robert Ransom, Jacob</i>
1000
+    <p>We would like to have a fully automatic firewall-probing system for
1001
+    blocking systems with no long-term state (i.e. firewalls that can
1002
+    examine each connection, but do not change their behaviour for future
1003
+    connections based on the traffic they have seen).</p>
1004
+    <p>Ideally, volunteers would only need to set up one or more test servers,
1005
+    and run the probe client program on a publicly accessible computer
1006
+    behind the firewall.</p>
1007
+    <p>The test tool should:</p>
1008
+    <ul>
1009
+    <li>generate packet captures on both ends (and send them out to the
1010
+        extent possible),</li>
1011
+    <li>cycle through all the SSL configurations we might want to test
1012
+        through a censorship device, and</li>
1013
+    <li>also test some other protocols to see whether they are allowed
1014
+        through the firewall (IMAP and other mail protocols, BitTorrent,
1015
+        DTLS, etc.).</li>
1016
+    </ul>
1017
+    </li>
1018
+    -->
1019
+    
1020
+    <!--
1021
+    <a id="obfsproxy-fuzzer"></a>
1022
+    <li>
1023
+    <b>Fuzzer for the Tor protocol</b>
1024
+    <br>
1025
+    Effort Level: <i>Medium to High</i>
1026
+    <br>
1027
+    Skill Level: <i>High</i>
1028
+    <br>
1029
+    Likely Mentors: <i>asn</i>
1030
+    <p>Involves researching good and smart ways to fuzz stateful network
1031
+    protocols, and also implementing the fuzzer.</p>
1032
+    
1033
+    <p>We are mostly looking for a fuzzer that fuzzes the Tor protocol
1034
+    itself, and not the Tor directory protocol.</p>
1035
+    
1036
+    <p>Bonus points if it's extremely modular. Relevant research:</p>
1037
+    
1038
+    <ul>
1039
+      <li>PROTOS - Security Testing of Protocol Implementations</li>
1040
+      <li>INTERSTATE: A Stateful Protocol Fuzzer for SIP</li>
1041
+      <li>Detecting Communication Protocol Security Flaws by Formal Fuzz
1042
+      Testing and Machine Learning</li>
1043
+      <li>SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZE</li>
1044
+      <li>Michal Zalewski's &quot;bugger&quot;</li>
1045
+      <li>Also look at the concepts of &quot;model checking&quot; and
1046
+      &quot;symbolic execution&quot; to get inspired.</li>
1047
+    </ul>
1048
+    </li>
1049
+    -->
1050
+    
1051
+    <a id="httpsImersonation"></a>
1052
+    <li>
1053
+    <b>HTTPS Server Impersonation</b>
1054
+    <br>
1055
+    Effort Level: <i>Medium to High</i>
1056
+    <br>
1057
+    Skill Level: <i>Medium to High</i>
1058
+    <br>
1059
+    Likely Mentors: <i>Nick (nickm)</i>
1010 1060
     <p>
1011
-    See tickets <a href="https://trac.torproject.org/7005">#7005</a> and <a
1012
-    href="https://trac.torproject.org/5219">#5219</a>, and their descendants,
1013
-    for more information.
1061
+    We have an open proposal for a way to make Tor bridges avoid censorship by
1062
+    impersonating an HTTPS server.  Specifically, we need to hack some popular
1063
+    SSL "reverse proxy" (your choice) so that it relays regular web connections
1064
+    to an HTTP server, but certain connections to a local Tor process.  <a
1065
+    href="https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/203-https-frontend.txt">Proposal
1066
+    203</a> has a general design sketch.
1014 1067
     </p>
1015 1068
     </li>
1016 1069
     
1017
-    <a id="docUpdate"></a>
1070
+    <!--
1071
+    <a id="geoIPUpgrade"></a>
1018 1072
     <li>
1019
-    <b>Website and video documentation update</b>
1073
+    <b>Improve our GeoIP file format</b>
1020 1074
     <br>
1021
-    Priority: <i>High</i>
1075
+    Effort Level: <i>Medium</i>
1076
+    <br>
1077
+    Skill Level: <i>Medium to High</i>
1078
+    <br>
1079
+    Likely Mentors: <i>Robert Ransom</i>
1080
+    <p>Currently, Tor bridges and relays read an entire IP-&gt;country database
1081
+    into memory from a text file during startup.  We would like to
1082
+    distribute this database and store it on disk in a much more compact
1083
+    form, and perform IP-&gt;country lookups on it in its on-disk format if
1084
+    possible.</p>
1085
+    <p>We have <a href='https://trac.torproject.org/projects/tor/ticket/2506'>a
1086
+    sketch of a design</a> for a moderately optimized format for IPv4 GeoIP
1087
+    data; this project will involve both implementing the IPv4 format and
1088
+    designing and implementing a format for IPv6 GeoIP data.</p>
1089
+    <p>Since the core of this project is researching IPv6 GeoIP data and
1090
+    designing the IPv6 format, this is not likely to be a good GSoC
1091
+    project.</p>
1092
+    </li>
1093
+    -->
1094
+    
1095
+    <!--
1096
+    <a id="unitTesting"></a>
1097
+    <li>
1098
+    <b>Improve our unit testing process</b>
1022 1099
     <br>
1023 1100
     Effort Level: <i>Medium</i>
1024 1101
     <br>
1025 1102
     Skill Level: <i>Medium</i>
1026 1103
     <br>
1027
-    Likely Mentors: <i>Runa, Karen</i>
1104
+    Likely Mentors: <i>Nick, Erinn</i>
1105
+    <p>Tor needs to be tested far more thoroughly. This is a
1106
+    multi-part effort. To start with, our unit test coverage should
1107
+    rise substantially, especially in the areas outside the utility
1108
+    functions. This will require significant refactoring of some parts
1109
+    of Tor, in order to dissociate as much logic as possible from
1110
+    globals.</p>
1111
+    <p>Additionally, we need to automate our performance testing. We've got
1112
+    buildbot to automate our regular integration and compile testing already
1113
+    (though we need somebody to set it up on Windows),
1114
+    but we need to get our network simulation tests (as built in <a
1115
+    href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
1116
+    updated for more recent versions of Tor, and designed to launch a test
1117
+    network either on a single machine, or across several, so we can test
1118
+    changes in performance on machines in different roles automatically.</p>
1119
+    </li>
1120
+    -->
1121
+    
1122
+    <!--
1123
+    <a id="vidaliaNetworkMap"></a>
1124
+    <li>
1125
+    <b>Improved and More Usable Network Map in Vidalia</b>
1126
+    <br>
1127
+    Effort Level: <i>Medium</i>
1128
+    <br>
1129
+    Skill Level: <i>Medium</i>
1130
+    <br>
1131
+    Likely Mentors: <i>Tomás</i>
1028 1132
     <p>
1029
-    Identify outdated and/or weak pages on torproject.org and re-write the
1030
-    documentation to appeal to a less technical, more goal-oriented
1031
-    audience. Create a number of 3-5 minute videos with graphically
1032
-    portray the written documentation. See
1033
-    <a href="https://trac.torproject.org/projects/tor/query?component=Website&status=new">the
1034
-    website tickets</a> for more information and a starting point.
1133
+    One of Vidalia's existing features is a network map that shows the user
1134
+    the approximate geographic location of relays in the Tor network and
1135
+    plots the paths the user's traffic takes as it is tunneled through the
1136
+    Tor network. The map is currently not very interactive and has rather
1137
+    poor graphics. Instead, we implemented KDE's Marble widget such
1138
+    that it gives us a better quality map and enables improved interactivity,
1139
+    such as allowing the user to click on individual relays or circuits to
1140
+    display additional information. We want to add the ability
1141
+    for users to click on a particular relay or a country containing one or
1142
+    more Tor exit relays and say, "I want my connections to exit
1143
+    from here."
1144
+    </p>
1145
+    
1146
+    <p>
1147
+    This project will first involve getting familiar with Vidalia
1148
+    and the Marble widget's API. One will then integrate the widget
1149
+    into Vidalia and customize Marble to be better suited for our application,
1150
+    such as making circuits clickable, storing cached map data in Vidalia's
1151
+    own data directory, and customizing some of the widget's dialogs.
1152
+    </p>
1153
+    
1154
+    <p>
1155
+    A person undertaking this project should have good C++ development
1156
+    experience. Previous experience with Qt and CMake is helpful, but not
1157
+    required.
1035 1158
     </p>
1036 1159
     </li>
1160
+    -->
1037 1161
     
1038
-    <a id="torCleanup"></a>
1162
+    <!--
1163
+    <a id="resistCensorship"></a>
1039 1164
     <li>
1040
-    <b>Tor Codebase Cleanup</b>
1165
+    <b>Improving Tor's ability to resist censorship</b>
1041 1166
     <br>
1042
-    Priority: <i>Medium to High</i>
1167
+    Effort Level: <i>Medium to High</i>
1043 1168
     <br>
1044
-    Effort Level: <i>Low to High, depending on subproject chosen</i>
1169
+    Skill Level: <i>High</i>
1170
+    <br>
1171
+    Likely Mentors: <i>Jake, Thomas</i>
1172
+    <p>The Tor 0.2.1.x series makes <a
1173
+    href="<svnprojects>design-paper/blocking.html">significant
1174
+    improvements</a> in resisting national and organizational censorship.
1175
+    But Tor still needs better mechanisms for some parts of its
1176
+    anti-censorship design.</p>
1177
+    <p>One huge category of work is adding features to our <a
1178
+    href="https://gitweb.torproject.org/bridgedb.git?a=tree">BridgeDB</a>
1179
+    service (Python). Tor aims to give out <a href="<page docs/bridges>">bridge
1180
+    relay addresses</a> to users that can't reach the Tor network
1181
+    directly, but there's an arms race between algorithms for distributing
1182
+    addresses and algorithms for gathering and blocking them. See <a
1183
+    href="<blog>bridge-distribution-strategies">our
1184
+    blog post on the topic</a> as an overview, and then look at <a
1185
+    href="https://lists.torproject.org/pipermail/tor-dev/2009-December/000666.html">Roger's
1186
+    or-dev post</a> from December 2009 for more recent thoughts &mdash; lots of
1187
+    design work remains.</p>
1188
+    <p>If you want to get more into the guts of Tor itself (C), a more minor problem
1189
+    we should address is that current Tors can only listen on a single
1190
+    address/port combination at a time. There's
1191
+    <a href="<specblob>proposals/118-multiple-orports.txt">a
1192
+    proposal to address this limitation</a> and allow clients to connect
1193
+    to any given Tor on multiple addresses and ports, but it needs more
1194
+    work.</p>
1195
+    <p>This project could involve a lot of research and design. One of the big
1196
+    challenges will be identifying and crafting approaches that can still
1197
+    resist an adversary even after the adversary knows the design, and
1198
+    then trading off censorship resistance with usability and
1199
+    robustness.</p>
1200
+    </li>
1201
+    -->
1202
+    
1203
+    <a id="improveTorbirdy"></a>
1204
+    <li>
1205
+    <b>Improving TorBirdy</b>
1206
+    <br>
1207
+    Effort Level: <i>High</i>
1045 1208
     <br>
1046 1209
     Skill Level: <i>Medium to High</i>
1047 1210
     <br>
1211
+    Likely Mentors: <i>Sukhbir, Jacob</i>
1212
+    <p>
1213
+    TorBirdy is Torbutton for Thunderbird, Icedove and related Mozilla mail
1214
+    clients.
1215
+    </p>
1216
+    <p>
1217
+    TorBirdy is under active development and is available from <a
1218
+    href="https://trac.torproject.org/projects/tor/wiki/torbirdy">our wiki</a>
1219
+    and <a
1220
+    href="https://addons.mozilla.org/en-US/thunderbird/addon/torbirdy/">mozilla's
1221
+    addons site</a>.
1222
+    </p>
1223
+    
1224
+    <p>
1225
+    The goal of this project is to improve TorBirdy by:
1226
+    </p>
1227
+    
1228
+    <ul>
1229
+      <li>
1230
+        Writing a Thunderbird patch to plug known leaks. We have already <a
1231
+        href="https://bugzilla.mozilla.org/show_bug.cgi?id=776397">submitted a
1232
+        patch to Thunderbird</a> but we anticipate there will be much more work
1233
+        required before it is accepted, possibly involving rewriting the entire
1234
+        patch; this appears trivial, but it is not, as we are proposing a
1235
+        completely new privacy-safe message-ID header generation algorithm for
1236
+        Thunderbird.
1237
+      </li>
1238
+      <li>
1239
+        Implementing a JavaScript HTTP proxy (see the <a
1240
+        href="https://trac.torproject.org/projects/tor/ticket/6958">ticket</a>)
1241
+      </li>
1242
+      <li>
1243
+        Auditing TorBirdy for leaks and for use with other add-ons (as an
1244
+        example see its <a
1245
+        href="https://trac.torproject.org/projects/tor/ticket/6319">ticket</a>)
1246
+      </li>
1247
+    </ul>
1248
+    
1249
+    <p>
1250
+    A student undertaking this project should have some C++ and JavaScript
1251
+    development experience. Previous experience with Firefox/Thunderbird
1252
+    extension development is a plus, but not required.
1253
+    </p>
1254
+    </li>
1255
+    
1256
+    <!--
1257
+    <a id="user-space-transport"></a>
1258
+    <li>
1259
+    <b>Integrating Tor with user-space transport protocol libraries</b>
1260
+    <br>
1261
+    Effort Level: <i>High</i>
1262
+    <br>
1263
+    Skill Level: <i>High</i>
1264
+    <br>
1265
+    Likely Mentors: <i>Steven</i>
1266
+    <p>Tor currently sends data over TCP links between nodes. <a
1267
+    href="http://static.usenix.org/events/sec09/tech/full_papers/reardon.pdf">Prior
1268
+    research</a> has indicated that this may not be optimal, and instead the
1269
+    role that TCP plays (congestion control and reliability) should be moved
1270
+    into Tor itself. This would allow a number of desirable changes, such as
1271
+    preventing errors on one circuit delaying another, and giving Tor control
1272
+    and visibility of congestion control.</p>
1273
+    <p>There are <a
1274
+    href="http://www.cl.cam.ac.uk/~sjm217/papers/tor11datagramcomparison.pdf">many
1275
+    ways to do this</a>, each with their own tradeoffs and difficulty of
1276
+    implementation. This project will be to select one (or more) option and
1277
+    implement it in Tor. The primary goal will be to test this modified version
1278
+    of Tor in simulation, but if it turns out to work well, it could be
1279
+    deployed in the live Tor network.</p>
1280
+    <p>Excellent C programming skills are needed, and knowledge of Tor
1281
+    internals are highly desirable.</p>
1282
+    </li>
1283
+    -->
1284
+    
1285
+    <a id="chutneyExpansion"></a>
1286
+    <li>
1287
+    <b>Make Chutney Do More, More Reliably</b>
1288
+    <br>
1289
+    Effort Level: <i>Medium to High, depending on scope of project</i>
1290
+    <br>
1291
+    Skill Level: <i>Medium</i>
1292
+    <br>
1048 1293
     Likely Mentors: <i>Nick (nickm)</i>
1049 1294
     <p>
1050
-    The Tor code is almost 10 years old in places, and we haven't always had
1051
-    enough time or wisdom to write things as well as we could have.  Our unit
1052
-    test coverage is shamefully low, and the dependency graph of our modules is
1053
-    shamefully convoluted . We could use refactoring and unit tests!  Please
1054
-    look through the Tor source code and look for ugly or tricky code or
1055
-    dependencies -- the uglier and trickier the better -- and think about how
1056
-    you could make the code look better, read better, and (subject to testing)
1057
-    work better.
1295
+    We have a little Python tool called <a
1296
+    href="https://gitweb.torproject.org/nickm/chutney.git">Chutney</a> for
1297
+    making small local test networks.  It's small, not widely used, and not as
1298
+    automated as it could be.
1058 1299
     </p>
1059 1300
     
1060 1301
     <p>
1061
-    If this is for a fun side-project, it would be great for you to work on
1062
-    anything that can be made better and more tested.  For an internship-level
1063
-    position, we'd hope that you could find a number of particularly tricky or
1064
-    knotty piece of the code to clean up, and aim for resolving the ugliest
1065
-    problems, not necessarily the easiest.
1302
+    It would be great to see chutney extended and a set of supporting tests
1303
+    built to the point where we could use Chutney to exercise various Tor
1304
+    features as an automated integration test.
1066 1305
     </p>
1306
+    </li>
1067 1307
     
1308
+    <!--
1309
+    <a id="torsocksForOSX"></a>
1310
+    <li>
1311
+    <b>Make torsocks/dsocks work on OS X</b>
1312
+    <br>
1313
+    Effort Level: <i>Medium</i>
1314
+    <br>
1315
+    Skill Level: <i>Medium</i>
1316
+    <br>
1317
+    Likely Mentors: <i>Robert Hogan</i>
1068 1318
     <p>
1069
-    For a big project here, it would be great to pick one of the major
1070
-    "submodules" of Tor -- path selection, node discovery, directory authority
1071
-    operations, directory service -- and refactor its interface completely, to
1072
-    minify and codify its points of contact with the rest of Tor.
1319
+    <a href="https://code.google.com/p/torsocks/">Torsocks</a> and <a
1320
+    href="https://code.google.com/p/dsocks/">dsocks</a> are wrappers that will
1321
+    run applications, intercept their outgoing network connections, and push
1322
+    those connections through Tor. The goal is to handle applications that
1323
+    don't support proxies (or don't supporting them well). To get it right,
1324
+    they need to intercept many system calls. The syscalls you need to
1325
+    intercept on Linux differ dramatically from those on BSD. So Torsocks
1326
+    works fine on Linux, dsocks works ok on BSD (though it may be less
1327
+    maintained and thus might miss more syscalls), and nothing works well
1328
+    on both. First, we should patch dsocks to use Tor's <i>mapaddress</i>
1329
+    commands from the controller interface, so we don't waste a whole
1330
+    round-trip inside Tor doing the resolve before connecting. Second,
1331
+    we should make our <i>torify</i> script detect which of torsocks or
1332
+    dsocks is installed, and call them appropriately. This probably means
1333
+    unifying their interfaces, and might involve sharing code between them
1334
+    or discarding one entirely.
1335
+    </p>
1336
+    </li>
1337
+    -->
1338
+    
1339
+    <!--
1340
+    <a id="obfsproxy-new-transports"></a>
1341
+    <li>
1342
+    <b>New and innovative pluggable transports</b>
1343
+    <br>
1344
+    Effort Level: <i>High</i>
1345
+    <br>
1346
+    Skill Level: <i>High</i>
1347
+    <br>
1348
+    Likely Mentors: <i>asn, Steven</i>
1349
+    <p>Not-very-smart transports like ROT13 and base64 are nice but not super
1350
+    interesting. Other ideas like bittorrent transports might be relevant,
1351
+    but you will have to provide security proofs on why they are harder to
1352
+    detect and block than other less-sophisticated transports.</p>
1353
+    
1354
+    <p>The whole point of this project, though, is to come up with new
1355
+    transports that we haven't already thought of. Be creative.</p>
1356
+    
1357
+    <p>Bonus points if your idea is interesting and still implementable
1358
+    through the summer period.</p>
1359
+    
1360
+    <p>More bonus points if it's implemented on top of obfsproxy, or if your
1361
+    implementation has a pluggable transport interface on top of it (as
1362
+    specified <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt">here</a>).</p>
1363
+    </li>
1364
+    -->
1365
+    
1366
+    <!--
1367
+    <a id="orbot-orlibAndOutreach"></a>
1368
+    <li>
1369
+    <b>Orbot integration library and community outreach</b>
1370
+    <br>
1371
+    Effort Level: <i>Low</i>
1372
+    <br>
1373
+    Skill Level: <i>Medium</i>
1374
+    <br>
1375
+    Likely Mentors: <i>Nathan (n8fr8)</i>
1376
+    <p>
1377
+    We need additional work on <a
1378
+    href="https://github.com/guardianproject/orlib">ORLib</a>, our library for
1379
+    use with third-party application to easily enable them to support
1380
+    &quot;Torification&quot; on non-rooted devices (i.e. w/o transparent
1381
+    proxying). This library includes a SOCKS client, a wrapper for the Apache
1382
+    HTTPClient library, a utility class for detecting the state of Orbot
1383
+    connectivity, and other relevant/useful things an Android app might need to
1384
+    anonymize itself. This work would includes direct development of the
1385
+    library, documentation, and sample code. Outreach or effort to implement
1386
+    the library within other open-source apps is also needed.
1073 1387
     </p>
1074 1388
     </li>
1389
+    -->
1390
+    
1391
+    <!--
1392
+    <a id="tailsHiddenServicePetnames"></a>
1393
+    <li>
1394
+    <b>Petname system for Tor hidden services</b>
1395
+    <br>
1396
+    Effort Level: <i>High</i>
1397
+    <br>
1398
+    Skill Level: <i>High</i>
1399
+    <br>
1400
+    Likely Mentors: <i>ague</i>
1401
+    <p>Tor provides hidden services. These services are only reachable through
1402
+    Tor itself, and provide greater anonymity both for the providers of the
1403
+    service and for its users.</p>
1404
+    <p>One current downside of Tor hidden services is that they are addressed
1405
+    using 80-bit base32-encoded addresses such as "v2cbb2l4lsnpio4q.onion".
1406
+    These addresses are hard to remember; this makes them hard to use
1407
+    within amnesic environment like Tails.</p>
1408
+    <p>The project is to implement a petname system for Tor hidden services:
1409
+    a way for users or providers of Tor hidden services to add a simple
1410
+    'nickname' to a central database. Users could then query this central
1411
+    database to retrieve a full hidden service address by giving
1412
+    a nickname.</p>
1413
+    <p>Adding petnames to the database could be done using a web interface or
1414
+    automated fetch like those described in the <a
1415
+    href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-onion-nyms.txt">&quot;.onion
1416
+    nym system&quot; proposal</a>.</p>
1417
+    <p>Querying the database could be done using a web interface, a REST API and
1418
+    a DNS interface.</p>
1419
+    <p>In order not to grow indefinitely, the software should make regular tests to
1420
+    see if hidden services are still reachable and, depending on the last time
1421
+    a nickname was accessed, cleanup the database as necessary.</p>
1422
+    <p>The software should allow a distributed, fault-tolerant setup.
1423
+    All nodes should have a synchronized copy of the database, should be
1424
+    ready to answer queries and should coordinate the tests for hidden
1425
+    service availability.</p>
1426
+    <p>The resulting codebase must be easy to deploy: it should not be hard to
1427
+    setup new databases.</p>
1428
+    <p>It is expected that the volunteer will be using Behaviour Driven
1429
+    Development methods. Either in Ruby using Cucumber and RSpec, or in
1430
+    Python using similar tools.</p>
1431
+    </li>
1432
+    -->
1075 1433
     
1076
-    <a id="httpsImersonation"></a>
1434
+    <a id="limitCapabilities"></a>
1077 1435
     <li>
1078
-    <b>HTTPS Server Impersonation</b>
1079
-    <br>
1080
-    Priority: <i>Medium</i>
1436
+    <b>Run With Limited Capabilities</b>
1081 1437
     <br>
1082 1438
     Effort Level: <i>Medium to High</i>
1083 1439
     <br>
1084
-    Skill Level: <i>Medium to High</i>
1440
+    Skill Level: <i>High</i>
1085 1441
     <br>
1086 1442
     Likely Mentors: <i>Nick (nickm)</i>
1087 1443
     <p>
1088
-    We have an open proposal for a way to make Tor bridges avoid censorship by
1089
-    impersonating an HTTPS server.  Specifically, we need to hack some popular
1090
-    SSL "reverse proxy" (your choice) so that it relays regular web connections
1091
-    to an HTTP server, but certain connections to a local Tor process.  <a
1092
-    href="https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/203-https-frontend.txt">Proposal
1093
-    203</a> has a general design sketch.
1444
+    Many modern operating systems give a running program the ability to drop
1445
+    capabilities that it no longer needs, and other ways for a program to run
1446
+    pieces of itself in a sandbox with diminished privileges.
1094 1447
     </p>
1095
-    </li>
1096 1448
     
1097
-    <a id="chutneyExpansion"></a>
1098
-    <li>
1099
-    <b>Make Chutney Do More, More Reliably</b>
1100
-    <br>
1101
-    Priority: <i>Medium</i>
1102
-    <br>
1103
-    Effort Level: <i>Medium to High, depending on scope of project</i>
1104
-    <br>
1105
-    Skill Level: <i>Medium</i>
1106
-    <br>
1107
-    Likely Mentors: <i>Nick (nickm)</i>
1108 1449
     <p>
1109
-    We have a little Python tool called <a
1110
-    href="https://gitweb.torproject.org/nickm/chutney.git">Chutney</a> for
1111
-    making small local test networks.  It's small, not widely used, and not as
1112
-    automated as it could be.
1450
+    We'd like to do this with Tor, to improve its resistance to attacks.  The
1451
+    easiest areas to address would be on systems like <a
1452
+    href="https://lwn.net/Articles/475361/">recent Linux kernels</a> that make
1453
+    it easy to drop or restrict the set of syscalls that a program can invoke.
1454
+    That's a great project, but probably not big enough for an internship just
1455
+    on its own.  For that, we'd want to make progress on at least multiple
1456
+    platforms, or look into refactoring Tor into pieces that need more
1457
+    privileges and pieces that don't with an eye towards sandboxing them
1458
+    differently.
1113 1459
     </p>
1114 1460
     
1115 1461
     <p>
1116
-    It would be great to see chutney extended and a set of supporting tests
1117
-    built to the point where we could use Chutney to exercise various Tor
1118
-    features as an automated integration test.
1462
+    See tickets <a href="https://trac.torproject.org/7005">#7005</a> and <a
1463
+    href="https://trac.torproject.org/5219">#5219</a>, and their descendants,
1464
+    for more information.
1119 1465
     </p>
1120 1466
     </li>
1121 1467
     
1122
-    <a id="stemUsability"></a>
1468
+    <a id="metricsSearch"></a>
1123 1469
     <li>
1124
-    <b>Stem Usability Improvements</b>
1125
-    <br>
1126
-    Priority: <i>Medium</i>
1470
+    <b>Searchable Tor descriptor and Metrics data archive</b>
1127 1471
     <br>
1128 1472
     Effort Level: <i>Medium</i>
1129 1473
     <br>
1130 1474
     Skill Level: <i>Medium</i>
1131 1475
     <br>
1132
-    Likely Mentors: <i>Damian (atagar)</i>
1133
-    <p>
1134
-    <a href="https://stem.readthedocs.org/en/latest/index.html">Stem</a> is a
1135
-    python controller library for tor. Like it's predecessor, <a
1136
-    href="#project-torctl">TorCtl</a>, it uses tor's <a
1137
-    href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt">control
1138
-    protocol</a> to help developers program against the tor process, enabling
1139
-    them to build things similar to <a href="#project-vidalia">Vidalia</a> and
1140
-    <a href="#project-arm">arm</a>.
1141
-    </p>
1142
-    
1143
-    <p>
1144
-    While TorCtl provided a fine first draft for this sort of functionality,
1145
-    it has not proved to be extensible nor maintainable. Stem is a rewrite of
1146
-    TorCtl with a heavy focus on testing, documentation, and providing a
1147
-    developer friendly API.
1148
-    </p>
1149
-    
1150
-    <p>
1151
-    Stem is very nearly feature complete but presently has no users. We
1152
-    want to change that prior to making our first release for a couple
1153
-    reasons...
1154
-    </p>
1155
-    
1156
-    <ul>
1157
-      <li>Make sure that we have a reasonably good API, and improve the rough
1158
-      edges that hurt its usability.</li>
1159
-      <li>Provide examples for how stem can be used.</li>
1160
-    </ul>
1161
-    
1162
-    <p>
1163
-    This project involves several tasks...
1164
-    </p>
1165
-    
1166
-    <ol>
1167
-      <li>Move stem's site to Tor's website (<a href="https://trac.torproject.org/projects/tor/ticket/7324">ticket</a>)</li>
1168
-      <li>Set up Piwik for our site (<a href="https://trac.torproject.org/projects/tor/ticket/7424">ticket</a>)</li>
1169
-      <li>Come up with a better, more developer friendly "Module Overview" for our documentation (<a href="https://stem.readthedocs.org/en/latest/api/control.html">example page</a>). For instance, it would be nice to provide interlinking between the overview and the classes/methods that it lists. This will probably involve asking for help from the <a href="http://sphinx-doc.org/">Sphinx user list</a>.</li>
1170
-      <li>Finally get your hands dirty using stem. We want to expand stem's <a href="https://stem.readthedocs.org/en/latest/tutorial.html">tutorial page</a> with more examples. To do this you'll want to both brainstorm some of your own and contact the <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev/">tor-dev@ email list</a> to solicit ideas. This last step is pretty open ended, so go nuts with whatever you think will improve stem's usability!</li>
1171
-    </ol>
1476
+    Likely Mentors: <i>Karsten</i>
1477
+    <p>The <a href="https://metrics.torproject.org/data.html">Metrics data
1478
+    archive</a> of Tor relay descriptors and other Tor-related network data has
1479
+    grown to over 100G in size, bz2-compressed.  We have developed two search
1480
+    interfaces: the <a
1481
+    href="https://metrics.torproject.org/relay-search.html">relay search</a>
1482
+    finds relays by nickname, fingerprint, or IP address in a given month; <a
1483
+    href="https://metrics.torproject.org/exonerator.html">ExoneraTor</a> finds
1484
+    whether a given IP address was a relay on a given day.</p>
1485
+    
1486
+    <p>We'd like to have a more general search application for Tor descriptors
1487
+    and metrics data.  There are more <a
1488
+    href="https://metrics.torproject.org/formats.html">descriptor types</a>
1489
+    that we'd like to include in the search.  The search application should
1490
+    handle most of them and understand some semantics like what's a timestamp,
1491
+    what's an IP address, and what's a link to another descriptor.  Users
1492
+    should then be able to search for arbitrary strings or limit their search
1493
+    to given time periods or IP address ranges.  Descriptors that reference
1494
+    other descriptors should contain links, and descriptors should be able to
1495
+    say from where they are linked.  The goal is to make the archive easily
1496
+    browsable.</p>
1497
+    
1498
+    <p>The search application shall be separate from the metrics website and
1499
+    shouldn't rely on the metrics website codebase.  The search application
1500
+    will contain hourly updated descriptor data from the metrics website via
1501
+    rsync.  Programming language and database system are not specified yet,
1502
+    though there's a slight preference for Python/Django and Postgres for
1503
+    maintenance reasons.  If there are good reasons to pick something else,
1504
+    e.g, some NoSQL variant or some search application framework, that's fine,
1505
+    too.  Further requirements are that lookups should be really fast and that
1506
+    changes to the search application can be implemented in reasonable
1507
+    time.</p>
1508
+    
1509
+    <p>Applications for this project should come with a design of the proposed
1510
+    search application, ideally with a proof-of-concept based on a subset of
1511
+    the available data to show that it will be able to handle the 100G+ of
1512
+    data.</p>
1172 1513
     </li>
1173 1514
     
1174
-    <a id="compassRefactoring"></a>
1515
+    <!--
1516
+    <a id="simulateSlowConnections"></a>
1175 1517
     <li>
1176
-    <b>Compass Refactoring</b>
1177
-    <br>
1178
-    Priority: <i>Medium</i>
1518
+    <b>Simulator for slow Internet connections</b>
1179 1519
     <br>
1180 1520
     Effort Level: <i>Medium</i>
1181 1521
     <br>
1182 1522
     Skill Level: <i>Medium</i>
1183 1523
     <br>
1184
-    Likely Mentors: <i>gsathya, karsten</i>
1524
+    Likely Mentors: <i>Nick</i>
1185 1525
     <p>
1186
-    Compass was first designed to be a cli app and then hacked into a web app.
1187
-    The codebase needs to be refactored such that the main processing code is
1188
-    separated from the display functions(probably into separate files) and made
1189
-    modular so that adding more features (<a
1190
-    href="https://trac.torproject.org/6612">#6612</a>) is easy. For example, the
1191
-    main processing logic could be in compass.py, whereas print_groups() and other
1192
-    display related functions could be part of a separate cli.py; web.py would also
1193
-    have to modified to make use of this new modular code. Bonus points for adding
1194
-    features to compass(<a href="https://trac.torproject.org/6619">#6619</a>, <a
1195
-    href="https://trac.torproject.org/6612">#6612</a>, <a
1196
-    href="https://trac.torproject.org/6728">#6728</a>).
1526
+    Many users of Tor have poor-quality Internet connections, giving low
1527
+    bandwidth, high latency, and high packet loss/re-ordering. User
1528
+    experience is that Tor reacts badly to these conditions, but it is
1529
+    difficult to improve the situation without being able to repeat the
1530
+    problems in the lab.
1531
+    </p>
1532
+    
1533
+    <p>
1534
+    This project would be to build a simulation environment which
1535
+    replicates the poor connectivity so that the effect on Tor performance
1536
+    can be measured. Other components would be a testing utility to
1537
+    establish what are the properties of connections available, and to
1538
+    measure the effect of performance-improving modifications to Tor.
1539
+    </p>
1540
+    
1541
+    <p>
1542
+    The tools used would be up to the student, but dummynet (for FreeBSD)
1543
+    and nistnet (for Linux) are two potential components on which this
1544
+    project could be built. Students should be experienced with network
1545
+    programming/debugging and TCP/IP, and preferably familiar with C and a
1546
+    scripting language.
1197 1547
     </p>
1198 1548
     </li>
1549
+    -->
1199 1550
     
1200 1551
     <!--
1201 1552
     <a id="stemPathsupport"></a>
1202 1553
     <li>
1203 1554
     <b>Stem PathSupport Capabilities</b>
1204 1555
     <br>
1205
-    Priority: <i>High</i>
1206
-    <br>
1207 1556
     Effort Level: <i>High</i>
1208 1557
     <br>
1209 1558
     Skill Level: <i>Medium</i>
... ...
@@ -1261,160 +1610,61 @@ meetings around the world.</li>
1261 1610
     </li>
1262 1611
     -->
1263 1612
     
1264
-    <!--
1265
-    <a id="orbot-userInterface"></a>
1613
+    <a id="stemUsability"></a>
1266 1614
     <li>
1267
-    <b>Build a better user interface for Orbot</b>
1268
-    <br>
1269
-    Priority: <i>High</i>
1615
+    <b>Stem Usability Improvements</b>
1270 1616
     <br>
1271 1617
     Effort Level: <i>Medium</i>
1272 1618
     <br>
1273 1619
     Skill Level: <i>Medium</i>
1274 1620
     <br>
1275
-    Likely Mentors: <i>Jake</i>
1276
-    <p>Improved home screen to show confirmation of connection (via a TorCheck
1277
-    API call), better statistics about data transferred (up/down), number of
1278
-    circuits connected, quality of connection and so on. The &quot;Tether
1279
-    Wifi&quot; Android application is a good model to follow in how it shows a
1280
-    realtime count of bytes transferred as well as notifications when wifi
1281
-    clients connect. In addition, better handling of Tor system and error
1282
-    messages would also be very helpful, include use of standard Android
1283
-    operating systems notifications. The addition of a wizard or tutorial
1284
-    walkthrough for novice users to explain to them exactly what is and what is
1285
-    not anonymized or protected would greatly improve the likelihood they will
1286
-    use Orbot correctly. All of this should work on the range of screens and
1287
-    device types now offered for Android, from 2&quot; phone to 10&quot;
1288
-    Tablet.</p>
1289
-    </li>
1290
-    -->
1621
+    Likely Mentors: <i>Damian (atagar)</i>
1622
+    <p>
1623
+    <a href="https://stem.readthedocs.org/en/latest/index.html">Stem</a> is a
1624
+    python controller library for tor. Like it's predecessor, <a
1625
+    href="#project-torctl">TorCtl</a>, it uses tor's <a
1626
+    href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt">control
1627
+    protocol</a> to help developers program against the tor process, enabling
1628
+    them to build things similar to <a href="#project-vidalia">Vidalia</a> and
1629
+    <a href="#project-arm">arm</a>.
1630
+    </p>
1291 1631
     
1292
-    <!--
1293
-    <a id="user-space-transport"></a>
1294
-    <li>
1295
-    <b>Integrating Tor with user-space transport protocol libraries</b>
1296
-    <br>
1297
-    Priority: <i>Medium to High</i>
1298
-    <br>
1299
-    Effort Level: <i>High</i>
1300
-    <br>
1301
-    Skill Level: <i>High</i>
1302
-    <br>
1303
-    Likely Mentors: <i>Steven</i>
1304
-    <p>Tor currently sends data over TCP links between nodes. <a
1305
-    href="http://static.usenix.org/events/sec09/tech/full_papers/reardon.pdf">Prior
1306
-    research</a> has indicated that this may not be optimal, and instead the
1307
-    role that TCP plays (congestion control and reliability) should be moved
1308
-    into Tor itself. This would allow a number of desirable changes, such as
1309
-    preventing errors on one circuit delaying another, and giving Tor control
1310
-    and visibility of congestion control.</p>
1311
-    <p>There are <a
1312
-    href="http://www.cl.cam.ac.uk/~sjm217/papers/tor11datagramcomparison.pdf">many
1313
-    ways to do this</a>, each with their own tradeoffs and difficulty of
1314
-    implementation. This project will be to select one (or more) option and
1315
-    implement it in Tor. The primary goal will be to test this modified version
1316
-    of Tor in simulation, but if it turns out to work well, it could be
1317
-    deployed in the live Tor network.</p>
1318
-    <p>Excellent C programming skills are needed, and knowledge of Tor
1319
-    internals are highly desirable.</p>
1320
-    </li>
1321
-    -->
1632
+    <p>
1633
+    While TorCtl provided a fine first draft for this sort of functionality,
1634
+    it has not proved to be extensible nor maintainable. Stem is a rewrite of
1635
+    TorCtl with a heavy focus on testing, documentation, and providing a
1636
+    developer friendly API.
1637
+    </p>
1322 1638
     
1323
-    <!--
1324
-    <a id="resistCensorship"></a>
1325
-    <li>
1326
-    <b>Improving Tor's ability to resist censorship</b>
1327
-    <br>
1328
-    Priority: <i>Medium to High</i>
1329
-    <br>
1330
-    Effort Level: <i>Medium to High</i>
1331
-    <br>
1332
-    Skill Level: <i>High</i>
1333
-    <br>
1334
-    Likely Mentors: <i>Jake, Thomas</i>
1335
-    <p>The Tor 0.2.1.x series makes <a
1336
-    href="<svnprojects>design-paper/blocking.html">significant
1337
-    improvements</a> in resisting national and organizational censorship.
1338
-    But Tor still needs better mechanisms for some parts of its
1339
-    anti-censorship design.</p>
1340
-    <p>One huge category of work is adding features to our <a
1341
-    href="https://gitweb.torproject.org/bridgedb.git?a=tree">BridgeDB</a>
1342
-    service (Python). Tor aims to give out <a href="<page docs/bridges>">bridge
1343
-    relay addresses</a> to users that can't reach the Tor network
1344
-    directly, but there's an arms race between algorithms for distributing
1345
-    addresses and algorithms for gathering and blocking them. See <a
1346
-    href="<blog>bridge-distribution-strategies">our
1347
-    blog post on the topic</a> as an overview, and then look at <a
1348
-    href="https://lists.torproject.org/pipermail/tor-dev/2009-December/000666.html">Roger's
1349
-    or-dev post</a> from December 2009 for more recent thoughts &mdash; lots of
1350
-    design work remains.</p>
1351
-    <p>If you want to get more into the guts of Tor itself (C), a more minor problem
1352
-    we should address is that current Tors can only listen on a single
1353
-    address/port combination at a time. There's
1354
-    <a href="<specblob>proposals/118-multiple-orports.txt">a
1355
-    proposal to address this limitation</a> and allow clients to connect
1356
-    to any given Tor on multiple addresses and ports, but it needs more
1357
-    work.</p>
1358
-    <p>This project could involve a lot of research and design. One of the big
1359
-    challenges will be identifying and crafting approaches that can still
1360
-    resist an adversary even after the adversary knows the design, and
1361
-    then trading off censorship resistance with usability and
1362
-    robustness.</p>
1363
-    </li>
1364
-    -->
1639
+    <p>
1640
+    Stem is very nearly feature complete but presently has no users. We
1641
+    want to change that prior to making our first release for a couple
1642
+    reasons...
1643
+    </p>
1644
+    
1645
+    <ul>
1646
+      <li>Make sure that we have a reasonably good API, and improve the rough
1647
+      edges that hurt its usability.</li>
1648
+      <li>Provide examples for how stem can be used.</li>
1649
+    </ul>
1650
+    
1651
+    <p>
1652
+    This project involves several tasks...
1653
+    </p>
1365 1654
     
1366
-    <!--
1367
-    <a id="tailsHiddenServicePetnames"></a>
1368
-    <li>
1369
-    <b>Petname system for Tor hidden services</b>
1370
-    <br>
1371
-    Priority: <i>Medium</i>
1372
-    <br>
1373
-    Effort Level: <i>High</i>
1374
-    <br>
1375
-    Skill Level: <i>High</i>
1376
-    <br>
1377
-    Likely Mentors: <i>ague</i>
1378
-    <p>Tor provides hidden services. These services are only reachable through
1379
-    Tor itself, and provide greater anonymity both for the providers of the
1380
-    service and for its users.</p>
1381
-    <p>One current downside of Tor hidden services is that they are addressed
1382
-    using 80-bit base32-encoded addresses such as "v2cbb2l4lsnpio4q.onion".
1383
-    These addresses are hard to remember; this makes them hard to use
1384
-    within amnesic environment like Tails.</p>
1385
-    <p>The project is to implement a petname system for Tor hidden services:
1386
-    a way for users or providers of Tor hidden services to add a simple
1387
-    'nickname' to a central database. Users could then query this central
1388
-    database to retrieve a full hidden service address by giving
1389
-    a nickname.</p>
1390
-    <p>Adding petnames to the database could be done using a web interface or
1391
-    automated fetch like those described in the <a
1392
-    href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-onion-nyms.txt">&quot;.onion
1393
-    nym system&quot; proposal</a>.</p>
1394
-    <p>Querying the database could be done using a web interface, a REST API and
1395
-    a DNS interface.</p>
1396
-    <p>In order not to grow indefinitely, the software should make regular tests to
1397
-    see if hidden services are still reachable and, depending on the last time
1398
-    a nickname was accessed, cleanup the database as necessary.</p>
1399
-    <p>The software should allow a distributed, fault-tolerant setup.
1400
-    All nodes should have a synchronized copy of the database, should be
1401
-    ready to answer queries and should coordinate the tests for hidden
1402
-    service availability.</p>
1403
-    <p>The resulting codebase must be easy to deploy: it should not be hard to
1404
-    setup new databases.</p>
1405
-    <p>It is expected that the volunteer will be using Behaviour Driven
1406
-    Development methods. Either in Ruby using Cucumber and RSpec, or in
1407
-    Python using similar tools.</p>
1655
+    <ol>
1656
+      <li>Move stem's site to Tor's website (<a href="https://trac.torproject.org/projects/tor/ticket/7324">ticket</a>)</li>
1657
+      <li>Set up Piwik for our site (<a href="https://trac.torproject.org/projects/tor/ticket/7424">ticket</a>)</li>
1658
+      <li>Come up with a better, more developer friendly "Module Overview" for our documentation (<a href="https://stem.readthedocs.org/en/latest/api/control.html">example page</a>). For instance, it would be nice to provide interlinking between the overview and the classes/methods that it lists. This will probably involve asking for help from the <a href="http://sphinx-doc.org/">Sphinx user list</a>.</li>
1659
+      <li>Finally get your hands dirty using stem. We want to expand stem's <a href="https://stem.readthedocs.org/en/latest/tutorial.html">tutorial page</a> with more examples. To do this you'll want to both brainstorm some of your own and contact the <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev/">tor-dev@ email list</a> to solicit ideas. This last step is pretty open ended, so go nuts with whatever you think will improve stem's usability!</li>
1660
+    </ol>
1408 1661
     </li>
1409
-    -->
1410 1662
     
1411 1663
     <!--
1412 1664
     <a id="tailsServer"></a>
1413 1665
     <li>
1414 1666
     <b>Tails server: Self-hosted services behind Tails-powered Tor hidden services</b>
1415 1667
     <br>
1416
-    Priority: <i>Medium</i>
1417
-    <br>
1418 1668
     Effort Level: <i>High</i>
1419 1669
     <br>
1420 1670
     Skill Level: <i>Medium, but wide-scoped</i>
... ...
@@ -1481,291 +1731,63 @@ meetings around the world.</li>
1481 1731
     <p>This project can easily grow quite large, so the first task would
1482 1732
     probably be to clarify what it would need to get an initial (minimal
1483 1733
     but working) implementation ready to be shipped to users.</p>
1484
-    <p>This project does not require to be an expert in one specific field,
1485
-    but it requires to be experienced and at ease with a large scope of
1486
-    software development tools, processes, and operating system knowledge.</p>
1487
-    <p>Undertaking this project requires in-depth knowledge of Debian-like
1488
-    systems (self-test: do the "dpkg conffile" and "debconf preseeding"
1489
-    words sound new to your ear?); the Debian Live persistence system
1490
-    being written in shell, being at ease with robust shell scripting is
1491
-    a must; to end with, at least two pieces of software need to be
1492
-    written from scratch (a GUI and a webapp): the preferred languages for
1493
-    these tasks would be Python and Perl. Using Behaviour Driven
1494
-    Development methods to convey expectations and acceptance criteria
1495
-    would be most welcome.</p>
1496
-    <p>For more information see https://tails.boum.org/todo/server_edition/</p>
1497
-    </li>
1498
-    -->
1499
-    
1500
-    <!--
1501
-    <a id="geoIPUpgrade"></a>
1502
-    <li>
1503
-    <b>Improve our GeoIP file format</b>
1504
-    <br>
1505
-    Priority: <i>Medium</i>
1506
-    <br>
1507
-    Effort Level: <i>Medium</i>
1508
-    <br>
1509
-    Skill Level: <i>Medium to High</i>
1510
-    <br>
1511
-    Likely Mentors: <i>Robert Ransom</i>
1512
-    <p>Currently, Tor bridges and relays read an entire IP-&gt;country database
1513
-    into memory from a text file during startup.  We would like to
1514
-    distribute this database and store it on disk in a much more compact
1515
-    form, and perform IP-&gt;country lookups on it in its on-disk format if
1516
-    possible.</p>
1517
-    <p>We have <a href='https://trac.torproject.org/projects/tor/ticket/2506'>a
1518
-    sketch of a design</a> for a moderately optimized format for IPv4 GeoIP
1519
-    data; this project will involve both implementing the IPv4 format and
1520
-    designing and implementing a format for IPv6 GeoIP data.</p>
1521
-    <p>Since the core of this project is researching IPv6 GeoIP data and
1522
-    designing the IPv6 format, this is not likely to be a good GSoC
1523
-    project.</p>
1524
-    </li>
1525
-    -->
1526
-    
1527
-    <!--
1528
-    <a id="armClientMode"></a>
1529
-    <li>
1530
-    <b>Client Mode Use Cases for Arm</b>
1531
-    <br>
1532
-    Priority: <i>Medium</i>
1533
-    <br>
1534
-    Effort Level: <i>High</i>
1535
-    <br>
1536
-    Skill Level: <i>Medium</i>
1537
-    <br>
1538
-    Likely Mentors: <i>Damian (atagar)</i>
1539
-    <p><a href="<page projects/arm>">Arm</a> is a Tor command line status
1540
-    monitor on *nix environments (Linux, Mac, and BSD). It functions much like
1541
-    top does, giving a CLI overlay of Tor's bandwidth usage, connections,
1542
-    configuration, log, etc. Thus far its design has been geared for Tor relay
1543
-    operators. However, this doesn't need to be the case. This project would be
1544
-    to expand and simplify arm to make it useful for Tor's client users
1545
-    too.</p>
1546
-    
1547
-    <p>This would include UI design, experimenting, and a lot of python
1548
-    hacking. Here's some ideas for client functionality arm could provide:</p>
1549
-    
1550
-    <ul>
1551
-      <li>A panel for client connections, showing each hop of the user's
1552
-      circuits with the ISP, country, and jurisdiction where those relays
1553
-      reside. Other interesting information would be the circuit's latency, how
1554
-      long its been around, and its possible exit ports. Some of this will be
1555
-      pretty tricky and require some experimentation to figure out what
1556
-      information can be fetched safely (for instance, scraping rdns and whois
1557
-      lookups could give hints about a relay's ISP, but we'd need to do it on
1558
-      all Tor relays to avoid leaking our connections to the resolver).</li>
1559
-      
1560
-      <li>Options to let the user request new circuits (the &quot;New
1561
-      Identity&quot; feature in Vidalia), select the exit country, etc.</li>
1562
-      
1563
-      <li>A panel showing Internet application and if their connections are
1564
-      being routed through Tor or not (giving a warning if there's leaks).</li>
1565
-      
1566
-      <li>The status of the bridges we're configured to use (ie, are they up?).
1567
-      This would include adding control port functionality to Tor for <a
1568
-      href="https://trac.torproject.org/projects/tor/ticket/2068">ticket
1569
-      2068</a>.</li>
1570
-      
1571
-      <li>A one click option to set Tor to be a client, relay, or bridge. The
1572
-      goal would be to make it trivial for users to voluntarily contribute to
1573
-      the Tor network.</li>
1574
-      
1575
-      <li>Menus as an alternative to hotkeys to make the interface more
1576
-      intuitive and usable for beginners (<a
1577
-      href="http://gnosis.cx/publish/programming/charming_python_6.html">example</a>).</li>
1578
-      
1579
-      <li>Look at Vidalia and TorK for ideas and solicit input from the Tor community.</li>
1580
-    </ul>
1581
-    
1582
-    <p>
1583
-    More information is available in the following sections of arm's dev notes: <a href="https://trac.torproject.org/projects/tor/wiki/doc/arm#ConnectionListingExpansion">Connection Listing Expansion</a>, <a href="https://trac.torproject.org/projects/tor/wiki/doc/arm#CircuitDetails">Circuit Details</a>, and <a href="https://trac.torproject.org/projects/tor/wiki/doc/arm#ClientModeUseCases">Client Mode Use Cases</a>
1584
-    </p>
1585
-    </li>
1586
-    -->
1587
-    
1588
-    <!--
1589
-    <a id="vidalia-hidden-service-panel"></a>
1590
-    <li>
1591
-    <b>Torrc plugin and improved hidden service configuration panel</b>
1592
-    <br>
1593
-    Priority: <i>Medium</i>
1594
-    <br>
1595
-    Effort Level: <i>Medium</i>
1596
-    <br>
1597
-    Skill Level: <i>Medium</i>
1598
-    <br>
1599
-    Likely Mentors: <i>Tomás</i>
1600
-    <p>Vidalia's configuration handling has changed in the alpha branch. Now
1601
-    every Tor option is saved in the torrc file. With that change, the
1602
-    Hidden Service configuration panel was removed due to its specificity
1603
-    and its multiple bugs.</p>
1604
-    
1605
-    <p>The idea would be to provide the new Torrc class' functionality to the
1606
-    Plugin Engine and with that, create a better Hidden Service
1607
-    configuration panel as a plugin.</p>
1608
-    
1609
-    <p>A person undertaking this project should have good UI design, layout
1610
-    skills and some C++ development experience. Previous experience with Qt
1611
-    and Qt's Designer will be very helpful, but are not required. Javascript
1612
-    knowledge is a plus, but it shouldn't be a problem if the person
1613
-    complies with the previous requirements.</p>
1614
-    </li>
1615
-    -->
1616
-    
1617
-    <a id="metricsSearch"></a>
1618
-    <li>
1619
-    <b>Searchable Tor descriptor and Metrics data archive</b>
1620
-    <br>
1621
-    Priority: <i>Medium</i>
1622
-    <br>
1623
-    Effort Level: <i>Medium</i>
1624
-    <br>
1625
-    Skill Level: <i>Medium</i>
1626
-    <br>
1627
-    Likely Mentors: <i>Karsten</i>
1628
-    <p>The <a href="https://metrics.torproject.org/data.html">Metrics data archive</a> of Tor relay descriptors and other Tor-related network data has grown to over 100G in size, bz2-compressed.  We have developed two search interfaces: the <a href="https://metrics.torproject.org/relay-search.html">relay search</a> finds relays by nickname, fingerprint, or IP address in a given month; <a href="https://metrics.torproject.org/exonerator.html">ExoneraTor</a> finds whether a given IP address was a relay on a given day.</p>
1629
-    
1630
-    <p>We'd like to have a more general search application for Tor descriptors and metrics data.  There are more <a href="https://metrics.torproject.org/formats.html">descriptor types</a> that we'd like to include in the search.  The search application should handle most of them and understand some semantics like what's a timestamp, what's an IP address, and what's a link to another descriptor.  Users should then be able to search for arbitrary strings or limit their search to given time periods or IP address ranges.  Descriptors that reference other descriptors should contain links, and descriptors should be able to say from where they are linked.  The goal is to make the archive easily browsable.</p>
1631
-    
1632
-    <p>The search application shall be separate from the metrics website and shouldn't rely on the metrics website codebase.  The search application will contain hourly updated descriptor data from the metrics website via rsync.  Programming language and database system are not specified yet, though there's a slight preference for Python/Django and Postgres for maintenance reasons.  If there are good reasons to pick something else, e.g, some NoSQL variant or some search application framework, that's fine, too.  Further requirements are that lookups should be really fast and that changes to the search application can be implemented in reasonable time.</p>
1633
-    
1634
-    <p>Applications for this project should come with a design of the proposed search application, ideally with a proof-of-concept based on a subset of the available data to show that it will be able to handle the 100G+ of data.</p>
1635
-    
1636
-    <!--
1637
-    <a id="unitTesting"></a><