ru/volunteer.wml (686590a58) - tor-webwml.git

volunteer.wml

## translation metadata
# Revision: $Revision: 23009 $
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="Tor: Volunteer" CHARSET="UTF-8"
<div class="main-column">

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

В проекте Tor есть <a href="<page open-positions>">две
вакансии</a>. Пожалуйста, <a href="<page contact>">сообщите нам</a>, если вы
подходите по квалификации!

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Документация</a></h2>
<ol>
<li>Помогите нам перевести нашу веб-страницу и документацию на другие
языки. Ознакомьтесь с <a href="<page translation>">руководством по
переводу</a>, если вы хотите помочь. Нам особенно нужны переводы на арабский
язык и Фарси для множества пользователей Tor, находящихся в странах с
Интернет цензурой.</li>
<li>Оцените и дополите <a href="<wiki>TorifyHOWTO">наш список программ</a>
которые можно настроить на работу через Tor.</li>
<li>У нас есть огромный список <a href="<wiki>SupportPrograms">потенциально
полезных программ, которые взаимодействуют с Tor</a>. Какие из них полезны,
в каких ситуациях? Пожалуйста, помогите нам протестировать их и
документируйте свои результаты.</li>
</ol>

<a id="Advocacy"></a>
<h2><a class="anchor" href="#Advocacy">Поддержка</a></h2>
<ol>
<li>Создайте <a
href="https://trac.torproject.org/projects/tor/wiki/CommunityLogos">логотип
сообщества</a> под свободной лицензией Creative Commons (СС), который сможет
быть использован и модифицирован всеми желающими;</li>
<li>Создайте презентацию, которая сможет быть использована для встреч различных
групп пользователей по всему миру;</li>
<li>Создайте видео ролик о хороших примерах использования Tor, о том, что такое
Tor, или о том, как его использовать. Многие уже начали это делать на таких
сервисах, как: <a href="http://media.torproject.org/video/">Медиа сервар
Tor</a>, <a
href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,
и <a href="http://www.youtube.com/thetorproject">Youtube</a>.</li> 
<li>Создайте плакат или серию плакатов на такие темы как "Tor за Свободу!"</li>
</ol>

<a id="Coding"></a> <a id="Summer"></a> <a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Хорошие проекты по программированию</a></h2>

Возможно, вы посчитаете, что идеи некоторых из описанных ниже проектов
подходят для участия в <a href="<page gsoc>">Google Summer of Code
2010</a>. Мы снабдили каждую идею описаниями, учитывая то, насколько
полезной она могла бы быть для проекта Tor в целом (приоритет), насколько
трудоемок процесс её реализации (уровень трудоемкости), насколько
подготовлен должен быть разработчик (уровень подготовки), и кто из наших <a
href="<page people>#Core">главных разработчиков</a> мог бы руководить
процессом. Если какие-то из приведенных идей вам интересны, пожалуйста, <a
href="<page contact>">свяжитесь с нами</a>, чтобы обсудить ваши планы, это
лучше чем просто отправить «слепую» заявку. Вы можете также предложить свою
собственную проектную идею — из них, как правило, и получаются лучшие
приложения.

<ol>

<li>
Пакет Tor Browser Bundle для Mac OS X Приоритет: Высокий
 Уровень трудоемкости: Высокий Уровень подготовки:
Средний Возможные руководители: Steven, Erinn, Jacob,
Andrew В состав пакета Tor Browser Bundle входят такие приложения,
как Tor, Firefox, Polipo, и пользовательский интерфейс Vidalia (иногда в
состав также включен интернет пейджер <a
href="http://pidgin.im/">Pidgin</a>. Компоненты предварительно настроены для
безопасной работы, и практически не зависят от установленной операционной
системы. Именно поэтому пакет стал практически самым легким в использовании,
и популярным, способом использования Tor под операционной системой
Windows. Однако у нас до сих пор нет выпущенных пакетов для Mac OS X,
таким образом, идея этого проекта заключается в создании пакета Tor Browser
Bundle для OS X. Это потребует внесения изменений в Vidalia (C++), возможно,
в браузер Firefox (C), а затем создания запускающего модуля и тестирования
его на различных версиях операционной системы и на компьютерах различных
конфигураций, чтобы проверить портативность. Часть работы в этом направлении
уже была проведена в рамках Google Summer of Code 2009. Другая часть этого
проекта – это идентификация всех следов, оставляемых при использовании Tor
Browser Bundle на Mac OS X или Linux. Финальным шагом будет разработка путей
предотвращения, регистрации или удаления этих следов. Студенты должны
быть знакомы с разработкой приложений для одной или, желательно, обеих
операционных систем: Linux и Mac OS X, и иметь опыт работы с языками
программирования C/C++ и написанием сценариев командного процессора. 
Частью этого проекта могло бы быть тестирование практичности пакета Tor
Browser Bundle, в идеале среди нашей целевой группы. Это позволило бы нам
получить информацию о том, что еще можно сделать в области исправления
ошибок или добавления новых свойств. До настоящего момента мы получаем эту
информацию неформально, но более структурированный процесс был бы лучше. Бета версия пакета Tor Browser Bundle была выпущена для GNU/Linux, но
работать еще нужно над пакетом Tor IM Browser bundle. Работа в настоящее
время ведется и над созданием версий для Mac OS X. Если вы хотели бы помочь
в расширении или проведении проверки безопасности для одной из (или обеих)
этих версий, пожалуйста, свяжитесь с Erinn.
</li>

<li>
Помощь в отслеживании общего статуса Сети Tor Приоритет:
Средний - высокий Уровень трудоемкости: Средний 
Уровень подготовки: Средний Возможные руководители:
Karsten, Roger Было бы отлично создать автоматизированную
систему отслеживания работоспособности сети во времени, с составлением
графиков и т.д. Частью этого проекта должна стать разработка лучшей системы
измерения для оценки работоспособности и роста сети. Увеличивается ли
среднее время работоспособности сети? Количество ретрансляторов необходимое
для обеспечения Зеленого статуса в этом месяца в сравнении с прошлым
месяцем? Как изменилось количество ретрансляторов, сколько новых
ретрансляторов появилось, сколько старых прекратили свою работу?
Периодически люди собирают некоторую информацию, но действительно интересной
она становится только тогда, когда мы начинаем отслеживать изменения данных
во времени. Данные могут собираться с сетевых сканеров Tor в <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, с
описаний серверов, которые публикует каждый ретранслятор, и с других
ресурсов. Изменение результатов во времени могло бы быть интегрировано в
одну из веб-страниц <a href="https://torstatus.blutmagie.de/">Статуса
Tor</a>, или сохраняться отдельно. Говоря о страницах статуса Tor, взгляните
на <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">список
требований статуса Tor</a>, подготовленный Роджером.
</li>

<li>
Перепись TorDNSEL, в этот раз с учетом спецификаций! 
Приоритет: Высокий Уровень трудоемкости: Средний 
Уровень подготовки: Средний Возможные руководители: Mike,
Roger, Sebastian, Damian <a href="<page tordnsel/index>">Tor DNS
Exit List</a> – это необслуживаемая Haskell программа, которая служит
достижению следующих трех целей. Во-первых, она предоставляет DNS интерфейс
rbl-стиля для людей, желающих проверить, является ли данный IP-адрес
выводным ретранслятором Tor (или был ли он таковым в недавнем
прошлом). Во-вторых, она активно строит цепи внутри сети Tor и подключает их
к себе, определяя настоящий выводной IP-адрес каждого ретранслятора —
некоторые ретрансляторы Tor отправляют информацию не через те адреса,
которые они рекламируют в своих дескрипторах. В-третьих, она экспортирует <a
href="http://exitlist.torproject.org/exitAddresses">набор заключений</a>
так, что <a href="https://check.torproject.org/">check.torproject.org</a>
может определить, настроен ли ваш браузер на работу через Tor. В
рамках этого проекта должен использоваться <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, ,
набор сценариев Python для взаимодействия с Tor, для определения модели
того, как на самом деле должен работать определитель выводных узлов Tor,
затем эта модель должна быть построена — вероятно, на языке Python, так как
Torflow написан на этом языке программирования. Главная цель – уменьшить
число лжепозитивных ответов насколько возможно, путем обеспечения скорейшего
распространения информации о новых ретрансляторах, путем обеспечения скорого
завершения фазы тестирования, и путем обеспечения быстрого прохождения
ответов через сценарий проверки. В качестве бонуса мы должны
стандартизировать (специфицировать) формат файлов exitAddresses, и
переписать сценарий <a
href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">списка
выводных узлов Tor Bulk</a> для того, чтобы он использовал этот файл, а не
нынешние <a
href="https://trac.torproject.org/projects/tor/ticket/1019">ужасные DNS
обрезки</a>. В качестве дополнительного бонуса мы должны работать с
Freenode, OFTC, и/или другими IRC сетями, чтобы добиться того, что
предлагаемые нами сценарии действительно являются теми, которые они хотят,
исходя из точности определения пользователей, пользующихся услугами сети
Tor. Посредством git вы можете получить <a
href="git://git.torproject.org/git/tordnsel">самую последнюю версию
tordnsel</a>.
</li>

<li>
Усиление способности Tor противостоять цензуре Приоритет:
Средний - высокий Уровень трудоемкости: Средний -
высокий Уровень подготовки: Высокий Возможные
руководители: Roger, Nick, Steven В версиях Tor серии 0.2.1.x
сделаны <a href="<svnprojects>design-paper/blocking.html">значительные
улучшения</a> для противостояния национальной и организационной цензуре. Но
Tor все еще нуждается в улучшении механизмов для некоторых частей
противоцензурной структуры. Одна огромная категория работы – это
добавление новых свойств и характеристик в наш сервис <a
href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
bridgedb (Python). Целью Tor является предоставление <a href="<page
bridges>">адресов ретрансляторов типа мост</a> тем пользователям, которые не
могут напрямую подключиться к сети Tor, но конкуренция между алгоритмами для
распределения адресов и алгоритмами их сбора и блокировки – это гонка «нос к
носу». Для ознакомления прочитайте <a
href="<blog>bridge-distribution-strategies">пост на эту тему, который
доступен на нашем блоге</a>, а затем взгляните на <a
href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">пост
Роджера</a>, написанный в декабре, для получения более свежей информации —
впереди еще много конструкторской работы. Если вы хотите углубиться в
разработку Tor (C), более незначительной проблемой, которой нам нужно
заняться – это существующая в настоящее время возможность Tor слушать только
один единственный адрес/комбинацию портов в один период времени. Есть <a
href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">предложение,
нацеленное на отмену этого ограничения</a>, что позволило бы пользователям
подключаться к множеству доступных в сети Tor адресов и портов, но над этим
нам нужно еще работать. Этот проект мог бы включать как
исследовательскую, так и конструкторскую работу. Один из больших вызовов –
это идентификация и использование подходов, которые позволили бы
противостоять цензорам, даже если им известна структура нашей сети, после
чего нужно связать возможность нашего сервиса противостояния цензуре с
повышением его практичности и надежности.
</li>

<li>
Интерфейс контроллера статуса событий для Vidalia Приоритет:
Средний Уровень трудоемкости: Средний Уровень
подготовки: Низкий - средний Возможные руководители:
Matt Есть определенное число меняющихся статусов Tor, о
которых пользователь должен знать. Например, если пользователь пытается
установить свой Tor в качестве ретранслятора , а программа Tor определяет,
что необходимые порты не доступны вне пользовательской сети, нам нужно
сообщать об этом пользователю. На данный момент все, что получают
пользователи, это парочка сообщений в логе программы Vidalia, который они,
как правило, никогда не открывают, так как они не получают сообщений о том,
что что-то пошло не так. Даже если пользователь посмотрит на сообщения в лог
файле, большинство из этих сообщений будут непонятны для новичка. В
Tor реализована возможность информирования приложения Vidalia о многих таких
статусных изменениях, и недавно мы внедрили поддержку для парочки таких
событий. И все же еще есть множество статусных событий, о которых
пользователь должен быть проинформирован. Для этого нам нужен более
качественный пользовательский интерфейс, который будет отображать эти
изменения.Таким образом, целью этого проекта будет разработка и внедрение
пользовательского интерфейса для отображения статуса событий Tor
пользователю. Например, мы можем настроить отображение маленького значка на
иконке Vidalia, расположенной в системном трее. Этот значок предупреждал бы
пользователя о наличии статусных событий, на которые ей/ему стоит
взглянуть. Двойной клик на иконке мог бы вызывать диалоговое окно, в котором
суммируются последние статусные события в простых, понятных пользователю
терминах и, возможно, предлагаются решения для проблемных ситуаций. Конечно
же, это просто пример, и вы можете предложить любой другой подход. 
Человек, который возьмет на себя этот проект должно иметь хороший опыт в
разработке пользовательских интерфейсов и схем размещения, а также иметь
некоторый опыт в разработке приложений на языке C++. Предыдущий опыт работы
с Qt и Qt's Designer был бы очень полезным, но не является
обязательным. Умение писать на английском тоже было бы полезным, так как в
рамках этого проекта придется готовить вспомогательную документацию, которая
должна быть понятна не разбирающимся в технике пользователям. Бонусы будут
даваться за хороший графический дизайн, так как нам, скорее всего, скоро
тоже понадобятся новые яркие иконки.
</li>

<li>
 Усиление процесса тестирования элементов Приоритет:
Средний Уровень трудоемкости: Средний Уровень
подготовки: Средний Возможные руководители: Nick, Erinn
 Tor нуждается в более серьезном тестировании. Это многоэтапная
работа. Для начала число тестируемых элементов должно существенно
увеличиться, особенно это касается области находящейся вне служебных
операций. Для этого потребуется существенная перестройка некоторых частей
сети Tor для того, чтобы разделить глобальную сеть на логичные
компоненты. Дополнительно нам нужно автоматизировать нашу систему
тестирования производительности. У нас уже есть бот разработки для
автоматизации процесса тестирования стандартной интеграции и компиляции, но
нам нужно, чтобы кто-нибудь установил его на Windows. Нам также нужно
обновить тесты симуляции сети (как это реализовано в <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>) для
более новых версий Tor, чтобы они поддерживали запуск теста сети как на
отдельном компьютере, так и на нескольких, чтобы мы могли автоматически
тестировать изменения производительности на компьютерах, выполняющих
различные функции.
</li>

<li>
 Поддержка разработки независимых клиентов Tor Приоритет:
Средний Уровень трудоемкости: Высокий Уровень
подготовки: Средний - высокий Возможные руководители:
Bruce, Nathan Многие сейчас работают над разработкой клиентов
Tor для сред Java, Android, и Maemo. На первом этапе необходимо ознакомиться
с текущим состоянием проекта, в разработке которого вы хотите содействовать;
<a href="http://github.com/brl/JTor">Tor для Java</a>, <a
href="https://svn.torproject.org/svn/projects/android/trunk/">Android/Orbot</a>,
или <a href="<page docs/N900>">Tor для Maemo</a>. Проверьте нашу базу данных
и ознакомьтесь с исходным кодом. Далее, желательна поддержка запросов или
даже предоставление скрытого сервиса Tor, но это не обязательно. 
Потенциальный разработчик должен быть в состоянии понимать и писать новый
код для Java, включая API (Программный Интерфейс Приложения) криптографию
Java. Желательно также наличие навыков чтения кода языка C. Он/а
должна/должен иметь интерес к прочтению существующей документации, к
внедрению основанных на ней кодов, а также к доработке документации в тех
случаях, когда старая документация устарела. Этот проект, главным образом,
связан с написанием кода, и только немного – с разработкой.
</li>
<li>
 Больше разработки для ОС Orbot и Android Приоритет:
Средний Уровень трудоемкости: Высокий Уровень
подготовки: Средний - высокий Возможные руководители:
Nathan Работа над созданием пользовательского интерфейса
для Android Java: улучшение домашнего экрана для отображения более
подробной статистики по количеству переданных данных (отправлено/получено),
числу каналов связи, качеству соединения и так далее. Android приложение
"Tether Wifi" является хорошей моделью для отслеживания процесса переданных
данных, а так же сообщений о подключении wifi клиента. В дополнение более
гибкие возможности просмотра/работы с системой Tor /её сообщениями об
ошибках было бы тоже очень полезно. В конце концов, добавление мастера или
обучающего компонента для новых пользователей, наглядно объясняющего им, что
означает анонимизация или защита, сильно повысило бы вероятность того, что
пользователи будут корректно использовать Orbot. Работа над
приложениями Android Java ОС/Ядро: Улучшение системного индикатора
через панель уведомлений, всплывающие диалоговые окна или какой-то другой
индикатор того, что трафик приложения действительно проходит через
Orbot/Tor. Например, сейчас вам нужно сначала перейти на веб страницу сайта
проверки (torcheck), чтобы убедиться в том, что трафик вашего браузера
проходит через Tor. Orbot должен уметь уведомлять пользователя о том, что
каналы связи открыты, они используются и т.д. Упомянутый ранее счетчик
передачи данных также может осуществлять эту проверку и сообщать
пользователю результат. Библиотека Android Java/работа с
сообществом: Нам необходимо скомплектовать простую библиотеку для работы
со сторонними приложениями, чтобы позволить им легко поддерживать
"Торификацию" на некорневых устройствах (aka без прозрачной работы через
прокси). Эта библиотека должна включать в свой состав упаковщик для
библиотеки Apache HTTP клиента, сервисную программу для определения статуса
подключения Orbot, и другие важные/полезные инструменты, которые позволили
бы Android приложению анонимизироваться. Эта работа включает в себя создание
библиотеки, документации и образцового кода. После чего последует работа с
сообществом, чтобы внедрить библиотеку в другие приложения с открытым
программным кодом. Работа с Android ОС/C/Linux: Порт от
Tor до Android является практически прямо кросс-компиляцоннным к Linux
ARM. Не проводилось никакой работы по оптимизации Tor для мобильной
аппаратной среды, на процессорах ARM или другом оборудовании для Android,
или на мобильных сетях. Стоит отметить, что даже без оптимизации, Tor
отлично справляется с работой в среде мобильных сетей, автоматически
фиксируя изменение IP-адреса, переподключаясь к каналам и т.д. при переходе
от 2G к 3G к Wifi, и т.д. 
</li>

<li>
Новые возможности Torbutton Приоритет: Средний 
Уровень трудоемкости: Высокий Уровень подготовки:
Высокий Возможные руководители: Mike Есть
несколько <a
href="https://trac.torproject.org/projects/tor/report/14">хороших запросов
на разработку новых возможностей</a> в секции Torbutton Trac. В частности <a
href="https://trac.torproject.org/projects/tor/ticket/523">Интеграция 'Новой
личности' в Vidalia</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/940">пути управления
множеством куки</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/637">сохранение
специфичных куки</a> при очистке куки, <a
href="https://trac.torproject.org/projects/tor/ticket/524">лучший спуфинг
заголовков</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/564">корректировка
отчетности по статусам Tor</a>, а также <a
href="https://trac.torproject.org/projects/tor/ticket/462">URL-адреса
"tor://" и "tors://"</a>. Все это интересные свойства, которые можно было бы
добавить. Эта работа должна быть реализована независимо в Javascript
и веселом мире <a
href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
без сильного вмешательства во внутреннюю структуру Tor.
</li>

<!-- <li>

New Thandy Features
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Martin
 
Additional capabilities are needed for assisted updates of all the Tor
related software for Windows and other operating systems. Some of the
features to consider include:
<ol>
<li> Integration of the <a
href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
Python library</a>
for authenticated HTTPS downloads.</li>
<li> Adding a level of indirection
between the timestamp signatures and the package files included in an
update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
<li> Support locale specific installation and configuration of assisted
updates based on preference, host, or user account language settings.
Familiarity with Windows codepages, unicode, and other character sets
is helpful in addition to general win32 and posix API experience and
Python proficiency.</li>
</ol>
</li> -->
<li>
Симулятор медленного подключения к сети Интернет Приоритет:
Средний Уровень трудоемкости: Средний Уровень
подготовки: Средний Возможные руководители: Steven Многие пользователи Tor используют подключения к сети Интернет, имеющие
малую полосу пропускания, высокий уровень задержек и потерь. Согласно опыту
пользователей Tor плохо работает в таких условиях, но трудно улучшить
ситуацию без воспроизведения этих проблем в лаборатории. Целью
данного проекта было бы создание среды симуляции, которая воспроизводила бы
плохое качество связи с тем, чтобы мы могли измерять его влияние на
производительность Tor. Другим компонентом могла бы быть утилита для
тестирования с целью установления доступных свойств соединений, и измерения
эффекта модификаций, повышающих производительность сети Tor. 
Инструменты студент сможет выбирать самостоятельно, но dummynet (для
FreeBSD) и nistnet (для Linux) – это два потенциальных компонента, на
которых можно было бы построить этот проект. Студенты должны иметь опыт
сетевого программирования /отладки и TCP/IP, желательным также является
знание языка программирования C и одного скриптового языка.
</li>

<li>
Улучшение карты сети в программе Vidalia Приоритет: Низкий
- средний Уровень трудоемкости: Средний Уровень
подготовки: Средний Возможные руководители: Matt 
Одним из существующих характеристик программы Vidalia является наличие
сетевой карты, которая показывает пользователю приблизительное
географическое расположение ретрансляторов в сети Tor, а также отмечает
ретрансляторы, через которые проходит трафик пользователя, проходящий через
сеть Tor. Эта карта в настоящее время не является интерактивной и имеет
скорее плохую графическую реализацию. Вместо неё мы внедрили виджет Marble
(KDE), который предоставляет карту лучшего качества и позволяет улучшить её
интерактивность, добавив такие элементы как, например, выбор отдельных
ретрансляторов или каналов и отображение дополнительной информации. Мы хотим
дать пользователю возможность выбора конкретного ретранслятора или страны,
содержащей один-два выводных ретранслятора Tor и сказать, "Я хочу, чтобы мои
подключения выходили через этот ретранслятор/эту страну". В рамках
этого проекта студенту сначала нужно будет ознакомиться с программой Vidalia
и программным интерфейсом приложения Marble. После чего можно будет заняться
интеграцией виджета в программу Vidalia и подстроить Marble на работу с
нашим приложением. Например, мы хотим сделать каналы выбираемыми, сохранять
кэшированные данные с карты в собственном каталоге Vidalia, и настройка
некоторых свойств виджета. Человек, который возьмется за этот проект,
должен иметь хороший опыт разработки на языке C++. Желательным (но не
обязательным) является предыдущий опыт работы с Qt и CMake.
</li>

<li>
Эквивалент Torbutton для Thunderbird Приоритет: Средний
 Уровень трудоемкости: Высокий Уровень подготовки:
Высокий Возможные руководители: Mike Все большее
число пользователей хотят использовать Thunderbird через Tor. Однако есть
множество препятствий уровня приложений на пути реализации этой
идеи. Например, по умолчанию программа Thunderbird добавляет имя вашего
хоста в исходящие сообщения, которые она рассылает. На определенном этапе
нам нужно будет сделать еще один рывок для создания дополнения к программе
Thunderbird, аналогичного Torbutton.
</li>

<li>
Улучшение Tor Weather Приоритет: Средний 
Уровень трудоемкости: Средний Уровень подготовки:
Средний Возможные руководители: Christian, Roger,
Damian <a href="https://weather.torproject.org/">Tor weather</a>
– это инструмент, позволяющий подписаться и получать уведомления о сбоях в
работе отдельных ретрансляторов Tor по электронной почте. В настоящее время
этот сервис не особо полезен для тех, кто использует функцию гибернации Tor,
или тех, кому регулярно необходимо отключать их ретрансляторы. В рамках
этого проекта, Tor weather мог бы быть расширен до предоставления более
гибких конфигураций. Возможны и другие улучшения: сервис Tor Weather мог бы
рассылать предупреждения, когда ПО вашего ретранслятора устарело или когда
параметры ширины пропускания вашего канала падают ниже определенного
уровня. Он также может стать отличным инструментом, позволяющим отслеживать
достижения вашим ретранслятором бонусов (<a href="<page
tshirt>">Футболка</a>, или рассылать напоминания в директорию управления о
том, что их ключи скоро станут недействительными. Будьте креативными и
подумайте над тем, как вышеописанный проект по отслеживанию статуса сети
может помочь вам, быстрей закончить вашу работу! Также смотрите <a
href="https://svn.torproject.org/svn/weather/trunk/README">README</a> и <a
href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.
</li>

<li>
Улучшения взаимодействия Tor и Vidalia на платформах Linux/Unix Приоритет: Средний Уровень трудоемкости: Средний Уровень подготовки: Средний Возможные руководители:
Erinn, Peter В настоящее время приложение Vidalia не очень
хорошо работает с Tor на платформах Linux и Unix. Сейчас на системах Debian
и Ubuntu есть механизм конфигурации, который позволяет Vidalia изменять
свойство программы Tor, стартовать при загрузке
(sourcing/etc/default/tor.vidalia установлением параметра RUN_DAEMON=no at
the user's request), но полное внедрение взаимодействий <a
href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> все еще
требуется. Более эффективным решением для Linux и Unix платформ могло
бы быть использование функции ControlSocket программы Tor, которая позволяет
Vidalia взаимодействовать с Tor через доменный сокет Unix. Эту функцию можно
было бы активировать в дистрибутивных пакетах Tor по умолчанию. Vidalia
могла бы после этого аутентифицироваться в Tor, используя основанную на
файловой системе (куки) аутентификацию, если пользователь работающий с
Vidalia находится в Tor группе со специфической дистрибуцией. В
рамках этого проекта нужно будет сначала работать над добавлением поддержки
функции ControlSocket (программа Tor) в Vidalia. После этого студент
разработает и протестирует эту поддержку на различных системах, чтобы
убедиться, что она работает предсказуемо и стабильно на каждой из них. Другим важным вызовом было бы нахождение интуитивно понятного и удобного
пути реализации в программе Vidalia возможности изменять конфигурацию Tor
(torrc) даже если конфигурационный файл расположен в /etc/tor/torrc и
поэтому предназначен только для чтения. В системах Debian и Ubuntu мы
справляемся с этой проблемой с использованием вышеупомянутого
/etc/default/tor.vidalia, но эта функциональность могла бы (или должна) быть
менее зависимой от вида дистрибутива. Лучшая из имеющихся у нас на
данный момент идей, это внедрение новых конфигураций в Tor через
ControlSocket во время запуска программы Vidalia, но это плохо, потому что
если у пользователя установлена не последняя версия Debian/Ubuntu,
автозапуск Tor во время загрузки не отключен, а в такой ситуации конечная
конфигурация может быть далека от желаемой. Второй лучшей идеей было
написать временный конфигурационный файл torrc для Vidalia, и попросить
пользователей вручную перенести его в /etc/tor/torrc, но это плохо, потому
что пользователи не должны работать напрямую с программными файлами. 
Человек, который хочет работать над этим проектом, должен иметь начальные
знания различных дистрибутивов Linux и механизмов их комплектации, а также
иметь опыт разработки приложений на языке C++. Предварительный опыт работы с
Qt желателен, но не является требованием.
</li>

<li>
Тестирование практичности сети Tor Приоритет: Средний
 Уровень трудоемкости: Средний Уровень подготовки:
Низкий - средний Возможные руководители: Andrew 
Особенно в таком тестировании нуждается пакет Tor Browser Bundle, в идеале
тестирование должно производиться на целевой аудитории. Эта работа была бы
очень полезной, так как позволила бы нам узнать, что необходимо сделать в
плане исправления багов и добавления новых возможностей. Мы получаем эту
информацию неформально, но более структурированный процесс был бы лучше.
</li>

<li>
 Аутентифицирующий IRC прокси Приоритет: Низкий 
Уровень трудоемкости: Средний - высокий Уровень подготовки:
Средний - высокий Возможные руководители: Sebastian,
Weasel, Roger Миру нужен аутентифицирующий irc прокси. Как нам
периодически напоминает веб комедия Penny Arcade, "Интернет пользователь +
анонимность = придурок". В отношении веб сайтов все в принципе в порядке,
так как они могут сделать обязательной регистрацию пользователей и
использовать другие способы аутентификации на уровне приложений. Что же
касается IRC серверов, там ситуация намного хуже, потому что большинство IRC
серверов имеют очень слабое программное обеспечение: трудное в обслуживании,
и плохо поддающееся модификациям. Многие IRC сети в настоящее время
блокируют подключения от сети Tor, и в принципе исключением являются только
два сервера (OFTC и Freenode). Такое положение вещей говорит о том, что
множество людей по всему миру думают "я же тебе говорил(а)" об анонимности в
сети, хотя на самом деле проблема заключается в отсутствии технологии,
которая позволила бы исправить эту проблему. Нам нужен метод, позволяющий
IRC сетям определять, какие пользователи имеют хорошую репутацию, а какие –
плохую, чтобы политика в отношении этих двух групп была разная. Есть
несколько действительно отличных исследовательских разработок, как,
например, <a href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>, которая
позволяет веб сайтам создавать черные списки пользователей без необходимости
узнавать, кто они. Но Nymble разработана для взаимодействий в веб. Нам нужно
адоптировать протокол IRC к работе с такими программами как, Nymble (или для
начала более простой, в качестве утверждения концепции). Одним из методов
реализации этой идеи является встраивание IRC прокси, который умеет
«слушать» клиентов IRC, и знает как «говорить» с серверами IRC, и имеет
дополнительный слой, который требует аутентификации пользователей. Некоторая
работа в этом направлении уже была начата нашими волонтерами, ознакомиться с
прогрессом их работы можно здесь <a
href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.
</li>

<li>
Реализовать возможность torsocks/dsocks работать под ОС X 
Приоритет: Средний Уровень трудоемкости: Средний 
Уровень подготовки: Средний Возможные руководители: ?
 <a href="http://code.google.com/p/torsocks/">Torsocks</a> и <a
href="http://code.google.com/p/dsocks/">dsocks</a> являются оболочками,
которые управляют работой приложений, перехватывают их исходящие сетевые
соединения, и пропускают эти соединения через Tor. Целью является работа с
приложениями, которые не поддерживают прокси (или нестабильно через них
работают). Чтобы все работало стабильно, они должны перехватывать множество
системных сигналов. Системные сигналы, которые вам нужно перехватывать на ОС
Linux сильно отличаются от таковых на ОС BSD. Таким образом, Torsocks хорошо
работает на Linux, а dsocks – на BSD (хотя эта оболочка менее гибкая, то
есть может давать сбои при работе с некоторыми системными сигналами). Нет ни
одной оболочки, которая хорошо работала бы на двух вышеуказанных
платформах. Во-первых, нам нужно пропатчить dsocks, чтобы она могла
использовать mapaddress команды Tor от интерфейса контроллера, чтобы
нам не пришлось проходить ненужный путь внутри Tor перед
подключением. Во-вторых, нам нужно сделать так, чтобы наш скрипт
торификации мог определять, torsocks или dsocks установлен. На основе
этого решения будет выбран «язык общения» с этой оболочкой. Это, скорее
всего, приведет к унификации их интерфейсов, и может возникнуть
необходимость обмена участками кода между ними или полного отключения одного
из них.
</li>

<li>
 Привносите свои идеи! Не нравятся эти идеи? Взгляните на <a
href="<svnprojects>roadmaps/2008-12-19-roadmap-full.pdf">план развития сети
Tor</a> и ознакомьтесь с другими идеями, или просто попробуйте использовать
Tor, Vidalia, и Torbutton, и узнайте, что на ваш взгляд должно быть
доработано. Некоторые из <a href="<gittree>doc/spec/proposals">актуальных
предложений</a> могут нуждаться в разработчиках.
</li>

</ol>

<a id="OtherCoding"></a>
<h2><a class="anchor" href="#OtherCoding">Другие идеи, касающиеся программного
кода и дизайна</a></h2>
<ol>
<li>Ретрансляторы Tor нестабильно работают под ОС Windows XP. На Windows Tor
использует стандартный <tt>select()</tt> системного сигнала, который
использует пробел в безстраничном пуле. Это означает, что ретранслятор Tor
среднего размера опустошит безстраничный пул, <a
href="<wiki>WindowsBufferProblems">вызывая опустошение и системные
сбои</a>. Нам, вероятно, стоит вместо этого использовать ввод-вывод с
перекрытием. Одним из решений было бы обучить <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> тому, как
использовать ввод-вывод с перекрытием вместо select () на ОС Windows, а
затем адаптировать Tor к новому интерфейсу libevent. Christian King сделал
<a href="https://svn.torproject.org/svn/libevent-urz/trunk/">хороший
старт</a> в этом направлении летом 2007.</li>

<li>Нам надо действительно начать разработку нашего <a href="<page
documentation>#DesignDoc">проекта противостояния блокированию</a>. Эта
работа будет включать изменение общего дизайна, модификацию множества
различных частей Tor, адаптацию <a href="<page vidalia/index>">Vidalia</a>
для поддержки новых характеристик, а также планирование их внедрения.</li>

<li>3.Нам нужна гибкая структура симулятора для изучения сквозных атак
подтверждения приема трафика. Многие исследователи на скорую руку создали
несовершенные симуляторы с упрощенной функциональностью. Можем ли мы создать
симулятор, достаточно открытый и с хорошей документацией, которому все
смогут доверять? Это привело бы к возникновению массы новых
исследований. Ознакомьтесь с информацией <a href="#Research">об атаках
подтверждения</a> для получения более детальной информации об
исследовательской части этого задания. Кто знает, когда эта работа будет
завершена, возможно, вы тоже можете написать один, два документа.</li>

<li>Программа Tor версии 0.1.1.x и выше поддерживает аппаратные
криптографические акселераторы через OpenSSL. Эту функцию почти не
тестировали, поэтому она может иметь множество багов. Мы надеемся в
ближайшее время провести тщательное тестирование, анализ производительности,
оптимальным было бы также исправить багги в openssl и, если понадобится, в
Tor.</li>

<li>Провести анализ безопасности Tor с использованием <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Определите,
есть ли хорошие библиотеки fuzz, которые подошли бы нам для проведения
анализа. Станьте популярным из-за того что мы выпустим новый релиз благодаря
вам!</li>

<li>Сеть Tor использует TCP для транспорта и TLS – для шифрования. Это хорошо и
просто, но при выпадении одного пакета, все ячейки соединения запаздывают, и
это означает, что в полной мере мы можем поддержать только потоки TCP. У нас
есть <a
href="<wiki>TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">список
причин, по которым мы не перешли на использование транспорта UDP</a>, но мы
хотели бы, чтобы этот список становился короче. Мы также предложили <a
href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">спецификацию для Tor
и UDP</a> — пожалуйста, сообщите нам, если вы нашли в ней ошибки.</li>

<li>Мы не так далеки от реализации поддержки IPv6 для целевых адресов (на
выводных узлах). Если вы очень серьезно заинтересованы в IPv6, с этого,
вероятно, вам и стоит начать.</li>

<li>Нам нужно найти способ генерирования диаграмм для веб-сайтов. Например,
работа над картинками "Как работает Tor " на <a href="<page
overview>">странице обзора</a> Нам нужно сделать так, чтобы мы могли
переводить их, просто добавляя текст UTF-8, а не вручную с использованием
программы Gimp. Возможно, мы захотим интегрировать эту функцию с помощью
файлов *.wml, так чтобы перевод можно было бы сделать легко, а картинки бы
генерировались на различных языках каждый раз, когда мы создаем веб-сайт.</li>

<li>Как нам упростить работу с различными LiveCD/USB системами, улучшить её и
документировать? Одним из примеров является <a
href="https://amnesia.boum.org/">Система (Amnesic) Incognito Live</a>.
</li>

<li>
Другим анти цензурным проектом является улучшение способности Tor
противостоять сканированию. В настоящее время наш соперник может
идентифицировать <a
href="<gitblob>doc/spec/proposals/125-bridges.txt">ретрансляторы Tor типа
мост</a>, просто осуществляя попытки подключения к ним, следуя протоколу Tor
и определяя, отвечают ли они. Чтобы решить эту проблему, мосты во время
контакта со сканирующими порты инструментами могли бы <a
href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">вести себя как
веб-серверы</a> (HTTP или HTTPS) до тех пор, пока пользователь не
предоставит свой специфичный данному мосту ключ. Чтобы начать работать в
этом направлении, ознакомьтесь с <a
href="http://dl.dropbox.com/u/37735/index.html">тезисом и прототипом</a>
Шэйна Поупа (Shane Pope).
</li>

</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Исследования</a></h2>
<ol>
<li>"Сквозная атака подтверждения трафика": просматривая трафик Алисы и Боба, мы
можем <a href="http://freehaven.net/anonbib/#danezis:pet2004">сравнивать
подписи трафика и с уверенностью говорить о том, что мы просматриваем один и
тот же канал</a>. На данный момент проект Tor принимает это как данность и
предполагает, что такая атака является тривиальной во всех
случаях. Во-первых, правда ли это? Сколько трафика, и от каких каналов
необходимо нашему сопернику, чтобы он был уверен в своей победе? Есть ли
сценарии (например, передача малого объема данных), которые усложняют
подобную атаку? Работают ли одни схемы заполнения и формирования трафика
лучше, чем другие?</li>
<li>Относящийся к теме вопрос: Обеспечивает ли предоставление
ретранслятора/моста дополнительную защиту против подобных атак? Может ли наш
условный противник извне, который не может видеть содержимое TLS ссылок, все
же с уверенностью распознавать отдельные потоки? Влияет ли объем трафика,
проходящий через узлы на возможность реализации подобных атак? Что если
клиентский ретранслятор умышленно увеличивает задержки при отправке
исходящего трафика, чтобы создать очередь, которую можно было бы
использовать для имитации временных характеристик клиентского входящего
трафика, чтобы он выглядел как перенаправленный через ретранслятор? Эта же
очередь могла бы быть использована для маскировки временных характеристик
исходящего трафика клиента с использованием метода <a
href="http://www.freehaven.net/anonbib/#ShWa-Timing06">адаптивного
заполнения</a>, но без необходимости в дополнительном трафике. Будет ли
подобный интерливинг исходящего трафика клиента скрывать временные
характеристики для внешних недоброжелателей? Придется ли адоптировать
стратегии для асимметричных ссылок? Например, на асимметричных ссылках,
действительно ли возможно отличить трафик клиента от стандартных пакетов
данных на основе их асимметричной разрядности? Или это проще чем с
симметричными ссылками по другой причине?</li>
<li>Повторить <a
href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">атаку из Окленда
05</a> , осуществленную Мардохом и Дэнезисом против сети Tor в её нынешнем
виде. Подумайте, возможно, вы могли бы узнать, почему атака работает на
одних узлах и не работает на других. (Согласно моей теории более быстрые
узлы с резервом производительности лучше противостоят атакам.) Если это
правда, тогда экспериментируйте с функциями RelayBandwidthRate (Уровень
пропускной способности ретранслятора) и RelayBandwidthBurst (Разбивка на
пакеты ретранслятора), предоставляя ретранслятор, который используется как
клиент, ретранслируя трафик атакующего: если мы снижаем значение
RelayBandwidthRate, усложняется ли атака? Каково правильное соотношение
значения параметра RelayBandwidthRate к текущей производительности? И
зависит ли успех атаки от этого соотношения вообще? Во время этой работы,
увеличивает ли наличие большего числа кандидатских ретрансляторов число
ложно позитивных ответов, и усложняется ли процесс реализации атаки? (Сеть
Tor в настоящее время выросла уже почти в два раза по сравнению с тем, какой
она была в момент написания отчета об атаке.) Убедитесь, что вы также
ознакомились с документом <a
href="http://freehaven.net/anonbib/#clog-the-queue">Не задерживай
очередь</a>.</li>
<li>«Атака маршрутизирующих зон»: в большинстве источников сетевой путь от Алисы
и её вводного узла (и от выводного узла до Боба) описывается, как одно звено
на определенном графике. Хотя на самом деле путь проходит через множество
автономных систем (АСы), и <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">это не удивительно,
что один и тот же АС появляется как на пути туда, так и на пути
обратно</a>. К сожалению, чтобы точно предсказать насколько опасной будет
путь Алиса, вход, выход, Боб, нам нужно скачать всю маршрутизирующую зону и
провести дорогой их анализ. Есть ли более практичные аппроксимации, такие
как избегание IP-адресов в одной сети /8?</li>
<li>Другие вопросы исследований, относящиеся к географическим различиям,
включают компромисс между выбором эффективного и выбором случайного
канала. Ознакомьтесь с <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">исследованием
местоположений</a> и узнайте, как заведомо отменить выбор особенно медленных
каналов, чтобы это не имело сильный негативный эффект на вашу
анонимность. Эта цепочка суждений нуждается в дальнейшей доработке и
переосмыслении, но, похоже, является очень обещающей.</li>
<li>Сеть Tor не очень хорошо работает на ретрансляторах, имеющих асимметричную
полосу пропускания (например, кабель или DSL). Так как Tor образует
отдельные TCP подключения между сетевыми сегментами, если входящие байты
поступают нормально, а исходящие байты теряются в пути, механизмы обратного
сообщения TCP не передают эту информацию на входящие потоки. Наверно Tor
должен уметь определять потерю исходящих пакетов, и лимитировать входящие
потоки, для саморегуляции? Я могу представить себе схемы нарастания и
сброса, при которых мы вбираем стандартное ограничение скорости, медленно
увеличиваем его до тех пор, пока произойдет потеря пакетов, возвращаемся к
исходной позиции и повторяем эксперимент. Нам нужен человек, хорошо
разбирающийся в сетях, чтобы симулировать этот процесс и помочь
сконструировать решения; и/или нам нужно лучше понять увеличение спада
производительности, и использовать это в качестве мотивации для пересмотра
концепции транспорта через UDP.</li>
<li>Относящийся к теме вопрос – это контроль над перегрузкой. Будет ли
существующая конструкция сети эффективной при более интенсивном
использовании? Возможно, нам стоит экспериментировать с изменяемыми, а не
фиксированными окнами? Похоже, это хорошо работает, что было показано во
время <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">эксперимента
с пропускной способностью ssh</a>. Нам понадобится провести ряд замеров и
подстроить систему, а возможно и реконструировать её в случае, если
результаты будут многообещающими.</li>
<li>К нашим целям противостояния цензуре относится также предотвращение
возможности атакующего, просматривающего трафик Tor на проводе, <a
href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">отличать
его от обычного SSL трафика</a>. Очевидно, что мы не можем достичь идеальной
стеганографии, оставляя Tor практичным, но для начала мы хотели бы
блокировать любые потенциально успешные атаки, осуществляемые путем
просмотра лишь нескольких пакетов. Одна из атак, которую мы до сих пор не
исследовали в достаточной мере, заключается в том, что пакеты Tor имеют
размер в 512 байтов, так что трафик в проводе будет кратен 512-ти
байтам. Насколько пакетирование и служебные данные в записях TLS смазывают
это свойство? Имеют ли различные стратегии смещения буфера в Tor влияние на
это? Могло бы незначительное добавление дополнительных битов к блокам данных
исправить эту ситуацию или нам просто нужно смириться с этой атакой?</li>
<li>Каналы Tor строятся в один сетевой сегмент за определенный отрезок времени,
таким образом, в теории у нас есть возможность настроить выход некоторых
потоков из второго сетевого сегмента, других – из третьего и т.д. Это,
похоже, было бы отлично, потому как нарушает последовательность исходящих
потоков, которые может «видеть» данный ретранслятор. Но если мы хотим, чтобы
каждый из потоков был надежным, «кратчайший путь» должен состоять как
минимум из трех сегментов сети (согласно нашей нынешней логике), так
остальные будут еще длиннее. Нам нужно изучить этот компромисс
производительности / безопасности.</li>
<li>Совсем не тяжело подвергнуть ретрансляторы Tor или директории управления
DoS-атакам. Является ли аутентификация клиентов правильным ответом? Какие
другие практичные подходы существуют? Было бы отлично, если бы они были
совместимы с существующим протоколом Tor.</li>
<li>Цель программ типа <a href="<page torbutton/index>">Torbutton</a> – скрывать
строку UserAgent вашего браузера путём замены её на стандартный для каждого
пользователя Tor вариант текста. При таком раскладе атакующий не может
взломать анонимность Tor, проверив заголовок. Программа пытается выбрать
вариант строки, который часто используется другими пользователями сети
Интернет, которые не используют сеть Tor, чтобы не отличаться от них. Вопрос
первый: насколько мы вредим себе, периодически обновляя версию браузера
Firefox, которую заявляет в вышеописанных данных Torbutton? Если мы
обновляем версии слишком часто, мы сами взламываем свою анонимность. Если мы
не достаточно часто обновляем её, то все пользователи сети Tor будут
отличаться от других устаревшими версиями браузера Firefox. Ответ здесь
зависит от непредсказуемой частоты выхода новых версий Firefox. Вопрос два:
периодически пользователи просят нас использовать некоторое число строк
UserAgent, а не останавливаться на использовании одной. Окажется ли этот
подход результативным, навредит ли он, или ничего не изменит? Примите во
внимание: куки и распознавание пользователей Torbutton по изменяющемуся
содержимому строки UserAgents; вредоносные веб-сайты, атакующие только один
определенный тип браузеров; и влияют ли ответы на первый вопрос на ответ ко
второму вопросу.
</li>
<li>В настоящее время клиенты Tor хотят повторно использовать определенный канал
в течение 10 минут после первого использования. Цель – избегание загрузки
сети с излишне большим количеством операций расширения канала, но в то же
время важно не допустить длительного использования клиентами одного и того
же канала, чтобы выводные узлы не могли создать их достаточно содержательный
псевдонимный профиль. Увы, 10 минут это слишком длинный промежуток времени,
тем более, если подключения через множество протоколов (например, Интернет
пейджер и веб браузер) проходят через один и тот же канал. Если мы установим
общее число расширений канала, которые необходимы для успешной работы сети
Tor, есть ли более эффективные и/или безопасные пути распределения клиентами
потоков по каналам, или создания клиентами простых/примитивных каналов?
Возможно, предмет этого исследования должен начаться сбором некоторых
примеров того, какие подключения пользователи, как правило, пытаются
запускать, чтобы был реальный материал для исследования того, что должно
быть оптимизировано.
</li>
<li>Сколько ретрансляторов типа «мост» вам нужно знать, чтобы обеспечить доступ?
Мы должны измерить нагрузку на наши «мосты». Если нагрузка слишком высока,
есть ли пути стимулирования пользователей, предоставляющих ретрансляторы
типа «мост», как можно дольше оставаться в сети?
</li>
</ol>

<a href="<page contact>">Сообщите нам</a>, если у вас есть успехи, в
реализации какой-либо из вышеописанных идей!

</div>

#include <foot.wmi>

tor-webwml.git

new and updated translations for the website