КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ

Наше предложение
по проекту MSec

Функциональные требования
  1. Звонки
  2. Текстовые сообщения
  3. Отправка фотографий ( снимок и из галереи ? )
  4. Отправка голосовых сообщений
  5. Групповые чаты
  6. Принудительная блокировка геолокации
  7. Блокировка на скриншот
  8. Пароль при входе в приложение ( буква и 4 цифры )
  9. Пароль при прикреплении файла
  10. Пароль для входа при выключении экрана ( скорее при включении? )
  11. Пароль номер 2 на удаление блокировку ( т.е. при вводе этого пароля телефон делает factory reset/удаление приложения )
  12. Отображение получения сообщений/файлов сигналом
  13. Отображение получения сообщений/файлов цифрой. Цифра отображает количество полученных сообщений
  14. Текст сообщения не отображается в уведомлениях
  15. Отправитель сообщения не отображается
  16. Отображение "typing"
  17. Принудительное сообщение/удаление файлов через 24 часа
  18. Установка удаления сообщений через заданное время ( 5,10,30 минут, 1,2,5,10 часов ) после прочтения
  19. Удаление чата одним из абонентов
  20. Удаление групповых чатов создателем чата
  21. Если сообщение/файл не прочитаны, то удалять их по истечении суток после отправки
  22. Алгоритм блокировки абонента администратором системы ( не совсем понятно что имеется ввиду, задача условий блокировки через интерфейс администратора?)
  23. Nickname 001-500 абонента присваивать при загрузке приложения ( хотелось бы понять данное требование на примере)
  24. Видеозвонки - нет
  25. Отображение "Online" - нет
  26. Отображения "когда был в сети" нет
  27. Отправка файлов - нет ( данное требование противоречит требованиям 9, 12, 13, 17, 21 полностью или частично в той формулировке, в которой они заданы )
  28. Отправка видео - нет
  29. Отображение «online» - нет
  30. Отображение «когда был в сети» — нет



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

  1. End to End encryption для сообщений ( включая метаданные )
  2. Client - Server encryption соединение ( TLS )
  3. Если мы говорим о том, что мы также будет заниматься сопровождением то стоит отметить как отказоустойчивость ( например 99% доступности в год ) так и восстановление после сбоев в автоматическом режиме
  4. Защита от DDos атак как сетевого так и уровня приложения
  5. Также в процессе разработки необходимо будет проработать механизм аудита и раннего обнаружения атак. Здесь надо подумать над балансом между тем насколько много данных пользователей мы будем хранить/получать на сервере и тем как точно и быстро мы хотим эти атаки обнаруживать. Чем больше данных тем точнее инструмент, но тем ниже уровень безопасности пользователей в случае если сервер будет скомпрометирован
  6. Также push сообщения по видимому не могут быть реализованы с использованием сторонних сервисов, это усложняет разработку.
  7. Обновление приложения в обход google play сервиса
  8. Локальное хранилище приложения ( e2e ключи и кэш ) должны быть зашифрованы
  9. Хранилище серверной части также должно быть зашифровано
Окружение для запуска приложения
Планируется что все приложение будет запускаться на ванильном Android, в котором будут отключен функционал из требования 6 и 7
Также это позволит нам запретить установку любых других приложений кроме нашего
Локальное хранилид

Ниже приведено 3 варианта решений

Решение на основе zulip
Opensource клиент-серверное приложение на Python
Плюсы:
  • Активно развивающийся проект
  • OpenSource, а значит имеет возможность проходить аудит широкой общественности
  • Интегрируется с IDM/IDP
  • Большая часть серверной части функционала уже есть
  • Высокий уровень покрытия тестами
  • Написан на статически типизированном Python 3
  • Есть bounty программа по поиску багов
Минусы:
  • Python имеет ряд ограничений, хотелось бы все-таки компилируемый язык
  • В целом разработан и заточен под хранение истории и поиск, поэтому потребует довольно много доработок
  • Сложнее поддерживать из-за высокого уровня доработок
  • Клиентская часть написана на React Native, что предположительно может вызвать затруднения для запуска на ванильном андроид. Также высокий уровень абстракции не позволит быть уверенным в высоком уровне безопасности приложения


Стоимость разработки - 25 140 000 рублей

Сроки реализации этапа 5 месяцей

Решение на основе форка Signal
Популярный мессенджер, доказавший свою надеждость уже давно.
Плюсы:
  • Давно на рынке
  • Opensource
  • Огромное количество контрибьютеров
  • Надежная, зарекомендовавшая себя команда разработки
  • Надежный протокол, получивший широкое распространение ( например его использует WhatsApp )
  • Есть e2e шифрование, даже групповых чатов
  • Регулярный аудит кода
  • Большая часть функционала уже реализована
  • Клиентская часть написана на Java, скорее всего проблем с запуском на ванильном android не будет
Минусы:
  • Команда разработки консервативна в принятии PR на новый функционал
  • Довольно старый проект, есть некоторый груз в виде например Java а не Kotlin на фронтенде
  • Некоторого функционала все-таки нет на бекенде



Стоимость разработки - 19 972 000 рублей

Сроки реализации проекта 4 месяца

Решение на основе XMPP протокола
Предполагается использование какого-то готового XMPP сервера, например Jackal
Плюсы:
  • Проверенный временем протокол
  • Большой выбор готовых решений практически под любой язык
  • Есть готовые библиотеки для e2e шифрования ( например OTR )
Минусы:
  • Выглядит менее надежным чем Signal
  • Большая часть готовых решений довольно вяло разрабатывается
  • Безопасность не является его основным функционалом как и в случае с zulip, а значит разработчики не уделяют этому так много внимания, как та же команда Signal
  • Потребует практически гарантированно написание фронтенд части с нуля, что увеличит риски не успеть в срок




Стоимость разработки - 22 500 000 рублей

Сроки реализации проекта 4 месяца

Продуктовая команда на решение на основе Signal fork:

1. DevOps/SecOps

2. Project Manager

3. Architect

4. Java Backend team lead

5. Java Backend Developer

6. Java Backend Developer

7. Kotlin frontend team lead

8. Kotlin frontend developer

9. Kotlin frontend developer

10. Vuejs Frontend

11. Q&A testing

12. Design

13. Project Manager

14. Security Specialist

Итого команда будет из 14 человек




Общий срок реализации проекта – 4 Месяца.


Технологический стек: Java, VueJs, Kotlin

Процесс разработки разделён на спринты.

Длина каждого спринта – 1 неделю.

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


Общая стоимость решения с использованием Signal fork - 19 972 000 рублей




Продуктовая команда на решение на основе XMPP:

1. DevOps/SecOps

2. Project Manager

3. Architect

4. GO Backend team lead

5. GO Backend Developer

6. GO Backend Developer

7. Kotlin frontend team lead

8. Kotlin frontend developer

9. Kotlin frontend developer

10. Vuejs Frontend developer

11. Q&A testing

12. Design

13. Project Manager

14.Security Specialist

Итого команда будет из 14 человек




Общий срок реализации проекта – 4 Месяца.


Технологический стек: GO, VueJs, Kotlin

Процесс разработки разделён на спринты.

Длина каждого спринта – 1 неделю.

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


Общая стоимость решения с использованием XMPP - 22 500 000 рублей




Продуктовая команда на решение на основе zulip:

1. DevOps/SecOps

2. Project Manager

3. Architect

4. Python Backend team lead

5. Python Backend Developer

6. Python Backend Developer

7. Python Backend Developer

8. Kotlin frontend team lead

9. Kotlin frontend developer

10. Kotlin frontend developer

11. Vuejs Frontend

12. Q&A testing

13. Design

14. Project Manager

15. Security Specialist

Итого команда будет из 15 человек




Общий срок реализации проекта – 5 Месяцов.


Технологический стек: Python, VueJs, Kotlin

Процесс разработки разделён на спринты.

Длина каждого спринта – 1 неделю.

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


Общая стоимость решения с использованием Zulip - 25 140 000 рублей

Никита Мушковец