[tor-commits] r26627: {website} Adding Tor and Orbot project ideas Yikes, between Nick and N (website/trunk/getinvolved/en)
Damian Johnson
atagar1 at gmail.com
Thu Feb 27 17:19:03 UTC 2014
Author: atagar
Date: 2014-02-27 17:19:03 +0000 (Thu, 27 Feb 2014)
New Revision: 26627
Modified:
website/trunk/getinvolved/en/volunteer.wml
Log:
Adding Tor and Orbot project ideas
Yikes, between Nick and Nathan there's quite a few! Adding GSoC project ideas
from them both for Tor and Orbot.
Modified: website/trunk/getinvolved/en/volunteer.wml
===================================================================
--- website/trunk/getinvolved/en/volunteer.wml 2014-02-26 16:19:35 UTC (rev 26626)
+++ website/trunk/getinvolved/en/volunteer.wml 2014-02-27 17:19:03 UTC (rev 26627)
@@ -425,7 +425,13 @@
<p>
<b>Project Ideas:</b><br />
<i><a href="#torCleanup">Tor Codebase Cleanup</a></i><br />
- <i><a href="#chutneyExpansion">Make Chutney Do More, More Reliably</a></i>
+ <i><a href="#chutneyExpansion">Make Chutney Do More, More Reliably</a></i><br />
+ <i><a href="#improveTorTestCoverage">Improve test coverage in Tor</a></i><br />
+ <i><a href="#useMoreCores">Have the Tor daemon use more cores</a></i><br />
+ <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i><br />
+ <i><a href="#consensusDiffs">Implement consensus diffs</a></i><br />
+ <i><a href="#improvedDnsSupport">Improved DNS support for Tor</a></i><br />
+ <i><a href="#torSandboxing">Help improve Tor sandboxing</a></i>
</p>
<a id="project-orchid"></a>
@@ -516,6 +522,12 @@
date with all changes in Android and mobile threats.
</p>
+ <p>
+ <b>Project Ideas:</b><br />
+ <i><a href="#orbotVPN">Orbot Android VPN</a></i><br />
+ <i><a href="#orfox">Orfox - Firefox/Gecko-based Android Browser for Tor</a></i>
+ </p>
+
<a id="project-tails"></a>
<h3><a href="https://tails.boum.org/">The Amnesic Incognito Live System</a> (<a
href="https://git-tails.immerda.ch/tails/">code</a>, <a
@@ -1306,7 +1318,427 @@
</p>
</li>
+ <a id="orbotVPN"></a>
<li>
+ <b>Orbot Android VPN</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>High</i>
+ <br>
+ Likely Mentors: <i>Nathan (n8fr8)</i>
+ <p>
+Android offers the ability for any application to establish a
+VPNService through which all traffic on the device is sent. We want to
+implement this type of service in order to route all traffic through
+the Tor network. This is a feature that will be implemented directly
+into Orbot: Tor for Android if successfully implemented.
+ </p>
+
+ <p>
+The deliverables for the project will be a working Android VPN
+implementation that routes traffic through Tor, and integration of VPN
+code into the Orbot app. There must also be time made for reporting on
+the project through blog posts, network auditing of tracking to ensure
+leakage is not occurring.
+ </p>
+
+ <p>
+Useful links and documentation to study:
+ </p>
+
+ <ul>
+ <li><a href="https://gitweb.torproject.org/orbot.git">Orbot</a></li>
+ <li><a href="http://developer.android.com/reference/android/net/VpnService.html">Android VPNService API</a></li>
+ <li><a href="https://github.com/guardianproject/OrbotVPN">Existing work on Orbot VPN</a></li>
+ </ul>
+
+ <p>
+Applicant should have the ability to build Orbot application from
+source using Android SDK and NDK tools. A solid understanding of IP
+routing, iptables, netfilter and VPN protocols would also be very
+helpful. The ability to use Wireshark or other network monitoring
+software to test and verify solution is something that can be taught,
+but if you already know how, bonus! Finally, understanding how the
+exiting Tor software can be used with various transparent proxying
+configurations is a good first step to understanding this problem.
+ </p>
+ </li>
+
+ <a id="orfox"></a>
+ <li>
+ <b>Orfox - Firefox/Gecko-based Android Browser for Tor</b>
+ <br>
+ Effort Level: <i>High</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nathan (n8fr8)</i>
+ <p>
+With almost 1 million downloads, our Orweb browser has been a popular
+solution for easily accessing the web via Tor or any other HTTP or
+SOCKS proxy, while also ensuring local data caches are cleared and
+cookies are properly managed. Orweb is based on WebView, which has its
+limitations unfortunately. We would like to move to a
+Firefox/Fennec/GeckoView based browser, and have created a prototype
+for it. Mozilla has begun releasing GeckoView as a standalone
+component, as well, but it needs more testing, debugging and work on
+integration into our streamlined browser app model. Our end goal is to
+have a mobile browser that matches Tor Browser in terms of privacy
+enhancing features and security.
+ </p>
+
+ <p>
+The deliverables for the project are expected to be the creation of a
+alpha quality release of Orfox, a GeckoView-based browser with feature
+parity of Orweb browser. A bonus goal is to implement additional
+features and capabilities based on Tor Browser patches for
+Fennec/Mozilla core. Finally, as always, a required activity is a
+network audit testing of implemented solution with write-ups, reports
+posted publicly.
+ </p>
+
+ <p>
+Useful links to review:
+ </p>
+
+ <ul>
+ <li><a href="https://github.com/guardianproject/orfox">Orfox (gecko prototype)</a></li>
+ <li><a href="https://github.com/guardianproject/orweb">Orweb (production browser on WebView)</a></li>
+ <li><a href="http://starkravingfinkle.org/blog/2013/10/geckoview-embedding-gecko-in-your-android-application/">GeckoView info</a></li>
+ <li><a href="https://www.torproject.org/projects/torbrowser.html.en">Tor Browser (desktop)</a></li>
+ </ul>
+
+ <p>
+Applicant should have the ability to build Fennec and GeckoView
+libraries from source using Android SDK and NDK. Some experince with
+browser security models and threats would be a useful background to
+have. Ability to do network audits to ensure browser proxying is not
+leaking DNS, media streams or other network traffic, as well as tests
+against common browser de-anonymizing attacks are necessary.
+ </p>
+ </li>
+
+ <a id="improveTorTestCoverage"></a>
+ <li>
+ <b>Improve test coverage in Tor</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+Right now, our unit test coverage with the tests we ship is around 30%
+-- only 30% of the executable lines in our source are reached by the
+unit tests. Improving this test coverage could make Tor development
+much more reliable.
+ </p>
+
+ <p>
+So we need better unit tests, and we need better integration tests too.
+ </p>
+
+ <p>
+Improving unit tests would would involve refactoring functions to be more
+testable, and writing a bunch of unit tests.
+ </p>
+
+ <p>
+Improving integratino tests would involve refactoring and improving
+the "chutney" program that launches a test tor network, and writing a
+bunch of tests to see what works and what doesn't work on such a
+network. It could also involve writing tests using the library "<a
+href="https://stem.torproject.org/">stem</a>" to script individual clients on a
+Chutney network.
+ </p>
+
+ <p>
+To get a feel for how testing works in Tor today, download Tor and
+Chutney, and make sure you can build Tor and use Chutney. See how the
+unit tests work by skimming some of the test code in the src/test
+subdirectory. Try computing test coverage (according to the
+instructions in the doc/HACKING file.
+ </p>
+
+ <p>
+Also, have a look at the one current integration test that works on
+chutney today: it is a shell script distributed with Tor as
+src/test/test-tor-network.sh . We probably don't want to have all of
+our integration tests be written as shell scripts, but it's interesting
+to see how one works.
+ </p>
+
+ <p>
+If working on designs for an improved or refactored Chutney, watch out for <a
+href="http://www.joelonsoftware.com/articles/fog0000000018.html">"archicture
+astronautics"</a>: while it's important that we have a well-designed and
+maintainable Chutney architecture, it wouldn't be very useful if a good
+architecture were the <em>only</em> outcome here: we need tests too.
+ </p>
+
+ <p>
+As part of the application process, please contribute a patch that makes
+a non-trivial improvement to chutney, and/or include a new test for some
+interesting Tor function. (Please pick a function that isn't completely
+easy to test.)
+ </p>
+ </li>
+
+ <a id="useMoreCores"></a>
+ <li>
+ <b>Have the Tor daemon use more cores</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+Right now, if you run a busy Tor server on a multicore computer, most of
+the cores are mostly unused. We have a "cpuworker" mechanism to move
+expensive computations into worker threads, but that mechanism is
+currently only used for a small fraction of our cryptography. Moving
+more work into the worker threads could improve performance immensely.
+ </p>
+
+ <p>
+So it would be great to parallelize our cryptography more in order to
+better handle more cores. See
+<a href="https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto">MultithreadedCrypto</a>
+for some background info, and
+<a href="https://trac.torproject.org/projects/tor/ticket/7572">ticket 7572</a> for some subtickets
+on our tracker.
+ </p>
+
+ <p>
+(If you're reading through the code to see how it works today, you will
+also want to have a look at the new implementation for cpuworkers
+described in <a href="https://trac.torproject.org/projects/tor/ticket/9682">9682</a>.)
+ </p>
+
+ <p>
+Completing the implementation of ticket #7572 --which would move our
+circuit crypto onto separate threads-- could be a good summer project.
+Alternatively, moving all of the signature generation and verification
+code onto the cpuworkers could be fun. In either case, you will have
+some important architectural decisions to make about how to minimize
+shared data between the main thread and the workers, how to avoid
+race conditions between them, and how to test it all to make sure it has
+no hidden failure cases.
+ </p>
+
+ <p>
+As part of the application process for this project, please contribute a
+nontrivial patch to Tor -- ideally, one that will affect some part of
+the codebase that you want to work on.
+ </p>
+ </li>
+
+ <a id="improveHiddenServices"></a>
+ <li>
+ <b>Help improve Tor hidden services</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+We're working on a revamp of the entire Tor hidden service design to
+improve the security and reliability of the hidden service system.
+ </p>
+
+ <p>
+This is a big project: see
+<a href="https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/224-rend-spec-ng.txt">proposal
+224</a> for the latest design. Are you interested in implementing some
+part of that?
+ </p>
+
+ <p>
+This is a very ambitious project, so we're deliberately not suggesting
+particular sub-topics. If you're interested in participating, try to
+read and understand the <a
+href="https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/rend-spec.txt">existing
+design</a> and the design proposal for the new design, and then talk to
+us about what part you want to work on.
+ </p>
+
+ <p>
+As part of the application process for this project, please contribute a
+nontrivial patch to Tor -- ideally, one that will affect some part of
+the codebase that you want to work on.
+ </p>
+ </li>
+
+ <a id="consensusDiffs"></a>
+ <li>
+ <b>Implement consensus diffs</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+Right now, every few hours, a Tor client downloads a new signed "consensus
+document" that describes the state of the network. Even though these
+documents are compressed, thisstill takes almost half a megabyte.
+ </p>
+
+ <p>
+<a
+href="https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/140-consensus-diffs.txt">Proposal
+140</a> describes a design to save a lot of bandwidth by transferring
+compressed <a href="http://en.wikipedia.org/wiki/Diff">diff</a>s instead
+of transferring the entire consensus document.
+ </p>
+
+ <p>
+That's an attractive idea, but it presents some programming challenges.
+We probably don't want to ship a 'diff' and 'patch' along with Tor. Is
+there a free, <strong>safe</strong>, robust implementation of one of the
+good diff algorithms that we can use?
+ </p>
+
+ <p>
+Alternatively, can we take advantage of regularities in the descriptor
+format in order to generate diffs more simply?
+ </p>
+
+ <p>
+As part of the application process for this project, please contribute a
+nontrivial patch to Tor -- ideally, one that will affect some part of
+the codebase that you want to work on. Make sure that your application
+describes which implementations of the diff and patch algorithms you
+intend to use, and that your coding samples show strong evidence that
+you can do secure string manipulation in C.
+ </p>
+ </li>
+
+ <a id="improvedDnsSupport"></a>
+ <li>
+ <b>Improved DNS support for Tor</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+Right now, you can only use Tor's DNS support to look up IPv4 and IPv6
+addresses, and to fetch PTR records. But DNS can do so much more!
+ </p>
+
+ <p>
+<a
+href="https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/219-expanded-dns.txt">Proposal
+219</a> describes some new cell types that Tor could use to support
+more types of DNS over Tor.
+ </p>
+
+ <p>
+To see how Tor implements its existing DNS lookups, start by tracing the
+the connection_exit_begin_resolve() function in src/or/connection_edge.c ,
+and see how we pass these requests downwards through src/or/dns.c to the
+underlying resolver. It's not too complicated, but there are some
+tricky parts to understand.
+ </p>
+
+ <p>
+As part of the application process for this project, please contribute a
+nontrivial patch to Tor -- ideally, one that will affect some part of
+the codebase that you want to work on.
+ </p>
+ </li>
+
+ <a id="torSandboxing"></a>
+ <li>
+ <b>Help improve Tor sandboxing</b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+The seccomp2 mechanism on Linux lets programs improve their robustness
+against unforseen bugs by running with restrictions on which system
+calls they can invoke and how they can call them. This can help
+security a lot.
+ </p>
+
+ <p>
+Thanks to a GSOC student from last year, we now have seccomp2 support on
+Linux, which we use to restrict the capabilities of the entire Tor
+process. (For implementation details, see src/commmon/sandbox.c in the
+Tor source.)
+ </p>
+
+ <p>
+But since the restrictions are done over the whole process, all pieces
+of the Tor code have permission to do things that only small parts of
+the Tor program need to do. Also, since we use seccomp2, these
+restrictions only work on Linux.
+ </p>
+
+ <p>
+It would be great to instead divide the main Tor program into multiple
+processes with a robust IPC mechanism and assign each process its own
+minimal set of privileges; and to have this work (as best we can) on
+systems that don't have seccomp2 (eg Windows, Mac).
+ </p>
+
+ <p>
+Either of these could be a whole GSOC project.
+ </p>
+
+ <p>
+To get started, make sure you understand the existing sandboxing code.
+If you're interested in splitting Tor into multiple processes, think
+about the architecture, and think about how we could reach this
+architecture without completely rewriting the codebase. (Remember that
+even if you're focusing on Linux, Tor still needs to work on other
+operating systems.)
+ </p>
+
+ <p>
+If you're interested in supporting more platforms, make sure you
+understand and can explain what sandboxing mechansisms you want to use,
+and what they're capable of. (You might want to investigate the way
+that other open-source programs, like the Chrome web browser, do their
+sandboxing on different platforms.)
+ </p>
+
+ <p>
+As part of the application process for this project, please contribute a
+nontrivial patch to Tor -- ideally, one that will affect some part of
+the codebase that you want to work on.
+ </p>
+ </li>
+
+<!--
+ <a id=""></a>
+ <li>
+ <b></b>
+ <br>
+ Effort Level: <i>Medium</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Damian (atagar)</i>
+ <p>
+
+ </p>
+
+ <p>
+
+ </p>
+ </li>
+-->
+
+ <li>
<b>Bring up new ideas!</b>
<br>
Don't like any of these? Look at the <a
More information about the tor-commits
mailing list