[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r15729: all the .fi pages were missing their props too. this caused (website/trunk/fi)
Author: arma
Date: 2008-07-07 11:39:22 -0400 (Mon, 07 Jul 2008)
New Revision: 15729
Modified:
website/trunk/fi/contribute.wml
website/trunk/fi/developers.wml
website/trunk/fi/documentation.wml
website/trunk/fi/donate.wml
website/trunk/fi/faq.wml
website/trunk/fi/howitworks.wml
website/trunk/fi/index.wml
website/trunk/fi/mirrors.wml
website/trunk/fi/people.wml
website/trunk/fi/research.wml
website/trunk/fi/sponsors.wml
website/trunk/fi/support.wml
website/trunk/fi/users.wml
website/trunk/fi/volunteer.wml
Log:
all the .fi pages were missing their props too. this caused them
not to show up in the flags. thanks to mfr for noticing.
Modified: website/trunk/fi/contribute.wml
===================================================================
--- website/trunk/fi/contribute.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/contribute.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,7 +1,7 @@
-## translation metadata
-# Based-On-Revision: 13768
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Siirrytään" REDIRECT="volunteer" CHARSET="UTF-8"
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 13768
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Siirrytään" REDIRECT="volunteer" CHARSET="UTF-8"
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/contribute.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/developers.wml
===================================================================
--- website/trunk/fi/developers.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/developers.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,7 +1,7 @@
-## translation metadata
-# Based-On-Revision: 8207
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Siirrytään" REDIRECT="documentation#Developers" CHARSET="UTF-8"
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 8207
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Siirrytään" REDIRECT="documentation#Developers" CHARSET="UTF-8"
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/developers.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/documentation.wml
===================================================================
--- website/trunk/fi/documentation.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/documentation.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,269 +1,269 @@
-## translation metadata
-# Based-On-Revision: 15123
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Ohjeet" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<a id="RunningTor"></a>
-<h2><a class="anchor" href="#RunningTor">Tor-ohjelman pyörittäminen</a></h2>
-<ul>
-<li><a href="<page docs/tor-doc-windows>">Tor-ohjelman asentaminen 32-bittisessä Windowssisa</a></li>
-<li><a href="<page docs/tor-doc-osx>">Tor-ohjelman asentaminen Mac OS X:ssä</a></li>
-<li><a href="<page docs/tor-doc-unix>">Tor-ohjelman asentaminen Linux/BSD/Unix:ssa</a></li>
-<li><a href="<page docs/tor-switchproxy>">SwitchProxy:n asentaminen Tor-ohjelmalle</a></li>
-<li><a href="<page docs/tor-doc-relay>">Tor-reitittimen määrittäminen</a></li>
-<li><a href="<page docs/tor-hidden-service>">Tor-piilopalvelun määrittäminen</a></li>
-</ul>
-
-<a id="Support"></a>
-<h2><a class="anchor" href="#Support">Avun saaminen</a></h2>
-<ul>
-<li>The <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorFAQ";>Tor
-Technical FAQ Wiki</a> should be the first place you look. The
-<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO";>Guide
-to Torifying various applications</a> is also popular. (While we
-monitor the Wiki page to help ensure accuracy, the Tor developers are
-not responsible for the content.)</li>
-<li>The <a href="<page faq-abuse>">Abuse FAQ</a> is a collection of
-common questions and issues discussed when running a Tor relay.</li>
-<li>The <a href="<page eff/tor-legal-faq>">Tor Legal FAQ</a> is written by
-EFF lawyers. It aims to give you an overview of some of the legal issues
-that arise from the Tor project in the US.</li>
-<li>The <a href="<page tor-manual>">manual</a>
-lists all the possible entries you can put in your <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#torrc";>torrc
-file</a>. We also provide a <a href="<page tor-manual-dev>">manual for
-the development version of Tor</a>.</li>
-<li>The <a href="https://wiki.torproject.org/noreply/TheOnionRouter";>Tor
-wiki</a> provides a plethora of helpful contributions from Tor
-users. Check it out!</li>
-<li>The Tor IRC channel (for users, relay operators, and developers)
-is <a href="irc://irc.oftc.net/tor">#tor on irc.oftc.net</a>.</li>
-<li>We have a <a
-href="https://bugs.torproject.org/tor";>bugtracker</a>.
-If you have a bug, especially a crash bug, read <a
-href="https://wiki.torproject.org/wiki/TheOnionRouter/TorFAQ#RelayCrashing";>how
-to report a Tor bug</a> first and then tell us as much information
-about it as you can in the bugtracker. (If your bug is
-with Privoxy, your browser, or some other application, please don't put
-it in our bugtracker.)</li>
-<li>Try the or-talk mailing list <a href="#MailingLists">below</a>.
-<li>As a last resort, look through <a href="<page contact>">the Tor
-contact page</a>.</li>
-</ul>
-
-<a id="MailingLists"></a>
-<h2><a class="anchor" href="#MailingLists">Postituslistatietoja</a></h2>
-<ul>
-<li>The <a href="http://archives.seul.org/or/announce/";>or-announce
-mailing list</a> is a low volume list for announcements of new releases
-and critical security updates. Everybody should be on this list.
-There is also an
-<a href="http://rss.gmane.org/gmane.network.onion-routing.announce";>RSS
-feed</a> of or-announce at <a href="http://gmane.org";>gmane.org</a>.</li>
-<li>The <a href="http://archives.seul.org/or/talk/";>or-talk list</a>
-is where a lot of discussion happens, and is where we send notifications
-of prerelease versions and release candidates.</li>
-<li>The <a href="http://archives.seul.org/or/dev/";>or-dev list</a>
-is for posting by developers only, and is very low traffic.</li>
-<li>A list for <a href="http://archives.seul.org/or/cvs/";>svn commits</a>
-may be interesting for developers.</li>
-</ul>
-
-<a id="UpToSpeed"></a>
-<h2><a class="anchor" href="#UpToSpeed">Getting up to speed on Tor's past,
-present, and future</a></h2>
-
-<ol>
-<li>
-First, read the <a href="<page overview>">overview page</a> to get a
-basic idea of how Tor works, what it's for, and who uses it.
-</li>
-
-<li>
-<a href="<page download>">Install the Tor bundle</a> and try it out.
-Make sure you've got Firefox installed first, and be sure to read the
-<a href="<page download>#Warning">list of warnings</a> about ways you
-can screw up your anonymity.
-</li>
-
-<li>
-Download and watch Roger's overview talk from What The Hack (<a
-href="http://freehaven.net/~arma/wth-anonymous-communication-58.mp4";>video</a>,
-<a href="http://freehaven.net/~arma/wth1.pdf";>slides</a>, <a
-href="http://wiki.whatthehack.org/index.php/Anonymous_communication_for_the_United_States_Department_of_Defense...and_you";>abstract</a>).
-This talk was given in July 2005, back when we were funded by EFF and back
-when the network was quite small, but it still provides good background
-on how Tor works and what it's for.
-</li>
-
-<li>
-Our <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ";>FAQ</a>
-covers all sorts of topics, including questions about setting up a client
-or relay, concerns about anonymity attacks, why we didn't build Tor in
-other ways, and discussion of Tor users and abuse.
-</li>
-
-<li>
-<a href="https://blog.torproject.org/";>Tor has a blog now</a>.
-We try to keep it updated every week or two with the latest news.
-</li>
-
-<li>
-Look through our <a href="#DesignDoc">Design
-Documents</a>. Notice that we have RFC-style specs to tell you exactly
-how Tor is built.
-</li>
-
-<li>
-There's a skeletal <a
-href="<svnsandbox>doc/design-paper/roadmap-future.pdf">list of items
-we'd like to tackle in the future</a>. Alas, many of those items need
-to be fleshed out more before they'll make sense to people who aren't
-Tor developers, but you can still get a general sense of what issues
-need to be resolved next.
-</li>
-
-<li>
-Download and watch Nick's "Technical changes since 2004" talk from
-Defcon in July 2007 (<a
-href="http://freehaven.net/~arma/Defcon15-Mathewson-Technical_Changes_since_you_Last_Heard_about_Tor.mp4";>video</a>, <a
-href="http://freehaven.net/~nickm/slides/Defcon07/TorChanges.pdf";>slides</a>),
-Roger's "blocking-resistance
-and circumvention" talk from 23C3 in December 2006 (<a
-href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v";>video</a>,
-<a href="http://freehaven.net/~arma/slides-23c3.pdf";>slides</a>,
-<a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html";>abstract</a>,
-<a href="<svnsandbox>doc/design-paper/blocking.html">design paper</a>),
-and Roger's "Current events in 2007" talk from 24C3 in December
-2007 (<a
-href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4";>video</a>,
-<a href="http://freehaven.net/~arma/slides-24c3.pdf";>slides</a>,
-<a href="http://events.ccc.de/congress/2007/Fahrplan/events/2325.en.html";>abstract</a>).
-We also have the What The Hack tutorial on hidden services (<a
-href="http://freehaven.net/~arma/wth_tor_hidden_services.mp4";>video</a>,
-<a href="http://freehaven.net/~arma/wth3.pdf";>slides</a>).
-</li>
-
-<li>
-Learn about the <a
-href="<svnsandbox>doc/spec/proposals/001-process.txt">Tor
-proposal process for changing our design</a>, and look over the <a
-href="<svnsandbox>doc/spec/proposals/">existing proposals</a>.
-</li>
-
-<li>
-Our <a href="<svnsandbox>doc/TODO">developer TODO file</a> starts with a
-timeline for external promises — things <a href="<page sponsors>">our
-sponsors</a> have paid to see done. It also lists many other tasks
-and topics we'd like to tackle next.
-</li>
-
-<li>
-Once you're up to speed, things will continue to change surprisingly fast.
-The <a href="#MailingLists">or-dev mailing list</a> is where the complex
-discussion happens, and the <a href="#Support">#tor IRC channel</a>
-is where the less complex discussion happens.
-</li>
-
-</ol>
-
-<a id="DesignDoc"></a>
-<h2><a class="anchor" href="#DesignDoc">Suunnitteludokumentteja</a></h2>
-<ul>
-<li>The <b>design document</b> (published at Usenix Security 2004)
-gives our justifications and security analysis for the Tor design:
-<a href="<svnsandbox>doc/design-paper/tor-design.pdf">PDF</a> and
-<a href="<svnsandbox>doc/design-paper/tor-design.html">HTML</a>
-versions available.</li>
-<li>Our follow-up paper on <b>challenges in low-latency anonymity</b>
-(still in draft form) details more recent experiences and directions:
-<a href="<svnsandbox>doc/design-paper/challenges.pdf">PDF
-draft</a>.</li>
-<li>Our paper at WEIS 2006 — <b>Anonymity Loves Company:
-Usability and the Network Effect</b> — explains why usability in
-anonymity systems matters for their security: <a
-href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf";>PDF</a>.</li>
-<li>Our preliminary design to make it harder for large firewalls to
-prevent access to the Tor network is described in
-<b>design of a blocking-resistant anonymity system</b>:
-<a href="<svnsandbox>doc/design-paper/blocking.pdf">PDF draft</a> and
-<a href="<svnsandbox>doc/design-paper/blocking.html">HTML draft</a>.
-Want to <a href="<page volunteer>#Coding">help us build it</a>?</li>
-<li>The <b>specifications</b> aim to give
-developers enough information to build a compatible version of Tor:
-<ul>
-<li><a href="<svnsandbox>doc/spec/tor-spec.txt">Main Tor specification</a>
-<li><a href="<svnsandbox>doc/spec/dir-spec.txt">Tor
-version 3 directory server specification</a> (and older <a
-href="<svnsandbox>doc/spec/dir-spec-v1.txt">version 1</a> and <a
-href="<svnsandbox>doc/spec/dir-spec-v2.txt">version 2</a> directory
-specifications)</li>
-<li><a href="<svnsandbox>doc/spec/control-spec.txt">Tor control protocol
-specification</a></li>
-<li><a href="<svnsandbox>doc/spec/rend-spec.txt">Tor rendezvous
-specification</a></li>
-<li><a href="<svnsandbox>doc/spec/path-spec.txt">Tor path selection
-specification</a></li>
-<li><a href="<svnsandbox>doc/spec/address-spec.txt">Special hostnames in
-Tor</a></li>
-<li><a href="<svnsandbox>doc/spec/socks-extensions.txt">Tor's SOCKS support
-and extensions</a></li>
-<li><a href="<svnsandbox>doc/spec/version-spec.txt">How Tor version numbers
-work</a></li>
-<li><a href="<svnsandbox>doc/spec/proposals/">In-progress drafts of
-new specifications and proposed changes</a></li>
-</ul></li>
-
-</ul>
-
-<a id="NeatLinks"></a>
-<h2><a class="anchor" href="#NeatLinks">Siistit linkit</a></h2>
-<ul>
-<li>The <a href="https://wiki.torproject.org/noreply/TheOnionRouter";>Tor
-wiki</a> provides a plethora of helpful contributions from Tor
-users. Check it out!</li>
-<li><a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms";>A
-list of supporting programs you might want to use in association with
-Tor</a>.</li>
-<li><a href="http://check.torproject.org/";>The
-Tor detector</a> or <a href="http://torcheck.xenobite.eu/";>the other
-Tor detector</a> try to guess if you're using Tor or not.</li>
-<li>Check out the
-<a href="http://torstatus.kgprog.com/";>Tor Status</a> page, the other
-<a href="http://torstatus.blutmagie.de/";>Tor Status</a> page, or
-Xenobite's <a href="https://torstat.xenobite.eu/";>Tor node status</a> page.
-Remember that these lists may not be as accurate as what your Tor
-client uses, because your client fetches all the authoritative directories
-and combines them locally.</li>
-<li>Read <a
-href="http://freehaven.net/anonbib/topic.html#Anonymous_20communication";>these
-papers</a> (especially the ones in boxes) to get up to speed on the field
-of anonymous communication systems.</li>
-</ul>
-
-<a id="Developers"></a>
-<h2><a class="anchor" href="#Developers">Kehittäjille</a></h2>
- Browse the Tor <b>source repository</b>: (which may not necessarily work or even compile)
- <ul>
- <li><a href="<svnsandbox>">Regularly updated SVN sandbox</a></li>
- <li><a href="https://svn.torproject.org/svn/tor/trunk";>Browse the repository's source tree directly</a></li>
- <li><a href="http://cvs.seul.org/viewcvs/viewcvs.cgi/tor/?root=Tor";>ViewCVS</a></li>
- <li>anonymous <a href="http://subversion.tigris.org/";>subversion</a> access:
- <ul>
- <li>Make a new empty directory and cd into it.</li>
- <li><kbd>svn checkout https://tor-svn.freehaven.net/svn/tor/trunk tor</kbd></li>
- <li><kbd>svn checkout https://tor-svn.freehaven.net/svn/website/trunk website</kbd></li>
- <li>To check out the maintenance branch, use<br /><kbd>svn checkout https://tor-svn.freehaven.net/svn/tor/branches/tor-0_1_2-patches</kbd></li>
- </ul><br>
- <b>HTTPS certificate fingerprint:</b> 11:34:5c:b1:c4:12:76:10:86:ce:df:69:3d:06:a9:57:fa:dc:c9:29
- </li>
- </ul>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 15123
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Ohjeet" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<a id="RunningTor"></a>
+<h2><a class="anchor" href="#RunningTor">Tor-ohjelman pyörittäminen</a></h2>
+<ul>
+<li><a href="<page docs/tor-doc-windows>">Tor-ohjelman asentaminen 32-bittisessä Windowssisa</a></li>
+<li><a href="<page docs/tor-doc-osx>">Tor-ohjelman asentaminen Mac OS X:ssä</a></li>
+<li><a href="<page docs/tor-doc-unix>">Tor-ohjelman asentaminen Linux/BSD/Unix:ssa</a></li>
+<li><a href="<page docs/tor-switchproxy>">SwitchProxy:n asentaminen Tor-ohjelmalle</a></li>
+<li><a href="<page docs/tor-doc-relay>">Tor-reitittimen määrittäminen</a></li>
+<li><a href="<page docs/tor-hidden-service>">Tor-piilopalvelun määrittäminen</a></li>
+</ul>
+
+<a id="Support"></a>
+<h2><a class="anchor" href="#Support">Avun saaminen</a></h2>
+<ul>
+<li>The <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorFAQ";>Tor
+Technical FAQ Wiki</a> should be the first place you look. The
+<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO";>Guide
+to Torifying various applications</a> is also popular. (While we
+monitor the Wiki page to help ensure accuracy, the Tor developers are
+not responsible for the content.)</li>
+<li>The <a href="<page faq-abuse>">Abuse FAQ</a> is a collection of
+common questions and issues discussed when running a Tor relay.</li>
+<li>The <a href="<page eff/tor-legal-faq>">Tor Legal FAQ</a> is written by
+EFF lawyers. It aims to give you an overview of some of the legal issues
+that arise from the Tor project in the US.</li>
+<li>The <a href="<page tor-manual>">manual</a>
+lists all the possible entries you can put in your <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#torrc";>torrc
+file</a>. We also provide a <a href="<page tor-manual-dev>">manual for
+the development version of Tor</a>.</li>
+<li>The <a href="https://wiki.torproject.org/noreply/TheOnionRouter";>Tor
+wiki</a> provides a plethora of helpful contributions from Tor
+users. Check it out!</li>
+<li>The Tor IRC channel (for users, relay operators, and developers)
+is <a href="irc://irc.oftc.net/tor">#tor on irc.oftc.net</a>.</li>
+<li>We have a <a
+href="https://bugs.torproject.org/tor";>bugtracker</a>.
+If you have a bug, especially a crash bug, read <a
+href="https://wiki.torproject.org/wiki/TheOnionRouter/TorFAQ#RelayCrashing";>how
+to report a Tor bug</a> first and then tell us as much information
+about it as you can in the bugtracker. (If your bug is
+with Privoxy, your browser, or some other application, please don't put
+it in our bugtracker.)</li>
+<li>Try the or-talk mailing list <a href="#MailingLists">below</a>.
+<li>As a last resort, look through <a href="<page contact>">the Tor
+contact page</a>.</li>
+</ul>
+
+<a id="MailingLists"></a>
+<h2><a class="anchor" href="#MailingLists">Postituslistatietoja</a></h2>
+<ul>
+<li>The <a href="http://archives.seul.org/or/announce/";>or-announce
+mailing list</a> is a low volume list for announcements of new releases
+and critical security updates. Everybody should be on this list.
+There is also an
+<a href="http://rss.gmane.org/gmane.network.onion-routing.announce";>RSS
+feed</a> of or-announce at <a href="http://gmane.org";>gmane.org</a>.</li>
+<li>The <a href="http://archives.seul.org/or/talk/";>or-talk list</a>
+is where a lot of discussion happens, and is where we send notifications
+of prerelease versions and release candidates.</li>
+<li>The <a href="http://archives.seul.org/or/dev/";>or-dev list</a>
+is for posting by developers only, and is very low traffic.</li>
+<li>A list for <a href="http://archives.seul.org/or/cvs/";>svn commits</a>
+may be interesting for developers.</li>
+</ul>
+
+<a id="UpToSpeed"></a>
+<h2><a class="anchor" href="#UpToSpeed">Getting up to speed on Tor's past,
+present, and future</a></h2>
+
+<ol>
+<li>
+First, read the <a href="<page overview>">overview page</a> to get a
+basic idea of how Tor works, what it's for, and who uses it.
+</li>
+
+<li>
+<a href="<page download>">Install the Tor bundle</a> and try it out.
+Make sure you've got Firefox installed first, and be sure to read the
+<a href="<page download>#Warning">list of warnings</a> about ways you
+can screw up your anonymity.
+</li>
+
+<li>
+Download and watch Roger's overview talk from What The Hack (<a
+href="http://freehaven.net/~arma/wth-anonymous-communication-58.mp4";>video</a>,
+<a href="http://freehaven.net/~arma/wth1.pdf";>slides</a>, <a
+href="http://wiki.whatthehack.org/index.php/Anonymous_communication_for_the_United_States_Department_of_Defense...and_you";>abstract</a>).
+This talk was given in July 2005, back when we were funded by EFF and back
+when the network was quite small, but it still provides good background
+on how Tor works and what it's for.
+</li>
+
+<li>
+Our <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ";>FAQ</a>
+covers all sorts of topics, including questions about setting up a client
+or relay, concerns about anonymity attacks, why we didn't build Tor in
+other ways, and discussion of Tor users and abuse.
+</li>
+
+<li>
+<a href="https://blog.torproject.org/";>Tor has a blog now</a>.
+We try to keep it updated every week or two with the latest news.
+</li>
+
+<li>
+Look through our <a href="#DesignDoc">Design
+Documents</a>. Notice that we have RFC-style specs to tell you exactly
+how Tor is built.
+</li>
+
+<li>
+There's a skeletal <a
+href="<svnsandbox>doc/design-paper/roadmap-future.pdf">list of items
+we'd like to tackle in the future</a>. Alas, many of those items need
+to be fleshed out more before they'll make sense to people who aren't
+Tor developers, but you can still get a general sense of what issues
+need to be resolved next.
+</li>
+
+<li>
+Download and watch Nick's "Technical changes since 2004" talk from
+Defcon in July 2007 (<a
+href="http://freehaven.net/~arma/Defcon15-Mathewson-Technical_Changes_since_you_Last_Heard_about_Tor.mp4";>video</a>, <a
+href="http://freehaven.net/~nickm/slides/Defcon07/TorChanges.pdf";>slides</a>),
+Roger's "blocking-resistance
+and circumvention" talk from 23C3 in December 2006 (<a
+href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v";>video</a>,
+<a href="http://freehaven.net/~arma/slides-23c3.pdf";>slides</a>,
+<a href="http://events.ccc.de/congress/2006/Fahrplan/events/1444.en.html";>abstract</a>,
+<a href="<svnsandbox>doc/design-paper/blocking.html">design paper</a>),
+and Roger's "Current events in 2007" talk from 24C3 in December
+2007 (<a
+href="http://freehaven.net/~arma/24c3-2325-en-current_events_in_tor_development.mp4";>video</a>,
+<a href="http://freehaven.net/~arma/slides-24c3.pdf";>slides</a>,
+<a href="http://events.ccc.de/congress/2007/Fahrplan/events/2325.en.html";>abstract</a>).
+We also have the What The Hack tutorial on hidden services (<a
+href="http://freehaven.net/~arma/wth_tor_hidden_services.mp4";>video</a>,
+<a href="http://freehaven.net/~arma/wth3.pdf";>slides</a>).
+</li>
+
+<li>
+Learn about the <a
+href="<svnsandbox>doc/spec/proposals/001-process.txt">Tor
+proposal process for changing our design</a>, and look over the <a
+href="<svnsandbox>doc/spec/proposals/">existing proposals</a>.
+</li>
+
+<li>
+Our <a href="<svnsandbox>doc/TODO">developer TODO file</a> starts with a
+timeline for external promises — things <a href="<page sponsors>">our
+sponsors</a> have paid to see done. It also lists many other tasks
+and topics we'd like to tackle next.
+</li>
+
+<li>
+Once you're up to speed, things will continue to change surprisingly fast.
+The <a href="#MailingLists">or-dev mailing list</a> is where the complex
+discussion happens, and the <a href="#Support">#tor IRC channel</a>
+is where the less complex discussion happens.
+</li>
+
+</ol>
+
+<a id="DesignDoc"></a>
+<h2><a class="anchor" href="#DesignDoc">Suunnitteludokumentteja</a></h2>
+<ul>
+<li>The <b>design document</b> (published at Usenix Security 2004)
+gives our justifications and security analysis for the Tor design:
+<a href="<svnsandbox>doc/design-paper/tor-design.pdf">PDF</a> and
+<a href="<svnsandbox>doc/design-paper/tor-design.html">HTML</a>
+versions available.</li>
+<li>Our follow-up paper on <b>challenges in low-latency anonymity</b>
+(still in draft form) details more recent experiences and directions:
+<a href="<svnsandbox>doc/design-paper/challenges.pdf">PDF
+draft</a>.</li>
+<li>Our paper at WEIS 2006 — <b>Anonymity Loves Company:
+Usability and the Network Effect</b> — explains why usability in
+anonymity systems matters for their security: <a
+href="http://freehaven.net/anonbib/cache/usability:weis2006.pdf";>PDF</a>.</li>
+<li>Our preliminary design to make it harder for large firewalls to
+prevent access to the Tor network is described in
+<b>design of a blocking-resistant anonymity system</b>:
+<a href="<svnsandbox>doc/design-paper/blocking.pdf">PDF draft</a> and
+<a href="<svnsandbox>doc/design-paper/blocking.html">HTML draft</a>.
+Want to <a href="<page volunteer>#Coding">help us build it</a>?</li>
+<li>The <b>specifications</b> aim to give
+developers enough information to build a compatible version of Tor:
+<ul>
+<li><a href="<svnsandbox>doc/spec/tor-spec.txt">Main Tor specification</a>
+<li><a href="<svnsandbox>doc/spec/dir-spec.txt">Tor
+version 3 directory server specification</a> (and older <a
+href="<svnsandbox>doc/spec/dir-spec-v1.txt">version 1</a> and <a
+href="<svnsandbox>doc/spec/dir-spec-v2.txt">version 2</a> directory
+specifications)</li>
+<li><a href="<svnsandbox>doc/spec/control-spec.txt">Tor control protocol
+specification</a></li>
+<li><a href="<svnsandbox>doc/spec/rend-spec.txt">Tor rendezvous
+specification</a></li>
+<li><a href="<svnsandbox>doc/spec/path-spec.txt">Tor path selection
+specification</a></li>
+<li><a href="<svnsandbox>doc/spec/address-spec.txt">Special hostnames in
+Tor</a></li>
+<li><a href="<svnsandbox>doc/spec/socks-extensions.txt">Tor's SOCKS support
+and extensions</a></li>
+<li><a href="<svnsandbox>doc/spec/version-spec.txt">How Tor version numbers
+work</a></li>
+<li><a href="<svnsandbox>doc/spec/proposals/">In-progress drafts of
+new specifications and proposed changes</a></li>
+</ul></li>
+
+</ul>
+
+<a id="NeatLinks"></a>
+<h2><a class="anchor" href="#NeatLinks">Siistit linkit</a></h2>
+<ul>
+<li>The <a href="https://wiki.torproject.org/noreply/TheOnionRouter";>Tor
+wiki</a> provides a plethora of helpful contributions from Tor
+users. Check it out!</li>
+<li><a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms";>A
+list of supporting programs you might want to use in association with
+Tor</a>.</li>
+<li><a href="http://check.torproject.org/";>The
+Tor detector</a> or <a href="http://torcheck.xenobite.eu/";>the other
+Tor detector</a> try to guess if you're using Tor or not.</li>
+<li>Check out the
+<a href="http://torstatus.kgprog.com/";>Tor Status</a> page, the other
+<a href="http://torstatus.blutmagie.de/";>Tor Status</a> page, or
+Xenobite's <a href="https://torstat.xenobite.eu/";>Tor node status</a> page.
+Remember that these lists may not be as accurate as what your Tor
+client uses, because your client fetches all the authoritative directories
+and combines them locally.</li>
+<li>Read <a
+href="http://freehaven.net/anonbib/topic.html#Anonymous_20communication";>these
+papers</a> (especially the ones in boxes) to get up to speed on the field
+of anonymous communication systems.</li>
+</ul>
+
+<a id="Developers"></a>
+<h2><a class="anchor" href="#Developers">Kehittäjille</a></h2>
+ Browse the Tor <b>source repository</b>: (which may not necessarily work or even compile)
+ <ul>
+ <li><a href="<svnsandbox>">Regularly updated SVN sandbox</a></li>
+ <li><a href="https://svn.torproject.org/svn/tor/trunk";>Browse the repository's source tree directly</a></li>
+ <li><a href="http://cvs.seul.org/viewcvs/viewcvs.cgi/tor/?root=Tor";>ViewCVS</a></li>
+ <li>anonymous <a href="http://subversion.tigris.org/";>subversion</a> access:
+ <ul>
+ <li>Make a new empty directory and cd into it.</li>
+ <li><kbd>svn checkout https://tor-svn.freehaven.net/svn/tor/trunk tor</kbd></li>
+ <li><kbd>svn checkout https://tor-svn.freehaven.net/svn/website/trunk website</kbd></li>
+ <li>To check out the maintenance branch, use<br /><kbd>svn checkout https://tor-svn.freehaven.net/svn/tor/branches/tor-0_1_2-patches</kbd></li>
+ </ul><br>
+ <b>HTTPS certificate fingerprint:</b> 11:34:5c:b1:c4:12:76:10:86:ce:df:69:3d:06:a9:57:fa:dc:c9:29
+ </li>
+ </ul>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/documentation.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/donate.wml
===================================================================
--- website/trunk/fi/donate.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/donate.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,179 +1,179 @@
-## translation metadata
-# Based-On-Revision: 15530
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Lahjoita!" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<h2>Lahjoita Tor-projektille!</h2>
-<hr />
-
-<p>
-Jos pidät Tor-ohjelmasta tai -verkosta ja haluat auttaa tukemalla Tor-projektia, ole hyvä ja harkitse lahjoituksen tekoa auttaakseen meitä jatkamaan työtämme. Tarjomme muutaman tavan tehdä lahjoituksen:</p>
-<ul>
-<li><a href="#check">Check, Money Order, or Postal Order</a></li>
-<li><a href="#paypal">PayPal</a></li>
-<li><a href="#wire">ACH/e-check/Wire Transfers</a></li>
-<li><a href="#eurobank">European Bank Transfers</a></li>
-<li><a href="#funds">What happens to my donation?</a></li>
-</ul>
-
-<p>As of December 2006, Tor is a US 501[c][3] research/educational
-nonprofit. Donations to The Tor Project may be tax deductible to persons
-who are in the US or who pay taxes in countries with reciprocity with
-the US on charitable donations. If you have any questions, please
-<a href="mailto:donations@xxxxxxxxxxxxxx";>contact us</a> directly. We're happy
-to discuss major gifts, planned giving, and public acknowledgement of donations
-with you.
-</p>
-
-<p>Donations of $65 or more qualify you for a <a href="<page
-tshirt>">bright green Tor t-shirt</a>. Help us keep Tor under <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Funding";>active
-development</a>!
-</p>
-
-<a id="check"></a>
-<h3><a class="anchor" href="#check">Checks, Money Orders, and Postal
-Orders</a></h3>
-<p>
-These payments can be sent to:
-</p>
-<blockquote><p>
-The Tor Project<br />
-122 Scott Circle<br />
-Dedham, MA 02026 USA</p>
-</blockquote>
-
-<p>
-Attention US citizens: if you would like an acknowledgement letter,
-please inform us with your donation. A canceled check, money/postal order receipt, or
-appraisal of donated property are valid records according to the IRS.
-</p>
-
-<a id="paypal"></a>
-<h3><a class="anchor" href="#paypal">PayPal</a></h3>
-<form id="subscribe" action="https://www.paypal.com/cgi-bin/webscr";
-method="post">
- <p>
-The most useful approach is to become a Tor project "member" for a
-<b>recurring payment</b> each month. Consistent
-donations let us worry less about fund-raising and focus more on
-development. You can become a member by clicking on this button (you
-will need a <a
-href="http://paypal.com/";>PayPal</a> account):<br />
-<input type="radio" name="a3" value="50.00" />$50
-<input type="radio" name="a3" value="20.00" checked="checked" />$20
-<input type="radio" name="a3" value="10.00" />$10
-<input type="radio" name="a3" value="5.00" />$5
-<input type="hidden" name="p3" value="1" />
-<input type="hidden" name="t3" value="M" />
-<input type="hidden" name="sra" value="1" />
-<input type="hidden" name="src" value="1" />
-<input type="hidden" name="no_shipping" value="1" />
-<input type="hidden" name="no_note" value="1" />
-<input type="image"
- src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif"; name="submit"
- alt="Make payments with PayPal - it's fast, free and secure!">
-<input type="hidden" name="cmd" value="_xclick-subscriptions" />
-<input type="hidden" name="business" value="donations@xxxxxxxxxxxxxx" />
-<input type="hidden" name="item_name" value="Tor Project Membership" />
-<input type="hidden" name="return" value="https://www.torproject.org/";>
-<input type="hidden" name="cancel_return"
- value="https://www.torproject.org/donate";>
-</p>
-</form>
-
-<form id="donate" action="https://www.paypal.com/cgi-bin/webscr"; method="post">
-<p>You can also make a <b>one-time donation</b> (via PayPal, but
-doesn't require any account):<br />
-<input type="radio" name="amount" value="100.00" />$100
-<input type="radio" name="amount" value="50.00" />$50
-<input type="radio" name="amount" value="20.00" checked="checked" />$20
-<input type="radio" name="amount" value="10.00" />$10
-<input type="radio" name="amount" value="" />other
-<input type="hidden" name="no_shipping" value="1" />
-<input type="image"
- src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif";
- name="submit" alt="Make payments with PayPal - it's fast, free and secure!">
-<input type="hidden" name="cmd" value="_xclick" />
-<input type="hidden" name="business" value="donations@xxxxxxxxxxxxxx" />
-<input type="hidden" name="item_name" value="Tor" />
-<input type="hidden" name="return" value="https://www.torproject.org/";>
-<input type="hidden" name="cancel_return" value="https://www.torproject.org/donate";>
-</p>
-</form>
-
-<a id="wire"></a>
-<h3><a class="anchor" href="#wire">ACH/e-check/Wire Transfers</a></h3>
-<p>In the US, ACH or e-check transfers are a fine way to donate.
-We're happy to accept wire transfers over US$100. Domestic United
-States ACH/e-check transfers are normally free for the sender, whereas wire transfers will incur fees.
-If you are located in Europe, <a href="#eurobank">please see below</a>.</p>
-
-<p>
-Organization Address:<br />
-The Tor Project<br />
-122 Scott Circle<br />
-Dedham, MA 02026<br />
-</p>
-<p>
-account number: 63904958202<br />
-routing number: 011075150<br />
-SWIFT Code: SVRNUS33//FW011075150<br />
-</p>
-<p>
-Bank Address:<br />
-Sovereign Bank<br />
-1130 Berkshire Boulevard<br />
-Wyomissing, PA 19610<br />
-</p>
-
-<a id="eurobank"></a>
-<h3><a class="anchor" href="#eurobank">European Bank Transfers</a></h3>
-<p>In Europe, we have a funding arrangement with the <a
-href="http://www.ccc.de/";>Chaos Computer Club</a>. Your donations go
-into a separate bank account managed by the CCC, and they use the funds
-to do beneficial activities for Tor in Europe. Residents from any of the <a
-href="http://en.wikipedia.org/wiki/Single_Euro_Payments_Area";>31 SEPA
-member states</a> can wire up to 50.000
-Euro at the cost of a domestic transaction (i.e., usually free if
-submitted electronically).</p>
-
-<p>
-The account information is:<br />
-Wau Holland Stiftung<br />
-IBAN DE57 5204 0021 0277 281202<br />
-SWIFT BIC COBADEFFXXX<br />
-</p>
-<p>
-Classic style German account information is:<br />
-Konto: 2772812-02<br />
-Inhaber: Wau Holland Stiftung<br />
-Bank: Commerzbank Kassel<br />
-BLZ: 52040021<br />
-</p>
-<p>WHS issues a donation receipt upon request (if provided with address
-information).
-</p>
-
-<a id="funds"></a>
-<h3><a class="anchor" href="#funds">What happens to my donation?</a></h3>
-<p>Your funds are deposited into our general fund. You join our
-<a href="<page sponsors>">many sponsors</a> in funding the future of Tor and online anonymity.
-In 2007, the Tor Project spent and received its funds as follows: </p>
-<p><img
-src="http://chart.apis.google.com/chart?cht=p&chtt=Who%20funds%20The%20Tor%20Project?&chco=00df00&chd=t:56,31,13&chs=450x225&chl=Governments%2056%|NGOs%2031%|Individuals%2013%" alt="Who funds the Tor Project?"/>
-<img
-src="http://chart.apis.google.com/chart?cht=p&chtt=How%20does%20The%20Tor%20Project%20allocate%20funds?&chco=00df00&chd=t:72,13,15&chs=450x225&chl=Development%2072%|Operational%2013%|Taxes%2015%" alt="How does the Tor Project allocate funds?"/></p>
-
-<hr />
-<strong>The Tor Project respects the confidentiality of our supporters,
-when requested. We do not lend, rent, or sell our lists of donors at
-any time.</strong>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
-
+## translation metadata
+# Based-On-Revision: 15530
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Lahjoita!" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<h2>Lahjoita Tor-projektille!</h2>
+<hr />
+
+<p>
+Jos pidät Tor-ohjelmasta tai -verkosta ja haluat auttaa tukemalla Tor-projektia, ole hyvä ja harkitse lahjoituksen tekoa auttaakseen meitä jatkamaan työtämme. Tarjomme muutaman tavan tehdä lahjoituksen:</p>
+<ul>
+<li><a href="#check">Check, Money Order, or Postal Order</a></li>
+<li><a href="#paypal">PayPal</a></li>
+<li><a href="#wire">ACH/e-check/Wire Transfers</a></li>
+<li><a href="#eurobank">European Bank Transfers</a></li>
+<li><a href="#funds">What happens to my donation?</a></li>
+</ul>
+
+<p>As of December 2006, Tor is a US 501[c][3] research/educational
+nonprofit. Donations to The Tor Project may be tax deductible to persons
+who are in the US or who pay taxes in countries with reciprocity with
+the US on charitable donations. If you have any questions, please
+<a href="mailto:donations@xxxxxxxxxxxxxx";>contact us</a> directly. We're happy
+to discuss major gifts, planned giving, and public acknowledgement of donations
+with you.
+</p>
+
+<p>Donations of $65 or more qualify you for a <a href="<page
+tshirt>">bright green Tor t-shirt</a>. Help us keep Tor under <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Funding";>active
+development</a>!
+</p>
+
+<a id="check"></a>
+<h3><a class="anchor" href="#check">Checks, Money Orders, and Postal
+Orders</a></h3>
+<p>
+These payments can be sent to:
+</p>
+<blockquote><p>
+The Tor Project<br />
+122 Scott Circle<br />
+Dedham, MA 02026 USA</p>
+</blockquote>
+
+<p>
+Attention US citizens: if you would like an acknowledgement letter,
+please inform us with your donation. A canceled check, money/postal order receipt, or
+appraisal of donated property are valid records according to the IRS.
+</p>
+
+<a id="paypal"></a>
+<h3><a class="anchor" href="#paypal">PayPal</a></h3>
+<form id="subscribe" action="https://www.paypal.com/cgi-bin/webscr";
+method="post">
+ <p>
+The most useful approach is to become a Tor project "member" for a
+<b>recurring payment</b> each month. Consistent
+donations let us worry less about fund-raising and focus more on
+development. You can become a member by clicking on this button (you
+will need a <a
+href="http://paypal.com/";>PayPal</a> account):<br />
+<input type="radio" name="a3" value="50.00" />$50
+<input type="radio" name="a3" value="20.00" checked="checked" />$20
+<input type="radio" name="a3" value="10.00" />$10
+<input type="radio" name="a3" value="5.00" />$5
+<input type="hidden" name="p3" value="1" />
+<input type="hidden" name="t3" value="M" />
+<input type="hidden" name="sra" value="1" />
+<input type="hidden" name="src" value="1" />
+<input type="hidden" name="no_shipping" value="1" />
+<input type="hidden" name="no_note" value="1" />
+<input type="image"
+ src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif"; name="submit"
+ alt="Make payments with PayPal - it's fast, free and secure!">
+<input type="hidden" name="cmd" value="_xclick-subscriptions" />
+<input type="hidden" name="business" value="donations@xxxxxxxxxxxxxx" />
+<input type="hidden" name="item_name" value="Tor Project Membership" />
+<input type="hidden" name="return" value="https://www.torproject.org/";>
+<input type="hidden" name="cancel_return"
+ value="https://www.torproject.org/donate";>
+</p>
+</form>
+
+<form id="donate" action="https://www.paypal.com/cgi-bin/webscr"; method="post">
+<p>You can also make a <b>one-time donation</b> (via PayPal, but
+doesn't require any account):<br />
+<input type="radio" name="amount" value="100.00" />$100
+<input type="radio" name="amount" value="50.00" />$50
+<input type="radio" name="amount" value="20.00" checked="checked" />$20
+<input type="radio" name="amount" value="10.00" />$10
+<input type="radio" name="amount" value="" />other
+<input type="hidden" name="no_shipping" value="1" />
+<input type="image"
+ src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif";
+ name="submit" alt="Make payments with PayPal - it's fast, free and secure!">
+<input type="hidden" name="cmd" value="_xclick" />
+<input type="hidden" name="business" value="donations@xxxxxxxxxxxxxx" />
+<input type="hidden" name="item_name" value="Tor" />
+<input type="hidden" name="return" value="https://www.torproject.org/";>
+<input type="hidden" name="cancel_return" value="https://www.torproject.org/donate";>
+</p>
+</form>
+
+<a id="wire"></a>
+<h3><a class="anchor" href="#wire">ACH/e-check/Wire Transfers</a></h3>
+<p>In the US, ACH or e-check transfers are a fine way to donate.
+We're happy to accept wire transfers over US$100. Domestic United
+States ACH/e-check transfers are normally free for the sender, whereas wire transfers will incur fees.
+If you are located in Europe, <a href="#eurobank">please see below</a>.</p>
+
+<p>
+Organization Address:<br />
+The Tor Project<br />
+122 Scott Circle<br />
+Dedham, MA 02026<br />
+</p>
+<p>
+account number: 63904958202<br />
+routing number: 011075150<br />
+SWIFT Code: SVRNUS33//FW011075150<br />
+</p>
+<p>
+Bank Address:<br />
+Sovereign Bank<br />
+1130 Berkshire Boulevard<br />
+Wyomissing, PA 19610<br />
+</p>
+
+<a id="eurobank"></a>
+<h3><a class="anchor" href="#eurobank">European Bank Transfers</a></h3>
+<p>In Europe, we have a funding arrangement with the <a
+href="http://www.ccc.de/";>Chaos Computer Club</a>. Your donations go
+into a separate bank account managed by the CCC, and they use the funds
+to do beneficial activities for Tor in Europe. Residents from any of the <a
+href="http://en.wikipedia.org/wiki/Single_Euro_Payments_Area";>31 SEPA
+member states</a> can wire up to 50.000
+Euro at the cost of a domestic transaction (i.e., usually free if
+submitted electronically).</p>
+
+<p>
+The account information is:<br />
+Wau Holland Stiftung<br />
+IBAN DE57 5204 0021 0277 281202<br />
+SWIFT BIC COBADEFFXXX<br />
+</p>
+<p>
+Classic style German account information is:<br />
+Konto: 2772812-02<br />
+Inhaber: Wau Holland Stiftung<br />
+Bank: Commerzbank Kassel<br />
+BLZ: 52040021<br />
+</p>
+<p>WHS issues a donation receipt upon request (if provided with address
+information).
+</p>
+
+<a id="funds"></a>
+<h3><a class="anchor" href="#funds">What happens to my donation?</a></h3>
+<p>Your funds are deposited into our general fund. You join our
+<a href="<page sponsors>">many sponsors</a> in funding the future of Tor and online anonymity.
+In 2007, the Tor Project spent and received its funds as follows: </p>
+<p><img
+src="http://chart.apis.google.com/chart?cht=p&chtt=Who%20funds%20The%20Tor%20Project?&chco=00df00&chd=t:56,31,13&chs=450x225&chl=Governments%2056%|NGOs%2031%|Individuals%2013%" alt="Who funds the Tor Project?"/>
+<img
+src="http://chart.apis.google.com/chart?cht=p&chtt=How%20does%20The%20Tor%20Project%20allocate%20funds?&chco=00df00&chd=t:72,13,15&chs=450x225&chl=Development%2072%|Operational%2013%|Taxes%2015%" alt="How does the Tor Project allocate funds?"/></p>
+
+<hr />
+<strong>The Tor Project respects the confidentiality of our supporters,
+when requested. We do not lend, rent, or sell our lists of donors at
+any time.</strong>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
+
Property changes on: website/trunk/fi/donate.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/faq.wml
===================================================================
--- website/trunk/fi/faq.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/faq.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,7 +1,7 @@
-## translation metadata
-# Based-On-Revision: 7832
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Siirrytään" REDIRECT="documentation" CHARSET="UTF-8"
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 7832
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Siirrytään" REDIRECT="documentation" CHARSET="UTF-8"
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/faq.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/howitworks.wml
===================================================================
--- website/trunk/fi/howitworks.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/howitworks.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,7 +1,7 @@
-## translation metadata
-# Based-On-Revision: 13768
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Siirrytään" REDIRECT="overview" CHARSET="UTF-8"
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 13768
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Siirrytään" REDIRECT="overview" CHARSET="UTF-8"
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/howitworks.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/index.wml
===================================================================
--- website/trunk/fi/index.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/index.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,120 +1,120 @@
-## translation metadata
-# Based-On-Revision: 14740
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: anonyymisesti verkossa" CHARSET="UTF-8"
-
-<!-- SIDEBAR (OPTIONAL) -->
-<div class="sidebar">
-<a href="<page download>"><img src="$(IMGROOT)/download_tor.png" alt="Lataa Tor" /></a>
-
-<br />
-
-<a href="<page overview>"><img src="$(IMGROOT)/how_tor_works_thumb.png" alt="Kuinka Tor toimii" /></a>
-<div class="donatebutton">
-<a href="<page donate>">Tue Tor-projektia: lahjoita!</a>
-</div>
-
-</div>
-<!-- END SIDEBAR -->
-
-<div class="main-column">
-
-<!-- PUT CONTENT AFTER THIS TAG -->
-
-<h2>Tor: anonyymisesti verkossa</h2>
-<hr />
-
-<p>Tor is a software project that helps you defend against <a
-href="<page overview>">traffic analysis</a>, a form of network
-surveillance that threatens personal freedom and privacy, confidential
-business activities and relationships, and state security.
-Tor protects you by bouncing your communications around a distributed
-network of relays run by volunteers all around the world: it prevents
-somebody watching your Internet connection from learning what sites you
-visit, and it prevents the sites you visit from learning your physical
-location.
-Tor toimii erilaisten ohjelmien kanssa, kuten esimerkiksi Internet-selainten, pikaviestintä-ohjelmien tai monien muiden TCP-protokollaa käyttävien ohjelmien kanssa.
-</p>
-
-<p> Hundreds of thousands of people around the world use Tor for a
-wide variety of reasons: journalists and
-bloggers, human rights workers, law enforcement officers, soldiers,
-corporations, citizens of repressive regimes, and just ordinary
-citizens. Vilkaise <a href="<page torusers>">Who Uses Tor?</a> -sivua huomatakseen esimerkkejä tyypillisistä Tor-käyttäjistä.
-Selaa <a href="<page overview>">yleiset-sivua</a> nähdäkseen lisää tietoa mitä Tor tekee, minkä takia monenlaiset käyttäjät ovat tärkeitä ja kuinka Tor toimii.
-</p>
-
-<p>
-There are three pieces of fine print you need to know about.
-</p>
-<ol>
-<li>Tor does not protect you if you do not use it correctly.
-Read <a href="<page download>#Warning">our list of warnings</a> and
-make sure to follow the
-<a href="<page documentation>#RunningTor">instructions for your platform</a>
-carefully.</li>
-<li> Even if you configure and use Tor correctly, there are still
-<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#RemainingAttacks";
->
-potential attacks that could compromise Tor's ability to protect
-you</a>.</li>
-<li>No anonymity system is perfect these days, and Tor is no exception:
-you should not rely solely on the current Tor network if you really need
-strong anonymity.</li>
-</ol>
-
-<p>
-Tor's security improves as its user
-base grows and as more people volunteer to
-<a href="<page docs/tor-doc-relay>">run relays</a>. (It isn't
-nearly as hard to set up as you might think, and can significantly
-<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#RelayAnonymity";>
-enhance your own security against some attacks</a>.)
-If running a relay isn't for you, we need
-<a href="<page volunteer>">help with many other aspects of the project</a>,
-and we need funds to <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Funding";>continue
-making the Tor network faster and easier to use while maintaining good
-security</a>.
-<a href="<page donate>">Ole hyvä ja lahjoita.</a>
-</p>
-
-<a id="News"></a>
-<h2><a class="anchor" href="#News">Uutiset</a></h2>
-<hr />
-
-<ul>
-<li>25 Toukokuuta 2008: Tor vastaanottaa kaksi palkintoa <a
-href="http://nlnet.nl/";>NLnet-säätiöltä</a>. Ensimmäinen on parantaakseen piilopalveluita. Toinen on parantaakseen Tor-ohjelman toimintaa käyttäjille joilla on vain vähän kaistaa.. NLnet:in <a
-href="http://nlnet.nl/news/2008/20080514-awards.html";>palkinnot-sivulla</a>
-on lisätietoa näistä kahdesta projektista.</li>
-
-<li>13 Toukokuuta 2008: <a href="http://archives.seul.org/or/talk/May-2008/msg00048.html";>Tor 0.2.0.26-rc</a>
-replaces several V3 directory authority keys affected by a recent <a
-href="http://lists.debian.org/debian-security-announce/2008/msg00152.html";>Debian
-OpenSSL-ohjelmointivirhe</a>. <strong>Tämä on kriittinen turvallisuusjulkaisu.</strong>
-Jokainen joka käyttää mitä tahansa versiota 0.2.0.x -sarjasta kannattaa päivittää, vaikka käyttää tai ei käytä Debiania. Also, all servers running any version of Tor
-whose keys were generated by Debian, Ubuntu, or any derived distribution may
-have to replace their identity keys. See our
-<a href="http://archives.seul.org/or/announce/May-2008/msg00000.html";>security
-advisory</a> or the <a
-href="https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mean-tor-clients%3F";>blog
-follow-up</a> for full details. As always, you can find Tor 0.2.0.26-rc on
-the <a href="https://www.torproject.org/download#Dev";>downloads page</a>.</li>
-
-<li><b>Etsimme aktiivisesti uusia sponsoreita ja rahoituksia.</b>
-If your organization has an interest in keeping the Tor network usable
-and fast, please <a href="<page contact>">contact us</a>.
-<a href="<page sponsors>">Sponsors of Tor</a>
-also get personal attention, better support, publicity (if they want it),
-and get to influence the direction of our research and development.
-<a href="<page donate>">Please donate.</a></li>
-
-</ul>
-<p><a href="<page news>">Lisää uutisia</a></p>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
-
+## translation metadata
+# Based-On-Revision: 14740
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: anonyymisesti verkossa" CHARSET="UTF-8"
+
+<!-- SIDEBAR (OPTIONAL) -->
+<div class="sidebar">
+<a href="<page download>"><img src="$(IMGROOT)/download_tor.png" alt="Lataa Tor" /></a>
+
+<br />
+
+<a href="<page overview>"><img src="$(IMGROOT)/how_tor_works_thumb.png" alt="Kuinka Tor toimii" /></a>
+<div class="donatebutton">
+<a href="<page donate>">Tue Tor-projektia: lahjoita!</a>
+</div>
+
+</div>
+<!-- END SIDEBAR -->
+
+<div class="main-column">
+
+<!-- PUT CONTENT AFTER THIS TAG -->
+
+<h2>Tor: anonyymisesti verkossa</h2>
+<hr />
+
+<p>Tor is a software project that helps you defend against <a
+href="<page overview>">traffic analysis</a>, a form of network
+surveillance that threatens personal freedom and privacy, confidential
+business activities and relationships, and state security.
+Tor protects you by bouncing your communications around a distributed
+network of relays run by volunteers all around the world: it prevents
+somebody watching your Internet connection from learning what sites you
+visit, and it prevents the sites you visit from learning your physical
+location.
+Tor toimii erilaisten ohjelmien kanssa, kuten esimerkiksi Internet-selainten, pikaviestintä-ohjelmien tai monien muiden TCP-protokollaa käyttävien ohjelmien kanssa.
+</p>
+
+<p> Hundreds of thousands of people around the world use Tor for a
+wide variety of reasons: journalists and
+bloggers, human rights workers, law enforcement officers, soldiers,
+corporations, citizens of repressive regimes, and just ordinary
+citizens. Vilkaise <a href="<page torusers>">Who Uses Tor?</a> -sivua huomatakseen esimerkkejä tyypillisistä Tor-käyttäjistä.
+Selaa <a href="<page overview>">yleiset-sivua</a> nähdäkseen lisää tietoa mitä Tor tekee, minkä takia monenlaiset käyttäjät ovat tärkeitä ja kuinka Tor toimii.
+</p>
+
+<p>
+There are three pieces of fine print you need to know about.
+</p>
+<ol>
+<li>Tor does not protect you if you do not use it correctly.
+Read <a href="<page download>#Warning">our list of warnings</a> and
+make sure to follow the
+<a href="<page documentation>#RunningTor">instructions for your platform</a>
+carefully.</li>
+<li> Even if you configure and use Tor correctly, there are still
+<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#RemainingAttacks";
+>
+potential attacks that could compromise Tor's ability to protect
+you</a>.</li>
+<li>No anonymity system is perfect these days, and Tor is no exception:
+you should not rely solely on the current Tor network if you really need
+strong anonymity.</li>
+</ol>
+
+<p>
+Tor's security improves as its user
+base grows and as more people volunteer to
+<a href="<page docs/tor-doc-relay>">run relays</a>. (It isn't
+nearly as hard to set up as you might think, and can significantly
+<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#RelayAnonymity";>
+enhance your own security against some attacks</a>.)
+If running a relay isn't for you, we need
+<a href="<page volunteer>">help with many other aspects of the project</a>,
+and we need funds to <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Funding";>continue
+making the Tor network faster and easier to use while maintaining good
+security</a>.
+<a href="<page donate>">Ole hyvä ja lahjoita.</a>
+</p>
+
+<a id="News"></a>
+<h2><a class="anchor" href="#News">Uutiset</a></h2>
+<hr />
+
+<ul>
+<li>25 Toukokuuta 2008: Tor vastaanottaa kaksi palkintoa <a
+href="http://nlnet.nl/";>NLnet-säätiöltä</a>. Ensimmäinen on parantaakseen piilopalveluita. Toinen on parantaakseen Tor-ohjelman toimintaa käyttäjille joilla on vain vähän kaistaa.. NLnet:in <a
+href="http://nlnet.nl/news/2008/20080514-awards.html";>palkinnot-sivulla</a>
+on lisätietoa näistä kahdesta projektista.</li>
+
+<li>13 Toukokuuta 2008: <a href="http://archives.seul.org/or/talk/May-2008/msg00048.html";>Tor 0.2.0.26-rc</a>
+replaces several V3 directory authority keys affected by a recent <a
+href="http://lists.debian.org/debian-security-announce/2008/msg00152.html";>Debian
+OpenSSL-ohjelmointivirhe</a>. <strong>Tämä on kriittinen turvallisuusjulkaisu.</strong>
+Jokainen joka käyttää mitä tahansa versiota 0.2.0.x -sarjasta kannattaa päivittää, vaikka käyttää tai ei käytä Debiania. Also, all servers running any version of Tor
+whose keys were generated by Debian, Ubuntu, or any derived distribution may
+have to replace their identity keys. See our
+<a href="http://archives.seul.org/or/announce/May-2008/msg00000.html";>security
+advisory</a> or the <a
+href="https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mean-tor-clients%3F";>blog
+follow-up</a> for full details. As always, you can find Tor 0.2.0.26-rc on
+the <a href="https://www.torproject.org/download#Dev";>downloads page</a>.</li>
+
+<li><b>Etsimme aktiivisesti uusia sponsoreita ja rahoituksia.</b>
+If your organization has an interest in keeping the Tor network usable
+and fast, please <a href="<page contact>">contact us</a>.
+<a href="<page sponsors>">Sponsors of Tor</a>
+also get personal attention, better support, publicity (if they want it),
+and get to influence the direction of our research and development.
+<a href="<page donate>">Please donate.</a></li>
+
+</ul>
+<p><a href="<page news>">Lisää uutisia</a></p>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
+
Property changes on: website/trunk/fi/index.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/mirrors.wml
===================================================================
--- website/trunk/fi/mirrors.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/mirrors.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,51 +1,51 @@
-## translation metadata
-# Based-On-Revision: 15540
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Mirrorit" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<h2>Tor: Mirrorit</h2>
-<hr />
-
-<p>
-Tämän sivuston alkuperäinen osoite on <a href="https://www.torproject.org/";>https://www.torproject.org/</a>,
-tästä on myös olemassa kopioita (mirroreita) eri osoitteissa.
-</p>
-
-<p>
-Jos haluaa pyörittää mirroria, se onnistuu helposti käyttämällä tätä komentoa lataakseen kaikki maailmalle jaettavat:
-<br /> <br />
-<tt>
-rsync -av rsync://rsync.torproject.org/tor tor-mirror/
-</tt>
-<br/> <br/>
-Suositeltavaa on pyrkiä pitämään mirroria ajan tasalla (suosittelemme automatisoimaan tämä tehtävä esimerkiksi sillaisella kuin '<tt>cron</tt>'). Sivustomme, lähdekoodit ja ohjelmat muuttuvat melko usein. Tor-käyttäjät kaikkialla kiittävät sinua.
-</p>
-
-<p>
-Jos sinulla on käynnissä mirrori, ole hyvä ja lähetä sähköpostia osoitteeseen
-<a href="mailto:tor-webmaster@xxxxxxxxxxxxxx";>tor-webmaster@xxxxxxxxxxxxxx</a>
-ja lisäämme sen listalle.
-</p>
-
-<table class="mirrors">
-<tr>
- <th>Maa</th>
- <th>Yritys</th>
- <th>Viimeksi päivitetty</th>
- <th>ftp</th>
- <th>http dist/</th>
- <th>http-sivusto</th>
- <th>https dist/</th>
- <th>https-sivusto</th>
- <th>rsync dist/</th>
- <th>rsync-sivusto</th>
-</tr>
-#include <mirrors-table.wmi>
-</table>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 15540
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Mirrorit" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<h2>Tor: Mirrorit</h2>
+<hr />
+
+<p>
+Tämän sivuston alkuperäinen osoite on <a href="https://www.torproject.org/";>https://www.torproject.org/</a>,
+tästä on myös olemassa kopioita (mirroreita) eri osoitteissa.
+</p>
+
+<p>
+Jos haluaa pyörittää mirroria, se onnistuu helposti käyttämällä tätä komentoa lataakseen kaikki maailmalle jaettavat:
+<br /> <br />
+<tt>
+rsync -av rsync://rsync.torproject.org/tor tor-mirror/
+</tt>
+<br/> <br/>
+Suositeltavaa on pyrkiä pitämään mirroria ajan tasalla (suosittelemme automatisoimaan tämä tehtävä esimerkiksi sillaisella kuin '<tt>cron</tt>'). Sivustomme, lähdekoodit ja ohjelmat muuttuvat melko usein. Tor-käyttäjät kaikkialla kiittävät sinua.
+</p>
+
+<p>
+Jos sinulla on käynnissä mirrori, ole hyvä ja lähetä sähköpostia osoitteeseen
+<a href="mailto:tor-webmaster@xxxxxxxxxxxxxx";>tor-webmaster@xxxxxxxxxxxxxx</a>
+ja lisäämme sen listalle.
+</p>
+
+<table class="mirrors">
+<tr>
+ <th>Maa</th>
+ <th>Yritys</th>
+ <th>Viimeksi päivitetty</th>
+ <th>ftp</th>
+ <th>http dist/</th>
+ <th>http-sivusto</th>
+ <th>https dist/</th>
+ <th>https-sivusto</th>
+ <th>rsync dist/</th>
+ <th>rsync-sivusto</th>
+</tr>
+#include <mirrors-table.wmi>
+</table>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/mirrors.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/people.wml
===================================================================
--- website/trunk/fi/people.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/people.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,195 +1,195 @@
-## translation metadata
-# Based-On-Revision: 15491
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Henkilöt" CHARSET="UTF-8" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<h2>Tor: Henkilöt</h2>
-<hr />
-
-<p>Tor-projekti on 501(c)(3) voittoa tavoittelematon yritys Yhdysvalloissa. Yrityksen virallinen osoite on:<br>
-<blockquote>
-The Tor Project<br>
-122 Scott Circle<br>
-Dedham, MA 02026 USA<br>
-</blockquote>
-
-<p>Yritys koostuu monista vapaaehtoisista henkilöistä sekä muutamasta työntekijästä.</p>
-
-<a id="Core"></a>
-<h3><a class="anchor" href="#Core">Päähenkilöt:</a></h3>
-
-<dl>
-<dt>Jacob Appelbaum</dt><dd>Runs the <a
-href="http://check.torproject.org/";>Tor DNSEL</a> <a
-href="http://exitlist.torproject.org/";>site</a>, the <a
-href="https://translation.torproject.org/";>Tor Translation Portal</a>, and also
-the in-progress Tor weather site.</dd>
-<dt>Roger Dingledine (Tor project leader; Director)</dt><dd>Original
-developer of Tor; now plays pretty much all the roles to keep
-everything on track.</dd>
-<dt>Matt Edman</dt><dd>Developer for <a
-href="http://vidalia-project.net/";>Vidalia</a>, a cross-platform Tor GUI
-included in the Windows and OS X bundles.</dd>
-<dt>Andrew Lewman (Director)</dt><dd>Manages building packages for
-Windows, OS X, Red Hat, and SuSE. Also provides common sense on topics
-like how to run a non-profit and generally helps keep everything moving
-forward.</dd>
-<dt>Karsten Loesing</dt><dd> Worked during the 2007 Google Summer of
-Code on <a
-href="https://www.torproject.org/svn/trunk/doc/spec/proposals/114-distributed-storage.txt";>distributing
-and securing the publishing and fetching of hidden service
-descriptors</a>.</dd>
-<dt>Nick Mathewson (Chief architect; Director)</dt><dd>One of the
-three original designers of Tor; does a lot of the ongoing design work.
-One of the two main developers, along with Roger.</dd>
-<dt>Steven Murdoch (Researcher)</dt><dd>Researcher at the University
-of Cambridge, currently funded by The Tor Project to improve
-the security, performance, and usability of Tor. Creator of the
-<a href="https://torbrowser.torproject.org/";>Tor Browser Bundle</a>.</dd>
-<dt>Peter Palfrader</dt><dd>Manages the Debian packages,
-runs one of the directory authorities, runs the website and the wiki,
-and generally helps out a lot.</dd>
-<dt>Mike Perry</dt><dd>Author of <a
-href="https://www.torproject.org/svn/torflow/README";>TorFlow</a>, a Tor
-controller that builds paths through the Tor network and
-measures various properties and behaviors. Working now on a <a
-href="https://torbutton.torproject.org/dev/";>much more comprehensive
-version of Torbutton</a>.</dd>
-<dt>Paul Syverson</dt><dd>Inventor of <a
-href="http://www.onion-router.net/";>Onion Routing</a>, original designer
-of Tor along with Roger and Nick, and project leader for original design,
-development, and deployment of Tor. Currently helps out with research
-and design.</dd>
-</dl>
-
-<a id="Board"></a>
-<h3><a class="anchor" href="#Board">Tor-projektin johtokunta:</a></h3>
-
-<dl>
-<dt>Ian Goldberg (Director)</dt><dd>Cryptographer,
-privacy expert, and professor; one of the designers of <a
-href="http://www.cypherpunks.ca/otr/";>Off-the-Record Messaging</a>.</dd>
-<dt>Xianghui (Isaac) Mao (Director)</dt><dd>Chinese blogging and privacy
-activist. His current activities can be found at <a
-href="http://isaacmao.com/";>his website</a>.<dd>
-<dt>Wendy Seltzer (Director)</dt><dd>Lawyer,
-cyberlaw professor, and founder of <a
-href="http://chillingeffects.org/";>ChillingEffects.org</a>.</dd>
-<dt>Fred von Lohmann (Director)</dt><dd>Fred is a Senior
-Intellectual Property Attorney at the Electronic Frontier
-Foundation (EFF). His complete bio can be found at the <a
-href="http://www.eff.org/about/staff/?f=fred_von_lohmann.html";>EFF
-Staff Site</a>.</dd>
-<dt>Along with Roger, Nick, and Andrew listed above as Directors.</dt>
-</dl>
-
-<a id="Translators"></a>
-<h3><a class="anchor" href="#Translators">Pääkääntäjät:</a></h3>
-
-<dl>
-<dt>Bogdan Drozdowski</dt><dd><a
-href="https://www.torproject.org/index.html.pl";>puolankieli</a>.</dd>
-<dt>fredzupy</dt><dd><a
-href="https://www.torproject.org/index.html.fr";>ranskankieli</a>.</dd>
-<dt>Ruben Garcia</dt><dd><a
-href="https://www.torproject.org/index.html.es";>espanjankieli</a>.</dd>
-<dt>Jens Kubieziel</dt><dd><a
-href="https://www.torproject.org/index.html.de";>saksankieli</a>.</dd>
-<dt>Pei Hanru</dt><dd><a
-href="https://www.torproject.org/index.html.zh-cn";>yksinkertaistettu kiinankieli</a>.</dd>
-<dt>Jan Reister</dt><dd><a
-href="https://www.torproject.org/index.html.it";>italiankieli</a>.</dd>
-<dt>Masaki Taniguchi</dt><dd><a
-href="https://www.torproject.org/index.html.ja";>japaninkieli</a>.</dd>
-<dt>Jan Woning</dt><dd><a
-href="https://www.torproject.org/index.html.nl";>hollanninkieli</a>.</dd>
-<dt>ygrek</dt><dd><a
-href="https://www.torproject.org/index.html.ru";>venäjänkieli</a>.</dd>
-</dl>
-
-<a id="Volunteers"></a>
-<h3><a class="anchor" href="#Volunteers">Monet vapaaehtoiset:</a></h3>
-
-<dl>
-<dt>Anonym</dt><dd>Incognito LiveCD:n ylläpitäjä.</dd>
-<dt>Kevin Bankston</dt><dd>EFF lawyer who helped write the <a
-href="<page eff/tor-legal-faq>">Tor Legal FAQ</a> and
-tirelessly answers the phone when somebody in the world has a legal
-question about Tor.</dd>
-<dt>Jeff Blum</dt><dd>Sivustomme vapaaehtoinen julkaisija, joka auttaa päivittämään Tor-sivuston sisältöä.</dd>
-<dt>Kasimir Gabert</dt><dd>Ylläpitää <a
-href="https://torstatus.kgprog.com/";>TorStatus</a> -tilastosivuja.</dd>
-<dt>Geoff Goodell</dt><dd>Runs one of the directory authorities, used to
-run the Blossom project which uses Tor as its overlay network, and runs
-the <a href="http://lefkada.eecs.harvard.edu/cgi-bin/exit.py";>exit.py</a>
-Tor relay list.</dd>
-<dt>Robert Hogan</dt><dd><a
-href="http://tork.sf.net/";>TorK</a>-Torhallintaohjelman kehittäjä.</dd>
-<dt>Fabian Keil</dt><dd>Yksi Privoxyn pääohjelmoijista ja Tor-fani. Hän on syynä Tor-ohjelman ja Privoxyn yhteistoiminnasta.</dd>
-<dt>Julius Mittenzwei</dt><dd>CCC:n lakimies Saksassa. Coordinates the German Tor community with respect to legal
-questions and concerns.</dd>
-<dt>Shava Nerad</dt><dd>Our former Development Director. She works on PR and community relations.</dd>
-<dt>Lasse Øverlier</dt><dd>Writes research papers on Tor: attacks,
-defenses, and resource management, especially for hidden services.</dd>
-<dt>Martin Peck and Kyle Williams</dt><dd>Developers for
-JanusVM, a VMWare-based
-transparent Tor proxy that makes Tor easier to set up and use.</dd>
-<dt>Steve Topletz</dt><dd>Developer for Torpark (now called Xerobank
-Browser), a preconfigured Tor+Firefox bundle for Windows.</dd>
-<dt>Tup (a pseudonym -- he's managed to stay anonymous even from
-us!)</dt><dd>Periodically adds new features for making Tor more
-transparent to use. Also maintains the <a
-href="http://p56soo2ibjkx23xo.onion/";>TorDNSEL code</a>.</dd>
-<dt>Ethan Zuckerman</dt><dd>A blogger who has written some
-<a href="http://www.ethanzuckerman.com/blog/?p=1019";>interesting</a>
-<a href="http://advocacy.globalvoicesonline.org/tools/guide/";>tutorials</a>
-for how, when, and whether to use Tor. He also teaches activists around
-the world about Tor and related tools.</dd>
-<dt>All our relay operators, people who write <a
-href="http://freehaven.net/anonbib/";>research papers</a> about Tor,
-people who teach others about Tor, etc.</dt>
-</dl>
-
-<a id="GSoC"></a>
-<a id="Past"></a>
-<h3><a class="anchor" href="#Past">Aikaisemmille työntekijöille kiitokset:</a></h3>
-
-<dl>
-<dt>Benedikt Boss</dt><dd>Worked during the 2007 Google Summer of Code on <a
-href="https://svn.torproject.org/svn/topf/trunk/README";>TOPF</a>,
-a fuzzer for Tor; mentored by Roger.</dd>
-<dt>Ren Bucholz</dt><dd>Meidän hieno logo ja kuvat.</dd>
-<dt>Pat Double</dt><dd>Incognito LiveCD:n tekijä.</dd>
-<dt>Justin Hipple</dt><dd>Toinen kehittäjä Vidalialle.</dd>
-<dt>Christian King</dt><dd> Worked during the 2007 Google Summer of Code
-on making Tor relays stable on
-Windows, by developing a <a
-href="https://svn.torproject.org/svn/libevent-urz/trunk/README";>buffer
-implementation for libevent</a>; mentored by Nick.</dd>
-<dt>Joe Kowalski</dt><dd>Original author and provider of the torstatus
-script formerly run on nighteffect.</dd>
-<dt>Adam Langley</dt><dd>Meidän hieno eventdns-koodi.</dd>
-<dt>Rebecca McKinnon</dt><dd>Former Director of Tor. Co-Founder of <a
-href="http://www.globalvoicesonline.org/";>Global Voices Online</a>.</dd>
-<dt>Matej Pfajfar</dt><dd>Author of the original onion routing code that
-Tor is based on, so we didn't have to start from scratch.</dd>
-<dt>Johannes Renner</dt><dd> Worked during the 2007 Google Summer of
-Code on modifying <a
-href="https://www.torproject.org/svn/torflow/README";>TorFlow</a>
-to measure various properties of the Tor network; mentored by Mike
-Perry.</dd>
-<dt>Scott Squires</dt><dd>Alkuperäinen kehittäjä lisäosalle <a
-href="https://torbutton.torproject.org/";>Torbutton</a>.</dd>
-</dl>
-
-<p>Please don't contact us individually about Tor topics — if
-you have a problem or question, please look through the <a href="<page
-contact>">contact page</a> for appropriate addresses.</p>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
-
+## translation metadata
+# Based-On-Revision: 15491
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Henkilöt" CHARSET="UTF-8" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<h2>Tor: Henkilöt</h2>
+<hr />
+
+<p>Tor-projekti on 501(c)(3) voittoa tavoittelematon yritys Yhdysvalloissa. Yrityksen virallinen osoite on:<br>
+<blockquote>
+The Tor Project<br>
+122 Scott Circle<br>
+Dedham, MA 02026 USA<br>
+</blockquote>
+
+<p>Yritys koostuu monista vapaaehtoisista henkilöistä sekä muutamasta työntekijästä.</p>
+
+<a id="Core"></a>
+<h3><a class="anchor" href="#Core">Päähenkilöt:</a></h3>
+
+<dl>
+<dt>Jacob Appelbaum</dt><dd>Runs the <a
+href="http://check.torproject.org/";>Tor DNSEL</a> <a
+href="http://exitlist.torproject.org/";>site</a>, the <a
+href="https://translation.torproject.org/";>Tor Translation Portal</a>, and also
+the in-progress Tor weather site.</dd>
+<dt>Roger Dingledine (Tor project leader; Director)</dt><dd>Original
+developer of Tor; now plays pretty much all the roles to keep
+everything on track.</dd>
+<dt>Matt Edman</dt><dd>Developer for <a
+href="http://vidalia-project.net/";>Vidalia</a>, a cross-platform Tor GUI
+included in the Windows and OS X bundles.</dd>
+<dt>Andrew Lewman (Director)</dt><dd>Manages building packages for
+Windows, OS X, Red Hat, and SuSE. Also provides common sense on topics
+like how to run a non-profit and generally helps keep everything moving
+forward.</dd>
+<dt>Karsten Loesing</dt><dd> Worked during the 2007 Google Summer of
+Code on <a
+href="https://www.torproject.org/svn/trunk/doc/spec/proposals/114-distributed-storage.txt";>distributing
+and securing the publishing and fetching of hidden service
+descriptors</a>.</dd>
+<dt>Nick Mathewson (Chief architect; Director)</dt><dd>One of the
+three original designers of Tor; does a lot of the ongoing design work.
+One of the two main developers, along with Roger.</dd>
+<dt>Steven Murdoch (Researcher)</dt><dd>Researcher at the University
+of Cambridge, currently funded by The Tor Project to improve
+the security, performance, and usability of Tor. Creator of the
+<a href="https://torbrowser.torproject.org/";>Tor Browser Bundle</a>.</dd>
+<dt>Peter Palfrader</dt><dd>Manages the Debian packages,
+runs one of the directory authorities, runs the website and the wiki,
+and generally helps out a lot.</dd>
+<dt>Mike Perry</dt><dd>Author of <a
+href="https://www.torproject.org/svn/torflow/README";>TorFlow</a>, a Tor
+controller that builds paths through the Tor network and
+measures various properties and behaviors. Working now on a <a
+href="https://torbutton.torproject.org/dev/";>much more comprehensive
+version of Torbutton</a>.</dd>
+<dt>Paul Syverson</dt><dd>Inventor of <a
+href="http://www.onion-router.net/";>Onion Routing</a>, original designer
+of Tor along with Roger and Nick, and project leader for original design,
+development, and deployment of Tor. Currently helps out with research
+and design.</dd>
+</dl>
+
+<a id="Board"></a>
+<h3><a class="anchor" href="#Board">Tor-projektin johtokunta:</a></h3>
+
+<dl>
+<dt>Ian Goldberg (Director)</dt><dd>Cryptographer,
+privacy expert, and professor; one of the designers of <a
+href="http://www.cypherpunks.ca/otr/";>Off-the-Record Messaging</a>.</dd>
+<dt>Xianghui (Isaac) Mao (Director)</dt><dd>Chinese blogging and privacy
+activist. His current activities can be found at <a
+href="http://isaacmao.com/";>his website</a>.<dd>
+<dt>Wendy Seltzer (Director)</dt><dd>Lawyer,
+cyberlaw professor, and founder of <a
+href="http://chillingeffects.org/";>ChillingEffects.org</a>.</dd>
+<dt>Fred von Lohmann (Director)</dt><dd>Fred is a Senior
+Intellectual Property Attorney at the Electronic Frontier
+Foundation (EFF). His complete bio can be found at the <a
+href="http://www.eff.org/about/staff/?f=fred_von_lohmann.html";>EFF
+Staff Site</a>.</dd>
+<dt>Along with Roger, Nick, and Andrew listed above as Directors.</dt>
+</dl>
+
+<a id="Translators"></a>
+<h3><a class="anchor" href="#Translators">Pääkääntäjät:</a></h3>
+
+<dl>
+<dt>Bogdan Drozdowski</dt><dd><a
+href="https://www.torproject.org/index.html.pl";>puolankieli</a>.</dd>
+<dt>fredzupy</dt><dd><a
+href="https://www.torproject.org/index.html.fr";>ranskankieli</a>.</dd>
+<dt>Ruben Garcia</dt><dd><a
+href="https://www.torproject.org/index.html.es";>espanjankieli</a>.</dd>
+<dt>Jens Kubieziel</dt><dd><a
+href="https://www.torproject.org/index.html.de";>saksankieli</a>.</dd>
+<dt>Pei Hanru</dt><dd><a
+href="https://www.torproject.org/index.html.zh-cn";>yksinkertaistettu kiinankieli</a>.</dd>
+<dt>Jan Reister</dt><dd><a
+href="https://www.torproject.org/index.html.it";>italiankieli</a>.</dd>
+<dt>Masaki Taniguchi</dt><dd><a
+href="https://www.torproject.org/index.html.ja";>japaninkieli</a>.</dd>
+<dt>Jan Woning</dt><dd><a
+href="https://www.torproject.org/index.html.nl";>hollanninkieli</a>.</dd>
+<dt>ygrek</dt><dd><a
+href="https://www.torproject.org/index.html.ru";>venäjänkieli</a>.</dd>
+</dl>
+
+<a id="Volunteers"></a>
+<h3><a class="anchor" href="#Volunteers">Monet vapaaehtoiset:</a></h3>
+
+<dl>
+<dt>Anonym</dt><dd>Incognito LiveCD:n ylläpitäjä.</dd>
+<dt>Kevin Bankston</dt><dd>EFF lawyer who helped write the <a
+href="<page eff/tor-legal-faq>">Tor Legal FAQ</a> and
+tirelessly answers the phone when somebody in the world has a legal
+question about Tor.</dd>
+<dt>Jeff Blum</dt><dd>Sivustomme vapaaehtoinen julkaisija, joka auttaa päivittämään Tor-sivuston sisältöä.</dd>
+<dt>Kasimir Gabert</dt><dd>Ylläpitää <a
+href="https://torstatus.kgprog.com/";>TorStatus</a> -tilastosivuja.</dd>
+<dt>Geoff Goodell</dt><dd>Runs one of the directory authorities, used to
+run the Blossom project which uses Tor as its overlay network, and runs
+the <a href="http://lefkada.eecs.harvard.edu/cgi-bin/exit.py";>exit.py</a>
+Tor relay list.</dd>
+<dt>Robert Hogan</dt><dd><a
+href="http://tork.sf.net/";>TorK</a>-Torhallintaohjelman kehittäjä.</dd>
+<dt>Fabian Keil</dt><dd>Yksi Privoxyn pääohjelmoijista ja Tor-fani. Hän on syynä Tor-ohjelman ja Privoxyn yhteistoiminnasta.</dd>
+<dt>Julius Mittenzwei</dt><dd>CCC:n lakimies Saksassa. Coordinates the German Tor community with respect to legal
+questions and concerns.</dd>
+<dt>Shava Nerad</dt><dd>Our former Development Director. She works on PR and community relations.</dd>
+<dt>Lasse Øverlier</dt><dd>Writes research papers on Tor: attacks,
+defenses, and resource management, especially for hidden services.</dd>
+<dt>Martin Peck and Kyle Williams</dt><dd>Developers for
+JanusVM, a VMWare-based
+transparent Tor proxy that makes Tor easier to set up and use.</dd>
+<dt>Steve Topletz</dt><dd>Developer for Torpark (now called Xerobank
+Browser), a preconfigured Tor+Firefox bundle for Windows.</dd>
+<dt>Tup (a pseudonym -- he's managed to stay anonymous even from
+us!)</dt><dd>Periodically adds new features for making Tor more
+transparent to use. Also maintains the <a
+href="http://p56soo2ibjkx23xo.onion/";>TorDNSEL code</a>.</dd>
+<dt>Ethan Zuckerman</dt><dd>A blogger who has written some
+<a href="http://www.ethanzuckerman.com/blog/?p=1019";>interesting</a>
+<a href="http://advocacy.globalvoicesonline.org/tools/guide/";>tutorials</a>
+for how, when, and whether to use Tor. He also teaches activists around
+the world about Tor and related tools.</dd>
+<dt>All our relay operators, people who write <a
+href="http://freehaven.net/anonbib/";>research papers</a> about Tor,
+people who teach others about Tor, etc.</dt>
+</dl>
+
+<a id="GSoC"></a>
+<a id="Past"></a>
+<h3><a class="anchor" href="#Past">Aikaisemmille työntekijöille kiitokset:</a></h3>
+
+<dl>
+<dt>Benedikt Boss</dt><dd>Worked during the 2007 Google Summer of Code on <a
+href="https://svn.torproject.org/svn/topf/trunk/README";>TOPF</a>,
+a fuzzer for Tor; mentored by Roger.</dd>
+<dt>Ren Bucholz</dt><dd>Meidän hieno logo ja kuvat.</dd>
+<dt>Pat Double</dt><dd>Incognito LiveCD:n tekijä.</dd>
+<dt>Justin Hipple</dt><dd>Toinen kehittäjä Vidalialle.</dd>
+<dt>Christian King</dt><dd> Worked during the 2007 Google Summer of Code
+on making Tor relays stable on
+Windows, by developing a <a
+href="https://svn.torproject.org/svn/libevent-urz/trunk/README";>buffer
+implementation for libevent</a>; mentored by Nick.</dd>
+<dt>Joe Kowalski</dt><dd>Original author and provider of the torstatus
+script formerly run on nighteffect.</dd>
+<dt>Adam Langley</dt><dd>Meidän hieno eventdns-koodi.</dd>
+<dt>Rebecca McKinnon</dt><dd>Former Director of Tor. Co-Founder of <a
+href="http://www.globalvoicesonline.org/";>Global Voices Online</a>.</dd>
+<dt>Matej Pfajfar</dt><dd>Author of the original onion routing code that
+Tor is based on, so we didn't have to start from scratch.</dd>
+<dt>Johannes Renner</dt><dd> Worked during the 2007 Google Summer of
+Code on modifying <a
+href="https://www.torproject.org/svn/torflow/README";>TorFlow</a>
+to measure various properties of the Tor network; mentored by Mike
+Perry.</dd>
+<dt>Scott Squires</dt><dd>Alkuperäinen kehittäjä lisäosalle <a
+href="https://torbutton.torproject.org/";>Torbutton</a>.</dd>
+</dl>
+
+<p>Please don't contact us individually about Tor topics — if
+you have a problem or question, please look through the <a href="<page
+contact>">contact page</a> for appropriate addresses.</p>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
+
Property changes on: website/trunk/fi/people.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/research.wml
===================================================================
--- website/trunk/fi/research.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/research.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,21 +1,21 @@
-## translation metadata
-# Based-On-Revision: 13768
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Tutkimustyö" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<h2>Tor: Tutkimustyö</h2>
-<hr />
-
-<p>Lue <a
-href="http://freehaven.net/anonbib/topic.html#Anonymous_20communication";>nämä paperit</a> (erityisesti laatikoissa olevat) saadakseen nopeutta anonyymisiin kommunikointijärjestelmiin.</p>
-
-<p>We need people to attack the system, quantify defenses,
-etc. Lisää tietoa "Tutkimustyö"-kohdasta
-<a href="<page volunteer>">auta</a>-sivulla.</p>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 13768
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Tutkimustyö" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<h2>Tor: Tutkimustyö</h2>
+<hr />
+
+<p>Lue <a
+href="http://freehaven.net/anonbib/topic.html#Anonymous_20communication";>nämä paperit</a> (erityisesti laatikoissa olevat) saadakseen nopeutta anonyymisiin kommunikointijärjestelmiin.</p>
+
+<p>We need people to attack the system, quantify defenses,
+etc. Lisää tietoa "Tutkimustyö"-kohdasta
+<a href="<page volunteer>">auta</a>-sivulla.</p>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/research.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/sponsors.wml
===================================================================
--- website/trunk/fi/sponsors.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/sponsors.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,38 +1,38 @@
-## translation metadata
-# Based-On-Revision: 14284
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Sponsorit" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<h2>Tor: Sponsorit</h2>
-<hr />
-
-<p>
-Tor's <a href="<page torusers>">diversity of users</a> means we
-have a diversity of funding sources too — and we're eager to diversify
-even further! Sponsoreinamme tällä hetkellä:
-</p>
-
-<ul>
-<li><a href="http://chacs.nrl.navy.mil/";>DARPA ja ONR Yhdysvaltain Naval Research Laboratoryn kautta</a> (2001-2007)</li>
-<li><a href="https://www.eff.org/";>Electronic Frontier Foundation</a> (2004-2005)</li>
-<li><a href="http://www.omidyar.net/";>Omidyar Network Enzyme -avustus</a> (2006)</li>
-<li>Bell Security Solutions Inc (2006)</li>
-<li><a href="http://seclab.cs.rice.edu/lab/2005/08/01/seclab-awarded-grant-to-study-security-of-p2p/";>NSF Ricen yliopiston kautta</a> (2006-2007)</li>
-<li>Anonyyminen eurooppalainen NGO (2006-2007)</li>
-<li><a href="<page donate>">Yli 500 henkilön lahjoitusta kaltaisiltasi</a> (2006-2008)</li>
-<li><a href="http://www.ibb.gov/";>International Broadcasting Bureau</a> (2006-2008)</li>
-<li><a href="http://www.cyber-ta.org/";>Cyber-TA -projekti</a> (2006-2008)</li>
-<li><a href="http://www.hrw.org/";>Human Rights Watch</a> (2007)</li>
-<li><a href="http://code.google.com/soc/";>Google Summer of Code</a> (2007, 2008)</li>
-</ul>
-
-<p>Kiitämme jokaista, joka on mahdollistanut Tor-verkon ja -ohjelman kehityksen ja toiminnan tähän asti. Erityisiä kiitoksia niille yksittäisille henkilöille jotka ovat auttaneet ilman rahallisia avustuksia: koodaamalla, testaamalla, dokumentoimalla, opettamalla, tutkimalla sekä pyörittämällä reitittimiä, joista muodostuu Tor-verkko.
-</p>
-
-</div><!-- #main -->
-
-#include <foot.wmi>
-
+## translation metadata
+# Based-On-Revision: 14284
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Sponsorit" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<h2>Tor: Sponsorit</h2>
+<hr />
+
+<p>
+Tor's <a href="<page torusers>">diversity of users</a> means we
+have a diversity of funding sources too — and we're eager to diversify
+even further! Sponsoreinamme tällä hetkellä:
+</p>
+
+<ul>
+<li><a href="http://chacs.nrl.navy.mil/";>DARPA ja ONR Yhdysvaltain Naval Research Laboratoryn kautta</a> (2001-2007)</li>
+<li><a href="https://www.eff.org/";>Electronic Frontier Foundation</a> (2004-2005)</li>
+<li><a href="http://www.omidyar.net/";>Omidyar Network Enzyme -avustus</a> (2006)</li>
+<li>Bell Security Solutions Inc (2006)</li>
+<li><a href="http://seclab.cs.rice.edu/lab/2005/08/01/seclab-awarded-grant-to-study-security-of-p2p/";>NSF Ricen yliopiston kautta</a> (2006-2007)</li>
+<li>Anonyyminen eurooppalainen NGO (2006-2007)</li>
+<li><a href="<page donate>">Yli 500 henkilön lahjoitusta kaltaisiltasi</a> (2006-2008)</li>
+<li><a href="http://www.ibb.gov/";>International Broadcasting Bureau</a> (2006-2008)</li>
+<li><a href="http://www.cyber-ta.org/";>Cyber-TA -projekti</a> (2006-2008)</li>
+<li><a href="http://www.hrw.org/";>Human Rights Watch</a> (2007)</li>
+<li><a href="http://code.google.com/soc/";>Google Summer of Code</a> (2007, 2008)</li>
+</ul>
+
+<p>Kiitämme jokaista, joka on mahdollistanut Tor-verkon ja -ohjelman kehityksen ja toiminnan tähän asti. Erityisiä kiitoksia niille yksittäisille henkilöille jotka ovat auttaneet ilman rahallisia avustuksia: koodaamalla, testaamalla, dokumentoimalla, opettamalla, tutkimalla sekä pyörittämällä reitittimiä, joista muodostuu Tor-verkko.
+</p>
+
+</div><!-- #main -->
+
+#include <foot.wmi>
+
Property changes on: website/trunk/fi/sponsors.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Property changes on: website/trunk/fi/support.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/users.wml
===================================================================
--- website/trunk/fi/users.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/users.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,7 +1,7 @@
-## translation metadata
-# Based-On-Revision: 13768
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Siirrytään" REDIRECT="documentation" CHARSET="UTF-8"
-
-#include <foot.wmi>
+## translation metadata
+# Based-On-Revision: 13768
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Siirrytään" REDIRECT="documentation" CHARSET="UTF-8"
+
+#include <foot.wmi>
Property changes on: website/trunk/fi/users.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Modified: website/trunk/fi/volunteer.wml
===================================================================
--- website/trunk/fi/volunteer.wml 2008-07-07 15:26:25 UTC (rev 15728)
+++ website/trunk/fi/volunteer.wml 2008-07-07 15:39:22 UTC (rev 15729)
@@ -1,1173 +1,1173 @@
-## translation metadata
-# Based-On-Revision: 15123
-# Last-Translator: djhasis(at)gmail.com
-
-#include "head.wmi" TITLE="Tor: Auta" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<!-- PUT CONTENT AFTER THIS TAG -->
-<h2>A few things everyone can do now:</h2>
-<ol>
-<li>Please consider <a href="<page docs/tor-doc-relay>">running
-a relay</a> to help the Tor network grow.</li>
-<li>Tell your friends! Get them to run relays. Get them to run hidden
-services. Get them to tell their friends.</li>
-<li>If you like Tor's goals, please <a href="<page donate>">take a moment
-to donate to support further Tor development</a>. We're also looking
-for more sponsors — if you know any companies, NGOs, agencies,
-or other organizations that want anonymity / privacy / communications
-security, let them know about us.</li>
-<li>We're looking for more <a href="<page torusers>">good examples of Tor
-users and Tor use cases</a>. If you use Tor for a scenario or purpose not
-yet described on that page, and you're comfortable sharing it with us,
-we'd love to hear from you.</li>
-</ol>
-
-<a id="Usability"></a>
-<h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>
-<ol>
-<li>We need more good ways to intercept DNS requests so they don't "leak" their
-request to a local observer while we're trying to be anonymous. (This
-happens because the application does the DNS resolve before going to
-the SOCKS proxy.)</li>
-<li>Tsocks/dsocks items:
-<ul>
-<li>We need to <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches";>apply
-all our tsocks patches</a> and maintain a new fork. We'll host it if
-you want.</li>
-<li>We should patch Dug Song's "dsocks" program to use Tor's
-<i>mapaddress</i> commands from the controller interface, so we
-don't waste a whole round-trip inside Tor doing the resolve before
-connecting.</li>
-<li>We need to make our <i>torify</i> script detect which of tsocks or
-dsocks is installed, and call them appropriately. This probably means
-unifying their interfaces, and might involve sharing code between them
-or discarding one entirely.</li>
-</ul>
-</li>
-<li>People running relays tell us they want to have one BandwidthRate
-during some part of the day, and a different BandwidthRate at other
-parts of the day. Rather than coding this inside Tor, we should have a
-little script that speaks via the <a href="<page gui/index>">Tor
-Controller Interface</a>, and does a setconf to change the bandwidth
-rate. There is one for Unix and Mac already (it uses bash and cron),
-but Windows users still need a solution.
-</li>
-<li>Tor can <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit";>exit
-the Tor network from a particular exit node</a>, but we should be able
-to specify just a country and have something automatically pick. The
-best bet is to fetch Blossom's directory also, and run a local Blossom
-client that fetches this directory securely (via Tor and checking its
-signature), intercepts <tt>.country.blossom</tt> hostnames, and does
-the right thing.</li>
-<li>Speaking of geolocation data, somebody should draw a map of the Earth
-with a pin-point for each Tor relay. Bonus points if it updates as the
-network grows and changes. Unfortunately, the easy ways to do this involve
-sending all the data to Google and having them draw the map for you. How
-much does this impact privacy, and do we have any other good options?</li>
-</ol>
-
-<a id="Documentation"></a>
-<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
-<ol>
-<li>Please help Matt Edman with the documentation and how-tos for his
-Tor controller,
-<a href="http://vidalia-project.net/";>Vidalia</a>.</li>
-<li>Evaluate and document
-<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO";>our
-list of programs</a> that can be configured to use Tor.</li>
-<li>We need better documentation for dynamically intercepting
-connections and sending them through Tor. tsocks (Linux), dsocks (BSD),
-and freecap (Windows) seem to be good candidates, as would better
-use of our new TransPort feature.</li>
-<li>We have a huge list of <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms";>potentially useful
-programs that interface to Tor</a>. Which ones are useful in which
-situations? Please help us test them out and document your results.</li>
-<li>Help translate the web page and documentation into other
-languages. See the <a href="<page translation>">translation
-guidelines</a> if you want to help out. We especially need Arabic or
-Farsi translations, for the many Tor users in censored areas.</li>
-</ol>
-
-<a id="Coding"></a>
-<a id="Summer"></a>
-<a id="Projects"></a>
-<h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>
-
-<p>
-You may find some of these projects to be good <a href="<page
-gsoc>">Google Summer of Code 2008</a> ideas. We have labelled each idea
-with how useful it would be to the overall Tor project
-(priority), how much work we expect it would be (effort level), how much
-clue you should start with (skill level), and which of our <a href="<page
-people>#Core">core developers</a> would be good mentors. There are plenty
-of other good ideas to work on too — see for example the <a
-href="<svnsandbox>doc/spec/proposals/">current proposals</a> list, or
-just make up your own ideas.
-</p>
-
-<ol>
-
-<li>
-<b>Tor Exit Scanner improvements</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>5</i>
-<br />
-The Tor exit node scanner 'SoaT', part of the <a
-href="<svnsandbox>torflow/">Torflow project</a>, makes connections out
-of each Tor exit node and compares the content it gets back with what it
-"should" get back. The goal is to notice misconfigured, broken, and even
-malicious exit relays. Alas, the code is
-currently written in rather rickety perl and relies on MD5sums of
-entire documents in order to determine if exit nodes are modifying
-content. The problem with this is threefold: 1) Perl sucks at life.
-2) The scanner can't verify pages that are dynamic, and attackers can
-focus malicious content injection on only those dynamic pages. 3)
-Pages change after a while (or based on GeoIP) and begin generating
-false positives.
-<br />
-Ideally, soat.pl would be reimplemented in a sane language with a
-robust html parser library (since the rest of Torflow is in Python
-that would be nice, but it is not required), and calculate signatures only for
-tags and content likely to be targeted by a malicious attacker (script
-tags, object links, images, css). It should also be robust in the face of
-changes to content outside of Tor, and ultimately even GeoIP localized
-content.
-<br />
-This scanner would likely be run by the Directory Authorities and
-report its results to the control port via the AuthDirBadExit config
-setting.
-<br />
-</li>
-
-<li>
-<b>Tor Node Scanner improvements</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium to High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
-Similar to the exit scanner (or perhaps even during exit scanning),
-statistics can be gathered about the reliability of nodes. Nodes that
-fail too high a percentage of their circuits should not be given
-Guard status. Perhaps they should have their reported bandwidth
-penalized by some ratio as well, or just get marked as Invalid. In
-addition, nodes that exhibit a very low average stream capacity but
-advertise a very high node bandwidth can also be marked as Invalid.
-Much of this statistics gathering is already done, it just needs to be
-transformed into something that can be reported to the Directory
-Authorities to blacklist/penalize nodes in such a way that clients
-will listen.
-<br />
-In addition, these same statistics can be gathered about the traffic
-through a node. Events can be added to the <a
-href="https://www.torproject.org/svn/torctl/doc/howto.txt";>Tor Control
-Protocol</a> to
-report if a circuit extend attempt through the node succeeds or fails, and
-passive statistics can be gathered on both bandwidth and reliability
-of other nodes via a node-based monitor using these events. Such a
-scanner would also report information on oddly-behaving nodes to
-the Directory Authorities, but a communication channel for this
-currently does not exist and would need to be developed as well.
-</li>
-
-<li>
-<b>Help track the overall Tor Network status</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Roger, Nick, Mike</i>
-<br />
-It would be great to set up an automated system for tracking network
-health over time, graphing it, etc. Part of this project would involve
-inventing better metrics for assessing network health and growth. Is the
-average uptime of the network increasing? How many relays are qualifying
-for Guard status this month compared to last month? What's the turnover
-in terms of new relays showing up and relays shutting off? Periodically
-people collect brief snapshots, but where it gets really interesting is
-when we start tracking data points over time.
-<br />
-Data could be collected from the "Tor Node Scanner" item above, from
-the server descriptors that each relay publishes, and from other
-sources. Results over time could be integrated into one of the <a
-href="https://torstatus.blutmagie.de/";>Tor Status</a> web pages, or be
-kept separate. Speaking of the Tor Status pages, take a look at Roger's
-<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html";>Tor
-Status wish list</a>.
-</li>
-
-<li>
-<b>Tor path selection improvements</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Low to Medium</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Roger, Nick, Mike</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>3</i>
-<br />
-Some simple improvements can be made to Tor's path selection to vastly
-improve Tor speed. For instance, some of the (unofficial) <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf";>Tor
-Performance Recommendations</a> on the wiki are to increase the number of
-guards and decrease the CircuitBuildTimeout. Ideally, the client would
-<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html";>learn
-these values by gathering statistics on circuit construction
-time</a> (and/or using values gained from Torflow), and set the timeouts
-low enough such that some high percentile (75%, 90%, 1-stddev?) of
-circuits succeed, yet extremely slow nodes are avoided. This would
-involve some statistics gathering+basic research, and some changes to
-Tor path selection code.
-<br />
-In addition, to improve path security, some elements from the <a
-href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt";>Two
-Hop Paths proposal</a> could be done as part of this (since it will
-likely touch the same code anyways), regardless of the adoption of
-that proposal. In particular, clients probably should avoid guards that
-seem to fail an excessive percentage of their circuits through them,
-and non-firewalled clients should issue a warning if they are only able
-to connect to a limited set of guard nodes. See also
-<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html";>this
-or-dev post</a>.
-</li>
-
-<li>
-<b>Translation Wiki</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Jacob</i>
-<br />
-We need a way to edit and translate sections of the website. Currently
-the website is made up of a bunch of <a href="<svnwebsite>en/">wml
-files</a>, and <a href="<page translation>">translators</a> fetch these
-wml files, translate them in an editor, and either send us the translation
-or use svn to commit them back. The current "cost" of publication of
-website changes is quite high even for English language users. For a
-single word change or any type of
-minor change, the page may never be corrected or translated. It would
-be nice to have a wiki that was specifically geared towards translation
-and would somehow track the upstream (English) versions to indicate when
-a fresh translation is needed, like our current
-<a href="<page translation-status>">translation status page</a>. This
-seems mostly like a job for a wiki
-integrator or wiki software author. Certainly the person would need to
-be interested in human languages and translation. They should at least
-be minimally familiar with what Tor is; but they would not have to interact
-with the software, only the documentation and the website.
-</li>
-
-<li>
-<b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Peter, Matt</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
-Vidalia currently doesn't play nicely on Debian and Ubuntu with the
-default Tor packages. The current Tor packages automatically start Tor
-as a daemon running as the debian-tor user and (sensibly) do not have a
-<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
-in the default torrc. Consequently, Vidalia will try
-to start its own Tor process since it could not connect to the existing
-Tor, and Vidalia's Tor process will then exit with an error message
-the user likely doesn't understand since Tor cannot bind its listening
-ports — they're already in use by the original Tor daemon.
-<br />
-The current solution involves either telling the user to stop the
-existing Tor daemon and let Vidalia start its own Tor process, or
-explaining to the user how to set a control port and password in their
-torrc. A better solution on Debian would be to use Tor's ControlSocket,
-which allows Vidalia to talk to Tor via a Unix domain socket, and could
-possibly be enabled by default in Tor's Debian packages. Vidalia can
-then authenticate to Tor using filesystem-based (cookie) authentication
-if the user running Vidalia is also in the debian-tor group.
-<br />
-This project will first involve adding support for Tor's ControlSocket
-to Vidalia. The student will then develop and test Debian and Ubuntu
-packages for Vidalia that conform to Debian's packaging standards and
-make sure they work well with the existing Tor packages. We can also
-set up an apt repository to host the new Vidalia packages.
-<br />
-The next challenge would be to find an intuitive usable way for Vidalia
-to be able to change Tor's configuration (torrc) even though it is
-located in <code>/etc/tor/torrc</code> and thus immutable. The best
-idea we've come up with so far is to feed Tor a new configuration via
-the ControlSocket when Vidalia starts, but that's bad because Tor starts
-each boot with a different configuration than the user wants. The second
-best idea
-we've come up with is for Vidalia to write out a temporary torrc file
-and ask the user to manually move it to <code>/etc/tor/torrc</code>,
-but that's bad because users shouldn't have to mess with files directly.
-<br />
-A student undertaking this project should have prior knowledge of
-Debian package management and some C++ development experience. Previous
-experience with Qt is helpful, but not required.
-</li>
-
-<li>
-<b>Improving Tor's ability to resist censorship</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Nick</i>
-<br />
-The Tor 0.2.0.x series makes <a
-href="<svnsandbox>doc/design-paper/blocking.html">significant
-improvements</a> in resisting national and organizational censorship.
-But Tor still needs better mechanisms for some parts of its
-anti-censorship design. For example, current Tors can only listen on a
-single address/port combination at a time. There's
-<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
-proposal to address this limitation</a> and allow clients to connect
-to any given Tor on multiple addresses and ports, but it needs more
-work. Another anti-censorship project (far more difficult) is to try
-to make Tor more scanning-resistant. Right now, an adversary can identify
-<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
-just by trying to connect to them, following the Tor protocol, and
-seeing if they respond. To solve this, bridges could
-<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
-webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
-and not act like bridges until the user provides a bridge-specific key.
-<br />
-This project involves a lot of research and design. One of the big
-challenges will be identifying and crafting approaches that can still
-resist an adversary even after the adversary knows the design, and
-then trading off censorship resistance with usability and robustness.
-</li>
-
-<li>
-<b>Tor/Polipo/Vidalia Auto-Update Framework</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Matt, Jacob</i>
-<br />
-We're in need of a good authenticated-update framework.
-Vidalia already has the ability to notice when the user is running an
-outdated or unrecommended version of Tor, using signed statements inside
-the Tor directory information. Currently, Vidalia simply pops
-up a little message box that lets the user know they should manually
-upgrade. The goal of this project would be to extend Vidalia with the
-ability to also fetch and install the updated Tor software for the
-user. We should do the fetches via Tor when possible, but also fall back
-to direct fetches in a smart way. Time permitting, we would also like
-to be able to update other
-applications included in the bundled installers, such as Polipo and
-Vidalia itself.
-<br />
-To complete this project, the student will first need to first investigate
-the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
-their strengths, weaknesses, security properties, and ability to be
-integrated into Vidalia. If none are found to be suitable, the student
-will design their own auto-update framework, document the design, and
-then discuss the design with other developers to assess any security
-issues. The student will then implement their framework (or integrate
-an existing one) and test it.
-<br />
-A student undertaking this project should have good C++ development
-experience. Previous experience with Qt is helpful, but not required. The
-student should also have a good understanding of common security
-practices, such as package signature verification. Good writing ability
-is also important for this project, since a vital step of the project
-will be producing a design document for others to review and discuss
-with the student prior to implementation.
-</li>
-
-<li>
-<b>An Improved and More Usable Network Map in Vidalia</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Matt</i>
-<br />
-One of Vidalia's existing features is a network map that shows the user
-the approximate geographic location of relays in the Tor network and
-plots the paths the user's traffic takes as it is tunneled through the
-Tor network. The map is currently not very interactive and has rather
-poor graphics. Instead, we would like to leverage KDE's Marble widget
-that gives us a better quality map and enables improved interactivity,
-such as allowing the user to click on individual relays or circuits to
-display additional information. We might also consider adding the ability
-for users to click on a particular relay or a country containing one or
-more Tor exit relays and say, "I want my connections to foo.com to exit
-from here."
-<br />
-This project will first involve the student getting familiar with Vidalia
-and the Marble widget's API. The student will then integrate the widget
-into Vidalia and customize Marble to be better suited for our application,
-such as making circuits clickable, storing cached map data in Vidalia's
-own data directory, and customizing some of the widget's dialogs.
-<br />
-A student undertaking this project should have good C++ development
-experience. Previous experience with Qt and CMake is helpful, but not
-required.
-</li>
-
-<li>
-<b>Tor Controller Status Event Interface</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Matt, Roger</i>
-<br />
-There are a number of status changes inside Tor of which the user may need
-to be informed. For example, if the user is trying to set up his Tor as a
-relay and Tor decides that its ports are not reachable from outside
-the user's network, we should alert the user. Currently, all the user
-gets is a couple log messages in Vidalia's 'message log' window, which they
-likely never see since they don't receive a notification that something
-has gone wrong. Even if the user does actually look at the message log,
-most of the messages make little sense to the novice user.
-<br />
-Tor has the ability to inform Vidalia of many such status changes, and
-we recently implemented support for a couple of these events. Still,
-there are many more status events the user should be informed of and we
-need a better UI for actually displaying them to the user.
-<br />
-The goal of this project then is to design and implement a UI for
-displaying Tor status events to the user. For example, we might put a
-little badge on Vidalia's tray icon that alerts the user to new status
-events they should look at. Double-clicking the icon could bring up a
-dialog that summarizes recent status events in simple terms and maybe
-suggests a remedy for any negative events if they can be corrected by
-the user. Of course, this is just an example and the student is free to
-suggest another approach.
-<br />
-A student undertaking this project should have good UI design and layout
-and some C++ development experience. Previous experience with Qt and
-Qt's Designer will be very helpful, but are not required. Some
-English writing ability will also be useful, since this project will
-likely involve writing small amounts of help documentation that should
-be understandable by non-technical users. Bonus points for some graphic
-design/Photoshop fu, since we might want/need some shiny new icons too.
-</li>
-
-<li>
-<b>Improvements on our active browser configuration tester</b> -
-<a href="https://check.torproject.org/";>https://check.torproject.org/</a>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Low to Medium</i>
-<br />
-Likely Mentors: <i>Jacob, Steven</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
-We currently have a functional web page to detect if Tor is working. It
-has a few places where it falls short. It requires improvements with
-regard to default languages and functionality. It currently only responds
-in English. In addition, it is a hack of a perl script that should have
-never seen the light of day. It should probably be rewritten in python
-with multi-lingual support in mind. It currently uses the <a
-href="http://exitlist.torproject.org/";>Tor DNS exit list</a>
-and should continue to do so in the future. It currently result in certain
-false positives and these should be discovered, documented, and fixed
-where possible. Anyone working on this project should be interested in
-DNS, basic perl or preferably python programming skills, and will have
-to interact minimally with Tor to test their code.
-<br />
-If you want to make the project more exciting
-and involve more design and coding, take a look at <a
-href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
-131-verify-tor-usage.txt</a>.
-</li>
-
-<li>
-<b>Improvements on our DNS Exit List service</b> -
-<a href="http://exitlist.torproject.org/";>http://exitlist.torproject.org/</a>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Low</i>
-<br />
-Likely Mentors: <i>Jacob, Tup</i>
-<br />
-The <a href="http://p56soo2ibjkx23xo.onion/";>exitlist software</a>
-is written by our fabulous anonymous
-contributer Tup. It's a DNS server written in Haskell that supports part of our <a
-href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt";>exitlist
-design document</a>. Currently, it is functional and it is used by
-check.torproject.org and other users. The issues that are outstanding
-are mostly aesthetic. This wonderful service could use a much better
-website using the common Tor theme. It would be best served with better
-documentation for common services that use an RBL. It could use more
-publicity. A person working on this project should be interested in DNS,
-basic RBL configuration for popular services, and writing documentation.
-The person would require minimal Tor interaction — testing their
-own documentation at the very least. Furthermore, it would be useful
-if they were interested in Haskell and wanted to implement more of the
-torel-design.txt suggestions.
-</li>
-
-<li>
-<b>Testing integration of Tor with web browsers for our end users</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Jacob, Mike, Greg</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
-The Tor project currently lacks a solid test suite to ensure that a
-user has a properly and safely configured web browser. It should test for as
-many known issues as possible. It should attempt to decloak the
-user in any way possible. Two current webpages that track these
-kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
-href="http://pseudo-flaw.net/tor/torbutton/";>list of issues along
-with their proof of concept code, bug issues, etc</a>. HD Moore runs
-the <a href="http://metasploit.com/research/projects/decloak/";>metasploit
-decloak website</a>. A student interested in defending Tor could start
-by collecting as many workable and known methods for decloaking a
-Tor user. (<a href="https://torcheck.xenobite.eu/";>This page</a> may
-be helpful as a start.) The student should be familiar with the common
-pitfalls but
-possibly have new methods in mind for implementing decloaking issues. The
-website should ensure that it tells a user what their problem is. It
-should help them to fix the problem or direct them to the proper support
-channels. The student should be closely familiar with using Tor and how
-to prevent Tor information leakage.
-</li>
-
-<li>
-<b>Libevent and Tor integration improvements</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Nick</i>
-<br />
-Tor should make better use of the more recent features of Niels
-Provos's <a href="http://monkey.org/~provos/libevent/";>Libevent</a>
-library. Tor already uses Libevent for its low-level asynchronous IO
-calls, and could also use Libevent's increasingly good implementations
-of network buffers and of HTTP. This wouldn't be simply a matter of
-replacing Tor's internal calls with calls to Libevent: instead, we'll
-need to refactor Tor to use Libevent calls that do not follow the
-same models as Tor's existing backends. Also, we'll need to add
-missing functionality to Libevent as needed — most difficult likely
-will be adding OpenSSL support on top of Libevent's buffer abstraction.
-Also tricky will be adding rate-limiting to Libevent.
-</li>
-
-<li>
-<b>Tuneup Tor!</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Nick, Roger, Mike</i>
-<br />
-Right now, Tor relays measure and report their own bandwidth, and Tor
-clients choose which relays to use in part based on that bandwidth.
-This approach is vulnerable to
-<a href="http://freehaven.net/anonbib/#bauer:wpes2007";>attacks where
-relays lie about their bandwidth</a>;
-to address this, Tor currently caps the maximum bandwidth
-it's willing to believe any relay provides. This is a limited fix, and
-a waste of bandwidth capacity to boot. Instead,
-Tor should possibly measure bandwidth in a more distributed way, perhaps
-as described in the
-<a href="http://freehaven.net/anonbib/author.html#snader08";>"A Tune-up for
-Tor"</a> paper
-by Snader and Borisov. A student could use current testing code to
-double-check this paper's findings and verify the extent to which they
-dovetail with Tor as deployed in the wild, and determine good ways to
-incorporate them into their suggestions Tor network without adding too
-much communications overhead between relays and directory
-authorities.
-</li>
-
-<!--
-<li>
-<b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Jacob, Andrew</i>
-<br />
-It would be useful to have automated build processes for Windows and
-probably other platforms. The purpose of having a continuous integration
-build environment is to ensure that Windows isn't left behind for any of
-the software projects used in the Tor project or its accompanying.<br />
-Buildbot may be a good choice for this as it appears to support all of
-the platforms Tor does. See the
-<a href="http://en.wikipedia.org/wiki/BuildBot";>wikipedia entry for
-buildbot</a>.<br />
-There may be better options and the person undertaking this task should
-evaluate other options. Any person working on this automatic build
-process should have experience or be willing to learn how to build all
-of the respective Tor related code bases from scratch. Furthermore, the
-person should have some experience building software in Windows
-environments as this is the target audience we want to ensure we do not
-leave behind. It would require close work with the Tor source code but
-probably only in the form of building, not authoring.<br />
-Additionally, we need to automate our performance testing for all platforms.
-We've got buildbot (except on Windows — as noted above) to automate
-our regular integration and compile testing already,
-but we need to get our network simulation tests (as built in torflow)
-updated for more recent versions of Tor, and designed to launch a test
-network either on a single machine, or across several, so we can test
-changes in performance on machines in different roles automatically.
-</li>
--->
-
-<li>
-<b>Improve our unit testing process</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Nick</i>
-<br />
-Tor needs to be far more tested. This is a multi-part effort. To start
-with, our unit test coverage should rise substantially, especially in
-the areas outside the utility functions. This will require significant
-refactoring of some parts of Tor, in order to dissociate as much logic
-as possible from globals.
-<br />
-Additionally, we need to automate our performance testing. We've got
-buildbot to automate our regular integration and compile testing already
-(though we need somebody to set it up on Windows),
-but we need to get our network simulation tests (as built in TorFlow: see
-the "Tor Node Scanner improvements" item)
-updated for more recent versions of Tor, and designed to launch a test
-network either on a single machine, or across several, so we can test
-changes in performance on machines in different roles automatically.
-</li>
-
-<li>
-<b>Help revive an independent Tor client implementation</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Karsten, Nick</i>
-<br />
-Applications as of 1 Apr 00::00 UTC: <i>4</i>
-<br />
-Reanimate one of the approaches to implement a Tor client in Java,
-e.g. the <a href="http://onioncoffee.sourceforge.net/";>OnionCoffee
-project</a>, and make it run on <a
-href="http://code.google.com/android/";>Android</a>. The first step
-would be to port the existing code and execute it in an Android
-environment. Next, the code should be updated to support the newer Tor
-protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
-directory protocol</a>. Further, support for requesting or even
-providing Tor hidden services would be neat, but not required.
-<br />
-The student should be able to understand and write new Java code, including
-a Java cryptography API. Being able to read C code would be helpful,
-too. The student should be willing to read the existing documentation,
-implement code based on it, and refine the documentation
-when things are underdocumented. This project is mostly about coding and
-to a small degree about design.
-</li>
-
-<li>
-<b>Automatic system tests and automatically starting private Tor networks</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Karsten, Nick, Roger</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>2</i>
-<br />
-Write a tool that runs automatic system tests in addition
-to the existing unit tests. The Java-based Tor simulator <a
-href="https://svn.torproject.org/svn/puppetor/trunk/";>PuppeTor</a>
-might be a good start for starting up a private Tor network, using it
-for a while, and verifying that at least parts of it are working. This
-project requires to conceive a blueprint for performing system tests
-of private Tor networks, before starting to code. Typical types of
-tests range from performing single requests over the private network to
-manipulating exchanged messages and see if nodes handle corrupt messages
-appropriately.
-<br />
-The student should be able to obtain a good understanding
-of how Tor works and what problems and bugs could arise to design good
-test cases. Understanding the existing Tor code structure and documentation is
-vital. If PuppeTor is used, the student should also be able to understand
-and possibly extend an existing Java application. This project is partly
-about design and partly about coding.
-</li>
-
-<li>
-<b>Bring moniTor to life</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Low to Medium</i>
-<br />
-Likely Mentors: <i>Karsten, Jacob</i>
-<br />
-Applications as of 1 Apr 00::00 UTC: <i>2</i>
-<br />
-Implement a <a href="http://www.ss64.com/bash/top.html";>top-like</a>
-management tool for Tor relays. The purpose of such a tool would be
-to monitor a local Tor relay via its control port and include useful
-system information of the underlying machine. When running this tool, it
-would dynamically update its content like top does for Linux processes.
-<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html";>This
-or-dev post</a> might be a good first read.
-<br />
-The student should be familiar
-with or willing to learn about administering a Tor relay and configuring
-it via its control port. As an initial prototype is written in Python,
-some knowledge about writing Python code would be helpful, too. This
-project is one part about identifying requirements to such a
-tool and designing its interface, and one part lots of coding.
-</li>
-
-<li>
-<b>Torbutton improvements</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br/>
-Torbutton has a number of improvements that can be made in the post-1.2
-timeframe. Most of these are documented as feature requests in the <a
-href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5";>Torbutton
-flyspray section</a>. Good examples include: stripping off node.exit on http
-headers, more fine-grained control over formfill blocking, improved referrer
-spoofing based on the domain of the site (a-la <a
-href="https://addons.mozilla.org/en-US/firefox/addon/953";>refcontrol extension</a>),
-tighter integration with Vidalia for reporting Tor status, a New Identity
-button with Tor integration and multiple identity management, and anything
-else you might think of.
-<br />
-This work would be independent coding in Javascript and the fun world of <a
-href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";>XUL</a>,
-with not too much involvement in the Tor internals.
-</li>
-
-<li>
-<b>Porting Polipo to Windows</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Andrew, Steven, Roger</i>
-<br />
-Help port <a
-href="http://www.pps.jussieu.fr/~jch/software/polipo/";>Polipo</a> to
-Windows. Example topics to tackle include:
-1) handle spaces in path names and understand the filesystem
-namespace — that is, where application data, personal data,
-and program data typically reside in various versions of Windows. 2) the
-ability to handle ipv6 communications. 3) the ability to asynchronously
-query name servers, find the system nameservers, and manage netbios
-and dns queries. 4) use native regex capabilities of Windows, rather
-than using 3rd party GNU regex libraries. 5) manage events and buffers
-natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
-Windows it's whatever the config specifies). 6) some sort of GUI config
-and reporting tool, bonus if it has a systray icon with right clickable
-menu options. Double bonus if it's cross-platform compatible.
-</li>
-
-<li>
-<b>Make our diagrams beautiful and automated</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Low</i>
-<br />
-Likely Mentors: <i>Andrew</i>
-<br />
-We need a way to generate the website diagrams (for example, the "How
-Tor Works" pictures on the <a href="<page overview>">overview page</a>
-from source, so we can translate them as UTF-8 text rather than edit
-them by hand with Gimp. We might want to
-integrate this as an wml file so translations are easy and images are
-generated in multiple languages whenever we build the website. See the
-"Translation Wiki" idea above.
-</li>
-
-<li>
-<b>Improve the LiveCD offerings for the Tor community</b>
-<br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Anonym, Jacob, Roger</i>
-<br />
-How can we make the <a
-href="http://anonymityanywhere.com/incognito/";>Incognito LiveCD</a>
-easier to maintain, improve, and document?
-</li>
-
-<li>
-<b>Rework and extend Blossom</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium to High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Goodell</i>
-<br />
-Rework and extend Blossom (a tool for monitoring and
-selecting appropriate Tor circuits based upon exit node requirements
-specified by the user) to gather data in a self-contained way, with
-parameters easily configurable by the user. Blossom is presently
-implemented as a single Python script that interfaces with Tor using the
-Controller interface and depends upon metadata about Tor nodes obtained
-via external processes, such as a webpage indicating status of the nodes
-plus publically available data from DNS, whois, etc. This project has
-two parts: (1) Determine which additional metadata may be useful and
-rework Blossom so that it cleanly obtains the metadata on its own rather
-than depend upon external scripts (this may, for example, involve
-additional threads or inter-process communication), and (2) develop a
-means by which the user can easily configure Blossom, starting with a
-configuration file and possibly working up to a web configuration engine.
-Knowledge of Tor and Python are important; knowledge of
-TCP, interprocess communication, and Perl will also be helpful. An
-interest in network neutrality is important as well, since the
-principles of evaluating and understanding internet inconsistency are at
-the core of the Blossom effort.
-</li>
-
-<li>
-<b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
-<br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Goodell</i>
-<br />
-Develop and implement a means of affording Blossom
-users the ability to qualitatively describe the exit node that they
-want. The Internet is an inconsistent place: some Tor exit nodes see
-the world differently than others. As presently implemented, Blossom (a
-tool for monitoring and selecting appropriate Tor circuits based upon
-exit node requirements specified by the user) lacks a sufficiently rich
-language to describe how the different vantage points are different.
-For example, some exit nodes may have an upstream network that filters
-certain kinds of traffic or certain websites. Other exit nodes may
-provide access to special content as a result of their location, perhaps
-as a result of discrimination on the part of the content providers
-themselves. This project has two parts: (1) develop a language for
-describing characteristics of networks in which exit nodes reside, and
-(2) incorporate this language into Blossom so that users can select Tor
-paths based upon the description.
-Knowledge of Tor and Python are important; knowledge of
-TCP, interprocess communication, and Perl will also be helpful. An
-interest in network neutrality is important as well, since the
-principles of evaluating and understanding internet inconsistency are at
-the core of the Blossom effort.
-</li>
-
-<li>
-<b>Bring up new ideas!</b>
-<br />
-Don't like any of these? Look at the <a
-href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
-roadmap</a> for more ideas.
-</li>
-
-</ol>
-
-<h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
-<ol>
-<li>Tor relays don't work well on Windows XP. On
-Windows, Tor uses the standard <tt>select()</tt> system
-call, which uses space in the non-page pool. This means
-that a medium sized Tor relay will empty the non-page pool, <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems";>causing
-havoc and system crashes</a>. We should probably be using overlapped IO
-instead. One solution would be to teach <a
-href="http://www.monkey.org/~provos/libevent/";>libevent</a> how to use
-overlapped IO rather than select() on Windows, and then adapt Tor to
-the new libevent interface. Christian King made a
-<a href="https://svn.torproject.org/svn/libevent-urz/trunk/";>good
-start</a> on this in the summer of 2007.</li>
-<li>We need to actually start building our <a href="<page
-documentation>#DesignDoc">blocking-resistance design</a>. This involves
-fleshing out the design, modifying many different pieces of Tor, adapting
-<a href="http://vidalia-project.net/";>Vidalia</a> so it supports the
-new features, and planning for deployment.</li>
-<li>We need a flexible simulator framework for studying end-to-end
-traffic confirmation attacks. Many researchers have whipped up ad hoc
-simulators to support their intuition either that the attacks work
-really well or that some defense works great. Can we build a simulator
-that's clearly documented and open enough that everybody knows it's
-giving a reasonable answer? This will spur a lot of new research.
-See the entry <a href="#Research">below</a> on confirmation attacks for
-details on the research side of this task — who knows, when it's
-done maybe you can help write a paper or three also.</li>
-<li>Tor 0.1.1.x and later include support for hardware crypto accelerators
-via OpenSSL. Nobody has ever tested it, though. Does somebody want to get
-a card and let us know how it goes?</li>
-<li>Perform a security analysis of Tor with <a
-href="http://en.wikipedia.org/wiki/Fuzz_testing";>"fuzz"</a>. Determine
-if there are good fuzzing libraries out there for what we want. Win fame by
-getting credit when we put out a new release because of you!</li>
-<li>Tor uses TCP for transport and TLS for link
-encryption. This is nice and simple, but it means all cells
-on a link are delayed when a single packet gets dropped, and
-it means we can only reasonably support TCP streams. We have a <a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP";>list
-of reasons why we haven't shifted to UDP transport</a>, but it would
-be great to see that list get shorter. We also have a proposed <a
-href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specification
-for Tor and
-UDP</a> — please let us know what's wrong with it.</li>
-<li>We're not that far from having IPv6 support for destination addresses
-(at exit nodes). If you care strongly about IPv6, that's probably the
-first place to start.</li>
-</ol>
-
-<a id="Research"></a>
-<h2><a class="anchor" href="#Research">Research</a></h2>
-<ol>
-<li>The "website fingerprinting attack": make a list of a few
-hundred popular websites, download their pages, and make a set of
-"signatures" for each site. Then observe a Tor client's traffic. As
-you watch him receive data, you quickly approach a guess about which
-(if any) of those sites he is visiting. First, how effective is
-this attack on the deployed Tor codebase? Then start exploring
-defenses: for example, we could change Tor's cell size from 512
-bytes to 1024 bytes, we could employ padding techniques like <a
-href="http://freehaven.net/anonbib/#timing-fc2004";>defensive dropping</a>,
-or we could add traffic delays. How much of an impact do these have,
-and how much usability impact (using some suitable metric) is there from
-a successful defense in each case?</li>
-<li>The "end-to-end traffic confirmation attack":
-by watching traffic at Alice and at Bob, we can <a
-href="http://freehaven.net/anonbib/#danezis:pet2004";>compare
-traffic signatures and become convinced that we're watching the same
-stream</a>. So far Tor accepts this as a fact of life and assumes this
-attack is trivial in all cases. First of all, is that actually true? How
-much traffic of what sort of distribution is needed before the adversary
-is confident he has won? Are there scenarios (e.g. not transmitting much)
-that slow down the attack? Do some traffic padding or traffic shaping
-schemes work better than others?</li>
-<li>A related question is: Does running a relay/bridge provide additional
-protection against these timing attacks? Can an external adversary that can't
-see inside TLS links still recognize individual streams reliably?
-Does the amount of traffic carried degrade this ability any? What if the
-client-relay deliberately delayed upstream relayed traffic to create a queue
-that could be used to mimic timings of client downstream traffic to make it
-look like it was also relayed? This same queue could also be used for masking
-timings in client upstream traffic with the techniques from <a
-href="http://www.freehaven.net/anonbib/#ShWa-Timing06";>adaptive padding</a>,
-but without the need for additional traffic. Would such an interleaving of
-client upstream traffic obscure timings for external adversaries? Would the
-strategies need to be adjusted for asymmetric links? For example, on
-asymmetric links, is it actually possible to differentiate client traffic from
-natural bursts due to their asymmetric capacity? Or is it easier than
-symmetric links for some other reason?</li>
-<li>Repeat Murdoch and Danezis's <a
-href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta";>attack from
-Oakland 05</a> on the current Tor network. See if you can learn why it
-works well on some nodes and not well on others. (My theory is that the
-fast nodes with spare capacity resist the attack better.) If that's true,
-then experiment with the RelayBandwidthRate and RelayBandwidthBurst
-options to run a relay that is used as a client while relaying the
-attacker's traffic: as we crank down the RelayBandwidthRate, does the
-attack get harder? What's the right ratio of RelayBandwidthRate to
-actually capacity? Or is it a ratio at all? While we're at it, does a
-much larger set of candidate relays increase the false positive rate
-or other complexity for the attack? (The Tor network is now almost two
-orders of magnitude larger than it was when they wrote their paper.) Be
-sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue";>Don't
-Clog the Queue</a> too.</li>
-<li>The "routing zones attack": most of the literature thinks of
-the network path between Alice and her entry node (and between the
-exit node and Bob) as a single link on some graph. In practice,
-though, the path traverses many autonomous systems (ASes), and <a
-href="http://freehaven.net/anonbib/#feamster:wpes2004";>it's not uncommon
-that the same AS appears on both the entry path and the exit path</a>.
-Unfortunately, to accurately predict whether a given Alice, entry,
-exit, Bob quad will be dangerous, we need to download an entire Internet
-routing zone and perform expensive operations on it. Are there practical
-approximations, such as avoiding IP addresses in the same /8 network?</li>
-<li>Other research questions regarding geographic diversity consider
-the tradeoff between choosing an efficient circuit and choosing a random
-circuit. Look at Stephen Rollyson's <a
-href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf";>position
-paper</a> on how to discard particularly slow choices without hurting
-anonymity "too much". This line of reasoning needs more work and more
-thinking, but it looks very promising.</li>
-<li>Tor doesn't work very well when relays have asymmetric bandwidth
-(e.g. cable or DSL). Because Tor has separate TCP connections between
-each hop, if the incoming bytes are arriving just fine and the outgoing
-bytes are all getting dropped on the floor, the TCP push-back mechanisms
-don't really transmit this information back to the incoming streams.
-Perhaps Tor should detect when it's dropping a lot of outgoing packets,
-and rate-limit incoming streams to regulate this itself? I can imagine
-a build-up and drop-off scheme where we pick a conservative rate-limit,
-slowly increase it until we get lost packets, back off, repeat. We
-need somebody who's good with networks to simulate this and help design
-solutions; and/or we need to understand the extent of the performance
-degradation, and use this as motivation to reconsider UDP transport.</li>
-<li>A related topic is congestion control. Is our
-current design sufficient once we have heavy use? Maybe
-we should experiment with variable-sized windows rather
-than fixed-size windows? That seemed to go well in an <a
-href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php";>ssh
-throughput experiment</a>. We'll need to measure and tweak, and maybe
-overhaul if the results are good.</li>
-<li>To let dissidents in remote countries use Tor without being blocked
-at their country's firewall, we need a way to get tens of thousands of
-relays, not just a few hundred. We can imagine a Tor client GUI that
-has a "Tor for Freedom" button at the top that opens a port and relays a
-few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
-much hassle, and there are few abuse issues since they're not being exit
-nodes.) But how do we distribute a list of these volunteer clients to the
-good dissidents in an automated way that doesn't let the country-level
-firewalls intercept and enumerate them? This probably needs to work on a
-human-trust level. See our <a href="<page documentation>#DesignDoc">early
-blocking-resistance design document</a> and our
-<a
-href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance";>FAQ
-entry</a> on this, and then read the <a
-href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship";>censorship
-resistance section of anonbib</a>.</li>
-<li>Our censorship-resistance goals include preventing
-an attacker who's looking at Tor traffic on the wire from <a
-href="https://www.torproject.org/svn/trunk/doc/design-paper/blocking.html#sec:network-fingerprint";>distinguishing
-it from normal SSL traffic</a>. Obviously we can't achieve perfect
-steganography and still remain usable, but for a first step we'd like to
-block any attacks that can win by observing only a few packets. One of
-the remaining attacks we haven't examined much is that Tor cells are 512
-bytes, so the traffic on the wire may well be a multiple of 512 bytes.
-How much does the batching and overhead in TLS records blur this on the
-wire? Do different buffer flushing strategies in Tor affect this? Could
-a bit of padding help a lot, or is this an attack we must accept?</li>
-<li>Tor circuits are built one hop at a time, so in theory we have the
-ability to make some streams exit from the second hop, some from the
-third, and so on. This seems nice because it breaks up the set of exiting
-streams that a given relay can see. But if we want each stream to be safe,
-the "shortest" path should be at least 3 hops long by our current logic, so
-the rest will be even longer. We need to examine this performance / security
-tradeoff.</li>
-<li>It's not that hard to DoS Tor relays or directory authorities. Are client
-puzzles the right answer? What other practical approaches are there? Bonus
-if they're backward-compatible with the current Tor protocol.</li>
-<li>Programs like <a
-href="https://torbutton.torproject.org/dev/";>Torbutton</a> aim to hide
-your browser's UserAgent string by replacing it with a uniform answer for
-every Tor user. That way the attacker can't splinter Tor's anonymity set
-by looking at that header. It tries to pick a string that is commonly used
-by non-Tor users too, so it doesn't stand out. Question one: how badly
-do we hurt ourselves by periodically updating the version of Firefox
-that Torbutton claims to be? If we update it too often, we splinter the
-anonymity sets ourselves. If we don't update it often enough, then all the
-Tor users stand out because they claim to be running a quite old version
-of Firefox. The answer here probably depends on the Firefox versions seen
-in the wild. Question two: periodically people ask us to cycle through N
-UserAgent strings rather than stick with one. Does this approach help,
-hurt, or not matter? Consider: cookies and recognizing Torbutton users
-by their rotating UserAgents; malicious websites who only attack certain
-browsers; and whether the answers to question one impact this answer.
-</li>
-</ol>
-
-<p>
-<a href="<page contact>">Let us know</a> if you've made progress on any
-of these!
-</p>
-
- </div><!-- #main -->
-
-#include <foot.wmi>
-
+## translation metadata
+# Based-On-Revision: 15123
+# Last-Translator: djhasis(at)gmail.com
+
+#include "head.wmi" TITLE="Tor: Auta" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<!-- PUT CONTENT AFTER THIS TAG -->
+<h2>A few things everyone can do now:</h2>
+<ol>
+<li>Please consider <a href="<page docs/tor-doc-relay>">running
+a relay</a> to help the Tor network grow.</li>
+<li>Tell your friends! Get them to run relays. Get them to run hidden
+services. Get them to tell their friends.</li>
+<li>If you like Tor's goals, please <a href="<page donate>">take a moment
+to donate to support further Tor development</a>. We're also looking
+for more sponsors — if you know any companies, NGOs, agencies,
+or other organizations that want anonymity / privacy / communications
+security, let them know about us.</li>
+<li>We're looking for more <a href="<page torusers>">good examples of Tor
+users and Tor use cases</a>. If you use Tor for a scenario or purpose not
+yet described on that page, and you're comfortable sharing it with us,
+we'd love to hear from you.</li>
+</ol>
+
+<a id="Usability"></a>
+<h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>
+<ol>
+<li>We need more good ways to intercept DNS requests so they don't "leak" their
+request to a local observer while we're trying to be anonymous. (This
+happens because the application does the DNS resolve before going to
+the SOCKS proxy.)</li>
+<li>Tsocks/dsocks items:
+<ul>
+<li>We need to <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches";>apply
+all our tsocks patches</a> and maintain a new fork. We'll host it if
+you want.</li>
+<li>We should patch Dug Song's "dsocks" program to use Tor's
+<i>mapaddress</i> commands from the controller interface, so we
+don't waste a whole round-trip inside Tor doing the resolve before
+connecting.</li>
+<li>We need to make our <i>torify</i> script detect which of tsocks or
+dsocks is installed, and call them appropriately. This probably means
+unifying their interfaces, and might involve sharing code between them
+or discarding one entirely.</li>
+</ul>
+</li>
+<li>People running relays tell us they want to have one BandwidthRate
+during some part of the day, and a different BandwidthRate at other
+parts of the day. Rather than coding this inside Tor, we should have a
+little script that speaks via the <a href="<page gui/index>">Tor
+Controller Interface</a>, and does a setconf to change the bandwidth
+rate. There is one for Unix and Mac already (it uses bash and cron),
+but Windows users still need a solution.
+</li>
+<li>Tor can <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit";>exit
+the Tor network from a particular exit node</a>, but we should be able
+to specify just a country and have something automatically pick. The
+best bet is to fetch Blossom's directory also, and run a local Blossom
+client that fetches this directory securely (via Tor and checking its
+signature), intercepts <tt>.country.blossom</tt> hostnames, and does
+the right thing.</li>
+<li>Speaking of geolocation data, somebody should draw a map of the Earth
+with a pin-point for each Tor relay. Bonus points if it updates as the
+network grows and changes. Unfortunately, the easy ways to do this involve
+sending all the data to Google and having them draw the map for you. How
+much does this impact privacy, and do we have any other good options?</li>
+</ol>
+
+<a id="Documentation"></a>
+<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
+<ol>
+<li>Please help Matt Edman with the documentation and how-tos for his
+Tor controller,
+<a href="http://vidalia-project.net/";>Vidalia</a>.</li>
+<li>Evaluate and document
+<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO";>our
+list of programs</a> that can be configured to use Tor.</li>
+<li>We need better documentation for dynamically intercepting
+connections and sending them through Tor. tsocks (Linux), dsocks (BSD),
+and freecap (Windows) seem to be good candidates, as would better
+use of our new TransPort feature.</li>
+<li>We have a huge list of <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms";>potentially useful
+programs that interface to Tor</a>. Which ones are useful in which
+situations? Please help us test them out and document your results.</li>
+<li>Help translate the web page and documentation into other
+languages. See the <a href="<page translation>">translation
+guidelines</a> if you want to help out. We especially need Arabic or
+Farsi translations, for the many Tor users in censored areas.</li>
+</ol>
+
+<a id="Coding"></a>
+<a id="Summer"></a>
+<a id="Projects"></a>
+<h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>
+
+<p>
+You may find some of these projects to be good <a href="<page
+gsoc>">Google Summer of Code 2008</a> ideas. We have labelled each idea
+with how useful it would be to the overall Tor project
+(priority), how much work we expect it would be (effort level), how much
+clue you should start with (skill level), and which of our <a href="<page
+people>#Core">core developers</a> would be good mentors. There are plenty
+of other good ideas to work on too — see for example the <a
+href="<svnsandbox>doc/spec/proposals/">current proposals</a> list, or
+just make up your own ideas.
+</p>
+
+<ol>
+
+<li>
+<b>Tor Exit Scanner improvements</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Mike</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>5</i>
+<br />
+The Tor exit node scanner 'SoaT', part of the <a
+href="<svnsandbox>torflow/">Torflow project</a>, makes connections out
+of each Tor exit node and compares the content it gets back with what it
+"should" get back. The goal is to notice misconfigured, broken, and even
+malicious exit relays. Alas, the code is
+currently written in rather rickety perl and relies on MD5sums of
+entire documents in order to determine if exit nodes are modifying
+content. The problem with this is threefold: 1) Perl sucks at life.
+2) The scanner can't verify pages that are dynamic, and attackers can
+focus malicious content injection on only those dynamic pages. 3)
+Pages change after a while (or based on GeoIP) and begin generating
+false positives.
+<br />
+Ideally, soat.pl would be reimplemented in a sane language with a
+robust html parser library (since the rest of Torflow is in Python
+that would be nice, but it is not required), and calculate signatures only for
+tags and content likely to be targeted by a malicious attacker (script
+tags, object links, images, css). It should also be robust in the face of
+changes to content outside of Tor, and ultimately even GeoIP localized
+content.
+<br />
+This scanner would likely be run by the Directory Authorities and
+report its results to the control port via the AuthDirBadExit config
+setting.
+<br />
+</li>
+
+<li>
+<b>Tor Node Scanner improvements</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>Medium to High</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Mike</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>1</i>
+<br />
+Similar to the exit scanner (or perhaps even during exit scanning),
+statistics can be gathered about the reliability of nodes. Nodes that
+fail too high a percentage of their circuits should not be given
+Guard status. Perhaps they should have their reported bandwidth
+penalized by some ratio as well, or just get marked as Invalid. In
+addition, nodes that exhibit a very low average stream capacity but
+advertise a very high node bandwidth can also be marked as Invalid.
+Much of this statistics gathering is already done, it just needs to be
+transformed into something that can be reported to the Directory
+Authorities to blacklist/penalize nodes in such a way that clients
+will listen.
+<br />
+In addition, these same statistics can be gathered about the traffic
+through a node. Events can be added to the <a
+href="https://www.torproject.org/svn/torctl/doc/howto.txt";>Tor Control
+Protocol</a> to
+report if a circuit extend attempt through the node succeeds or fails, and
+passive statistics can be gathered on both bandwidth and reliability
+of other nodes via a node-based monitor using these events. Such a
+scanner would also report information on oddly-behaving nodes to
+the Directory Authorities, but a communication channel for this
+currently does not exist and would need to be developed as well.
+</li>
+
+<li>
+<b>Help track the overall Tor Network status</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Roger, Nick, Mike</i>
+<br />
+It would be great to set up an automated system for tracking network
+health over time, graphing it, etc. Part of this project would involve
+inventing better metrics for assessing network health and growth. Is the
+average uptime of the network increasing? How many relays are qualifying
+for Guard status this month compared to last month? What's the turnover
+in terms of new relays showing up and relays shutting off? Periodically
+people collect brief snapshots, but where it gets really interesting is
+when we start tracking data points over time.
+<br />
+Data could be collected from the "Tor Node Scanner" item above, from
+the server descriptors that each relay publishes, and from other
+sources. Results over time could be integrated into one of the <a
+href="https://torstatus.blutmagie.de/";>Tor Status</a> web pages, or be
+kept separate. Speaking of the Tor Status pages, take a look at Roger's
+<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html";>Tor
+Status wish list</a>.
+</li>
+
+<li>
+<b>Tor path selection improvements</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>Low to Medium</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Roger, Nick, Mike</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>3</i>
+<br />
+Some simple improvements can be made to Tor's path selection to vastly
+improve Tor speed. For instance, some of the (unofficial) <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf";>Tor
+Performance Recommendations</a> on the wiki are to increase the number of
+guards and decrease the CircuitBuildTimeout. Ideally, the client would
+<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html";>learn
+these values by gathering statistics on circuit construction
+time</a> (and/or using values gained from Torflow), and set the timeouts
+low enough such that some high percentile (75%, 90%, 1-stddev?) of
+circuits succeed, yet extremely slow nodes are avoided. This would
+involve some statistics gathering+basic research, and some changes to
+Tor path selection code.
+<br />
+In addition, to improve path security, some elements from the <a
+href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt";>Two
+Hop Paths proposal</a> could be done as part of this (since it will
+likely touch the same code anyways), regardless of the adoption of
+that proposal. In particular, clients probably should avoid guards that
+seem to fail an excessive percentage of their circuits through them,
+and non-firewalled clients should issue a warning if they are only able
+to connect to a limited set of guard nodes. See also
+<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html";>this
+or-dev post</a>.
+</li>
+
+<li>
+<b>Translation Wiki</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Jacob</i>
+<br />
+We need a way to edit and translate sections of the website. Currently
+the website is made up of a bunch of <a href="<svnwebsite>en/">wml
+files</a>, and <a href="<page translation>">translators</a> fetch these
+wml files, translate them in an editor, and either send us the translation
+or use svn to commit them back. The current "cost" of publication of
+website changes is quite high even for English language users. For a
+single word change or any type of
+minor change, the page may never be corrected or translated. It would
+be nice to have a wiki that was specifically geared towards translation
+and would somehow track the upstream (English) versions to indicate when
+a fresh translation is needed, like our current
+<a href="<page translation-status>">translation status page</a>. This
+seems mostly like a job for a wiki
+integrator or wiki software author. Certainly the person would need to
+be interested in human languages and translation. They should at least
+be minimally familiar with what Tor is; but they would not have to interact
+with the software, only the documentation and the website.
+</li>
+
+<li>
+<b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Peter, Matt</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>1</i>
+<br />
+Vidalia currently doesn't play nicely on Debian and Ubuntu with the
+default Tor packages. The current Tor packages automatically start Tor
+as a daemon running as the debian-tor user and (sensibly) do not have a
+<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
+in the default torrc. Consequently, Vidalia will try
+to start its own Tor process since it could not connect to the existing
+Tor, and Vidalia's Tor process will then exit with an error message
+the user likely doesn't understand since Tor cannot bind its listening
+ports — they're already in use by the original Tor daemon.
+<br />
+The current solution involves either telling the user to stop the
+existing Tor daemon and let Vidalia start its own Tor process, or
+explaining to the user how to set a control port and password in their
+torrc. A better solution on Debian would be to use Tor's ControlSocket,
+which allows Vidalia to talk to Tor via a Unix domain socket, and could
+possibly be enabled by default in Tor's Debian packages. Vidalia can
+then authenticate to Tor using filesystem-based (cookie) authentication
+if the user running Vidalia is also in the debian-tor group.
+<br />
+This project will first involve adding support for Tor's ControlSocket
+to Vidalia. The student will then develop and test Debian and Ubuntu
+packages for Vidalia that conform to Debian's packaging standards and
+make sure they work well with the existing Tor packages. We can also
+set up an apt repository to host the new Vidalia packages.
+<br />
+The next challenge would be to find an intuitive usable way for Vidalia
+to be able to change Tor's configuration (torrc) even though it is
+located in <code>/etc/tor/torrc</code> and thus immutable. The best
+idea we've come up with so far is to feed Tor a new configuration via
+the ControlSocket when Vidalia starts, but that's bad because Tor starts
+each boot with a different configuration than the user wants. The second
+best idea
+we've come up with is for Vidalia to write out a temporary torrc file
+and ask the user to manually move it to <code>/etc/tor/torrc</code>,
+but that's bad because users shouldn't have to mess with files directly.
+<br />
+A student undertaking this project should have prior knowledge of
+Debian package management and some C++ development experience. Previous
+experience with Qt is helpful, but not required.
+</li>
+
+<li>
+<b>Improving Tor's ability to resist censorship</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Nick</i>
+<br />
+The Tor 0.2.0.x series makes <a
+href="<svnsandbox>doc/design-paper/blocking.html">significant
+improvements</a> in resisting national and organizational censorship.
+But Tor still needs better mechanisms for some parts of its
+anti-censorship design. For example, current Tors can only listen on a
+single address/port combination at a time. There's
+<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
+proposal to address this limitation</a> and allow clients to connect
+to any given Tor on multiple addresses and ports, but it needs more
+work. Another anti-censorship project (far more difficult) is to try
+to make Tor more scanning-resistant. Right now, an adversary can identify
+<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
+just by trying to connect to them, following the Tor protocol, and
+seeing if they respond. To solve this, bridges could
+<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
+webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
+and not act like bridges until the user provides a bridge-specific key.
+<br />
+This project involves a lot of research and design. One of the big
+challenges will be identifying and crafting approaches that can still
+resist an adversary even after the adversary knows the design, and
+then trading off censorship resistance with usability and robustness.
+</li>
+
+<li>
+<b>Tor/Polipo/Vidalia Auto-Update Framework</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Matt, Jacob</i>
+<br />
+We're in need of a good authenticated-update framework.
+Vidalia already has the ability to notice when the user is running an
+outdated or unrecommended version of Tor, using signed statements inside
+the Tor directory information. Currently, Vidalia simply pops
+up a little message box that lets the user know they should manually
+upgrade. The goal of this project would be to extend Vidalia with the
+ability to also fetch and install the updated Tor software for the
+user. We should do the fetches via Tor when possible, but also fall back
+to direct fetches in a smart way. Time permitting, we would also like
+to be able to update other
+applications included in the bundled installers, such as Polipo and
+Vidalia itself.
+<br />
+To complete this project, the student will first need to first investigate
+the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
+their strengths, weaknesses, security properties, and ability to be
+integrated into Vidalia. If none are found to be suitable, the student
+will design their own auto-update framework, document the design, and
+then discuss the design with other developers to assess any security
+issues. The student will then implement their framework (or integrate
+an existing one) and test it.
+<br />
+A student undertaking this project should have good C++ development
+experience. Previous experience with Qt is helpful, but not required. The
+student should also have a good understanding of common security
+practices, such as package signature verification. Good writing ability
+is also important for this project, since a vital step of the project
+will be producing a design document for others to review and discuss
+with the student prior to implementation.
+</li>
+
+<li>
+<b>An Improved and More Usable Network Map in Vidalia</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Matt</i>
+<br />
+One of Vidalia's existing features is a network map that shows the user
+the approximate geographic location of relays in the Tor network and
+plots the paths the user's traffic takes as it is tunneled through the
+Tor network. The map is currently not very interactive and has rather
+poor graphics. Instead, we would like to leverage KDE's Marble widget
+that gives us a better quality map and enables improved interactivity,
+such as allowing the user to click on individual relays or circuits to
+display additional information. We might also consider adding the ability
+for users to click on a particular relay or a country containing one or
+more Tor exit relays and say, "I want my connections to foo.com to exit
+from here."
+<br />
+This project will first involve the student getting familiar with Vidalia
+and the Marble widget's API. The student will then integrate the widget
+into Vidalia and customize Marble to be better suited for our application,
+such as making circuits clickable, storing cached map data in Vidalia's
+own data directory, and customizing some of the widget's dialogs.
+<br />
+A student undertaking this project should have good C++ development
+experience. Previous experience with Qt and CMake is helpful, but not
+required.
+</li>
+
+<li>
+<b>Tor Controller Status Event Interface</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Matt, Roger</i>
+<br />
+There are a number of status changes inside Tor of which the user may need
+to be informed. For example, if the user is trying to set up his Tor as a
+relay and Tor decides that its ports are not reachable from outside
+the user's network, we should alert the user. Currently, all the user
+gets is a couple log messages in Vidalia's 'message log' window, which they
+likely never see since they don't receive a notification that something
+has gone wrong. Even if the user does actually look at the message log,
+most of the messages make little sense to the novice user.
+<br />
+Tor has the ability to inform Vidalia of many such status changes, and
+we recently implemented support for a couple of these events. Still,
+there are many more status events the user should be informed of and we
+need a better UI for actually displaying them to the user.
+<br />
+The goal of this project then is to design and implement a UI for
+displaying Tor status events to the user. For example, we might put a
+little badge on Vidalia's tray icon that alerts the user to new status
+events they should look at. Double-clicking the icon could bring up a
+dialog that summarizes recent status events in simple terms and maybe
+suggests a remedy for any negative events if they can be corrected by
+the user. Of course, this is just an example and the student is free to
+suggest another approach.
+<br />
+A student undertaking this project should have good UI design and layout
+and some C++ development experience. Previous experience with Qt and
+Qt's Designer will be very helpful, but are not required. Some
+English writing ability will also be useful, since this project will
+likely involve writing small amounts of help documentation that should
+be understandable by non-technical users. Bonus points for some graphic
+design/Photoshop fu, since we might want/need some shiny new icons too.
+</li>
+
+<li>
+<b>Improvements on our active browser configuration tester</b> -
+<a href="https://check.torproject.org/";>https://check.torproject.org/</a>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Low</i>
+<br />
+Skill Level: <i>Low to Medium</i>
+<br />
+Likely Mentors: <i>Jacob, Steven</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>1</i>
+<br />
+We currently have a functional web page to detect if Tor is working. It
+has a few places where it falls short. It requires improvements with
+regard to default languages and functionality. It currently only responds
+in English. In addition, it is a hack of a perl script that should have
+never seen the light of day. It should probably be rewritten in python
+with multi-lingual support in mind. It currently uses the <a
+href="http://exitlist.torproject.org/";>Tor DNS exit list</a>
+and should continue to do so in the future. It currently result in certain
+false positives and these should be discovered, documented, and fixed
+where possible. Anyone working on this project should be interested in
+DNS, basic perl or preferably python programming skills, and will have
+to interact minimally with Tor to test their code.
+<br />
+If you want to make the project more exciting
+and involve more design and coding, take a look at <a
+href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
+131-verify-tor-usage.txt</a>.
+</li>
+
+<li>
+<b>Improvements on our DNS Exit List service</b> -
+<a href="http://exitlist.torproject.org/";>http://exitlist.torproject.org/</a>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Low</i>
+<br />
+Skill Level: <i>Low</i>
+<br />
+Likely Mentors: <i>Jacob, Tup</i>
+<br />
+The <a href="http://p56soo2ibjkx23xo.onion/";>exitlist software</a>
+is written by our fabulous anonymous
+contributer Tup. It's a DNS server written in Haskell that supports part of our <a
+href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt";>exitlist
+design document</a>. Currently, it is functional and it is used by
+check.torproject.org and other users. The issues that are outstanding
+are mostly aesthetic. This wonderful service could use a much better
+website using the common Tor theme. It would be best served with better
+documentation for common services that use an RBL. It could use more
+publicity. A person working on this project should be interested in DNS,
+basic RBL configuration for popular services, and writing documentation.
+The person would require minimal Tor interaction — testing their
+own documentation at the very least. Furthermore, it would be useful
+if they were interested in Haskell and wanted to implement more of the
+torel-design.txt suggestions.
+</li>
+
+<li>
+<b>Testing integration of Tor with web browsers for our end users</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Jacob, Mike, Greg</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>1</i>
+<br />
+The Tor project currently lacks a solid test suite to ensure that a
+user has a properly and safely configured web browser. It should test for as
+many known issues as possible. It should attempt to decloak the
+user in any way possible. Two current webpages that track these
+kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
+href="http://pseudo-flaw.net/tor/torbutton/";>list of issues along
+with their proof of concept code, bug issues, etc</a>. HD Moore runs
+the <a href="http://metasploit.com/research/projects/decloak/";>metasploit
+decloak website</a>. A student interested in defending Tor could start
+by collecting as many workable and known methods for decloaking a
+Tor user. (<a href="https://torcheck.xenobite.eu/";>This page</a> may
+be helpful as a start.) The student should be familiar with the common
+pitfalls but
+possibly have new methods in mind for implementing decloaking issues. The
+website should ensure that it tells a user what their problem is. It
+should help them to fix the problem or direct them to the proper support
+channels. The student should be closely familiar with using Tor and how
+to prevent Tor information leakage.
+</li>
+
+<li>
+<b>Libevent and Tor integration improvements</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Nick</i>
+<br />
+Tor should make better use of the more recent features of Niels
+Provos's <a href="http://monkey.org/~provos/libevent/";>Libevent</a>
+library. Tor already uses Libevent for its low-level asynchronous IO
+calls, and could also use Libevent's increasingly good implementations
+of network buffers and of HTTP. This wouldn't be simply a matter of
+replacing Tor's internal calls with calls to Libevent: instead, we'll
+need to refactor Tor to use Libevent calls that do not follow the
+same models as Tor's existing backends. Also, we'll need to add
+missing functionality to Libevent as needed — most difficult likely
+will be adding OpenSSL support on top of Libevent's buffer abstraction.
+Also tricky will be adding rate-limiting to Libevent.
+</li>
+
+<li>
+<b>Tuneup Tor!</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Nick, Roger, Mike</i>
+<br />
+Right now, Tor relays measure and report their own bandwidth, and Tor
+clients choose which relays to use in part based on that bandwidth.
+This approach is vulnerable to
+<a href="http://freehaven.net/anonbib/#bauer:wpes2007";>attacks where
+relays lie about their bandwidth</a>;
+to address this, Tor currently caps the maximum bandwidth
+it's willing to believe any relay provides. This is a limited fix, and
+a waste of bandwidth capacity to boot. Instead,
+Tor should possibly measure bandwidth in a more distributed way, perhaps
+as described in the
+<a href="http://freehaven.net/anonbib/author.html#snader08";>"A Tune-up for
+Tor"</a> paper
+by Snader and Borisov. A student could use current testing code to
+double-check this paper's findings and verify the extent to which they
+dovetail with Tor as deployed in the wild, and determine good ways to
+incorporate them into their suggestions Tor network without adding too
+much communications overhead between relays and directory
+authorities.
+</li>
+
+<!--
+<li>
+<b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
+<br />
+Priority: <i>High</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Jacob, Andrew</i>
+<br />
+It would be useful to have automated build processes for Windows and
+probably other platforms. The purpose of having a continuous integration
+build environment is to ensure that Windows isn't left behind for any of
+the software projects used in the Tor project or its accompanying.<br />
+Buildbot may be a good choice for this as it appears to support all of
+the platforms Tor does. See the
+<a href="http://en.wikipedia.org/wiki/BuildBot";>wikipedia entry for
+buildbot</a>.<br />
+There may be better options and the person undertaking this task should
+evaluate other options. Any person working on this automatic build
+process should have experience or be willing to learn how to build all
+of the respective Tor related code bases from scratch. Furthermore, the
+person should have some experience building software in Windows
+environments as this is the target audience we want to ensure we do not
+leave behind. It would require close work with the Tor source code but
+probably only in the form of building, not authoring.<br />
+Additionally, we need to automate our performance testing for all platforms.
+We've got buildbot (except on Windows — as noted above) to automate
+our regular integration and compile testing already,
+but we need to get our network simulation tests (as built in torflow)
+updated for more recent versions of Tor, and designed to launch a test
+network either on a single machine, or across several, so we can test
+changes in performance on machines in different roles automatically.
+</li>
+-->
+
+<li>
+<b>Improve our unit testing process</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Nick</i>
+<br />
+Tor needs to be far more tested. This is a multi-part effort. To start
+with, our unit test coverage should rise substantially, especially in
+the areas outside the utility functions. This will require significant
+refactoring of some parts of Tor, in order to dissociate as much logic
+as possible from globals.
+<br />
+Additionally, we need to automate our performance testing. We've got
+buildbot to automate our regular integration and compile testing already
+(though we need somebody to set it up on Windows),
+but we need to get our network simulation tests (as built in TorFlow: see
+the "Tor Node Scanner improvements" item)
+updated for more recent versions of Tor, and designed to launch a test
+network either on a single machine, or across several, so we can test
+changes in performance on machines in different roles automatically.
+</li>
+
+<li>
+<b>Help revive an independent Tor client implementation</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Karsten, Nick</i>
+<br />
+Applications as of 1 Apr 00::00 UTC: <i>4</i>
+<br />
+Reanimate one of the approaches to implement a Tor client in Java,
+e.g. the <a href="http://onioncoffee.sourceforge.net/";>OnionCoffee
+project</a>, and make it run on <a
+href="http://code.google.com/android/";>Android</a>. The first step
+would be to port the existing code and execute it in an Android
+environment. Next, the code should be updated to support the newer Tor
+protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
+directory protocol</a>. Further, support for requesting or even
+providing Tor hidden services would be neat, but not required.
+<br />
+The student should be able to understand and write new Java code, including
+a Java cryptography API. Being able to read C code would be helpful,
+too. The student should be willing to read the existing documentation,
+implement code based on it, and refine the documentation
+when things are underdocumented. This project is mostly about coding and
+to a small degree about design.
+</li>
+
+<li>
+<b>Automatic system tests and automatically starting private Tor networks</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Karsten, Nick, Roger</i>
+<br />
+Applications as of 1 Apr 00:00 UTC: <i>2</i>
+<br />
+Write a tool that runs automatic system tests in addition
+to the existing unit tests. The Java-based Tor simulator <a
+href="https://svn.torproject.org/svn/puppetor/trunk/";>PuppeTor</a>
+might be a good start for starting up a private Tor network, using it
+for a while, and verifying that at least parts of it are working. This
+project requires to conceive a blueprint for performing system tests
+of private Tor networks, before starting to code. Typical types of
+tests range from performing single requests over the private network to
+manipulating exchanged messages and see if nodes handle corrupt messages
+appropriately.
+<br />
+The student should be able to obtain a good understanding
+of how Tor works and what problems and bugs could arise to design good
+test cases. Understanding the existing Tor code structure and documentation is
+vital. If PuppeTor is used, the student should also be able to understand
+and possibly extend an existing Java application. This project is partly
+about design and partly about coding.
+</li>
+
+<li>
+<b>Bring moniTor to life</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Low to Medium</i>
+<br />
+Likely Mentors: <i>Karsten, Jacob</i>
+<br />
+Applications as of 1 Apr 00::00 UTC: <i>2</i>
+<br />
+Implement a <a href="http://www.ss64.com/bash/top.html";>top-like</a>
+management tool for Tor relays. The purpose of such a tool would be
+to monitor a local Tor relay via its control port and include useful
+system information of the underlying machine. When running this tool, it
+would dynamically update its content like top does for Linux processes.
+<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html";>This
+or-dev post</a> might be a good first read.
+<br />
+The student should be familiar
+with or willing to learn about administering a Tor relay and configuring
+it via its control port. As an initial prototype is written in Python,
+some knowledge about writing Python code would be helpful, too. This
+project is one part about identifying requirements to such a
+tool and designing its interface, and one part lots of coding.
+</li>
+
+<li>
+<b>Torbutton improvements</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Mike</i>
+<br/>
+Torbutton has a number of improvements that can be made in the post-1.2
+timeframe. Most of these are documented as feature requests in the <a
+href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5";>Torbutton
+flyspray section</a>. Good examples include: stripping off node.exit on http
+headers, more fine-grained control over formfill blocking, improved referrer
+spoofing based on the domain of the site (a-la <a
+href="https://addons.mozilla.org/en-US/firefox/addon/953";>refcontrol extension</a>),
+tighter integration with Vidalia for reporting Tor status, a New Identity
+button with Tor integration and multiple identity management, and anything
+else you might think of.
+<br />
+This work would be independent coding in Javascript and the fun world of <a
+href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";>XUL</a>,
+with not too much involvement in the Tor internals.
+</li>
+
+<li>
+<b>Porting Polipo to Windows</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Andrew, Steven, Roger</i>
+<br />
+Help port <a
+href="http://www.pps.jussieu.fr/~jch/software/polipo/";>Polipo</a> to
+Windows. Example topics to tackle include:
+1) handle spaces in path names and understand the filesystem
+namespace — that is, where application data, personal data,
+and program data typically reside in various versions of Windows. 2) the
+ability to handle ipv6 communications. 3) the ability to asynchronously
+query name servers, find the system nameservers, and manage netbios
+and dns queries. 4) use native regex capabilities of Windows, rather
+than using 3rd party GNU regex libraries. 5) manage events and buffers
+natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
+Windows it's whatever the config specifies). 6) some sort of GUI config
+and reporting tool, bonus if it has a systray icon with right clickable
+menu options. Double bonus if it's cross-platform compatible.
+</li>
+
+<li>
+<b>Make our diagrams beautiful and automated</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Low</i>
+<br />
+Skill Level: <i>Low</i>
+<br />
+Likely Mentors: <i>Andrew</i>
+<br />
+We need a way to generate the website diagrams (for example, the "How
+Tor Works" pictures on the <a href="<page overview>">overview page</a>
+from source, so we can translate them as UTF-8 text rather than edit
+them by hand with Gimp. We might want to
+integrate this as an wml file so translations are easy and images are
+generated in multiple languages whenever we build the website. See the
+"Translation Wiki" idea above.
+</li>
+
+<li>
+<b>Improve the LiveCD offerings for the Tor community</b>
+<br />
+Priority: <i>Low</i>
+<br />
+Effort Level: <i>Low</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Anonym, Jacob, Roger</i>
+<br />
+How can we make the <a
+href="http://anonymityanywhere.com/incognito/";>Incognito LiveCD</a>
+easier to maintain, improve, and document?
+</li>
+
+<li>
+<b>Rework and extend Blossom</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium to High</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Goodell</i>
+<br />
+Rework and extend Blossom (a tool for monitoring and
+selecting appropriate Tor circuits based upon exit node requirements
+specified by the user) to gather data in a self-contained way, with
+parameters easily configurable by the user. Blossom is presently
+implemented as a single Python script that interfaces with Tor using the
+Controller interface and depends upon metadata about Tor nodes obtained
+via external processes, such as a webpage indicating status of the nodes
+plus publically available data from DNS, whois, etc. This project has
+two parts: (1) Determine which additional metadata may be useful and
+rework Blossom so that it cleanly obtains the metadata on its own rather
+than depend upon external scripts (this may, for example, involve
+additional threads or inter-process communication), and (2) develop a
+means by which the user can easily configure Blossom, starting with a
+configuration file and possibly working up to a web configuration engine.
+Knowledge of Tor and Python are important; knowledge of
+TCP, interprocess communication, and Perl will also be helpful. An
+interest in network neutrality is important as well, since the
+principles of evaluating and understanding internet inconsistency are at
+the core of the Blossom effort.
+</li>
+
+<li>
+<b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
+<br />
+Priority: <i>Low</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Goodell</i>
+<br />
+Develop and implement a means of affording Blossom
+users the ability to qualitatively describe the exit node that they
+want. The Internet is an inconsistent place: some Tor exit nodes see
+the world differently than others. As presently implemented, Blossom (a
+tool for monitoring and selecting appropriate Tor circuits based upon
+exit node requirements specified by the user) lacks a sufficiently rich
+language to describe how the different vantage points are different.
+For example, some exit nodes may have an upstream network that filters
+certain kinds of traffic or certain websites. Other exit nodes may
+provide access to special content as a result of their location, perhaps
+as a result of discrimination on the part of the content providers
+themselves. This project has two parts: (1) develop a language for
+describing characteristics of networks in which exit nodes reside, and
+(2) incorporate this language into Blossom so that users can select Tor
+paths based upon the description.
+Knowledge of Tor and Python are important; knowledge of
+TCP, interprocess communication, and Perl will also be helpful. An
+interest in network neutrality is important as well, since the
+principles of evaluating and understanding internet inconsistency are at
+the core of the Blossom effort.
+</li>
+
+<li>
+<b>Bring up new ideas!</b>
+<br />
+Don't like any of these? Look at the <a
+href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
+roadmap</a> for more ideas.
+</li>
+
+</ol>
+
+<h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
+<ol>
+<li>Tor relays don't work well on Windows XP. On
+Windows, Tor uses the standard <tt>select()</tt> system
+call, which uses space in the non-page pool. This means
+that a medium sized Tor relay will empty the non-page pool, <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems";>causing
+havoc and system crashes</a>. We should probably be using overlapped IO
+instead. One solution would be to teach <a
+href="http://www.monkey.org/~provos/libevent/";>libevent</a> how to use
+overlapped IO rather than select() on Windows, and then adapt Tor to
+the new libevent interface. Christian King made a
+<a href="https://svn.torproject.org/svn/libevent-urz/trunk/";>good
+start</a> on this in the summer of 2007.</li>
+<li>We need to actually start building our <a href="<page
+documentation>#DesignDoc">blocking-resistance design</a>. This involves
+fleshing out the design, modifying many different pieces of Tor, adapting
+<a href="http://vidalia-project.net/";>Vidalia</a> so it supports the
+new features, and planning for deployment.</li>
+<li>We need a flexible simulator framework for studying end-to-end
+traffic confirmation attacks. Many researchers have whipped up ad hoc
+simulators to support their intuition either that the attacks work
+really well or that some defense works great. Can we build a simulator
+that's clearly documented and open enough that everybody knows it's
+giving a reasonable answer? This will spur a lot of new research.
+See the entry <a href="#Research">below</a> on confirmation attacks for
+details on the research side of this task — who knows, when it's
+done maybe you can help write a paper or three also.</li>
+<li>Tor 0.1.1.x and later include support for hardware crypto accelerators
+via OpenSSL. Nobody has ever tested it, though. Does somebody want to get
+a card and let us know how it goes?</li>
+<li>Perform a security analysis of Tor with <a
+href="http://en.wikipedia.org/wiki/Fuzz_testing";>"fuzz"</a>. Determine
+if there are good fuzzing libraries out there for what we want. Win fame by
+getting credit when we put out a new release because of you!</li>
+<li>Tor uses TCP for transport and TLS for link
+encryption. This is nice and simple, but it means all cells
+on a link are delayed when a single packet gets dropped, and
+it means we can only reasonably support TCP streams. We have a <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP";>list
+of reasons why we haven't shifted to UDP transport</a>, but it would
+be great to see that list get shorter. We also have a proposed <a
+href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specification
+for Tor and
+UDP</a> — please let us know what's wrong with it.</li>
+<li>We're not that far from having IPv6 support for destination addresses
+(at exit nodes). If you care strongly about IPv6, that's probably the
+first place to start.</li>
+</ol>
+
+<a id="Research"></a>
+<h2><a class="anchor" href="#Research">Research</a></h2>
+<ol>
+<li>The "website fingerprinting attack": make a list of a few
+hundred popular websites, download their pages, and make a set of
+"signatures" for each site. Then observe a Tor client's traffic. As
+you watch him receive data, you quickly approach a guess about which
+(if any) of those sites he is visiting. First, how effective is
+this attack on the deployed Tor codebase? Then start exploring
+defenses: for example, we could change Tor's cell size from 512
+bytes to 1024 bytes, we could employ padding techniques like <a
+href="http://freehaven.net/anonbib/#timing-fc2004";>defensive dropping</a>,
+or we could add traffic delays. How much of an impact do these have,
+and how much usability impact (using some suitable metric) is there from
+a successful defense in each case?</li>
+<li>The "end-to-end traffic confirmation attack":
+by watching traffic at Alice and at Bob, we can <a
+href="http://freehaven.net/anonbib/#danezis:pet2004";>compare
+traffic signatures and become convinced that we're watching the same
+stream</a>. So far Tor accepts this as a fact of life and assumes this
+attack is trivial in all cases. First of all, is that actually true? How
+much traffic of what sort of distribution is needed before the adversary
+is confident he has won? Are there scenarios (e.g. not transmitting much)
+that slow down the attack? Do some traffic padding or traffic shaping
+schemes work better than others?</li>
+<li>A related question is: Does running a relay/bridge provide additional
+protection against these timing attacks? Can an external adversary that can't
+see inside TLS links still recognize individual streams reliably?
+Does the amount of traffic carried degrade this ability any? What if the
+client-relay deliberately delayed upstream relayed traffic to create a queue
+that could be used to mimic timings of client downstream traffic to make it
+look like it was also relayed? This same queue could also be used for masking
+timings in client upstream traffic with the techniques from <a
+href="http://www.freehaven.net/anonbib/#ShWa-Timing06";>adaptive padding</a>,
+but without the need for additional traffic. Would such an interleaving of
+client upstream traffic obscure timings for external adversaries? Would the
+strategies need to be adjusted for asymmetric links? For example, on
+asymmetric links, is it actually possible to differentiate client traffic from
+natural bursts due to their asymmetric capacity? Or is it easier than
+symmetric links for some other reason?</li>
+<li>Repeat Murdoch and Danezis's <a
+href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta";>attack from
+Oakland 05</a> on the current Tor network. See if you can learn why it
+works well on some nodes and not well on others. (My theory is that the
+fast nodes with spare capacity resist the attack better.) If that's true,
+then experiment with the RelayBandwidthRate and RelayBandwidthBurst
+options to run a relay that is used as a client while relaying the
+attacker's traffic: as we crank down the RelayBandwidthRate, does the
+attack get harder? What's the right ratio of RelayBandwidthRate to
+actually capacity? Or is it a ratio at all? While we're at it, does a
+much larger set of candidate relays increase the false positive rate
+or other complexity for the attack? (The Tor network is now almost two
+orders of magnitude larger than it was when they wrote their paper.) Be
+sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue";>Don't
+Clog the Queue</a> too.</li>
+<li>The "routing zones attack": most of the literature thinks of
+the network path between Alice and her entry node (and between the
+exit node and Bob) as a single link on some graph. In practice,
+though, the path traverses many autonomous systems (ASes), and <a
+href="http://freehaven.net/anonbib/#feamster:wpes2004";>it's not uncommon
+that the same AS appears on both the entry path and the exit path</a>.
+Unfortunately, to accurately predict whether a given Alice, entry,
+exit, Bob quad will be dangerous, we need to download an entire Internet
+routing zone and perform expensive operations on it. Are there practical
+approximations, such as avoiding IP addresses in the same /8 network?</li>
+<li>Other research questions regarding geographic diversity consider
+the tradeoff between choosing an efficient circuit and choosing a random
+circuit. Look at Stephen Rollyson's <a
+href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf";>position
+paper</a> on how to discard particularly slow choices without hurting
+anonymity "too much". This line of reasoning needs more work and more
+thinking, but it looks very promising.</li>
+<li>Tor doesn't work very well when relays have asymmetric bandwidth
+(e.g. cable or DSL). Because Tor has separate TCP connections between
+each hop, if the incoming bytes are arriving just fine and the outgoing
+bytes are all getting dropped on the floor, the TCP push-back mechanisms
+don't really transmit this information back to the incoming streams.
+Perhaps Tor should detect when it's dropping a lot of outgoing packets,
+and rate-limit incoming streams to regulate this itself? I can imagine
+a build-up and drop-off scheme where we pick a conservative rate-limit,
+slowly increase it until we get lost packets, back off, repeat. We
+need somebody who's good with networks to simulate this and help design
+solutions; and/or we need to understand the extent of the performance
+degradation, and use this as motivation to reconsider UDP transport.</li>
+<li>A related topic is congestion control. Is our
+current design sufficient once we have heavy use? Maybe
+we should experiment with variable-sized windows rather
+than fixed-size windows? That seemed to go well in an <a
+href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php";>ssh
+throughput experiment</a>. We'll need to measure and tweak, and maybe
+overhaul if the results are good.</li>
+<li>To let dissidents in remote countries use Tor without being blocked
+at their country's firewall, we need a way to get tens of thousands of
+relays, not just a few hundred. We can imagine a Tor client GUI that
+has a "Tor for Freedom" button at the top that opens a port and relays a
+few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
+much hassle, and there are few abuse issues since they're not being exit
+nodes.) But how do we distribute a list of these volunteer clients to the
+good dissidents in an automated way that doesn't let the country-level
+firewalls intercept and enumerate them? This probably needs to work on a
+human-trust level. See our <a href="<page documentation>#DesignDoc">early
+blocking-resistance design document</a> and our
+<a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance";>FAQ
+entry</a> on this, and then read the <a
+href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship";>censorship
+resistance section of anonbib</a>.</li>
+<li>Our censorship-resistance goals include preventing
+an attacker who's looking at Tor traffic on the wire from <a
+href="https://www.torproject.org/svn/trunk/doc/design-paper/blocking.html#sec:network-fingerprint";>distinguishing
+it from normal SSL traffic</a>. Obviously we can't achieve perfect
+steganography and still remain usable, but for a first step we'd like to
+block any attacks that can win by observing only a few packets. One of
+the remaining attacks we haven't examined much is that Tor cells are 512
+bytes, so the traffic on the wire may well be a multiple of 512 bytes.
+How much does the batching and overhead in TLS records blur this on the
+wire? Do different buffer flushing strategies in Tor affect this? Could
+a bit of padding help a lot, or is this an attack we must accept?</li>
+<li>Tor circuits are built one hop at a time, so in theory we have the
+ability to make some streams exit from the second hop, some from the
+third, and so on. This seems nice because it breaks up the set of exiting
+streams that a given relay can see. But if we want each stream to be safe,
+the "shortest" path should be at least 3 hops long by our current logic, so
+the rest will be even longer. We need to examine this performance / security
+tradeoff.</li>
+<li>It's not that hard to DoS Tor relays or directory authorities. Are client
+puzzles the right answer? What other practical approaches are there? Bonus
+if they're backward-compatible with the current Tor protocol.</li>
+<li>Programs like <a
+href="https://torbutton.torproject.org/dev/";>Torbutton</a> aim to hide
+your browser's UserAgent string by replacing it with a uniform answer for
+every Tor user. That way the attacker can't splinter Tor's anonymity set
+by looking at that header. It tries to pick a string that is commonly used
+by non-Tor users too, so it doesn't stand out. Question one: how badly
+do we hurt ourselves by periodically updating the version of Firefox
+that Torbutton claims to be? If we update it too often, we splinter the
+anonymity sets ourselves. If we don't update it often enough, then all the
+Tor users stand out because they claim to be running a quite old version
+of Firefox. The answer here probably depends on the Firefox versions seen
+in the wild. Question two: periodically people ask us to cycle through N
+UserAgent strings rather than stick with one. Does this approach help,
+hurt, or not matter? Consider: cookies and recognizing Torbutton users
+by their rotating UserAgents; malicious websites who only attack certain
+browsers; and whether the answers to question one impact this answer.
+</li>
+</ol>
+
+<p>
+<a href="<page contact>">Let us know</a> if you've made progress on any
+of these!
+</p>
+
+ </div><!-- #main -->
+
+#include <foot.wmi>
+
Property changes on: website/trunk/fi/volunteer.wml
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native