Комментарии 225
А потом придёт ФСБ и попроситК кому это оно придёт? К каждому из миллиона пользователей? Замучается приходить.
Впрочем… Если процесс будет развиваться как сейчас, то общество разделится на две примерно равных части: одни будут приходить, к другим будут приходить. Вот тогда удастся охватить всех.
если это им обеспечит храенение и передачу информации куданадо
полагаете вк или майл.ру не хватает своих ресурсов настолько что они заморочаться на п2п?
предполагаю, что экономия никому еще не мешала, вот налоговая перестает слать письма почтой при перво заходе в их ЛК — это экономия, я не думаю что у налоговой нет денег на почту…
Когда Дуров продал ВК фирме Майл.Ру — он не продал датацентр, железо, сервера.
Видимо, Майл.Ру, также как и вы, поначалу считала, что сэкономила.
И начала Майл.Ру постепенно переезжать, но при этом продолжала платить Дурову за сервера арендную плату.
Год вроде фирма Майл.Ру пыталась это сделать… Как впоследствии оказалось — безуспешно.
Ибо в в конечном итоге решила фирма Майл.Ру, что дешевле будет выкупить датацентр вКонтакте со всем железом, чем менять базис, на котором основан сервис вКонтакте.
Так Дуров дважды продал вКонтакте фирме Майл.Ру.
К каждому не надо, достаточно прийти к паре сотен (в месяц), посадить лет на восемь за измену родине и раструбить в СМИ, остальные забоятся.
shifttstas прав, конечно, государств много, но вам это вряд ли поможет — не будете же вы менять государство из-за какого-то мессенджера, если до сих пор всё устраивало.
Какие именно случаи? Сажают на восемь лет? Я не в курсе, VK не пользуюсь, поясните, пожалуйста.
Очень интересно.
Мне казалось, это такая cамодеятельность служивых людей на местах, проявления палочной системы и сведение личных счётов, а соответствующего госзаказа нет.
Возможно, что я неправ — я за новостями не слежу, подписан только на профильные сайты, сиськи, котиков и башорг.
Не могли бы вы дать пару ссылок на тексты решений судов?
Тут подробней: graniru.org/Society/Law/m.261472.html
Прения только начались, решения ещё нет, судят даже не случайного человека лайкнувшего мемасик, а активистку, так что меня это не коснётся, я же не оппозиционер.
Нет, ничего не значит. Если сбил ребёнка на переходе — ничего не значит последователь ли ты Навального или племянник прокурора. Ну, при нормальной судебной системе не значит. А при имеющей место быть пародии, конечно же значит, увы…
Ничего не должно значить, если вы оцениваете справедливость законов и правоприменительной практики.
И даже если вы считаете себя "неуловимым джо" — вы или ваши близкие можете быть на её месте. Ну знаете "Сначала они пришли...", да?
Таким образом любые такие обращения пресекаются на корню: код открыт, доступен всем, а никаких общих ключей просто нет, добывайте сами на устройствах пользователей как хотите, господа хорошие.
Серверов тоже нет — точки давления в сети просто нет, не на что надавить, нечего блокировать, нечем пугать.
Единственный вектор атаки — непосредственно угрозы физической расправы на разработчиков, и требование внести в код изменения, ослабляющие защиту.
С этим столкнулись многие компании, и все они прогнулись — увы, модель коммерческой разработки такого софта тупо нежизнеспособна в принципе. На любую компанию можно надавить, налогами, проверками, лицензиями.
Вспомним историю того же трукрипта — давление оказалось таким, что разработчики, спасаясь, вынуждены были уничтожить свой сайт и прекратить разработку. Решили погубить проект, лишь бы не делать дырок в угоду спецслужбам.
Именно такой выбор и остается, и большинство сверлят дырки — касается всех сотовых операторов например, соцсетей, и т.п. массовые продукты.
Соответственно для такого мессенджера не выйдет оформить право собственности и оставить себе какие-либо рычаги контроля — все это сразу делает вас, и ваше детище, уязвимым для внешнего воздействия.
Остается только полностью открытая разработка со свободной лицензией.
В таком случае у спецслужб остается последний канал воздействия: пилить закладки в софт.
Это лучший вариант, т.к. по крайней мере код открыт, и у сообщества есть высокий шанс противодействовать такому, находить и блокировать источники закладок.
А система доставки подписанного кода давно и хорошо проработана — весь софт подписывается ключами, которые автоматически проверяются при установке, а для параноиков всегда есть возможность все собирать самому
От постоянной передачи по блютусу\вайфаю телефоны и полдня не проживут. Но идея мне нравится.
Как повезёт, я не утверждаю, что будет экономия, но догадываюсь, что будет примерно так же как сейчас. А при загрузке больших файлов (типа видео) может быть даже появится экономия из-за соседей — источников.
Вряд ли 5%.
Попробуйте включить на телефоне хотспот и посмотреть через него фильм, да ещё тремя устройствами сразу — часа через три сядет. Лопата — через четыре.
Думаю, у чата и трафик копеешный, попробуйте пораздавать локально с телефона видосики минут сорок на десяток устройств с постоянным реконнектами.
Ну и модем тоже ж никуда не пропадёт, будет постоянно в сети, ждать звонков, докачивать отсутствующий у соседей контент.
Давайте возьмем конкретный пример. Телеграм в фоне обновляет ленты переодически, так он это делает через модем, переводя его в активное состояние и потребляя энергию (прямо пропорционально удаленности БС кстати говоря) в случае с wi-fi — мы гарантировано взаимодействует с ближайшим устройством не включая модем.
1. Простое добавление в группу/чат/канал людей (Например вы — студент или родитель на собрании или турист в группе и гид/учитель/староста создал чат, вместо муторного сканирования QR кодов/шаринга ссылки — можно просто поставить опцию — сделать чет видимым рядом находящимся на N минут — и все его увидят сразу)
2. Простая отправка файла/чат с соседом — у Apple файлы могут быть отправлены через AirDrop, ровно такой же принцип только для обычного чата (кейс — надо что-то передать по быстрому с ранее не известным человеком, открываем видимость себя в настройках и оп — второй человек видит в списке вас и отправляет вам всё что надо) дополнительным бонусом идет не раскрытие номера телефона
3. Помощь с доступом чащего всего, Wi-Fi в мире, безлимитный по объему трафика, почему бы мессенджеру не предоставить возможность работать через другой телефон который подключен к wi-fi сети (Кейс — вы заграницей и у вас не работает интернет, но рядом есть пользователь с подключением по wi-fi к своей домашней сети — можно подключится к серверам мессенджера в урезанном варианте — например передача только текста, без мультимедия) по идее никого из этой схемы ни за что привлечь нельзя, доступа в интернет как таковой — нет, только к мессенджеру.
Вы поддерживаете идею Mesh сети из вашего мессенджера?Да, я поддержу любую фичу, которая будет не по зубам Роскомнадзору.
Как только вы зайдете в вагон, приложение соединится с аналогичным приложением и начнет обновлять контент через него.
Через что соединится-то?
То есть вместо двух соединений (одно по BT с моими наушниками, и второе по соте) телефону придется держать минимум четыре (потому что чтобы была сеть, нужно, чтобы каждое устройство держало как минимум два соединения), два из них — с недоверенными устройствами, и постоянно прокачивать через себя чужой трафик? Спасибо, но нет, и батарейка не вечная, и безопасность моя мне дороже.
Собственно в посте я и рассматриваю то, что на безопасность это не повлияет от слова совсем.
Да разве? У вас есть гарантия, что P2P соединение двух устройств не дает поверхности для атаки?
Единственное что может быть видно соседям (если не сильно усложнять алгоритм, хотя можно и скрыть) — на какой контент вы подписаны (каналы) — не более.
Для начала, им видно то сетевое соединение, через которое они с вами соединились.
Тут не понятия сетевое соединение, вы вещаете в эфир на общем канале — не более, что то типа wi-fi ad-hoc
Какую атаку вы можете придумать, если есть общая сеть к которой имеет доступ только конкретное приложение с обеих сторон, протокол жестко сертифицирован Google/Apple и приложения сидят в песочнице?
Например, обнаружение устройства в радиусе — это раскрытие приватности. И это не считая атак на сам протокол и "конкретное приложение".
протокол жестко сертифицирован Google/Apple
Напомните название протокола, пожалуйста.
Со стороны Apple — multipeer connectivity framework, со стороны Гугл так быстро подсказать не смогу.
Ваше устройство и так можно обнаружить при включённом wi-fi/bluetooth
… которые я могу и не включать, потому что они далеко не всегда мне нужны (ну и про обнаружение незапаренного блютуса за разумное время тоже вопрос интересный, да ну ладно).
Со стороны Apple — multipeer connectivity framework, со стороны Гугл так быстро подсказать не смогу.
… самое смешное начнется, когда вам понадобится говорить между этими системами.
И это мы еще не начали рассматривать атаки на само приложение, пока только на стек смотрим.
… которые я могу и не включать, потому что они далеко не всегда мне нужны (ну и про обнаружение незапаренного блютуса за разумное время тоже вопрос интересный, да ну ладно).
Bluetooth — по BLE протоколу, при Wi-Fi — создать сеть к которой вы заведомо были подключены — MT_FREE например. При подключении к фейковой сети вы передадите свой настоящий Mac адрес
… самое смешное начнется, когда вам понадобится говорить между этими системами.
И это мы еще не начали рассматривать атаки на само приложение, пока только на стек смотрим.
Все верно, вот телеграм решили свой протокол придумать и ничего — живут как-то, так что вопрос дырявости протокола обычно пропорционален его зрелости. (если ничего не делать то ничего и не будет)
Bluetooth — по BLE протоколу,
Который у меня включен? Нет.
при Wi-Fi — создать сеть к которой вы заведомо были подключены — MT_FREE например.
… но не был же. Подключен, в смысле, не был.
так что вопрос дырявости протокола обычно пропорционален его зрелости
А поскольку протокол новый, степень защищенности вы — по сравнению со зрелым протоколом — понизили. О чем и речь.
Я же не предлагаю использовать только её, я предлагаю дополнительно использовать её.
Я же не предлагаю использовать только её, я предлагаю дополнительно использовать её
В этот момент повышая степень своей уязвимости. Я об этом и говорю.
Не "нет защищенности", а "защищенность понижается". Вы утверждаете, что ваше решение ее не понижает. Это не так.
только как имнно понижается мы так и не решили
Выше по треду. Вы пока что не показали характеристики защищенности предлагаемых вами протоколов (а на multipeer, например, была — закрытая уже — атака, позволявшая понизить на нем уровень шифрования и сделать MITM).
и на этом уровне — я не вижу проблем
Так не работает. Система небезопасна, пока не доказано обратное.
Раскрытия отправителя/получателя — нет
Определения кто источник а кто промежуточное звено — нет
С тем же успехом можно сказать, что tor/i2p небезопасны. хотя метод работы схож
Раскрытия отправителя/получателя — нет
Идентификации устройства, к которому вы подключились, тоже нет? Никакой? Уверены?
Зачем вам идентифицировать устройство к которому вы подключились?
Чтобы отслеживать, где еще оно появляется.
У вас есть основания утверждать, что реализация multipeer у Apple не раскрывает больше информации об устройстве?
Никто не мешает сделать как сделал telegram — не брать openwhisper протокол, а сделать свой — mtproto и героически исправлять в нем ошибки.
Никто не мешает сделать как сделал telegram — не брать openwhisper протокол, а сделать свой
Свой протокол соединения двух устройств разных поставщиков? А где вы доступ к железу-то получите? И откуда после этого возьмется обещанное вами выше "протокол жестко сертифицирован Google/Apple"?
или же делаем свой велосипед (mtproto) который может быть, например, мультивендорным.
Я боюсь, что ни один вендор не даст вам доступа к железу, на котором вы сможете это реализовать.
android/pc/mac/linux — режим работы карты в adhoc+/infrastructure и далее уже делаем все что угодно.
"Все, что угодно" — это прекрасное начало для атаки.
Есть стандартные mesh протоколы, включая сертифицированный из семейства 802
Сертифицированный на что конкретно? Каждый раз, когда мы берем "стандартный протокол", надо точно понимать, какие гарантии он дает.
Вот пример о котором я говорю, если же говорит о недоверии стандарту 802.х — дальше обсуждать вообще глупо.
defining how wireless devices can interconnect to create a WLAN mesh network, which may be used for relatively fixed (not mobile) topologies
Уже забавно, да?
А дальше пойнт в том, что (а) нигде не сказано, что это стандарт для анонимных сетей (более того, там больше одного раза упоминаются стандарты аутентификации) и (б) выглядит так, как если бы мы получали обычную TCP/IP сеть в результате, т.е. возвращаемся к началу и поверхности атаки.
Так что дело не в том, чтобы "не доверять стандарту", пойнт в том, чтобы знать, что именно этот стандарт гарантирует.
Если он не будет анонимным, можно будет отслеживать перемещения устройства.
А если он будет приватным, все ваши меш-сети не смогут возникнуть, потому что в каждом конкретном вагоне не будет людей, заранее обменявшихся кредами.
Приватность — тоже был приведет пример доступа не напрямую к источнику, а через посредника.
я уже выше приводил пример, при mac randoimization вы остаетесь анонимным через определенный промежуток времени.
Вот только (а) не показано, что в этом стандарте работает mac randomization и (б) не показано, что в этом стандарте нет других идентифицирующих узел признаков.
Приватность — тоже был приведет пример доступа не напрямую к источнику, а через посредника.
У вас свое понимание приватности применительно к сетям, не совпадающее с моим.
на какой контент вы подписаны
Именно это лично мне и не нравится, например
Фактически это сейчас знает любой ваш интернет провайдер
Нет, в браузере всё шифруется по HTTPS, в телеграме вроде тоже какой-то велосипед есть (трафик между клиентом и сервером шифруется и без секретных чатов, насколько я знаю). Мой провайдер даже не может узнать, что я сейчас написал этот комментарий)
Ваш провайдер не узнает что вы написали, но он знает что вы заходили на домен habrahabr.ru, собственно при описанном мной сценарии будет ровно то же самое.
Измерили вы уровень сигнала и дальше то что? Вы сможете сказать, что только в том направлении любитель поней с маком ххх.
+ опять же, я в посте упоминал, что это самый простой вариант реализации, никто не мешает использовать функцию раздачи только при наличии 3 и более пиров, таким образом кто именно любит поней — вам будет не известно.
у вас adhoc/p2p
Ладно, тут я матчасти не знаю
Вы сможете сказать, что только в том направлении любитель поней с маком ххх.
Ну так этого более чем достаточно! В вагоне с очень высокой вероятностью в указанном направлении будет находиться ровно один человек. Если, конечно, направление не вдоль вагона и не в час пик, но тогда можно и самому по вагону походить для уточнения деанонимизации.
никто не мешает использовать функцию раздачи только при наличии 3 и более пиров, таким образом кто именно любит поней — вам будет не известно
Возможно, я тупой, но не понял, как из первой части предложения следует вторая часть
Мы с вами едем в одном вагоне в метро, так же в метро с нами едут ещё 5 пользователей мессенджера.
Предположим, я решил скачать контент (поней) который есть у вас, а вы планируете меня вычислить.
Цифры — номера других людей которые вообще не подписаны на поней.
Пони могут передаваться так:
Вы ->3–>2->5 -> я
Или так
Вы -> 2 -> 5 -> я
Или в любой последовательности когда между мной и вами — случайные люди, которые выполняют роль пересылки. Таким образом вы знаете, что пони пришли с пользователя 1 но вы не знаете подписан ли он на поней или просто передал их. Точно так же работает Tor/i2p
А, ну если как в Tor/i2p, тогда может быть. Наверно, здесь ещё есть что закритиковать, но у меня голова не варит и я пока воздержусь от продолжения ветки)
Или в любой последовательности когда между мной и вами — случайные люди, которые выполняют роль пересылки.
В этот момент последние остатки эффективности — кончились, потому что вы заставили передать контент те устройства, которые вообще никак на него не подписывались. Чтобы эта система работала, каждому устройству придется передавать, грубо, в пять раз больше трафика, чем ему нужно.
с большой вероятностью контент передаваемый через устройство будет ему интересен
И это как раз и означает, что мы вычислили его интересы. Здравствуй, раскрытие информации опять. А чтобы интересы нельзя было вычислить, придется скрывать реальный трафик в потоке мусорного — в обмен на многократное увеличение нагрузки, которого мобильное приложение себе позволить не может.
Как вы его вычеслите?
Очень просто: тот, кто с меня читает — заинтересован.
нет, с вас может читать ближайшее к вам устройство, оно же просто прочитает контент и перешлёт его далее
Если ближайшее ко мне устройство читает с меня только один канал — для кого оно его читает?
Мы с вами едем в автобусе, я хочу прочитать у вас канал «Хабрахабр», мы оба подписаны на хабрахабр.
Но кроме нас с вами в автобусе еще 5 пользователей мессенджера который вообще не вкурсе про хабрахабр.
В итоге, я могу читать его так:
Я --> 2 --> 4 --> Вы
Я --> 1 --> 3 --> Вы
или же так (при этом номер 5 — тоже заинтересован в данном канале)
Я --> 2 --> 5 --> 3 --> Вы
Таким образом, не я не вы не знаете кому информация нужна, а кто её просто передаёт.
В итоге, я могу читать его так:
Я --> 2 --> 4 --> Вы
Я --> 1 --> 3 --> Вы
В этом примере 1, 2, 3 и 4 передают информацию, которая им вообще не нужна. Это нарушает ваш постулат "с большой вероятностью контент передаваемый через устройство будет ему интересен" (потому что мы только получили вероятность интереса 1/3).
Я про это и говорю: ваша система либо эффективна (тогда минимум устройств запрашивает контент, который им не нужен), либо не раскрывает заинтересованность в контенте (тогда максимум устройств постоянно прокачивает посторонний контент).
Потеря эффективности будет иметь место, согласен, промежуточные узлы будут передавать данные которым им может быть не интересны, но я не вижу в этом ничего плохого.
А я вот вижу как раз. Вы предлагаете моему устройству постоянно прокачивать трафик, который ему не интересен (и да, это как раз разновидность атаки).
Интересно, что бы вы выбрали — моментальную загрузку 100 мегабайтного видео в метро (при наличии паразитного трафика, скажем, 500 мб) или же ожидание загрузки файла в 3 минуты но экономия 500 мегабайт трафика (деньги за трафик с вас конечно не берут, только % аккумулятора)
Battery attack?
Вообще-то еще и пропускная способность канала расходуется.
Интересно, что бы вы выбрали — моментальную загрузку 100 мегабайтного видео в метро (при наличии паразитного трафика, скажем, 500 мб) или же ожидание загрузки файла в 3 минуты но экономия 500 мегабайт трафика (деньги за трафик с вас конечно не берут, только % аккумулятора)
Ну вот смотрите, вы предлагаете мне думать, что файл в 100 мегабайт грузится три минуты. Сколько будет прокачиваться 500 мегабайт паразитного трафика? (это, напомню, 500 мб входящего трафика и 500 мб исходящего)? Если хотя бы пять минут (а я думаю, что больше), то нафиг такое, я потерял на этом видео больше аккумулятора, чем если бы я сам его скачивал.
И еще раз, вы скорее всего будете больше тратить аккумулятора чем обычно (теоритчески) но взамен вы будете получать другие свойства системы, которые не доступы при нынешней архитектуре.
Это как с Bitcoin и любым blockchain — для верификации транзакций и постройки дерева тратится уйма электричества, но такова архитектура системы и она даёт свои плюсы, которые нельзя получить иным способом.
достаточно иметь лимиты для отражения атаки + лимит на передачу файла, скажем не более 500мб.
Ну вот видите, еще лимиты понадобились. А где лимиты, там и ограничение сервиса для потребителей, и в самый интересный момент кому-то не дадут.
при скорости 100 мб/с 500 мегабайт будут передаватся менее минуты.
… и какое энергопотребление у устройства в таком режиме? Вот, скажем, мой планшет, когда я на него файлы по wi-fi заливаю, сильно лучше держать включенным в сеть, иначе батарейка пробивает дно.
И еще раз, вы скорее всего будете больше тратить аккумулятора чем обычно
Я вам про это и говорю — прощай, эффективность.
Ну вот видите, еще лимиты понадобились. А где лимиты, там и ограничение сервиса для потребителей, и в самый интересный момент кому-то не дадут.
Так у любого сервиса есть лимит, у телеграма есть ограничение на размер файла, длинну видео.
и какое энергопотребление у устройства в таком режиме? Вот, скажем, мой планшет, когда я на него файлы по wi-fi заливаю, сильно лучше держать включенным в сеть, иначе батарейка пробивает дно
Для сравнения посчитал сколько весит недельный объем контента от одного популярного канала с мемами в телеграме (картинки+видео) те самые 500 мб набрались за неделю. Выходит, что в день будет около 70 мегабайт или в час около 5 (будем считать, что ночью активности нет)
Далее к нам приходит тервер, с вероятностью распределения популярных каналов в обществе. В конечном итоге получается, что за час в (например) метро, трафик 1 канала составит 5 мегабайт, берем паразитный как х5 = 25 мегабайт паразитного, из статистики возьмем среднее количество каналов — 10: 250 мегабайт трафика будет передано с учетом паразитного за время поездки.
Вы думаете, что заметите трату аккумулятора при передаче 250 мегабайт?
Вы думаете, что заметите трату аккумулятора при передаче 250 мегабайт?
Я замечу пятикратное увеличение траты аккумулятора.
Но опять же — я не говорю, что энергоэффективность будет выше/такая же, очевижно, что затраты будут, не пятикратные конечно в конечном итоге, но будут.
Но опять же — я не говорю, что энергоэффективность будет выше/такая же, очевижно, что затраты будут, не пятикратные конечно в конечном итоге, но будут.
Ну вот а я вам говорю, что для меня это неприемлемо. Особенно учитывая, что сам я предпочитаю текстовую информацию, а в соцсетях преимущественно читаю друзей.
но при его отуствии — вы бы использовали?
Нет, потому что отсутствие оверхеда автоматически означает отсутствие конфиденциальности.
тут я не вижу особой проблемы с конфеденциальностью
Вы — не видите, а я не хочу, чтобы произвольное соседнее устройство знало, что я читаю дневник Сэм Джоунс.
1) Выберут не конфиденциальный режим для любых каналов
2) Выберут конфиденциальный режим
3) Полностью отключат фичу
Но я догадываюсь, все будут именно на первый вариант, тк берем тот же вконтакте — группы насколько мне известно, там публичны и членство в них отображается.
Значит, если аналогичный функционал будет реализован в каком-то ПО, то вы его отключите.
Или вовсе не буду пользоваться этим ПО. Ну да. А что, собственно?
Но я догадываюсь, все будут именно на первый вариант, тк берем тот же вконтакте — группы насколько мне известно, там публичны и членство в них отображается.
А вот подписчики RSS-каналов — анонимны (ну, не всех, конечно, но тем не менее). Угадайте, чего у меня больше — групп ВК или RSS-каналов в аггрегаторе?
По этому я и предоставил два примера, с промежуточным заинтересованным и без.
… в случае с промежуточным заинтересованым вероятность интереса 1/2. Это тоже очень мало для оправдания эффективности.
То же самое с пассажирами в транспорте.
> И что-то мне подсказывает, что я прав и эту главу начнут именно мессенджеры, а не браузеры или операционные системы…
Нет, эту главу начнут операторы, если уже не начали, а мессенджеры, и уж тем более браузеры с операционными системами, в эту сторону даже двигаться не станут. Мессенджеры — потому что это на порядки дороже, чем воткнуть свой сервер у провайдера. А остальным это и не уперлось.
> выше я описал, как с помощью незначительной доработки мессенджера
Ничего ж себе незначительная. Это просто другой сервис, совершенно.
Почему вы считаете что дорого? Вот пример создания такого мессенджера используя библиотеку от Apple, весь код в пару строк, всё сетевое взаимодействие делает библиотека и разработчику переживать не нужно. www.appcoda.com/intro-multipeer-connectivity-framework-ios-programming
+ я специально упомянул случае, когда даже покупка сервера не поможет повышению скорости/удобства/доступности.
Зашёл посмотреть на эту картинку в комментариях:
Кажется вы только что изобрели Фидо. Но через беспровод.
Хм, есть же bluetooth — от качества мобильной связи не зависит, трафик безлимитный, да и передать через него это действие в пару нажатий
К тому же в случае с мессенджером становится возможной проблема отсутствия у друга зарегистрированного аккаунта мессенджера через который я ему хочу передать документ.
Еще для примера есть scuttlebutt, который реализует gossip-протокол, тоже интересная штука.
а не только мессенджеры.
Также чтобы любое устройство могло выступить в роли провайдера,
даже между разными каналами связи.
Может быть даже владелец устройства мог получать плату за провод трафика,
через свое устройство.
1. получать входящее если адресат находится в этой ноде (о том, в какой ноде уже заранее известно отправителю, если адресат переходит в другую ноду и он там регистрируется — автоматически, то текущая нода говорит предыдущему, что вот юзер у меня с таким то ид), т.е. ноды это всего-лишь транспорт.
2. Клиента можно сделать каким-угодно, шифрование любым из доступных методов, ведь разворачивать умеет его только клиент, но для этого ключи придется передавать адресату каким-то способом, чтобы он смог сообщение прочитать.
Таким образом, даже если пакеты данных будут передаваться через голубей, то там виден всего лишь ид юзера и набор непонятных битов, который никак не коррелирует с логином (случайный набор символов, даже uuid сойдет), а в клиенте в контактах соотнести логин-ид, да и вообще логин можно прочитать уже внутри зашифрованного сообщения.
P2P для сообщений — лишено смысла.
Без дублей это работать не будет (ваше сообщение попало на телефон-посредник, а он разрядился или вышел из зоны уверенного приема). То есть P2P будет генерировать много дублирующегося мусора в сети. Видео развлекательного характера, чтобы посмотреть на диване под кофе или чипсы — еще можно подождать, пока вечером придет сидер и включит свой компьютер. Для сообщений такие задержки и такая негарантия доставки — не приемлимы. Значит, нужны дубли. Много дублей.
И не забываем, что все это мобильный (дорогой) трафик и заряд аккумулятора за то, что вы помогаете кому-то получать их сообщения.
Автор, есть ipfs, есть ethereum swarm. Оба имеют внушительные сети.
Вы сравнивали существующие решения со своим?
Ох, если бы в распределенных системах всё было так просто.
Во-первых, нужно понимать, что практически всегда распределённые коммуникации в разы затратнее централизованных. Если в централизованных для передачи единицы данных необходимо выполнить одну посылку (условно один tcp пакет по установленному соединению), то в распределенных средах нужно сразу озадачиваться роутингом, надёжным релеем (вы же не хотите передавать данные кредитной карты через хакера Васю), и подтверждением доставки. Кстати, внезапно, часть этих проблем решена в TCP.
Во-вторых скорость и стабильность передачи данных. Благодаря сильно неоднородной среде добиться приемлемой скорости коннекта будет крайне сложно. Если где-то на 33-м хопе от меня до вас у пользователя села его нокия, то увы, придётся подождать либо обратного распространения ошибки (а оно еще и может не дойти обратно:) ), либо таймаута, либо сигнального костра.
Ну и самое главное, в-третьих, интернет и сейчас работает примерно схожим образом.
Вообще, велкам в мир распределённых систем. Здесь очень весело :)
Итернет можно дополнить mesh сетью для расширения его доступности туда куда сигналы вышек и wifi не дотягиваются. Так же добавить p2p cdn(межпланетная файловая система например) для доставки контента в отрезанные от прямого доступа в интернет либо с нестабильной связью и маленькой скоростью участки.
Потом p2p взаимодействие может включать в себя и клиент сервер. Клиент может начать загрузку видео с сервера и в процессе искать дополнительные источники для увеличения скорости загрузки. Когда скорость загрузки от альтернативных источников будет достаточной можно отключиться либо снизить нагрузку на сервер.
А еще можно каждому медиаконтенту загруженному присвоить свой айди, но не репостнутому тогда можно синхронизировать на уровне контента а не узлов.
Первое это торренты, и для снятия нагрузки с центральных серверов используются давно, дистрибы линукса, игрушек… их даже применяет мелкософт для распространения обновлений. Добавь в торрент поиск локальных пиров (уже есть) — вот он и ездит поверх локалки или любого меша.
Имхо, к проблеме с батареей добавится расход процессора. т.к. чтобы анонсировать кучу мелких файлов в сеть (мы о мессенджерах же) это не то же самое что один большой фильм например.
Мне больше интересен вопрос именно нижнего уровня передачи. Если обычный wifi работает через точку доступа, как соединяться нескольким устройствам без нее? И как сосуществовать нескольким соединениям одновременно на одном устройстве, если например я подключен к нормальной точке доступа и хочу еще лазить в меш — адаптеры умеют такие фокусы?
В качестве резюме: все плюсы этой идеи только для пользователей, а для хозяев и майоров — одни минусы. Так что в сервисах имеющих документальное ответственное лицо такие чудеса реализованы никогда не будут.
Проблема анонса большого количества файлов решается фильтром Блума.
Tox обновлялся последний раз 2 года назад. Он может и думает над этой проблемой, но не больно сильно дело продвигается.
github.com/qTox/qTox/releases/tag/v1.14.1 — 18 марта 2018
вы о каком-то другом токсе?
Вы слышали звон, да не знаете, где он. Думать о сетевой части может только лишь ядро Токса, никак не его клиент, который занимается отрисовкой формочек и текстовых сообщений. qTox — это клиент, вы его привели сюда абсолютно бездумно.
TokTok — это неофициальный форк ядра Токса. Официальная репа у токса только одна: https://github.com/irungentoo/toxcore/. И последний коммит в ней был сделан 28 сентября 2016.
Конечно qTox может переползти и на TokTok, да вот только я недавно смотрел изменения в TokTok в сравнении с оригинальной версией, ребята в основном добавили тесты, отформатировали код, поправили пару багов.
Уж я-то знаю какой это внутри франкенштейн. Очень сильно сомневаюсь в ваших знаниях.
У меня крутится в голове простая идея распространения контента в одноранговых соцсетях: если пользователь поставил лайк к некоторому объекту — то он автоматически становится пиром, распространяющим этот объект.
Что касается именно mesh сетей — думаю это может быть один из вариантов, точнее один из модулей связи. Другими модулями могут быть прямое соединение через интернет, соединение через TOR, I2P и т.п. Пользователь сам будет решать, какие соединения использовать, причем возможно — в зависимости от распространяемого контента.
Лично мое мнение, что Ваша идея имеет тот же недостаток. Мобильный интернет дешевеет, в СНГ появляются безлимитные тарифы, Маск вот-вот свои спутники запустит. Постоянная гонка 3g -> 4g -> 5g идет. Проблема есть еще пока сейчас, но она будет отсутствовать к тому моменту, когда смогут появится первые стабильные версии таких мессенджеров.
А если считаете, что основной затык в серверной инфраструктуре, то, подумайте, какой будет % cache hit у толпы людей со смартфонами и у парочки современных кеширующих серверов с 10G каналом и парой десятков терабайт места на дисках (сейчас это стоит предельно дешево), стоящих в дата-центре мобильного оператора. А где будет стабильность выше? А в сколько (десятков) раз?
Подводя итог, я бы Вам посоветовал искать новые сферы бизнеса, где можно свою исключительно инженерную идею использовать (связь для военных и МЧС, мобильный интернет в открытом море)
Что-то мне кажется, что совпадений будет не очень много, соответственно обмениваться так получится только максимум несколькими процентами реально потребляемого контента. Есть ли в таком случае смысл?
ИМХО, такая идея хорошо будет работать только в узких тематических сообществах — студенты в аудитории, сотрудники в офисе и т.п. группы людей которым часто надо иметь доступ к одним и тем же материалам. Но и в данном случае есть более простые и надежные решения.
Хранение контента ничего не стоит в масштабах компании. Посчитайте, сколько весит текстовое сообщение. Вы за всю жизнь даже один терабайтный диск не забьете. Фото и видео — потяжелее, но часто репостят одни и те же файлы и тут можно сэкономить.
Также, P2P имеет тот недостаток, что переписка и данные хранятся у пользователей, а не на сервере, и их трудно сканировать, использовать для таргетинга, продавать метаданные из них итд.
Выгоды для производительности в P2P особой нет, так как там данные могут не найтись, надо делать повторные запросы и тд. Выгода есть в приватности, в том, что можно сделать защищенный мессенджер без сервера с хранением сообщений у пользователей — но непонятно, как на нем зарабатывать.
Причем проблем тут две. Во-первых, никто, разумеется, не хочет светить, скажем так, не вполне легальным контентом.
Но есть еще и вторая проблема. Посканировав контент на моем устройстве, можно составить мой профиль для таргетирования рекламы. Если учесть, что заодно отслеживаются мои маршруты (ведь предлагается сканировать соседние устройства), можно вообще обо мне довольно много узнать. Кстати, эту информацию можно и не только для рекламы использовать, а для мошенничества, например.
Как решать эти проблемы, не очень понятно.
P2p сети — очень древняя идея и её регулярно кто-то где-то использует. Можете хоть сами написать p2p-мессенджер за пару дней. Но если посмотреть на действительность, то становится видно: крупные компании наоборот стремятся всеми путями это p2p уничтожить и заменить на свои централизованные серверы (примеры: всем известное убирание p2p из скайпа, всеобщее противодействие jabber-у который хоть и не полностью p2p но распределённый). И очевидно почему: крупным компаниям, у которых есть много денег на пиар, ваши п2п с приватностью нафиг не сдались, и никогда не будут нужны. Им нужна прибыль, а для неё лучше вложиться во что-то другое, например в пиар, да и с регуляторами так проще договариваться.
(примеры: всем известное убирание p2p из скайпа, всеобщее противодействие jabber-у который хоть и не полностью p2p но распределённый)
Утопист так же и вы — видите злой умысел там, где его нет.
Скайп центролизовали по причинам сугубо экономическим. Он получался просто дешевле. Это обсуждалось в интернете с деталями почему да как. См. статьи эпохи приобретения Скайпа Мелкомягкими — тогда и обсасывалось со всеми экономическими расчетами.
Джабберу никто не противодействует. Просто он неудобен в плане разворачивания доп. серверов и их поддержка и подключение к новому серверу — делается вручную, кучей не особо заинтересованных друг в друге людей. Ну и система адресации не сквозная — если вы меняете сервер, то и ваш адрес меняется.
1. Пусть есть у меня канал в интернет, обычно это 3G/LTE с каким-то лимитом, например 10ГБ в месяц (у меня и вовсе 30МБ в день). А сосед по вагону Вася подключается по Mesh сети ко мне и начинает мои скромные 10ГБ выкачивать. Ему хорошо, он только WiFi соединение держит, а я буду работать как точка доступа, выжирая аккумулятор. Думаете, мне, простому пользователю, не гику, это понравится? Да я сразу снесу этот мессенджер к чертям.
2. Интернет ОЧЕНЬ большой. И вероятность, что разные пользователи на расстоянии 10-30м смотрят одни и те же ролики (или даже каналы мессенджера!) очень низка. Даже у каждого пользователя VK или Youtube своя лента.
3. Кэшировать видосики на телефоне? Сколько вы готовы отдать места на флеш памяти, чтобы сосед по вагону посмотрел видосик через вас? Но сколько не отдадите, все равно будет мало из-за пункта 2.
4. Нет никакой коммерческой выгоды делать такую функцию мессенджерам. Напротив, рядовой пользователь столкнется с высаживанием батарейки, поставит низкий рейтинг и удалит приложение.
Как реально решить проблему доступа к интернету — нужно просто создавать больше открытых стационарных точек доступа. В моем дворе телефон видит около 100 запароленных точек WiFi. Все они сидят на широком безлимитном канале, и энергопотребление никого не волнует. Волнует только легальность доступа.
Если решить проблему легальности, скажем открыв на точке WiFi возможность авторизации по номеру телефона через какой-нибудь единый центр авторизации, то проблемы с интернетом в городах просто не будет! Но нужно это сделать так, чтобы не пришлось слать смс каждый раз. Как-то делать запросы на сим-карту, она там своим приватным ключом зашифрует, потом сервер авторизации сможет её аутентифицировать.
2. Есть контент, который захотят просмотреть очень многие. А есть контент, мало кому нужный. Вероятность того, что кто-нибудь из соседей захочет что-нибудь из популярного я оцениваю, как довольно высокую (ну, скажем, 50%)
3. Можно кешировать только популярный контент, и ненадолго, популярность быстро проходит
2. Популярные каналы в подписках у многих, так же как и с youtube — раздел тренды тому пример. как и кэш гугла — он то каким образом работает? он не кэширует вообще весь ютуб если что…
3. Сейчас телеграм вообще никогда не удаляет кэш, так что вы и так отдаёте ему место, я просто призываю этот груз контента использовать.
4. Не могу сказать — надо тестировать, есть подозрение, что в зонах с плохим покрытием/медленным интернетом может быть даже экономия
Ваш пример с точками доступа — утопичен и не решит главной проблемы озвученной в посте — приложение вынуждено оплачивать внешний канал до вас, почему бы приложению не сэкономить часть денег через p2p?
Много ли контента потребляют в метро? Думаю, намного меньше, чем те люди, которые крутят ленту дома через свой WiFi. То есть если даже вы сэкономите траффик компаний, то очень небольшую его часть (1%?). Стоит ли ради этого делать очень сложную разработку?
На самом деле, вот что точно не является проблемой для таких компаний, так это оплата каналов связи. Чем больше пользователей и чем больше они потребили контента, тем лучше. Инвесторы покупают акции, капитализация летит вверх.
Чем еще плох такой кэш через соседей — часть картинок/видео у вас загрузится, а часть нет. Лента будет такой пестрой. Кликаешь — не грузит, другую кликаешь — грузит. Так себе UX для простого пользователя…
Не понятно почему вы тутже исключаете сервер. Не смог загрузить с соседа грузи с сервера или параллельно и с соседа и с сервера.
А без p2p в таких условиях получится что ничего не грузит.
Понимаете, это НЕ проблема, что вы в затрудненной ситуации не можете посмотреть некоторые популярные видеоролики и картинки. Для пользователя важно чтобы либо работало нормально, либо не работало совсем. Иначе только раздражение будет вызывать.
Вы немного не уловили мысль — он будет использовать не ваш канал, а только тот контент который уже у вас есть.
объемы на телефона не терабайтные, а постоянное перемещение только увеличивает «сферу интересов вашей потенциальное аудитории».
вероятность того, что нужный контент у соседа — возможно имеет смысл у одногруппников/одноклассников.
но для случайных людей в метро — вероятность крайне ничтожна.
Проверяется легко.
Качаете обычные торренты и см. кто вам их раздает
У меня обычно с локального треккера идет отсилы 0,1%. Не редкость, когда раздача идет с противоположенной части страны.
Если вы торрент взяли не с локального трекера провайдера то логично. Хотите узнать что качают соседи?
Конец халяве: I Know What You Download
Если вы торрент взяли не с локального трекера провайдера то логично
Какова вероятность встретить в метро того, что сидит на одном с вами сайте и интересуется ровно одними и теми же темами?
Одноклассники/одногруппники — вероятность выше. Но и тут она далека от 50%.
Случайный прохожие — забудь.
Идея автора статьи изначально утопична.
Так тебе нужно не одну статью на Пикабу синхрить через свой телефон.
А хотя бы несколько десятков последних статей и фотографий, чтобы иметь ненулевую вероятность попасть в интересы соседей.
И это только один-едининственный сайт — Пикабу.
Фото в плане проблемы нагрузки на канал уже давно никому не интересно
Дефолт сити, дефолт кантри? Не пробовали загрузить ленту фейсбука с телефона в городе Никко, Япония?
Больше не дам: аппарат у меня старенький, а апетиты у програм большие.
И не думаю, что много народу будут выделять десятками гигов под кэш.
Использует, свой собственный, если они ничего не поменяли
Bitmessage nodes store the encrypted messages only for two days before erasing them, therefore, messages are not archived in the network. New nodes joining the network can only download and broadcast the pool's messages from the last two days. Any messages which did not result in a receipt acknowledgement can be re-sent by the originator of the message after the two-day period.
en.wikipedia.org/wiki/Bitmessage
Это многое усложняет, плюс дает хороший вектор атаки на всю сеть: вклиниваться в проверку подлинности.
Лучше сегментная сеть, когда сеть может рассыпаться на сегменты, и каждый сегмент сам может контролировать свою подсеть.
Тогда в неблагоприятных условиях сеть просто рассыпется на множество изолированных, но полнофункциональных, сетей, в пределах которых пользователи смогут полноценно пользоваться всеми сервисами сети, но будут ограничены в контенте и контактах, что естественно: связи с внешними сетями просто нет, нет и внешнего контента, нет и возможности общения с внешними контактами.
А при появлении внешних каналов связи весь сегмент общается с внешней сетью через них.
В принципе такое уже существует — те же сети tor и i2p например.
Единственное что в них нет — аутентификации пользователей. Пока нет сервиса, который может работать в таких режимах, и обеспечить надежность. Максимум, что тут было — модель подписок, как во всяких даркнетах, когда каждый пользователь сам проверяет свое окружение, и сам дает разрешение на обмен открытыми данными с тем или иным узлом, а закрытые данные просто проксируются через любой доступный узел, не важно, надежен он или нет — данные зашифрованы многослойным шифрованием.
Да, в теории можно обеспечить надежность и необходимый функционал. Сложность в том, что это возможно только в централизованном режиме, что дает точку воздействия на сеть, что опять же ведет к печальной участи сети: рано или поздно до центрального узла доберутся, и разработчик вынужден будет его погасить, похоронив всю сеть.
У телеграмм тут минус в серверах — их можно заблокировать.
Хотя приватные чаты могут остаться работоспособны, т.к. они идут в обход серверов. После блокировки останется шифрованный аналог аськи.
необходимость подключения к сети для проверки подлинностидумаю, схема с открытым и приватным ключом проблему решит. Если у каждого клиента будет открытый ключ сервера, то можно и без подключения к серверу проверить. Но вот зачем?)
Я считаю, что должен быть нормальный стек протоколов, где свое место занимает CJDNS или аналог, который организует IP протокол, а уже под ним, меш и роутинг распределенный.
В этом направлении двигаются ребята с LibP2P
Мессенджеры, пора делать следующий шаг