1) какие есть альтернативы? Self-signed не вариант, работать без HTTPS тоже не вариант. Интересует именно техническое, а не политическое решение проблемы защиты пользовательских данных от третьих ли.
2) есть список корневых сертификатов в Windows. https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT Поиск government по странице выдаёт 62 сертификата (некоторые страны повторяются, поэтому количество стран сказать не могу). Видел Францию, Бразилию, Тунис, Мексику. Почему их включение в список это допустимо, а российский сертификат - нет?
Я понимаю какие возможности даёт включение корневого сертификата в список доверенных, но я не вижу альтернативных вариантов если ситуация усугубится и перестанут работать даже бесплатные let’s encrypt. Ещё раз уточню что я не призываю никого сейчас бежать и ставить гос.сертификат. Может возникнуть ситуация когда у нас просто не будет альтернатив
Соглашусь с тем что эта технология (подмена CallerID) как минимум сомнительна. С другой стороны есть мирное применение этой технологии. Мы в CRM для сервисных центров (Servix.io) похожим образом реализуем автоматический звонок клиенту о готовности. Когда мастер заканчивает работать над заказом мы можем отправить роботизированный звонок клиенту.
Безопасность обеспечивается проверкой номеров телефонов (человек должен ответить по этому номеру и в тоновом режиме сделать нажимать кнопки для подтверждения).
Такие звонки нормально работают если регистрируется номер из какой-нибудь IP-телефонии вроде манго или задарма. Если зарегистрировать номер мобильного оператора (МТС / Мегафон / теле 2), то роботизированные звонки на телефон клиента внутри оператора (МТС -МТС) будут заблокированы.
1) Картинки пережимаются и на клиенте, и на сервере. Можно отправить картинку как документ и передать без сжатия.
2) С видео пока не работаем, оно просто передается как файл без генерации превью.
В нашем мессенджере есть end-to-end шифрование, но это опциональная возможность. В некоторых других продуктах это обязательная опция, которая добавляет приватности, но лишает пользователей ряда возможностей. Если вы будете использовать оконечное шифрование в Y messenger, он будет защищен как Tox и BitMessage. Если не использовать — сообщения сохранятся на сервере в открытом виде и администратор будет иметь возможность читать эту переписку. Такая же возможность есть у администраторов других мессенджеров. Какой вариант использования вам лучше подходит — решать вам, мы предлагаем оба варианта.
У администрации любого сервиса которым вы пользуетесь (мессенджер, почта, соц.сети) есть доступ к вашей незащищённой информации. Вы вполне спокойно доверяете свои данные каким-то людям. В нашем проекте вы можете запустить сами для себя хаб и общаться со своими друзьями только в рамках своего личного хаба. Никто кроме вас не получит доступ к этой информации.
Как считаем непрочитанные сообщения
1.1. В диалогах
Каждое сообщение хранится в двух экземплярах, по одному для каждого из собеседников. У сообщения есть флаг Read:bool, а количество непрочитанных = количеству входящих с Read == false
1.2 В групповых чатах
В чатах/каналах каждый участник имеет поле с идентификатором последнего прочитанного сообщения. Количество непрочитанных = количество входящих сообщений после сообщения с ID = последнему прочитанному.
Решение этой проблемы сейчас стоит в очереди. Либо клиент будет определять момент обрыва соединения и, после соединения, запрашивать с хаба недошедшие по ID последнего известного клиенту, либо в объект сообщения добавим ссылку на предыдущее и при получении 107 клиент увидит идентификатор предыдущего — 106, определит что его нет в локальной базе и запросит его.
Мы разрабатываем мессенджер как корпоративный инструмент, но и про физиков не забываем :) в корпорациях же все равно работают люди, которые пользуются и телегой и WhatsApp. Они ведь видят как можно удобно сделать инструмент, поэтому мы тоже стараемся сделать его удобным для людей.
Возник вопрос: а как при передаче ключей от А к В обходится ситуация, когда А уже выключен (не отвечает на запросы)? Например, пользователь отложил телефон, телефон залочен, и пользователь входить в чат с ПК.
Хороший вопрос. Да, это серьезная проблема и у нас есть только два решения:
разбудить приложение через push-уведомление;
сделать сервис для фоновой работы.
Ни одно из решений мы у себя еще не реализовали.
Если девайс прям выключен, то все. Без стороннего хранилища не обойтись, а мертвые клиенты на запросы не отвечают.
Хранить мастер-фразу на хабе в нашем случае достаточно рискованно, даже в зашифрованном виде. Запоминать мастер-фразу обычный пользователь вряд ли будет. Мы в интерфейсе пишем как это важно и предлагаем его куда-нибудь записать. Мастер-фразой может быть какой-нибудь афоризм, который легко запомнить или найти.
В отличие от централизированных мессенджеров, мы не имеем доступа к данным пользователей на хабах. Бэкдоры для несанкционированного доступа мы не ставили и с открытым кодом это неразумно. У администратора хаба есть доступ к нешифрованной переписке и возможность запретить шифрованную переписку своим пользователям. При возникновении вопросов в рамках СОРМ, отвечать на них придется администратору хаба.
В этом вопросе наш мессенджер очень похож на электронную почту. Есть сервер с открытым исходным кодом (как Postfix), есть протокол, есть клиент с открытым кодом. Если возникает вопрос в рамках СОРМ, то ответственные лица будут задавать вопросы не (к сожалению ныне покойным) разработчикам почты, Ноэлю Моррису и Тому Ван Влеку, а владельцам сервера где все произошло.
В matrix идентификация пользователей похожа на e-mail: alice@server.com. У нас идентификатор пользователя — случайное число. За счет отсутствия привязки идентификатора к серверу, у нас пользователь может переезжать между серверами со всеми своими данными.
Протокол позволяет проксировать соединения пользователя между хабами. Например, пользователь U(a) не может напрямую подключиться к своему хабу H(a), но может подключиться к H(b). За счет проксирования получается цепочка соединений U(a) <-> H(b) <-> H(a).
Серверное приложение из коробки имеет массу настроек под разные юрисдикции, включая российскую.
Мы используем WebSocket, а не REST.
У нас есть голосования с цифровыми подписями, которые можно использовать для согласования документов.
У нас нет звонков, но наш проект еще слишком молод. На сегодняшний день он уже способен работать и решать задачи пользователей.
У нас нет API для ботов и интеграций. Причина полностью аналогична предыдущему пункту.
Мы ведем разработку в своем репозитории. В гитхаб выкладываются все релизы. Пока вся разработка ведется исключительно нашей командой, переносить весь процесс в гитхаб нет необходимости
«Сражаться» с государствами мы не планируем, наша зона ответственности ограничивается разработкой ПО. Все что касается эксплуатации — дело владельца отдельного сервера. Серверное приложение обладает десятками параметров, позволяющее настроить его работу под разные законы.
Конкретно по вашему вопросу: пункт 9 статьи 2 этого же закона говорит что распространение = «получение информации неопределенным кругом лиц». Настройки сервера позволяют ограничить свободную регистрацию, а также создавать приватные групповые чаты и каналы. В этом случае участник сети не будет распространителем информации.
Но если вы копируете без абсолютного понимания новоприобретенного кода и того, что он делает, вы рискуете сделать свой собственный код только хуже.
Вот эту фразу нужно попапом показывать при Ctrl+C из StackOverflow. Сколько было испорчено кода тупым заимствованием. В большинстве случаев спасает нормальный git, хотя и его тоже умудряются портить.
Да, наилучшим образом. Вы можете общаться с остальными, вы будете владельцем своих данных. Ни ваш сервер, ни остальные, не почувствуют проблем с тем что на вашем сервера вы один. Мы так и задумывали что сервера будут создаваться под небольшие команды.
При желании можете сделать сервер на ноутбуке у себя дома / в офисе. Перехват коммуникации исключен надежным шифрованием. Посмотрите на второй слой шифрования — «Шифрование данных в канале связи» в нашей документации
Почему это вдруг автор альтернативного сервера теряет возможность общения между серверами, если протокол открыт?
Владельцу альтернативного сервера будет проблематично подключаться к оригинальным серверам, т.к. он не будет иметь необходимой подписи, которую мы выдаем при лицензировании и оригинальные сервера будут отвергать такой коннект. Альтернативному серверу придется создавать свою сеть альтернативных серверов.
Что тогда мешает клиентам перейти на форк вашего сервера, где не надо ничего никому платить?
Ничего не помешает. Нужно сделать форк сервера и клиентов под этот сервер. Будет новый мессенджер на основе нашего. Если он будет популярнее оригинального — хорошо. Это не исключено. В этом случае мы обновим свои CV и пойдем искать работу :)
Точно имелось ввиду «малого»? Сложно представить ИП Пупкин на SAP
1) какие есть альтернативы? Self-signed не вариант, работать без HTTPS тоже не вариант. Интересует именно техническое, а не политическое решение проблемы защиты пользовательских данных от третьих ли.
2) есть список корневых сертификатов в Windows. https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT Поиск government по странице выдаёт 62 сертификата (некоторые страны повторяются, поэтому количество стран сказать не могу). Видел Францию, Бразилию, Тунис, Мексику. Почему их включение в список это допустимо, а российский сертификат - нет?
Я понимаю какие возможности даёт включение корневого сертификата в список доверенных, но я не вижу альтернативных вариантов если ситуация усугубится и перестанут работать даже бесплатные let’s encrypt. Ещё раз уточню что я не призываю никого сейчас бежать и ставить гос.сертификат. Может возникнуть ситуация когда у нас просто не будет альтернатив
Соглашусь с тем что эта технология (подмена CallerID) как минимум сомнительна. С другой стороны есть мирное применение этой технологии. Мы в CRM для сервисных центров (Servix.io) похожим образом реализуем автоматический звонок клиенту о готовности. Когда мастер заканчивает работать над заказом мы можем отправить роботизированный звонок клиенту.
Безопасность обеспечивается проверкой номеров телефонов (человек должен ответить по этому номеру и в тоновом режиме сделать нажимать кнопки для подтверждения).
Такие звонки нормально работают если регистрируется номер из какой-нибудь IP-телефонии вроде манго или задарма. Если зарегистрировать номер мобильного оператора (МТС / Мегафон / теле 2), то роботизированные звонки на телефон клиента внутри оператора (МТС -МТС) будут заблокированы.
1) Картинки пережимаются и на клиенте, и на сервере. Можно отправить картинку как документ и передать без сжатия.
2) С видео пока не работаем, оно просто передается как файл без генерации превью.
В нашем мессенджере есть end-to-end шифрование, но это опциональная возможность. В некоторых других продуктах это обязательная опция, которая добавляет приватности, но лишает пользователей ряда возможностей. Если вы будете использовать оконечное шифрование в Y messenger, он будет защищен как Tox и BitMessage. Если не использовать — сообщения сохранятся на сервере в открытом виде и администратор будет иметь возможность читать эту переписку. Такая же возможность есть у администраторов других мессенджеров. Какой вариант использования вам лучше подходит — решать вам, мы предлагаем оба варианта.
У администрации любого сервиса которым вы пользуетесь (мессенджер, почта, соц.сети) есть доступ к вашей незащищённой информации. Вы вполне спокойно доверяете свои данные каким-то людям. В нашем проекте вы можете запустить сами для себя хаб и общаться со своими друзьями только в рамках своего личного хаба. Никто кроме вас не получит доступ к этой информации.
1.1. В диалогах
Каждое сообщение хранится в двух экземплярах, по одному для каждого из собеседников. У сообщения есть флаг
Read:bool, а количество непрочитанных = количеству входящих сRead == false1.2 В групповых чатах
В чатах/каналах каждый участник имеет поле с идентификатором последнего прочитанного сообщения. Количество непрочитанных = количество входящих сообщений после сообщения с ID = последнему прочитанному.
Мы разрабатываем мессенджер как корпоративный инструмент, но и про физиков не забываем :) в корпорациях же все равно работают люди, которые пользуются и телегой и WhatsApp. Они ведь видят как можно удобно сделать инструмент, поэтому мы тоже стараемся сделать его удобным для людей.
sazonovd@corp.ymessenger.org можете найти меня по почте в нашем приложении или @DmitriySazonov в телеге
Хороший вопрос. Да, это серьезная проблема и у нас есть только два решения:
Ни одно из решений мы у себя еще не реализовали.
Если девайс прям выключен, то все. Без стороннего хранилища не обойтись, а мертвые клиенты на запросы не отвечают.
Хранить мастер-фразу на хабе в нашем случае достаточно рискованно, даже в зашифрованном виде. Запоминать мастер-фразу обычный пользователь вряд ли будет. Мы в интерфейсе пишем как это важно и предлагаем его куда-нибудь записать. Мастер-фразой может быть какой-нибудь афоризм, который легко запомнить или найти.
В отличие от централизированных мессенджеров, мы не имеем доступа к данным пользователей на хабах. Бэкдоры для несанкционированного доступа мы не ставили и с открытым кодом это неразумно. У администратора хаба есть доступ к нешифрованной переписке и возможность запретить шифрованную переписку своим пользователям. При возникновении вопросов в рамках СОРМ, отвечать на них придется администратору хаба.
В этом вопросе наш мессенджер очень похож на электронную почту. Есть сервер с открытым исходным кодом (как Postfix), есть протокол, есть клиент с открытым кодом. Если возникает вопрос в рамках СОРМ, то ответственные лица будут задавать вопросы не (к сожалению ныне покойным) разработчикам почты, Ноэлю Моррису и Тому Ван Влеку, а владельцам сервера где все произошло.
alice@server.com. У нас идентификатор пользователя — случайное число. За счет отсутствия привязки идентификатора к серверу, у нас пользователь может переезжать между серверами со всеми своими данными.U(a) <-> H(b) <-> H(a).Server (c#, .netCore 2.2): github.com/Ymessenger/ymessenger
Android (Kotlin): github.com/Ymessenger/android-app
Конкретно по вашему вопросу: пункт 9 статьи 2 этого же закона говорит что распространение = «получение информации неопределенным кругом лиц». Настройки сервера позволяют ограничить свободную регистрацию, а также создавать приватные групповые чаты и каналы. В этом случае участник сети не будет распространителем информации.
Server (c#, .netCore 2.2): github.com/Ymessenger/ymessenger
Android (Kotlin): github.com/Ymessenger/android-app
Вот эту фразу нужно попапом показывать при Ctrl+C из StackOverflow. Сколько было испорчено кода тупым заимствованием. В большинстве случаев спасает нормальный git, хотя и его тоже умудряются портить.
Да, наилучшим образом. Вы можете общаться с остальными, вы будете владельцем своих данных. Ни ваш сервер, ни остальные, не почувствуют проблем с тем что на вашем сервера вы один. Мы так и задумывали что сервера будут создаваться под небольшие команды.
Владельцу альтернативного сервера будет проблематично подключаться к оригинальным серверам, т.к. он не будет иметь необходимой подписи, которую мы выдаем при лицензировании и оригинальные сервера будут отвергать такой коннект. Альтернативному серверу придется создавать свою сеть альтернативных серверов.
Ничего не помешает. Нужно сделать форк сервера и клиентов под этот сервер. Будет новый мессенджер на основе нашего. Если он будет популярнее оригинального — хорошо. Это не исключено. В этом случае мы обновим свои CV и пойдем искать работу :)