Pull to refresh

Comments 61

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

...с монастырями, ремесленниками и крестьянами...

Если честно, то по ощущениям мы уже вошли в "современное средневековье"

Из статьи непонятно - это какой-то новый отдельный протокол обмена сообщениями, типа WhatsApp, Telegram и т.д., когда для передачи сообщения, надо чтобы получатель был зарегистрирован в том же сервисе?
Или ваш сервис позволяет отправлять и получать сообщения через обычный email на любые другие уже существующие адреса?

Если первое, то перед пользователем встаёт проблема крепостного права (если рассуждать в терминах феодализма). Кому отправлять сообщения через ваш сервис, если все потенциальные получатели сидят в WhatsApp, Telegram и Viber?

Это новый открытый протокол. Он позволяет отправлять и получать письма внутри сети Eppie и связываться с другими децентрализованными сетями, например Ethereum. Eppie умеет получать письма с обычной почты. Отправлять — пока нет, потому что это противоречит сути проекта: если мы выпускаем письмо из децентрализованной сети, оно попадает на сервер. Но приложение умеет работать и как обычный почтовый клиент. На начальном этапе, пока сеть невелика, это будет необходимо. Совместимость очень важна, мы над этим работаем. Ну, и поскольку это открытый протокол, на нем можно будет строить новые сервисы. Мы очень надеемся что бессерверные сети в скором времени станут нормой.

Дельтачат отличный пример мессенджера через почту.

Да, Deltachat хороший. Но мы делаем новое поколение почты в котором адреса и данные принадлежат пользователям.

Чтобы адрес почты пренадлежал пользователю, надо просто домен у регистратора купить, разве нет?

"Купить домен" - такая же условность, как "купить приложение" в Play Market.
Деньги выложили, а юридического статуса собственности нет. Такого, какой защищает собственность по статьям УК "кража" или "грабёж". Регистратор прописывает в договорах, что ему удобно, с возможностью исправить в будущем без вашего согласия (то есть, не согласны с изменениями правил - прекращайте действие договора и лишитесь домена).

И, кстати, мы будем рады, если вы подпишетесь на ранний доступ на Eppie.io.

И этим автор меня потерял. Зачем подписываться, если это P2P децентрализованная почта??? Достаточно дать ссылку на исходники клиента. Я и сам его смогу скомпилировать и установить.

А подписываться тогда зачем? И на что?

Чтобы быть в курсе развития проекта. Участвовать в опросах чтобы повлиять на развитие. Но разработчикам, конечно, лучше подписываться на GitHub проекта.

Исходники тут: Eppie (github.com)

А оно на C# написано... Пожалуй, подожду клиент на C/C++.

Подписывайтесь, чтобы узнать когда в проекте появятся библиотеки написанные на С++ :)

Да вы, батенька раСИст. И, возможно, даже СИонист :)

Неа, я ассемблерист, но и реалист. Ожидать клиент на ассемблере можно, но только если сам напишу. Из других языков – C хуже, но типа приемлемо.

На самом деле в статье явно поставлена телега впереди лошади, в имя рекламы продукта.

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

Что первично, "сервис" или "приватность"? На примере гугль-почты. Очевидно первичен сервис. Без сервиса нет объекта, к которому можно применить, а можно и НЕ ПРИМЕНИТЬ приватность. Т.е. сначала сервис почты, а потом сервис провайдер ГАРАНТИРУЕТ его приватность. Все просто. И да, приватность, хотя и достаточно условно, гарантируется даже не провайдерами, а законодательством. Пример таких регулирующих норм - GDPR.

Поэтому "приватность" - это просто по факту некий ожидаемый стандарт качества услуги. без него услуга провайдера выглядит как обновленная Гранта в сравнении с автомобилем.

Что до рекламируемого сервиса - ну такое. Если честно, никто не запрещает хранить в "облаке" и пользоваться облачными сервисами вместе с локальным бэкапом (либо в другом облаке). И все. Но если кому-то хочется заморочиться - ну флаг ему в руки :)

Дело не только в данных. Почтовый адрес — ключ к сотням других сервисов, то что называется Digital Identity. В статье есть актуальные примеры, как сервис может его у пользователя отобрать. Или хотя бы элементарный взлом аккаунта. Ваше имя вам не принадлежит, вот и все. Наверное, не все сталкиваются на практике с катастрофическими последствиями. Но приемлемо ли крепостное право, если барин хорошо кормит и не каждый день проигрывает твоих детей в карты? Кто-то сегодня может без такого сервиса обойтись. А кто-то уже и не может. Мы верим что таких людей достаточно много, чтобы проект был полезен.

Давайте без лирики и спокойно разберемся :)

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

Что у меня есть (в общем)

  • национальный паспорт с зоной действия в моей стране

  • во многих странах дополнительный номер, с той же зоной действия

  • заграничный паспорт с зоной действия по всему миру

  • номер телефона

  • адрес почтового ящика

  • ...

Ок, рассмотрим почтовый адрес. К примеру вяся.пупкин@gmail.com. Что мы видим. Что он имеет простую структуру, имя + домен. Имя "мое, домен - НЕТ. Т.е. получается, что почтовый адрес является уникальным, так как Гугль КУПИЛ себе домен, а в рамках этого КУПЛЕННОГО домена Вася получил себе уникальное имя. При этом Вася ничего не платил и получил его на основании публичного договора, который не читал :)

Т.е. имя вася.пупкин@gmail.com как минимум частично принадлежит Гуглю законно и по праву, а в остальном Васе на условиях публичного договора.

К чему вся эта патетика? Никто ж не запрещает. Купи себе домен, поставь почтовый сервак и ты красавчик. Иначе сорян, твой email всегда принадлежит частично владельцу домена.

--------------------

И главное - это все БЕСПЛАТНО! Ну блин, реально. Хочеш лучше сервис - плати. Многие так и делают, в том же гугле. К примеру, один из моих прошлых работодателей "жил" в гугле. Почта, документооборот и т.д. Платишь и получаеш лучший сервис :)

--------------------

Про взлом. Ну опять же. Это стандартный риск, который имеет место быть для ЛЮБОГО идентификатора. Любого. Всегда есть модель угроз и уязвимости. Каждый имеет право выбора провайдера с лучшим "уровнем" безопасности.

Никто ж не запрещает. Купи себе домен, поставь почтовый сервак и ты красавчик. Иначе сорян, твой email всегда принадлежит частично владельцу домена

Ну ок, не хочу потерять имя, куплю ка я себе домен, к примеру, torrents.ru, и настрою там почту, чтобы никто не отобрал и не заблокировал. И тут, о, черррт...

Значит, надо купить такое имя, чтобы его не могли заблокировать!

Погодите-ка, да тут опять децентрализацией пахнет..

Ну, если вы купили домен и за него платите - он ваш :) Более того, вы же и админ почтового сервиса, кто у вас может ваше имя в пределах этого домена забрать?

Так что, вот ответ на вопрос. Либо платный сервис у облачного провайдера. там за ДЕНЬГИ столько всего :) И никто не заберет

А то набежало тут ... свидетелей мороженного за 10 копеек. Им мало того, что дали ящик и 15 гиг (у гугля) на шару. Им еще и подавай 100% защиту от взлома, имя навсегда и все остальные плюшки :)

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

Ну, за полной независимость - на марс :)

В реальности, вы ж паспорт получили? А как же так?

Так все таки, какие риски купить домен или просто платный сервис провайдера?

Напомню, хотите вы или нет, на ваш email это ВСЕГДА имя + домен. Домены глобальны, хотя могут быть приобретены у локального "провайдера". В таком контесте любое решение идентично :) Та же "почта", которая рекламируется несет в себе те же риски :)

-----------------

Боюсь мы уже перешли от решения технической "задачи" (хотя она решается тривиально) к философским вопросам, а именно возможности абсолютно независмого существования :)

Кажется, мы по основным пунктам с вами согласны:

  • Имя в домене gmail.com принадлежит Google

  • Аренда домена и собственный почтовый сервер почти решают заявленную проблему

  • Сервисы Google бесплатны (можно было бы поспорить, что мы платим данными, но в общепринятом понимании действительно бесплатны)

  • Платить больше за лучший сервис — логично и правильно

  • Каждый имеет право выбора

Но, кажется, разговор идет в разных плоскостях одновременно. Давайте разделим.

  1. Практическая плоскость — где лучше хранить секреты.

Мы утверждаем, что децентрализованная сеть с асимметричным шифрованием защищена лучше, потому что в ней исключен фактор доверия. Нет сервера — нет свободной воли провайдера, который может по разным причинам обмануть доверие. Примеров тому масса, в том числе и в этой статье. А также нет центрального хранилища — значит, нет цели для атаки, поэтому массовый слив значительно менее вероятен, если не сказать исключен.

Это не значит, что взломать сервер Google легко, и не значит, что пользователь децентрализованной сети полностью защищен. Но он защищен лучше. В том числе в бесплатной версии.

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

  1. «Лирическая», как вы говорите, плоскость — кому что принадлежит.

Арендованный домен вам не принадлежит — он арендован. Публичный ключ в деценрализованной сети принадлежит тому, кто владеет приватным. Адрес в Eppie — это публичный ключ. Никто не может принимать никаких решений относительно этого адреса и связанных с ним данных, кроме вас. Мы даже удалить адрес не можем.

Считать ли это преимуществом — вопрос ценностный. О ценностях, наверное, не нужно спорить. Мы делаем такой продукт, потому что разделяем цености децентрализации, независимости и открытого программного обеспечения. Мы делаем ставку на то, что децентрализованные сети и ценность цифровой независимости будут становится популярнее.

Тогда больше падает на меня, как на пользователя. Если я правильно понял.

  • Сервис фактически на мне, как и вопросы резервирования. Это как-бы уже минус в том смысле, что ... ну блин, в облаке я просто и лениво получил и пользуюсь

  • По взлому - взламывается обычно не сервер, а "пользователь". Легкий пароль, отсутствие второго канала аутентификации :) Это ж классика - в массовой системе именно человек - слабое звено :)

  • По ключам - честно, лениво читать. Но если говорить о ключе как о сертификате (т.е. плюс подтверждение личности), то всегда есть третья сторона, от которой ты зависишь и который подписался, что ты - это ты.

Плюс прикол Гугла (я просто им пользуюсь, но тот же мелкософт делает аналогичное) в синегрии сервисов. даже в реальной жизни как приватному лицу мне нужна не только почта. Есть диск, фотки, авторизация на других сайтах, ...

Про плюсы для юр. лиц, где начинаются деньги и вообще речь не идет

---------------

Но я понимаю вашу концепцию, спасибо за детальное разъяснение

  1. На стороне пользователя Eppie выглядит как почтовый клиент и специального обслуживания не требует. Что касается бэкапа, у нас есть три способа:

  • Если пользователь подключает несколько устройств, они соединяются в приватный кластер, и синхронизируются автоматически.

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

  • Можно купить дополнительное место в децентрализованном хранилище.

    Какой бы вариант вы ни выбрали, никаких других действий для создания резервной копии с вашей стороны не нужно.

  1. Вы правы, есть много способов взломать пользователя. Например, от физического отъема сид-фразы, мы, увы, спасти не можем. Но надо понимать, что у нас нет паролей, а сид-фраза не пароль, она по-другому работает. Из сид-фразы генерится пара ключей. Публичный можно показать кому угодно. Приватный хранится у вас локально. Если очень коротко, вы шифруете письмо с помощью публичного ключа вашего адресата, а расшифровать его можно только с помощью парного приватного, который есть только у него. Сила этой схемы в том что критическая информация никогда не покидает устройство пользователя. Тот же пароль вы передаете серверу в момент регистрации, сервер его сохраняет в виде хеша и использует, чтобы сравнить с хешем, который вы будете передавать в момент аутентификации. Поэтому пароль можно перехватить в процессе или утащить с сервера и потом спокойно подобрать, если он слабый. С сид-фразой это все невозможно. Не бывает простых сид-фраз, и ее неоткуда украсть.

    Двухфакторная аутентификация в нашем случае не нужна. 2FA — это же способ для сервера перепроверить, что пользователь, с которым он имеет дело, именно тот, за кого он себя выдает. В Eppie процесс аутентификации в некотором смысле отсутсвует. То есть нет никакого посредника, который взял бы на себя право допустить или не допустить пользователя до сети или конкретных данных. Это решение принимается локально, на машине пользователя. Можешь расшифровать данные — они твои.

  2. И поэтому, когда мы говорим о «почте без провайдера», мы именно это хотим сказать: третьей стороны не существует.

Вот здесь мы писали подробно о том, как работает асимметричная криптография. Почитайте, когда будет настроение. А здесь очень наглядная аналогия.

Что касается Google, мы же не заставляем от него отказываться. Пользуйтесь на здоровье, наш клиент позволяет подключать аккаунт Google и Microsoft и получать лучшее из двух миров.

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

Да Вы знатный тролль... ;)

Ладно, многие не стараются :)

Я бы сказал, немногие стараются, и напомнил известное благодаря Марксу высказывание Даннинга про капитал, норму прибыли и преступление.

Узкое место таких децентрализованных систем - непродуманность защититы от флуда и спама.
Например, РКН по указке сверху может регистрировать по 500 аккаунтов в день в вашей сети и лить с них 100 гигабит в секунду шифрованных "писем" в сеть. Как быстро закончится storage у добровольных нод? Как отличить легитимных юзеров от спамеров?

@BaJlepa, этот вопрос требует обсуждения. А то и правда от спама как защищаться будем?

Да, это важные вопросы. Ответил ниже.

Не скажу за представленный проект, но попробуйте, для разминки, зафлудить сеть эфира. ;)

Там блокчейн на PoW. А здесь - блокчейн?

Создание аккаунта в Eppie — это локальная генерация пары ключей, она не нагружает сеть. А чтобы лить 100 гигабит, нужно подключать свои зловредные ноды. Но каждая нода в сети должна работать согласно протоколу иначе будет выброшена из сети. А если она будет работать согласно протоколу, то будет усиливать сеть.

Также Eppie использует в качестве инфраструктуры для доставки сообщений другие децентрализованные сети: IPFS, SBBS, DHT — то есть нужно зафлудить их все.

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

И у нас предусмотрен переход на proof of work и proof of space при отправке писем в моменты сильной нагрузки сети.

Против спама у пользователя будут черные списки, белые списки, и специальные адреса на которые могут писать только доверенные адресаты.

Но каждая нода в сети должна работать согласно протоколу иначе будет выброшена из сети

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

Eppie использует в качестве инфраструктуры для доставки сообщений другие децентрализованные сети: IPFS, SBBS, DHT

DHT это протокол, или даже алгоритм (принцип). А не конкретная сеть. IPFS, как я понял, используется для бекапов.

Полностью согласен, написать можно любой зловредный код. И когда он будет написан будем писать защиту дополнительную.

Имеется ввиду конкретные реализации DHT которые работают в разных проектах.

IPFS используется и для пересылки сообщений тоже.

И когда он будет написан будем писать защиту дополнительную

Ну такой себе подход. Атака случилась, и пока вы придумываете меры противодействия, пишете код, тестируете и раскатываете обновление, сеть целый месяц не работает.

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

Релиз же только после долгого публичного бетатестирования будет.

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

Так наезды РКН начнутся не к релизу, а когда сеть станет популярной и будет 100500 юзеров и 200 клиентов на 20 ЯП. И это всё обновлять будет чертовски сложно.

И у нас предусмотрен переход на proof of work и proof of space при отправке писем в моменты сильной нагрузки сети.

А кто решает, когда "сильная нагрузка?"

Против спама у пользователя будут черные списки, белые списки, и специальные адреса на которые могут писать только доверенные адресаты.

Это хорошо. Нужно не забывать заранее закладывать такое в p2p протоколы.

Пока планируется принятие решения на двух уровнях:

  1. каждая нода решает

  2. кластер нод решает (вырабатывает консенсус)

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

Есть ли законченный документ, описывающий текущее состояние протокола? Хотелось бы почитать в технических терминах про "сильную нагрузку сети", про консенсус.

Всё верно, полной спецификации нет.

Часть в коде: https://github.com/Eppie-io

Часть просто идеи.

Из документации, сейчас работаем над White Paper, как только будет готов черновик опубликую на GitHub. Подписывайтесь, чтобы почитать и покритиковать одним из первых :)

Против спама у пользователя будут черные списки, белые списки, и специальные адреса на которые могут писать только доверенные адресаты.

Списки чего? Публичных ключей?

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

Белые списки в принципе зло – какая-то социальная сеть получается, а не почта. Ведь, по почте каждый должен иметь возможность написать каждому.

Да, чёрные списки для именованых адресов.

Зло или не зло, пусть каждый сам решает.

Да, чёрные списки для именованых адресов.

А можно подробнее об именованных адресах? Они откуда появились? Ведь были только ключи. (ну и сид-фраза от которой они генерируются).

Зло или не зло, пусть каждый сам решает.

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

А если кому-то нужна почта-почта, он принципиально не защищен от спама.

То есть белый список, это защита от спама, через отказ от почты. Что уже, мне кажется, не «пусть каждый сам решает», а фатальный недостаток концепции.

Не уверен что это недостаток, тем более фатальный :)

Читайте внимательно:

защита от спама, через отказ от почты

Лечение мигрени декапитацией? Ну да, лечит с гарантией...

П.С. Забыли про именованные адреса объяснить.

Давайте с другой стороны зайдём.

Белые списки реализуются на уровне клиентского кода, а не на уровне протокола. Т. к. проект с открытыми исходниками, то и белые и чёрные и серые списки будут реализованы, хотим мы того или нет.

То есть, надо ли понимать, что в протоколе вообще не включена защита от спама и пользователь должен защищаться или не защищаться сам.

Система доставляет каждое отправленное письмо а пользователь решает хочет он его читать или просто стереть.

Так?

В большинстве случаев да. Но возможен вариант, когда клиент на последнем этапе доставки решает получать письмо или нет.

Концепция именованых адресов следующая: система может разрешать имена в публичные ключи и наоборот. На первом этапе с помощью интеграции существующих сервисов имён, таких как ENS, BANS и других. Возможно даже DNS. Затем добавим собственный сервис имён.

А если кому-то нужна почта-почта, он принципиально не защищен от спама.

То есть белый список, это защита от спама, через отказ от почты. Что уже, мне кажется, не «пусть каждый сам решает», а фатальный недостаток концепции.

Тут столкновение двух концепций, у каждой свои плюсы и минусы:

  1. "Социалистическая" концепция - вы делегируете защиту от спама третьей стороне, и у себя на клиенте принимаете почту "от всех". Плюс в том, что вам не надо думать, минус в том, что за вас думает третья сторона, чье мнение, мягко говоря, может не совпадать с вашими идеями о том, что есть спам.

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

Еще не вспоминали тут такую допотопную вещь, как mail-bomb...

Плюс очевидно в том, что вы сами все решаете, минус в том, что для этого нужно немного поднапрячься.

Плохо не это что нужно поднапрячься. Плохо то, что чтобы правильно отфильтровать спам от неспам надо либо идентифицировать как-то отправителя, что в p2p системе невозможно в принципе, либо читать все письма и сортировать по смыслу. Но прочтение письма, это именно того чего спамер добывается.

Конечно можно включить всякие байесовские фильтры и даже нейронные сети, но спамеры давно с ними научились бороться.

В классической почте есть глобальные черные списки, которые работают потому что отправителя можно идентифицировать по IP адресу. В распределенной p2p почте такая идентификация невозможна в принципе.

Отпадет очень мощный инструмент защиты а ничего взамен протокол не предлагает.

В классической почте есть глобальные черные списки, которые работают потому что отправителя можно идентифицировать по IP адресу.

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

Это точно. Сколько проблем сис. админам доставляют "некоммерческие организации борьбы со спамом" типа SPAMHAUS, когда подсеть попадает в чёрный список. Оспорить это нельзя, потому что организация негосударственная и некоммерческая, а потому ничего никому не должна, но в то же время от тебя никто не принимает письма, потому что ты в их списках.

Там есть простая система удаления из черного списка. Когда настраивал свой имейл сервер пришлось ознакомится. Нормально работает. Произвола вроде не заметил.

Вся сатья как раз про делегирование защиты :)

Sign up to leave a comment.