[or-cvs] r8817: almost completed ru/volunteer.wml (in website/trunk: docs/ru ru)

Tue Oct 24 18:54:38 UTC 2006

Author: ygrek
Date: 2006-10-24 14:54:33 -0400 (Tue, 24 Oct 2006)
New Revision: 8817

Modified:
   website/trunk/docs/ru/tor-doc-win32.wml
   website/trunk/ru/volunteer.wml
Log:
almost completed ru/volunteer.wml

Modified: website/trunk/docs/ru/tor-doc-win32.wml
===================================================================

--- website/trunk/docs/ru/tor-doc-win32.wml	2006-10-24 13:22:08 UTC (rev 8816)
+++ website/trunk/docs/ru/tor-doc-win32.wml	2006-10-24 18:54:33 UTC (rev 8817)
@@ -1,6 +1,6 @@
 ## translation metadata
-# Based-On-Revision: 8724
-# Last-Translator: ygrekheretix ON gmail
+# Based-On-Revision: 8734
+# Last-Translator: ygrekheretix/gmail
 
 #include "head.wmi" TITLE="õÓÔÁÎÏ×ËÁ Tor ÎÁ MS Windows" CHARSET="KOI8-R"
 
@@ -29,13 +29,13 @@
 (GUI (ÇÒÁÆÉÞÅÓËÉÊ ÉÎÔÅÒÆÅÊÓ) ÄÌÑ Tor), É <a
 href="http://www.privoxy.org">Privoxy</a> (ÆÉÌØÔÒÕÀÝÉÊ ×ÅÂ ÐÒÏËÓÉ) ×
 ÏÄÎÏÍ ÐÁËÅÔÅ, ×ÓÅ ÔÒÉ ÐÒÉÌÏÖÅÎÉÑ ÎÁÓÔÒÏÅÎÙ ÒÁÂÏÔÁÔØ ×ÍÅÓÔÅ "ÉÚ ËÏÒÏÂËÉ".
-<a href="<page download>">óËÁÞÁÊÔÅ <!--ÌÉÂÏ ÓÔÁÂÉÌØÎÕÀ ÌÉÂÏ 
-ÜËÓÐÅÒÉÍÅÎÔÁÌØÎÕÀ ×ÅÒÓÉÀ--> ÉÎÓÔÁÌÌÑÔÏÒ ÄÌÑ Windows ÓÏ ÓÔÒÁÎÉÃÙ Download</a>.
+<a href="<page download>">óËÁÞÁÊÔÅ ÓÔÁÂÉÌØÎÕÀ ÉÌÉ 
+ÜËÓÐÅÒÉÍÅÎÔÁÌØÎÕÀ ×ÅÒÓÉÀ ÉÎÓÔÁÌÌÑÔÏÒÁ ÄÌÑ Windows ÓÏ ÓÔÒÁÎÉÃÙ Download</a>.
 </p>
 
 <p>åÓÌÉ ×Ù ÎÅ ÈÏÔÉÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÐÁËÅÔ, ×Ù ÍÏÖÅÔÅ ÓËÁÞÁÔØ Tor ÏÔÄÅÌØÎÏ
-ÓÏ <a href="<page download>">ÓÔÒÁÎÉÃÙ download</a>, É ÐÏÔÏÍ <a
-href="<page docs/tor-doc-unix>#privoxy">ÕÓÔÁÎÏ×ÉÔØ É ÎÁÓÔÒÏÉÔØ
+ÓÏ ÓÔÒÁÎÉÃÙ <a href="<page download-windows>">download ÄÌÑ Windows</a>, Á ÚÁÔÅÍ
+<a href="<page docs/tor-doc-unix>#privoxy">ÕÓÔÁÎÏ×ÉÔØ É ÎÁÓÔÒÏÉÔØ
 Privoxy ÓÁÍÏÓÔÏÑÔÅÌØÎÏ</a>.
 </p>
 

Modified: website/trunk/ru/volunteer.wml
===================================================================
--- website/trunk/ru/volunteer.wml	2006-10-24 13:22:08 UTC (rev 8816)
+++ website/trunk/ru/volunteer.wml	2006-10-24 18:54:33 UTC (rev 8817)
@@ -1,5 +1,5 @@
 ## translation metadata
-# Based-On-Revision: 8183 partial
+# Based-On-Revision: 8183
 # Last-Translator: ygrekheretix/gmail
 
 #include "head.wmi" TITLE="äÏÂÒÏ×ÏÌØÃÙ" CHARSET="KOI8-R"
@@ -56,160 +56,155 @@
 ÐÏÔÒÅÂÕÅÔÓÑ ÕÎÉÆÉÃÉÒÏ×ÁÔØ ÉÈ ÉÎÔÅÒÆÅÊÓÙ, É ÍÏÖÅÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÔØ ÏÂÝÉÊ ËÏÄ,
 ÉÌÉ ×ÏÏÂÝÅ ÏÔÂÒÏÓÉÔØ ÐÏÄÄÅÒÖËÕ ÏÄÎÏÇÏ ÉÚ ÎÉÈ.</li>
 </ul>
-<li>People running servers 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. Perhaps it would run out
-of cron, or perhaps it would sleep until appropriate times and then do
-its tweak (that's probably more portable). Can somebody write one for us
-and we'll put it into <a href="<svnsandbox>contrib/">contrib/</a>?
-This is a good entry for the <a href="<page gui/index>">Tor GUI
-competition</a>.</li>
-<li>Tor can <a
-href="http://wiki.noreply.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 server. 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>
+<li>ïÐÅÒÁÔÏÒÙ ÓÅÒ×ÅÒÏ× ÈÏÔÑÔ ÉÍÅÔØ ×ÏÚÍÏÖÎÏÓÔØ ÕËÁÚÙ×ÁÔØ ÒÁÚÎÙÅ ÚÎÁÞÅÎÉÑ BandwidthRate
+× ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ×ÒÅÍÅÎÉ ÄÎÑ. ÷ÍÅÓÔÏ ÔÏÇÏ, ÞÔÏÂÙ ËÏÄÉÔØ ÜÔÏ ×ÎÕÔÒØ ÓÁÍÏÇÏ Tor, ÌÕÞÛÅ
+ÎÁÐÉÓÁÔØ ÓËÒÉÐÔ ËÏÔÏÒÙÊ ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ <a href="<page gui/index>">
+éÎÔÅÒÆÅÊÓ Tor Controller</a>, É ÐÏÓÙÌÁÔØ setconf ÄÌÑ ÉÚÍÅÎÅÎÉÑ ÏÇÒÁÎÉÞÅÎÉÊ ÔÒÁÆÉËÁ.
+÷ÏÚÍÏÖÎÏ ÏÎ ÂÕÄÅÔ ÚÁÐÕÓËÁÔØÓÑ cron'ÏÍ, ÉÌÉ ÍÏÖÅÔ ÓÁÍÏÓÔÏÑÔÅÌØÎÏ ÚÁÓÙÐÁÔØ É ÐÒÏÓÙÐÁÔØÓÑ 
+(×ÙÐÏÌÎÑÑ ÄÅÊÓÔ×ÉÑ ÐÏ ÎÁÓÔÒÏÊËÅ) × ÏÐÒÅÄÅÌ£ÎÎÏÅ ×ÒÅÍÑ. íÏÖÅÔ-ÌÉ ËÔÏ-ÎÉÂÕÄØ
+ÎÁÐÉÓÁÔØ ÔÁËÏÅ ÚÁ ÎÁÓ É ÍÙ ÐÏÌÏÖÉÍ ÜÔÏÔ ÓËÒÉÐÔ × <a href="<svnsandbox>contrib/">contrib/</a>?
+üÔÏ ÂÕÄÅÔ ÎÅÐÌÏÈÁÑ ÚÁÑ×ËÁ ÎÁ <a href="<page gui/index>">Tor GUI ÓÏÒÅ×ÎÏ×ÁÎÉÅ</a>.</li>
+<li>Tor ÍÏÖÅÔ <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">
+×ÙÈÏÄÉÔØ ÉÚ ÓÅÔÉ Tor ÞÅÒÅÚ ÕËÁÚÁÎÎÙÊ ÕÚÅÌ</a>, ÎÏ Õ ÎÁÓ ÄÏÌÖÎÁ ÂÙÔØ ×ÏÚÍÏÖÎÏÓÔØ 
+ÕËÁÚÁÔØ ÔÏÌØËÏ ÓÔÒÁÎÕ É ÏÓÔÁÌØÎÏÅ ÄÏÌÖÎÏ ÒÁÂÏÔÁÔØ Á×ÔÏÍÁÔÉÞÅÓËÉ. ìÕÞÛÉÊ ÓÐÏÓÏÂ ÜÔÏ
+ÄÏÂÙÔØ ÄÉÒÅËÔÏÒÉÀ Blossom, ÚÁÐÕÓÔÉÔØ ÌÏËÁÌØÎÏ ËÌÉÅÎÔ Blossom, ËÏÔÏÒÙÊ ÂÅÚÏÐÁÓÎÏ 
+(ÞÅÒÅÚ Tor É ÐÒÏ×ÅÒÑÑ ÐÏÄÐÉÓÉ) ÐÏÌÕÞÁÅÔ ÜÔÕ ÄÉÒÅËÔÏÒÉÀ,  ÐÅÒÅÈ×ÁÔÙ×ÁÅÔ ÉÍÅÎÁ ×ÉÄÁ
+<tt>.country.blossom</tt>, É ÄÅÌÁÅÔ ËÁË ÒÁÚ ÔÏ ÞÔÏ ÎÕÖÎÏ.</li>
+<li>ëÁÓÁÔÅÌØÎÏ ÇÅÏÌÏËÁÃÉÉ, ËÔÏ-ÔÏ ÄÏÌÖÅÎ ÎÁÒÉÓÏ×ÁÔØ ËÁÒÔÕ úÅÍÌÉ Ó ÏÔÍÅÞÅÎÎÙÍÉ
+ÓÅÒ×ÅÒÁÍÉ Tor. ìÕÞÛÅ ÅÓÌÉ ÜÔÁ ËÁÒÁÔ ÂÕÄÅÔ ÏÂÎÏ×ÌÑÔØÓÑ ÓÏ ×ÒÅÍÅÎÅÍ. îÁ ÖÁÌØ,
+ÐÒÏÓÔÏÊ ÓÐÏÓÏÂ ÓÄÅÌÁÔØ ÜÔÏ - ÐÏÓÙÌÁÔØ ×ÓÅ ÄÁÎÎÙÅ Ë Google ÞÔÏÂÙ ÏÎÉ ÎÁÒÉÓÏ×ÁÌÉ ËÁÒÔÕ 
+ÚÁ ÎÁÓ. ëÁË ÜÔÏ ÓËÁÖÅÔÓÑ ÎÁ ÂÅÚÏÐÁÓÎÏÓÔÉ, É ÎÅÔ ÌÉ Õ ÎÁÓ ÄÒÕÇÉÈ ×ÁÒÉÁÎÔÏ×?</li>
 </ol>
 
 <a id="Documentation"></a>
-<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
+<h2><a class="anchor" href="#Documentation">äÏËÕÍÅÎÔÁÃÉÑ</a></h2>
 <ol>
-<li>We hear that Tor users can fall victim to anonymity-breaking attacks
-from javascript, java, activex, flash, etc, if they don't disable
-them. Are there plugins out there (like NoScript for Firefox) that make
-it easier for users to manage this risk? What is the risk exactly?</li>
-<li>Is there a full suite of plugins that will replace all of Privoxy's
-functionality for Firefox 1.5+? We hear Tor is much faster when you take
-Privoxy out of the loop.</li>
-<li>Please help Matt Edman with the documentation and how-tos for his
-<a href="http://vidalia-project.net/">Tor Controller</a>.</li>
-<li>Evaluate and document
-<a href="http://wiki.noreply.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.</li>
-<li>We have a huge list of <a href="http://wiki.noreply.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 also need people to help
-maintain the existing Italian, French, and Swedish translations -
-see the <a href="<page translation-status>">translation status
-overview</a>.</li>
+<li>íÙ ÞÁÓÔÏ ÓÌÙÛÉÍ ÞÔÏ ÐÏÌØÚÏ×ÁÔÅÌÉ Tor ÍÏÇÕÔ ÓÔÁÔØ ÖÅÒÔ×ÁÍÉ ÁÔÁË ÐÒÏÔÉ× 
+ÁÎÏÎÉÍÎÏÓÔÉ, ÅÓÌÉ ÎÅ ÏÔËÌÀÞÁÔ JavaScript, Java, ActiveX, Flash, ÉÔÄ. óÕÝÅÓÔ×ÕÀÔ 
+ÌÉ ËÁËÉÅ-ÎÉÂÕÄØ ÐÌÁÇÉÎÙ (ËÁË ÎÁÐÒÉÍÅÒ NoScript ÄÌÑ Firefox), ËÏÔÏÒÙÅ ÐÏÍÏÇÕÔ 
+ÐÏÌØÚÏ×ÁÔÅÌÑÍ ÕÐÒÁ×ÌÑÔØ ÜÔÉÍ ÒÉÓËÏÍ. ëÁËÉÅ ÔÏÞÎÏ ÒÉÓËÉ Ó ÜÔÏÊ ÓÔÏÒÏÎÙ?</li>
+<li>óÕÝÅÓÔ×ÕÅÔ ÌÉ ÎÁÂÏÒ ÐÌÁÇÉÎÏ× ËÏÔÏÒÙÊ ÍÏÖÅÔ ÐÏÌÎÏÓÔØÀ ÚÁÍÅÎÉÔØ Privoxy ÄÌÑ 
+Firefox 1.5+? íÙ ÓÌÙÛÁÌÉ ÞÔÏ Tor ÒÁÂÏÔÁÅÔ ÎÁÍÎÏÇÏ ÂÙÓÔÒÅÅ, ÅÓÌÉ ÎÅ ÉÓÐÏÌØÚÏ×ÁÔØ 
+Privoxy ÐÒÉ ÜÔÏÍ.</li>
+<li>ðÏÖÁÌÕÊÓÔÁ ÐÏÍÏÇÉÔÅ Matt Edman Ó ÄÏËÕÍÅÎÔÁÃÉÅÊ É ÐÒÉÍÅÒÁÍÉ Ë 
+<a href="http://vidalia-project.net/">Vidalia</a>.</li>
+<li>ðÒÏ×ÅÒØÔÅ
+<a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">ÓÐÉÓÏË
+ÐÒÏÇÒÁÍÍ</a> ËÏÔÏÒÙÅ ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÞÅÒÅÚ Tor.</li>
+<li>îÁÍ ÎÕÖÎÏ ÂÏÌØÛÅ ÄÏËÕÍÅÎÔÁÃÉÉ ÐÏ ÄÉÎÁÍÉÞÅÓËÏÍÕ ÐÅÒÅÈ×ÁÔÕ
+ÓÏÅÄÉÎÅÎÉÊ É ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÀ ÉÈ × Tor. ëÁÎÄÉÄÁÔÙ - tsocks (Linux), dsocks (BSD),
+É freecap (Windows).</li>
+<li>õ ÎÁÓ ÅÓÔØ ÂÏÌØÛÏÊ ÓÐÉÓÏË
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">
+ÐÒÏÇÒÁÍÍ ËÏÔÏÒÙÊ ÍÏÇÕÔ ÂÙÔØ ÐÏÌÅÚÎÙÍÉ × ËÁÞÅÓÔ×Å ÉÎÔÅÒÆÅÊÓÁ Ë Tor</a>. 
+ëÏÔÏÒÙÅ ÉÚ ÎÉÈ × ËÁËÉÈ ËÏÎËÒÅÔÎÏ ÓÉÔÕÁÃÉÑÈ ÍÏÇÕÔ ÐÒÉÇÏÄÉÔÓÑ? ðÏÖÁÌÕÊÓÔÁ ÐÏÍÏÇÉÔÅ ÉÈ
+ÐÒÏ×ÅÒÉÔØ É ÚÁÄÏËÕÍÅÎÔÉÒÏ×ÁÔØ ÒÅÚÕÌØÔÁÔÙ.</li>
+<li>ðÏÍÏÇÉÔÅ ÐÅÒÅ×ÅÓÔÉ ×ÅÂ-ÓÔÒÁÎÉÃÙ É ÄÏËÕÍÅÎÔÁÃÉÀ ÎÁ ÄÒÕÇÉÅ ÑÚÙËÉ.
+óÍÏÔÒÉÔÅ <a href="<page translation>">ÉÎÓÔÒÕËÃÉÉ ÄÌÑ ÐÅÒÅ×ÏÄÞÉËÏ×</a> 
+ÅÓÌÉ ×Ù ÈÏÔÉÔÅ ÐÏÍÏÞØ. îÁÍ ÔÁËÖÅ ÎÕÖÎÙ ÌÀÄÉ, ÞÔÏÂÙ ÐÏÄÄÅÒÖÉ×ÁÔØ × ÁËÔÕÁÌØÎÏÍ 
+ÓÏÓÔÏÑÎÉÉ ÉÔÁÌØÑÎÓËÉÊ, ÆÒÁÎÃÕÚÓËÉÊ É Û×ÅÄÓËÉÊ ÐÅÒÅ×ÏÄÙ - ÓÍÏÔÒÉÔÅ
+<a href="<page translation-status>">ÓÔÒÁÎÉÃÕ ÓÏÓÔÏÑÎÉÑ ÐÅÒÅ×ÏÄÏ×</a>.</li>
 </ol>
 
 <a id="Coding"></a>
-<h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
+<h2><a class="anchor" href="#Coding">ëÏÄÉÒÏ×ÁÎÉÅ É ÐÒÏÅËÔÉÒÏ×ÁÎÉÅ</a></h2>
 <ol>
-<li>Right now the hidden service descriptors are being stored on just a
-few directory servers. This is bad for privacy and bad for robustness. To
-get more robustness, we're going to need to make hidden service
-descriptors even less private because we're going to have to mirror them
-onto many places. Ideally we'd like to separate the storage/lookup system
-from the Tor directory servers entirely. The first problem is that we need
-to design a new hidden service descriptor format to a) be ascii rather
-than binary for convenience; b) keep the list of introduction points
-encrypted unless you know the <tt>.onion</tt> address, so the directory
-can't learn them; and c) allow the directories to verify the timestamp
-and signature on a hidden service descriptor so they can't be tricked
-into giving out fake ones. Second, any reliable distributed storage
-system will do, as long as it allows authenticated updates, but as far
-as we know no implemented DHT code supports authenticated updates.</li>
-<li>Tor exit servers need to do many DNS resolves in parallel. But
-gethostbyname() is poorly designed --- it blocks until it has finished
-resolving a query --- so it requires its own thread or process. So Tor
-is forced to spawn many separate DNS "worker" threads. There are some
-asynchronous DNS libraries out there, but historically they are buggy and
-abandoned. Are any of them stable, fast, clean, and free software? (Remember,
-Tor uses OpenSSL, and OpenSSL is (probably) not compatible with the GPL, so
-any GPL libraries are out of the running.) If so
-(or if we can make that so), we should integrate them into Tor. See <a
-href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">Agl's
-post</a> for one potential approach. Also see
-<a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> and
+<li>óÅÊÞÁÓ ÄÅÓËÒÉÐÔÏÒÙ ÓËÒÙÔÙÈ ÓÅÒ×ÉÓÏ× ÈÒÁÎÑÔÓÑ ÔÏÌØËÏ ÎÁ ÎÅÓËÏÌØËÉÈ
+ÓÅÒ×ÅÒÁÈ ÄÉÒÅËÔÏÒÉÊ. üÔÏ ÐÌÏÈÏ ÄÌÑ ÐÒÉ×ÁÔÎÏÓÔÉ É ÎÁÄ£ÖÎÏÓÔÉ. þÔÏÂÙ Õ×ÅÌÉÞÉÔØ 
+ÎÁÄ£ÖÎÏÓÔØ ÍÙ ÄÏÌÖÎÙ ÓÄÅÌÁÔØ ÄÅÓËÒÉÐÔÏÒÙ ÓËÒÙÔÙÈ ÓÅÒ×ÉÓÏ× ÍÅÎÅÅ ÓËÒÙÔÙÍÉ, 
+ÔÁË ËÁË ÍÙ ÓÏÂÉÒÁÅÍÓÑ ÚÅÒËÁÌÉÒÏ×ÁÔØ ÉÈ ×Ï ÍÎÏÇÉÈ ÍÅÓÔÁÈ. ÷ ÉÄÅÁÌÅ ÎÁÄÏ ÂÙ 
+ÐÏÌÎÏÓÔØÀ ÒÁÚÄÅÌÉÔØ ÓÉÓÔÅÍÕ ÈÒÁÎÅÎÉÑ/ÐÏÉÓËÁ ÏÔ ÄÉÒÅËÔÏÒÉÊ ÓÅÒ×ÅÒÏ× Tor. ðÅÒ×ÁÑ
+ÐÒÏÂÌÅÍÁ × ÔÏÍ, ÞÔÏ ÎÁÄÏ ÒÁÚÒÁÂÏÔÁÔØ ÎÏ×ÙÊ ÆÏÒÍÁÔ ÈÒÁÎÅÎÉÑ ÄÅÓËÒÉÐÔÏÒÏ× ÓËÒÙÔÙÈ
+ÓÅÒ×ÉÓÏ×, ËÏÔÏÒÙÊ ÂÕÄÅÔ Á) ÓÉÍ×ÏÌØÎÙÍ ×ÍÅÓÔÏ ÂÉÎÁÒÎÏÇÏ; Â) ÈÒÁÎÉÔØ
+ÓÐÉÓÏË introduction ÕÚÌÏ× ÚÁÛÉÆÒÏ×ÁÎÎÙÍ, ÄÌÑ ×ÓÅÈ ËÔÏ ÎÅ ÚÎÁÅÔ <tt>.onion</tt>
+ÁÄÒÅÓ, ÔÁË ÞÔÏ ÓÅÒ×ÅÒ ÄÉÒÅËÔÏÒÉÉ ÎÅ ÍÏÖÅÔ ÕÚÎÁÔØ ÄÅÓËÒÉÐÔÏÒ; ×) ÐÏÚ×ÏÌÉÔØ ÄÉÒÅËÔÏÒÉÑÍ
+ÐÒÏ×ÅÒÑÔØ ÏÔÍÅÔËÕ ×ÒÅÍÅÎÉ É ÐÏÄÐÉÓØ ÄÅÓËÒÉÐÔÏÒÁ ÓËÒÙÔÙÈ ÓÅÒ×ÉÓÏ×, ÞÔÏÂÙ
+ÎÅÌØÚÑ ÂÙÌÏ ÐÏÄÓÕÎÕÔØ ÌÏÖÎÙÊ ÄÅÓËÒÉÐÔÏÒ. ÷Ï-×ÔÏÒÙÈ, ÐÏÄÏÊÄ£Ô ÌÀÂÁÑ 
+ÎÁÄ£ÖÎÁÑ ÒÁÓÐÒÅÄÅÌ£ÎÎÁÑ ÓÉÓÔÅÍÁ ÈÒÁÎÅÎÉÑ, ÒÁÚÒÅÛÁÀÝÁÑ ÁÕÔÅÎÔÉÆÉÃÉÒÏ×ÁÎÎÙÅ
+ÏÂÎÏ×ÌÅÎÉÑ, ÎÏ ÎÁÓËÏÌØËÏ ÍÙ ÚÎÁÅÍ, ÎÉ ÏÄÎÁ ÉÚ ÒÅÁÌÉÚÁÃÉÊ DHT ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔ
+ÔÁËÉÅ ÏÂÎÏ×ÌÅÎÉÑ.</li>
+<li>÷ÙÈÏÄÑÝÉÊ ÕÚÅÌ Tor ÄÏÌÖÅÎ ×ÙÐÏÌÎÑÔØ ÍÎÏÖÅÓÔ×Ï DNS ÚÁÐÒÏÓÏ× ÏÄÎÏ×ÒÅÍÅÎÎÏ. îÏ
+gethostbyname() ÓÐÒÏÅËÔÉÒÏ×ÁÎÁ ÎÅÕÄÁÞÎÏ ÄÌÑ ÔÁËÉÈ ÔÒÅÂÏ×ÁÎÉÊ --- ×ÙÐÏÌÎÅÎÉÅ ÂÌÏËÉÒÕÅÔÓÑ
+ÄÏ ÏËÏÎÞÁÎÉÑ ×ÙÐÏÌÎÅÎÉÑ ÚÁÐÒÏÓÁ --- ÐÏÜÔÏÍÕ ÔÒÅÂÕÅÔÓÑ ×ÙÄÅÌÑÔØ ÏÔÄÅÌØÎÙÊ ÐÏÔÏË
+ÉÌÉ ÐÒÏÃÅÓÓ. ôÁËÉÍ ÏÂÒÁÚÏÍ Tor ×ÙÎÕÖÄÅÎ ÚÁÐÕÓËÁÔØ ÍÎÏÇÏ ÐÏÔÏËÏ× ÄÌÑ DNS. ëÏÎÅÞÎÏ,
+ÓÕÝÅÓÔ×ÕÀÔ ÂÉÂÌÉÏÔÅËÉ ÒÅÁÌÉÚÕÀÝÉÅ ÁÓÉÎÈÒÏÎÎÙÅ DNS ÚÁÐÒÏÓÙ, ÎÏ ÐÏ ÉÓÔÏÒÉÞÅÓËÉÍ
+ÐÒÉÞÉÎÁÍ, ÂÏÌØÛÉÎÓÔ×Ï ÉÚ ÎÉÈ ÇÌÀÞÉÔ É ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ ÒÁÚÒÁÂÏÔÞÉËÏÍ. ÷Ù ÎÅ ÚÎÁÅÔÅ
+ËÁËÕÀ-ÎÉÂÕÄØ ÐÏÄÈÏÄÑÝÕÀ ÓÔÁÂÉÌØÎÕÀ, ÂÙÓÔÒÕÀ, ËÒÁÓÉ×ÕÀ É Ó×ÏÂÏÄÎÕÀ ÌÉÂÕ?
+(ðÏÍÎÉÔÅ, Tor ÉÓÐÏÌØÚÕÅÔ OpenSSL, Á OpenSSL (×ÅÒÏÑÔÎÏ) ÎÅ GPL-ÓÏ×ÍÅÓÔÉÍ, Ô.Å.
+×ÓÅ GPL ÂÉÂÌÉÏÔÅËÉ ÎÅ ÇÏÄÑÔÓÑ.). åÓÌÉ ÔÁËÉÅ ÅÓÔØ, ÎÁÍ ÓÔÏÉÔ ÉÎÔÅÇÒÉÒÏ×ÁÔØ ÉÈ
+× Tor. óÍÏÔÒÉÔÅ 
+<a href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">ÜÔÏÔ ÐÏÓÔ by Agl</a> 
+Ó ×ÁÒÉÁÎÔÁÍÉ ÒÅÛÅÎÉÑ. ôÁËÖÅ ÏÃÅÎÉÔÅ
+<a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> É
 <a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.
 </li>
-<li>Tor 0.1.1.x includes 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>Because Tor servers need to store-and-forward each cell they handle,
-high-bandwidth Tor servers end up using dozens of megabytes of memory
-just for buffers. We need better heuristics for when to shrink/expand
-buffers. Maybe this should be modelled after the Linux kernel buffer
-design, where you have many smaller buffers that link to each other,
-rather than monolithic buffers?</li>
-<li>Implement reverse DNS requests inside Tor (already specified in
-Section 5.4 of <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</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>How hard is it to patch bind or a
-DNS proxy to redirect requests to Tor via our <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">tor-resolve
-socks extension</a>? dsocks already does this on BSD. What about to
-convert UDP DNS requests to TCP requests and send them through Tor?</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="http://wiki.noreply.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/tor-spec-udp.txt">specification for Tor and
-UDP</a> &mdash; 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>
+<li>Tor 0.1.1.x ×ËÌÀÞÁÅÔ ÐÏÄÄÅÒÖËÕ ÁÐÐÁÒÁÔÎÙÈ ÕÓËÏÒÉÔÅÌÅÊ ËÒÉÐÔÏÇÒÁÆÉÞÅÓËÉÈ ÏÐÅÒÁÃÉÊ 
+Ó ÐÏÍÏÝØÀ OpenSSL. ÷ÐÒÏÞÅÍ, ÎÉËÔÏ ÎÉËÏÇÄÁ ÜÔÏ ÎÅ ÐÒÏ×ÅÒÑÌ. îÉËÔÏ ÎÅ ÈÏÞÅÔ
+ÐÒÏ×ÅÒÉÔØ Tor ÎÁ Ó×ÏÅÊ ËÁÒÔÏÞËÅ É ÓÏÏÂÝÉÔØ ÎÁÍ?</li>
+<li>ôÁË ËÁË Tor ÓÏÈÒÁÎÑÅÔ × ÐÁÍÑÔÉ ËÁÖÄÕÀ ÑÞÅÊËÕ (cell) ÄÌÑ ÏÂÒÁÂÏÔËÉ,
+×ÙÓÏËÏ-ÓËÏÒÏÓÔÎÙÅ ÓÅÒ×ÅÒÁ ÐÏÔÒÅÂÌÑÀÔ ÍÎÏÇÏ ÐÁÍÑÔÉ, ÐÒÏÓÔÏ ÄÌÑ ÓÏÈÒÁÎÅÎÉÑ ×ÓÅÈ
+ÜÔÉÈ ÂÕÆÅÒÏ×. îÁÍ ÎÕÖÎÏ ÕÌÕÞÛÉÔØ Ü×ÒÉÓÔÉÞÅÓËÉÊ ÁÌÇÏÒÉÔÍ, ËÏÔÏÒÙÊ ÏÐÒÅÄÅÌÑÅÔ
+ËÏÇÄÁ ÓÖÉÍÁÔØ/ÒÁÓÛÉÒÑÔØ ÂÕÆÅÒÙ. íÏÖÅÔ ÂÙÔØ ÓÔÏÉÔ ÉÓÐÏÌØÚÏ×ÁÔØ ËÏÎÃÅÐÃÉÀ ÉÚ ÑÄÒÁ
+Linux, ÇÄÅ ÍÎÏÇÏ ÍÁÌÅÎØËÉÈ ÂÕÆÅÒÏ× ÓÓÙÌÁÀÔÓÑ ÎÁ ÄÒÕÇ ÄÒÕÇÁ, ×ÍÅÓÔÏ ÔÏÇÏ
+ÞÔÏÂÙ ÉÓÐÏÌØÚÏ×ÁÔØ ÍÏÎÏÌÉÔÎÙÅ ÂÕÆÅÒÙ?</li>
+<li>òÅÁÌÉÚÏ×ÁÔØ ÏÂÒÁÔÎÙÅ DNS ÚÁÐÒÏÓÙ ×ÎÕÔÒÉ Tor (ÕÖÅ ÏÐÉÓÁÎÏ × 
+óÅËÃÉÉ 5.4 × <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
+<li>÷ÙÐÏÌÎÉÔØ ÁÎÁÌÉÚ ÂÅÚÏÐÁÓÎÏÓÔÉ Tor Ó ÐÏÍÏÝØÀ
+<a href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. ïÐÒÅÄÅÌÉÔØ,
+ÓÕÝÅÓÔ×ÕÀÔ ÌÉ ÐÏÄÈÏÄÑÝÉÅ ÂÉÂÌÉÏÔÅËÉ.</li>
+<li>îÁÓËÏÌØËÏ ÓÌÏÖÎÏ ÐÒÏÐÁÔÞÉÔØ bind ÉÌÉ DNS ÐÒÏËÓÉ ÄÌÑ ÐÅÒÅÓÙÌËÉ ÚÁÐÒÏÓÏ×
+× Tor ÞÅÒÅÚ ÎÁÛ
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">tor-resolve</a>?
+îÁ BSD ÜÔÏ ÕÖÅ ÄÅÌÁÅÔÓÑ Ó ÐÏÍÏÝØÀ dsocks. ëÁË ÎÁÓÞ£Ô ÔÏÇÏ ÞÔÏÂÙ ËÏÎ×ÅÒÔÉÒÏ×ÁÔØ
+UDP DNS ÚÁÐÒÏÓÙ × TCP ÚÁÐÒÏÓÙ É ÐÏÓÙÌÁÔØ ÉÈ ÞÅÒÅÚ Tor?</li>
+<li>Tor ÉÓÐÏÌØÚÕÅÔ TCP ÎÁ ÔÒÁÎÓÐÏÒÔÎÏÍ ÕÒÏ×ÎÅ É TLS ÄÌÑ ÛÉÆÒÏ×ÁÎÉÑ
+ÓÏÅÄÉÎÅÎÉÊ. üÔÏ ÐÒÏÓÔÏ É ËÒÁÓÉ×Ï, ÎÏ ÜÔÏ ÚÎÁÞÉÔ ÞÔÏ ×ÓÅ ÑÞÅÊËÉ (cell)
+ÚÁÄÅÒÖÉ×ÁÀÔÓÑ, ÅÓÌÉ ÏÄÉÎ ÐÁËÅÔ ÐÏÔÅÒÑÅÔÓÑ, É ÜÔÏ ÚÎÁÞÉÔ ÞÔÏ ÍÙ ÍÏÖÅÍ
+ÐÏÄÄÅÒÖÉ×ÁÔØ ÔÏÌØËÏ TCP ÐÏÔÏËÉ. õ ÎÁÓ ÅÓÔØ 
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
+ÓÐÉÓÏË ÐÒÉÞÉÎ ÐÏ ËÏÔÏÒÙÍ ÍÙ ÎÅ ÉÓÐÏÌØÚÕÅÍ UDP ÔÒÁÎÓÐÏÒÔ</a>, ÎÏ ÈÏÔÅÌÏÓØ
+ÂÙ ÓÏËÒÁÔÉÔØ ÜÔÏÔ ÓÐÉÓÏË. õ ÎÁÓ ÔÁËÖÅ ÅÓÔØ ÐÒÅÄÌÁÇÁÅÍÁÑ 
+<a href="<svnsandbox>doc/tor-spec-udp.txt">ÓÐÅÃÉÆÉËÁÃÉÑ ÄÌÑ Tor É UDP</a>
+ &mdash; ÐÏÖÁÌÕÊÓÔÁ ÓÏÏÂÝÉÔÅ ÅÓÌÉ Ó ÎÅÊ ÞÔÏ ÎÅ ÔÁË.</li>
+<li>íÙ ÕÖÅ ÂÌÉÚËÉ Ë ÐÏÄÄÅÒÖËÅ IPv6 ÄÌÑ ÁÄÒÅÓÏ× ÎÁÚÎÁÞÅÎÉÑ (ÎÁ ×ÙÈÏÄÑÝÉÈ
+ÕÚÌÁÈ). åÓÌÉ ×ÁÓ ÉÎÔÅÒÅÓÕÅÔ IPv6, ÐÏÖÁÌÕÊ ÓÔÏÉÔ ÎÁÞÁÔØ Ó ÜÔÏÇÏ ÐÕÎËÔÁ.</li>
 </ol>
 
 <a id="Research"></a>
-<h2><a class="anchor" href="#Research">Research</a></h2>
+<h2><a class="anchor" href="#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>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>"áÔÁËÁ ÐÏ ÓÉÇÎÁÔÕÒÅ ÓÁÊÔÁ": ÓÏÚÄÁÔØ ÓÐÉÓÏË ÎÅÓËÏÌØËÉÈ ÓÏÔÅÎ 
+ÐÏÐÕÌÑÒÎÙÈ ÓÁÊÔÏ×, ÓËÁÞÁÔØ ÉÈ ÓÔÒÁÎÉÃÙ, É ÓÏÈÒÁÎÉÔØ ÎÁÂÏÒ "ÓÉÇÎÁÔÕÒ"
+ÜÔÉÈ ÓÔÒÁÎÉÃ. îÁÂÌÀÄÁÑ ÔÒÁÆÉË ËÌÉÅÎÔÁ Tor, ÐÏ ×ÈÏÄÑÝÉÍ ÄÁÎÎÙÍ,
+ÐÕÔ£Í ÓÏÐÏÓÔÁ×ÌÅÎÉÑ ÓÉÇÎÁÔÕÒ ÍÏÖÎÏ ÐÏÐÙÔÁÔØÓÑ ÏÔÇÁÄÁÔØ Ó ËÁËÉÍ ÉÚ
+ÜÔÉÈ ÓÁÊÔÏ× ÓÅÊÞÁÓ ÕÓÔÁÎÏ×ÌÅÎÏ ÓÏÅÄÉÎÅÎÉÅ. ÷Ï-ÐÅÒ×ÙÈ, ÎÁÓËÏÌØËÏ ÜÆÆÅËÔÉ×ÎÁ
+ÜÔÁ ÁÔÁËÁ ÐÒÏÔÉ× Tor? ðÏÓÌÅ ÏÔ×ÅÔÁ ÎÁ ÜÔÏÔ ×ÏÐÒÏÓ, ÎÁÞÎÉÔÅ ÐÒÏ×ÅÒÑÔØ ÚÁÝÉÔÕ:
+ÎÁÐÒÉÍÅÒ ÍÏÖÎÏ Õ×ÅÌÉÞÉÔØ ÒÁÚÍÅÒ ÑÞÅÊËÉ Ó 512 ÄÏ 1024 ÂÁÊÔ, ÍÏÖÎÏ ÒÅÁÌÉÚÏ×ÁÔØ
+ÔÅÈÎÉËÉ ÄÏÐÏÌÎÅÎÉÑ (padding), ÔÁËÉÅ ËÁË 
+<a href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,
+ÉÌÉ ÍÏÖÎÏ ××ÅÓÔÉ ÚÁÄÅÒÖËÉ ÔÒÁÆÉËÁ. ëÁË ÜÔÏ ÐÏ×ÌÉÑÅÔ ÎÁ ÁÔÁËÕ, É ËÁË ÜÔÏ ÓËÁÖÅÔÓÑ
+ÎÁ ÀÚÁÂÉÌÉÔÉ?
+<li>áÔÁËÁ ÐÏ "ËÏÒÒÅÌÑÃÉÉ ÏËÏÎÅÞÎÏÇÏ ÔÒÁÆÉËÁ": ÎÁÂÌÀÄÁÑ ÔÒÁÆÉË áÌÉÓÙ É âÏÂÁ,
+ÍÙ ÍÏÖÅÍ <a href="http://freehaven.net/anonbib/#danezis:pet2004">ÓÒÁ×ÎÉÔØ
+ÓÉÇÎÁÔÕÒÙ ÔÒÁÆÉËÁ É ÕÂÅÄÉÔØÓÑ ÞÔÏ ÍÙ ÎÁÂÌÀÄÁÅÍ ÏÄÉÎ ÐÏÔÏË</a>.
+îÁ ÄÁÎÎÏÍ ÜÔÁÐÅ Tor ÐÒÉÎÉÍÁÅÔ ÜÔÏÔ ÆÁËÔ ËÁË ÄÁÎÎÏÓÔØ É ÓÞÉÔÁÅÔÓÑ, ÞÔÏ
+ÁÔÁËÁ ÔÒÉ×ÉÁÌØÎÏ ÒÅÁÌÉÚÕÅÔÓÑ × ÌÀÂÏÍ ÓÌÕÞÁÅ. ÷Ï-ÐÅÒ×ÙÈ, ÐÒÁ×ÄÉ×Ï ÄÉ ÜÔÏ
+ÄÏÐÕÝÅÎÉÅ. óËÏÌØËÏ ÔÒÁÆÉËÁ Ó ËÁËÉÍ ÒÁÓÐÒÅÄÅÌÅÎÉÅÍ ÎÁÄÏ ÎÁÂÌÀÄÁÔØ ÞÔÏÂÙ
+ÁÔÁËÕÀÝÁÑ ÓÔÏÒÏÎÁ ÂÍÏÇÌÁ ÂÙÔØ Õ×ÅÒÅÎÁ × ÒÅÚÕÌØÔÁÔÅ? åÓÔØ ÌÉ ÓÐÏÓÏÂÙ
+ÚÁÍÅÄÌÉÔØ ÁÔÁËÕ (ÍÏÖÅÔ ÂÙÔØ ÕÍÅÎØÛÉÔØ ËÏÌ-×Ï ÐÅÒÅÄÁ×ÁÅÍÏÊ ÉÎÆÏÒÍÁÃÉÉ)?
+íÏÖÅÔ ÂÙÔØ ÎÅËÏÔÏÒÙÅ ÓÈÅÍÙ ÄÏÐÏÌÎÅÎÉÑ ÉÌÉ ÉÚÍÅÎÅÎÉÑ ÐÒÏÆÉÌÑ ÔÒÁÆÉËÁ
+ÐÒÉ ÔÁËÏÊ ÁÔÁËÅ ÒÁÂÏÔÁÀÔ ÌÕÞÛÅ ÞÅÍ ÄÒÕÇÉÅ?</li>
+<li>áÔÁËÁ "ÐÏ ÚÏÎÅ ÍÁÒÛÒÕÔÁ": × ÂÏÌØÛÉÎÓÔ×Å ÌÉÔÅÒÁÔÕÒÙ ÐÒÅÐÏÌÁÇÁÅÔÓÑ ÞÔÏ
+ÐÕÔØ ÏÔ áÌÉÓÙ Ë ×ÈÏÄÎÏÍÕ ÕÚÌÁ (É ÏÔ ×ÙÈÏÄÎÏÇÏ ÕÚÌÁ Ë âÏÂÕ) ÜÔÏ ÏÄÎÏ ÒÅÂÒÏ
+ÎÁ ÎÅËÏÔÏÒÏÍ ÇÒÁÆÅ. îÁ ÐÒÁËÔÉËÅ-ÖÅ, ÐÕÔØ ÐÒÏÈÏÄÉÔ ÞÅÒÅÚ ÎÅÓËÏÌØËÏ "Á×ÔÏÎÏÍÎÙÈ
+ÓÉÓÔÅÍ" (AS), É
+<a href="http://freehaven.net/anonbib/#feamster:wpes2004">
+ÎÅ ÆÁËÔ ÞÔÏ ÏÄÎÁ É ÔÁ ÖÅ AS ÎÅ ÂÕÄÅÔ ×ËÌÀÞÁÔØ É ×ÈÏÄÑÝÉÊ É ×ÙÈÏÄÑÝÉÊ ÐÕÔØ</a>.
+ë ÎÅÓÞÁÓÔØÀ, ÞÔÏÂÙ ÏÐÒÅÄÅÌÉÔØ ÂÅÚÏÐÁÓÎÏÓÔØ ËÁÖÄÏÊ ËÏÎËÒÅÔÎÏÊ ÞÅÔ×£ÒËÉ ÉÚ áÌÉÓÙ, 
+×ÈÏÄÑÝÅÇÏ ÕÚÌÁ, ×ÙÈÏÄÑÝÅÇÏ, É âÏÂÁ, ÍÙ ÄÏÌÖÎÙ ÚÁÇÒÕÚÎÉÔØ ÐÏÌÎÕÀ ÍÁÒÛÒÕÔÎÕÀ ÔÁÂÌÉÃÕ 
+éÎÔÅÒÎÅÔÁ É ×ÙÐÏÌÎÉÔØ ÒÅÓÕÒÓÏ£ÍËÉÅ ÏÐÅÒÁÃÉÉ. óÕÝÅÓÔ×ÕÀÔ ÌÉ ËÁËÉÅ-ÎÉÂÕÄØ ÐÒÁËÔÉÞÅÓËÉÅ
+ÐÒÉÂÌÉÖÅÎÉÑ, ÎÁÐÒÉÍÅÒ ÉÚÂÅÇÁÎÉÅ IP ÁÄÒÅÓÁ × ÔÏÊ ÖÅ /8 ÓÅÔÉ?</li>
 <li>Tor doesn't work very well when servers 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
@@ -250,15 +245,14 @@
 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 servers or dirservers. 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>óÅÊÞÁÓ ÄÏ×ÏÌØÎÏ ÐÒÏÓÔÏ ÚÁDoSÉÔØ ÓÅÒ×ÅÒÁ Tor ÉÌÉ ÓÅÒ×ÅÒÁ ËÁÔÁÌÏÇÏ×. 
+ðÒÁ×ÉÌØÎÙÊ ÏÔ×ÅÔ - ÉÇÒÁ × ÚÁÇÁÄËÉ Ó ËÌÉÅÎÔÏÍ? ëÁËÉÅ ÅÝ£ ÐÒÁËÔÉÞÅÓËÉÅ 
+ÐÏÄÈÏÄÙ ×Ù ÍÏÖÅÔÅ ÐÒÅÄÌÏÖÉÔØ? öÅÌÁÔÅÌØÎÏ ÞÔÏÂÙ ÏÎÉ ÂÙÌÉ ÓÏ×ÍÅÓÔÉÍÙ Ó ÓÕÝÅÓÔ×ÕÀÝÉÍ 
+ÐÒÏÔÏËÏÌÏÍ.</li>
 </ol>
 
-<a href="<page contact>">Let us know</a> if you've made progress on any
-of these!
+<a href="<page contact>">óÏÏÂÝÉÔÅ ÎÁÍ</a> ÅÓÌÉ ×Ù ÎÁ ÐÕÔÉ Ë ÒÅÛÅÎÉÀ!
 
   </div><!-- #main -->
 
 #include <foot.wmi>
-

