[or-cvs] r16695: {} ru update (removed russian translation of volunteer.wml, it (website/trunk/ru)

Sat Aug 30 17:55:41 UTC 2008

Author: ygrek
Date: 2008-08-30 13:55:41 -0400 (Sat, 30 Aug 2008)
New Revision: 16695

Removed:
   website/trunk/ru/volunteer.wml
Log:
ru update (removed russian translation of volunteer.wml, it is largely outdated, english source has
such info that is not needed in russian for the majority of visitors and any potential volunteer should be able to
speak english anyway :) )


Deleted: website/trunk/ru/volunteer.wml
===================================================================

--- website/trunk/ru/volunteer.wml	2008-08-30 17:48:56 UTC (rev 16694)
+++ website/trunk/ru/volunteer.wml	2008-08-30 17:55:41 UTC (rev 16695)
@@ -1,604 +0,0 @@
-## translation metadata
-# Based-On-Revision: 13933
-# Last-Translator: ygrekheretix/gmail/com
-
-#include "head.wmi" TITLE="Tor: Добровольцы" CHARSET="UTF-8"
-
-<div class="main-column">
-
-<h2>Три вещи которые можно сделать прямо сейчас:</h2>
-<ol>
-<li> Пожалуйста задумайтесь над возможностью
-<a href="https://svn.torproject.org/svn/tor/trunk/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><!-- #main -->
-
-#include <foot.wmi>

