Такая идея уже мелькала - пожертвовать трафиком и сделать каждого клиента одновременно и прокси-анонимайзером без логов, исключительно для ослиных нужд, не паблик. Тогда я буду качать через васю, а вася - через меня. И если теща возьмет кого-то за грудкИ, то обломится, т.к. достаточно показать клиента. Информацию о таких свойствах следет аршинными буквами написать в manual, и теща сама не полезет, т.к. будет знать, что ничего не поимеет. И будет 100% алиби, что качал не ты, а кто - ты понятия не имеешь и никак определить сам не можешь - что-то от фринета. Ослиный сервер может сам сводить вместе таких клиентов, или же клиент может получать список от другого клиента самостоятельно.
Тонкости можно решить потом. Главное:
1) Является ли твоим алиби то, что ты сам не качал, а качал кто-то через твой комп? Или ты все равно отвественен? Думаю, что нет, т.к. иначе владельцы ньюсов (alt.binaries.*) и некоторых анонимных паблик прокси уже были бы на нарах.
2) Готовы ли пользователи пожертвовать половиной bandwidth для анонимности? А может быть и меньше, скажем, 10% но с шатким алиби, я бы предпочел ВСЁ вести через другого клиента, а не часть. С другой стороны, во фринет скачать что-то крупное - абсолютно дохлый номер, но есть же и там энтузиасты файлообмена.
3) Можно ли это реализовать ограничившись изданием нового мода?

https://netlab.e2k.ru/forum/index.php?showtopic=20185

В том топике разговор ушел в сторону. Мне бы хотелось получить ответы на конкретные технические и юридические вопросы, реально ли написать клиента и решит ли это вопрос тещи. Без споров о фринете и других сетях.

Я уверен, что будущее именно за такими системами.
Посмотрите на skype от авторов KaZa, он работает именно по такому принципу, каждый пользователь является прокси, через него люди сидящие за NAT-ом устанавливают соединения между собой.
Что касается юрической стороны, то мне кажеться, что докопаться тут не некчему если использовать криптографию с асимметричным ключом. Прокси даже если закочет не сможет прослушать трафик.

Спорим, что через некоторое время выйдет KaZa c поддержкой такого протокола?

А ты можешь рассказать подробнее, как тебе это видится? Т.е. конкретно - у тебя есть файл, ты его шаришь, как тебя должны находить люди и тп... Чисто абстрактно мне кажется, что релизы просто встанут - наши 10к будут делится между проксей и отдачей релиза...

То, что ресурсы придется делить - это безусловно так, и это самый большой минус, но за безопасность+удобство нужно платить. Удобство в том, что файл могут качать два пользователя с LowID т.е. сидящих за NAT-ом или прокси.
Нужно будет выставлять Up, Down, Transit. Можно будет их как-то интеллектуально комбинировать, например, если Up или Down использует не всю полосу, то излишек отдается в Transit.
Передача файла - классический туннель, обмен ключами и трафик пошел.
Самое сложное - поиск. Детально я не обдумывал, но в общих чертах можно пофантазировать о прототипе протокола.
Основная идея - источники шифруются с использованием ассиметричной криптографии, прокси сам не знает, то что он ищет. Открытый ключ генерит eDonkey-сервер, клиент шифрует им свой запрос и отдает его прокси. Информацию о IP-адресах(без открытого хеша файла) получает только прокси.
Система будет надежной, если eDonkey-сервер не будет "поддельным", он выступает как удостоверяющий центр.

Если есть реальный интерес и возможна реализация как дополнения к мулу, то давайте прорабатывать вопрос плотнее.

В данный момент меня интересует один важный вопрос - поиск как таковой меня волнует мало, ибо я уже давно им не пользовался - как (в маштабах сети, а не локальной компьюнити) ты хочешь сделать вот что: у меня есть файл ХХХ, я его хочу рассшарить и даю на него линк\хэш. Чтобы меня найти - мой ИП должен быть где-то записан - зная хеш, я могу запросить место, где записан мои ИП и получить оный. То, что я должен запросить не сервер, а прокси-клиент и он от моего имени должен запросить сервер - мне кажется, дела не меняет... Не говоря уже о поддельных донк серверах...

Мне кажется, проще добиться анонимности спуффингом (подстановкой фиктивного обратного адреса в заголовках IP пакетов).
На некотором удалении от провайдера обнаружить, откуда поступают такие пакеты будет чрезвычайно проблематично.

Спуффинг работает у многих провайдеров.
Если не указывать чей-то чужой адрес, не отсылать незапрошенные пакеты, то он юридически законен (это просто анонимный пакет).

Правда есть сложная проблема - нужно спроектировать протокол контроля интенсивности трафика, в чём-то подобный TCP, для того, чтобы клиент имел возможность каким-то образом сообщать серверу, что трафик слишком интенсивен, или - наоборот.

Причём напрямую сообщаться нельзя (а вдруг сервер запустила тёща!) - только пакетами с неверным обраным адресом, через посредников, алгоритм работы которых должен сводить вероятность прослеживания адреса клиентов и других посредников к разумному минимуму. Посредникам, естественно, также нельзя доверять, но хороших людей больше чем плохих поэтому посредников должно быть как минимум несколько, расположены в разных странах и сетях, не принадлежащих тёще.

Конечно, желательно чтобы этот алгоритм автоматически балансировал нагрузку, маршрутизировал трафик по пседослучайному закону, при этом не имея каких-нибудь постоянных идентификаторов и т.п., но для начала главное - чтобы он вообще работал

Придумать такой алгоритм трудно...

Зато при его использовании через "систему прокси" будет идти только небольшой управляющий трафик.
Проблема bandwich возможно будет решена.

This post has been edited by gorilka on 12-11-2003, 19:06

Под поиском я имел в виду не поиск хеша по имени файла, а именно поиск IP-адреса+порта.
Исходим из того, ослиный сервер не поддельный.
Допустим я (сервер) расшарил файл. Соединяюсь с ослосервером отдаю ему хеши расшаренных файлов. Т.е. теперь сервер знает мой IP и при поиске по хешу готов его отдать.
Есть человек (клиент) который хочет скачать файл и знает его хеш. Он идет на ослосервер и говорит "хочу". Тот говорит - иди за файлом на такой-то (случайно выбранный) прокси. Клиент идет на прокси, прокси идет серверу (или сервер идет к прокси для LowID). Клиент и сервер обмениваются ключами и начинают качать файл.
Прокси знает IP-адреса обоих, но не знает, что через него качается (хеш файла). А клиент и сервер знают хеш, но незнают IP-адресов друг друга.

Слабое место - ослосервер, он знает и IP-адреса и хеши, поэтому важно, чтобы он был неподдельным.
Если усложнить алгоритм, то думаю этот недостаток можно устранить. Как именно - я не готов сходу ответить, нужно подумать.

Если передавать список расшаренных файлов без шифрации, то об этом будет знать либо сервер, либо прокси, если к серверу обращаться только за списком прокси. Вариантов нет, ближайщий сосед будет всегда в курсе при процессе расшарки. Мне кажется проще иметь доверенный сервер, чем неизвестно чей прокси-клиент. Тогда достаточно иметь фильтр для списка серверов и идти только на проверенные сервера. Этот метод будет уже достаточно эффективным и можно будет смело лазить по крайней мере на NNOV и некоторых других. Схема IP-фильтрации в некоторых уже существующих модах бесполезна, т.к. скачка идет напрямую и достаточно начать качать, как будет ясно у кого что расшарено. Достоинство - такую феньку можно сделать прямо сейчас, только придумать рейтинг прокси, и давать кредиты наиболее толстым прокси-каналам. Также можно использовать одновременно несколько прокси для связи, если одного не хватает. Достаточно жестко привязать скорость аплоада к лимиту на прокси-канал и все сами побегут делиться bandwidth. Вот только как быть с личерами? Разве что мод сделать закрытым, без исходников.

Если вы хотите чтобы сервер тоже не знал, и никто один не знал, у кого расшаренный файл, то надо обдумать схемы шифрации двумя ключами и разбросать ключи между сервером и прокси. Как - не знаю, не спец.

На самом деле такая (почти )система есть - единственное отличие, это то, что баунсер там отдельно - http://www.filetopia.org/

Filetopia основана, вроде бы, на одном сервере. И технология там совершенно другая. Речь идет о развитии именно ослосети.

Я не столько про технологию конкретную, сколько про ее отдельные компоненты - шифрования трафика, баунсер - это в чистом виде прокси, просто она отдельно. Я не против и осолосеть развить - только пока не видно того, кто это будет программить....

LF:
Ты случайно не в курсе, как дела с написанием OpenSourсe ослосервера (e-farm)?
Он уже в работоспособном состоянии?
Мне кажется, что средствами только клиента предлагаемую схему не реализовать.

Да, вполне - они там вроде месяц назад начали финальное тестирование нового релиза... Вроде как там речь идет о всяких наворотах - базовые вещи работают...