ru/volunteer.wml (e52229dcd) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 13933
# Last-Translator: ygrekheretix/gmail/com

#include "head.wmi" TITLE="Tor: Добровольцы" CHARSET="UTF-8"

<h2>Три вещи которые можно сделать прямо сейчас:</h2>
<ol>
<li> Пожалуйста задумайтесь над возможностью
<a href="<cvssandbox>tor/doc/tor-doc-relay.html">запустить сервер</a>,
чтобы увеличить сеть Tor.</li>
<li> Расскажите друзьям! Пусть они тоже запустят сервер Tor. Пусть
запустят скрытый сервис. Пусть они расскажут своим друзьям!</li>
<li> Мы ищем финансирование и спонсоров. Если вам по душе цели Tor,
пожалуйста <a href="<page donate>">
помогите проекту деньгами, чтобы поддержать дальнейшую разработку</a>.
И если вы знаете какие-либо компании, негосударственные организации,
или другие организации, которым нужна безопасная связь в Сети, расскажите им о нас.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Поддержка приложений</a></h2>
<ol>
<li>Нам нужно больше хороших способов перехвата DNS запросов, чтобы они не давали
дополнительной информации локальному наблюдателю когда мы пытаемся оставаться
анонимными. (Это происходит потому что приложения самостоятельно посылают
DNS запросы перед обращением к SOCKS прокси.)</li>
<li>По tsocks/dsocks:
<ul>
<li>Нужно
<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">применить
все наши патчи к tsocks</a> и форкнуться. Мы предоставим хостинг для
этого проекта если требуется.</li>
<li>Мы должны пропатчить программу "dsocks" (автор Dug Song), чтобы использовать
Tor'овскую команду <i>mapaddress</i> из интерфейса контроллера, таким образом мы
не будем терять время в Tor на DNS разрешение перед соединением.</li>
<li>Мы должны исправить наш скрипт <i>torify</i> так, чтобы он определял
установленный tsocks или dsocks и правильно вызывал их. Пожалуй для этого
потребуется унифицировать их интерфейсы, и может быть использовать общий код,
или вообще отбросить поддержку одного из них.</li>
</ul>
</li>
<li>Операторы серверов хотят иметь возможность указывать разные значения BandwidthRate
в зависимости от времени дня. Вместо того, чтобы кодить это внутрь самого Tor, лучше
написать скрипт который будет использовать <a href="<page gui/index>">
Интерфейс Tor Controller</a>, и посылать setconf для изменения ограничений трафика.
У нас уже есть такой скрипт для Unix и Mac (он использует bash и cron), но ещё требуется
аналогичное решение для пользователей Windows.
</li>
<li>Tor может <a
href="https://wiki.torproject.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">Документация</a></h2>
<ol>
<li>Пожалуйста помогите Matt Edman с документацией и примерами к его контроллеру
Tor, <a href="http://vidalia-project.net/">Vidalia</a>.</li>
<li>Проверьте
<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">список
программ</a> которые можно использовать через Tor.</li>
<li>Нам нужно больше документации по динамическому перехвату
соединений и перенаправлению их в Tor. Кандидаты - tsocks (Linux), dsocks (BSD),
и freecap (Windows), т.к. будут лучше использовать нашу новую фичу TransPort.</li>
<li>У нас есть большой список
<a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">
программ которые могут быть полезны в качестве интерфейса к Tor</a>.
Какие из них в каких конкретно ситуациях могут пригодиться? Пожалуйста помогите их
проверить и задокументировать результаты.</li>
<li>Помогите перевести веб-страницы и документацию на другие языки.
Смотрите <a href="<page translation>">инструкции для переводчиков</a>
если вы хотите помочь. Нам особенно нужен перевод на арабский или фарси,
для пользователей Tor в странах с сильной цензурой.
</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.
</p>

<ol>

<li>
Tor/Polipo/Vidalia Auto-Update Framework
<br />
Vidalia already has the ability to notice when the user is running an
outdated or unrecommended version of Tor. 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. 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 basic 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>
An Improved and More Usable Network Map
<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>
Better Debian Support &amp; Packaging
<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
CntrolPort 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 then 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 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
making sure it works well with the existing Tor packages. We can also
set up an apt repository to host the new Vidalia packages.
<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>
Tor Status Event Interface
<br />
There may are a number of status changes of which the user may need
to be informed. For example, if the user is trying to set up a Tor
relay and Tor decides the user's relay is 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', 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 statuses 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
experience and some C++ development experience. Previous experience
with Qt and Qt's Designer will be very helpful, but 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>
A translation wiki
<br />
We require a way to edit and translate sections of the website &mdash;
possibly resulting in a patch for the official svn tree. The current
"cost" of publication of website changes is quite high even for English
language users. They need to check out our template files, translate them
and send us the translation. 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. 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 would not have to interact
with the software, only the documentation on the website.
</li>

<li>
https://check.torproject.org
<br />
We currently have a functional web page to detect if Tor is working. It
is 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 Tor DNS exit
list and should continue to do so in the future. It may 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.
</li>

<li>
exitlist.torproject.org
<br />
The exitlist software 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's 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 &mdash; 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>
Testing Tor for end users
<br />
The Tor project currently lacks a solid test to ensure that a
user has a properly 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 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/misc/decloak/">metasploit
decloak website</a>. A person interested in attacking Tor could start
by collecting as many workable and known methods for decloaking a
Tor user. The person 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 person should be closely familiar with using Tor and how
to prevent Tor leakage.
</li>

<li>
Tor needs even better censorship resistance mechanisms.  There are
several mechanisms that can help.  Tor should be able listen on multiple
addresses and ports, and allow clients to connect to all of them.
Tor should be able to appear like a webserver (HTTP or HTTPS) when
contacted by port-scanning tools.
</li>

<li>
Tor should make better use of the more recent features of Niels Provos's
Libevent library.  Libevent already provides HTTP and socket buffers;
Tor's code for those could be replaced.  We'll need to improve libevent's
code as needed; particularly, to add good openssl support on top of
libevent's buffer abstraction.
</li>

<li>
Tor should possibly measure bandwidth in a distributed way, as in the
<a href="http://freehaven.net/anonbib/">"A Tuneup 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 in the wild, and determine good ways to incorporate them
into the Tor network without adding undesirable n^2 traffic properties
at the directory authorities.
</li>

<li>
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.
</li>

<li>
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 (except on Windows &mdash; see 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.<br />
</li>

<li>
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. 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 helping,
too. The student should be willing to read the existing documentation,
implement code based on it, and, if required, refine the documentation
if things are underdocumented. This project is mostly about coding and
to a small degree about design.
</li>

<li>
Write a tool that runs automatic system tests in addition
to the existing unit tests. The Java-based Tor simulator <a
href="https://tor-svn.freehaven.net/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. 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 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>
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. 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 for the one part about identifying requirements to such a
tool and designing its interface; but on the other part, the project
also requires a lot of coding.
</li>

<li>Help Mike Perry on his <a
href="https://www.torproject.org/svn/torflow/">TorFlow</a>
library (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):
it's a python library that uses the <a
href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor controller
protocol</a> to instruct Tor to build circuits in a variety of ways,
and then it measures performance and tries to detect anomalies.</li>
<li>Torflow / soat to detect bad relays and automatically get that
info to the directory authorities for realtime blacklisting</li>
<li>Torstatus. Set up an automated system for tracking network health
over time, graphing it, etc. Better metrics for assessing network
health and growth.</li>
<li>vidalia and upnp</li>
<li>nymble</li>

<li>
Help port <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
Windows. 1) handle spaces in path names and understand the filesystem
namespace &mdash; namespace meaning 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>
a way to generate the website diagrams from source, so we can translate
them as utf-8 text rather than with gimp. (svg? or imagemagick?)
integrate this with a wml file so translations are easy and images are
generated in multiple languages at web publish
</li>

<li>How can we make the <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
easier to maintain, improve, and document?</li>
<li>We need a distributed testing framework. We have unit tests,
but it would be great to have a script that starts up a Tor network, uses
it for a while, and verifies that at least parts of it are working.</li>

<li>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>
<li>Don't see your idea here? We probably need it anyway! Contact
us and find out.</li>
</ol>

<h2><a class="anchor" href="#Coding">Кодирование и проектирование</a></h2>
<ol>
<li>Серверы Tor под Windows XP работают не очень стабильно. Под Windows,
Tor использует стандартный системный вызов <tt>select()</tt>, который потребляет
память из non-page pool. Это значит что средний Tor сервер исчерпает весь
non-page pool,
<a href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">
вызовет ошибку и аварийный останов системы</a>. Наверное лучше было бы
использовать overlapped IO. Т.е. надо научить
<a href="http://www.monkey.org/~provos/libevent/">libevent</a> для Windows использовать
overlapped IO вместо select(), а потом адаптировать Tor к новому интерфейсу
libevent. Прошлым летом (2007) Christian King начал 
<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">работу в этом
направлении</a>.</li>
<li>Пора уже начинать вводить наш
<a href="<page documentation>#DesignDoc">дизайн для противодействия
блокированию</a>. Это включает отшлифовывание дизайна, исправления кода во
многих местах, адаптирование <a href="http://vidalia-project.net/">Vidalia</a>
так чтобы поддерживались новые возможности, и планирование внедрения.</li>
<li>Нам требуется гибкая система симулирования для изучения атак на опознание
трафика с оконечным шифрованием. 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. Можем ли мы создать хорошо
документированный и открытый симулятор так чтобы все могли доверять полученным
результатам? Это вызовет много новых исследований. Смотрите раздел <a
href="#Research">ниже</a> о атаках на распознавание &mdash; кто знает, может
быть когда это будет сделано вы сможете помочь в написании работы.</li>
<li>Tor версии 0.1.1.x и выше поддерживают аппаратные ускорители криптографических операций
с помощью OpenSSL. Впрочем, никто никогда это не проверял. Если у вас есть такая
возможность, проверьте Tor на своей карточке и сообщите нам результаты.</li>
<li>Выполнить анализ безопасности Tor с помощью
<a href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Определить,
существуют ли подходящие библиотеки.</li>
<li>Tor использует TCP на транспортном уровне и TLS для шифрования
соединений. Это просто и красиво, но это значит что все ячейки (cell)
задерживаются, если один пакет потеряется, и это значит что мы можем
поддерживать только TCP потоки. У нас есть
<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
список причин по которым мы не используем UDP транспорт</a>, но хотелось
бы сократить этот список. У нас также есть предлагаемая
<a href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">спецификация для Tor и UDP</a>
 &mdash; пожалуйста сообщите если с ней что не так.</li>
<li>Мы уже близки к поддержке IPv6 для адресов назначения (на выходящих
узлах). Если вас интересует IPv6, пожалуй стоит начать с этого пункта.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Исследования</a></h2>
<ol>
<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>Другие исследования географического разнообразия рассматривают компромисс
между выбором эффективной цепочки и случайной. Смотрите
<a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">работу</a>
Stephen Rollyson'на о том как отбросить особенно медленные варианты "не сильно"
ухудшая анонимность. Это направление исследований требует больше работы и размышлений,
но выглядит многообещающе.</li>
<li>Tor не работает очень хорошо на серверах с ассиметричной пропускной
способностью (например кабель или DSL). Tor устанавливает отдельные TCP
соединения между каждым прыжком, и если входящие байты прибывают нормально а
исходящие теряются, механизм TCP push-back не передаёт эту информацию входящему
потоку. Пожалуй Tor должен определять когда он теряет слишком много исходящих
пакетов, и устанавливать ограничение на входящий поток чтобы регулировать
самостоятельно? Можно представить такую схему - сначала выбирается
консервативное ограничение трафика, которое медленно увеличивается до тех пор
пока мы начинаем терять пакеты, откатываемся назад, повторяем. Нам требуется
кто-нибудь хорошо разбирающийся в сетях чтобы симулировать это поведение и
помочь спроектировать решение, и/или надо понять насколько упадёт
производительность, и использовать это как мотивацию для пересмотра решения по
использованию UDP транспорта.</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>Для того чтобы диссиденты в разных странах могли использовать Tor избегая
блокирования на уровне брандмауэра страны, требуется не несоклько сотен
серверов, а несколько десятков тысяч. Надо придумать способ получить такое
число серверов. Например можно представить GUI для Tor с кнопкой "Tor для
Свободы" запускающей небольшой сервер (несколько КБ/сек и политика выхода
non-exit не должны доставлять много хлопот). Но как нам автоматическим образом
доставить список всех этих добровольных клиентов-серверов диссидентам так чтобы
брандмауэры на уровне страны не могли перехватить эти списки? Возможно придётся
разработать сеть доверия пользователей. Смотрите наши
<a href="<page documentation>#DesignDoc">ранние работы по проектированию
архитектуры устойчивой к блокированию</a> и соответствующий
<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">раздел FAQ</a>,
а также
<a
href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">раздел anonbib
посвящённый противодействию цензуре</a>.</li>
<li>Цепочки Tor строятся по одному прыжку за раз, так что в теории мы можем
использовать некторые потоки для выхода со второго прыжка, некторые с третьего,
и так далее. Это хорошо так как разбивает мноество выходящих потоков которое
может наблюдать один конкретный сервер. Но если мы хотим добиться безопасности
каждого потока, то по нашей логике они должны быть не менее трёх прыжков в длину
каждый, а остальные тогда будут даже длиннее. Надо исследовать влияние такого
подхода на скорость и безопасность.</li>
<li>Сейчас довольно просто заDoSить сервера Tor или сервера каталогов.
Правильный ответ - игра в загадки с клиентом? Какие ещё практические
подходы вы можете предложить? Желательно чтобы они были совместимы с существующим
протоколом.</li>
</ol>

<a href="<page contact>">Сообщите нам</a> если вы на пути к решению!

</div>

#include <foot.wmi>

tor-webwml.git

ru update