Alex Ivanov
ИТ-Предприниматель. Увлекаюсь аналитикой, low-code инструментами и growth-hacking подходом в разработке и маркетинге.
SLA именно на закрытие уязвимостей, не на доступность =) до доступности пока в рассуждениях даже не дошли, кроме упоминания названия компании-хостера. Это например публичное заявление, что критические уязвимости, взятые с таких-то уважаемых 5+ площадок мы обязуемся закрывать за 5 дней, высокий риск - за 7, средний за 10 и т.д.
Про весьма крупных клиентов, абсолютно не аргумент, это просто факт того, что их купили по тем или иным причинам весьма крупные клиенты, логически это не сильно коррелирует с реальной безопасностью. Да, требования от таких контрагентов выше, чем в среднем по рынку.
Ребята, ребятушки...Астанавитесь. @Compass @Пачка Pararam, @Jetchat , @eXpress , @Мессенджер Frisbee , @tada.team , AtChat, Росчат.
Я рад, что вы растягиваете рынок чатов, конкуренция нужна всегда, она делает рынок чище и лучше, но, каммон, если говорите о безопасности не на словах, просто дайте ответы:
1. А как устроен ваш процесс управления безопасностью , вкратце? Что для вас вообще значит понятие - мы являемся безопасным мессенджером?
2. Закрываете ли вы последние уязвимости ? с каких платформ и как быстро вы их берете и применяете ? Состав команды, которая занимается именно этим и методология этой работы? Где почитать про ваш statement по обязательству закрытия критических уязвимостей за лимитированное время? SLA ?
3. Есть ли своя программа BugBounty ?
4. Как часто и какими инструментами вы проводите внутренний аудит кода? Как часто и какие команды проводят внешний Пентест и проводят ли? Есть отчеты?
5. Банально, все ли есть на GitHub ?
Открыты issues на github? Ни разу не сталкивался, дайте линк пожалуйста.
В плане багов - продукт очень динамично разрабатывается, найденные баги закрываются.
Какие боли? Ограниченное количество пушей решается сборкой своего приложение из исходников. Начиная с 3-их версий продукт стабилен и хорошо масштабируется.
Mattermost vs RC.
1. RC будет быстрее потому что он написан на Meteor (JS), а не на GO + React. Говоря про БД - в RC можно создавать производительные кластеры из MongoDB, объекты выносить в s3.
В RC можно делать мультиинстансы. Единственная проблема в RC - утечка памяти лечится перезапуском по расписанию.
2. Что с whitelabelling у MM? Использовать его как хочется тебе в коммерческих целях легально?
Можно прописывать пуш-гейты у мобильных приложений?
3. В RC тонна security настроек из коробки. Только разрешений у юзера может быть 160+. Как с этим у MM?
4. в RC нет дополнительных фишек типа бордов, это коммуникационный железобетонный комбайн. Нужно трекать задачи и борды - Asana etc.
Коллеги, @Alex Melnikoff @Davidov Alexander @Максим Кульгин , Поддерживаю, конечно же, ваши мысли про бесплатные (не считая Total Cost of Ownership) решения на рынке коммуникаций, но почему Mattermost а не Rocket.Chat ? Хотя бы пару плюсов
Еще момент, посмотрел отзывы в сторах на приложения, в iOS их нет, в Android - честно говоря, откровенно видно, что не все настоящие и всего 59 их. Какие-то проблемы с мобильной версией? Спасибо.
на базе какой БД ваш продукт? сколько вариантов разрешений можно назначать каждой роли (вообще, это есть?)? есть ли API ? есть ли кластеризация? какие схемы деплоймента? где хранятся объекты (s3)? Типовая конфигурация железа на 1000 постоянных пользователей?
Здорово!!! Особенно анимация при авторизации пользователя!
Все плюсы "фрилансера" для работодателя не перекроют ресурсозатрат на дополнительный контроль. Если проект про четкие сроки, координацию и контроль, команда должна быть в зоне действия "кнута и пряника".
Отличный вариант для этих целей - использовать WorkFlowy. Минималистичный интерфейс, четкое разложение по полочкам. Но нужно привыкнуть к восприятию информации без картинок. Можно здоровски организовать вставку линков на картинки/файлы из dropbox, и придумать свою систему теггирования. В свое время это заставило меня полностью отказаться от облачных закладок в браузере, потому как получение любой инфы стартует с открытия соответствующего раздела в WF, и тезисно накидывается туда же после прочтения.
Спасибо за статью!
Интересный момент - насколько правильно сотруднику привязываться именно к временным интервалам грейдов текущей компании? Не вернее ли будет привязка к "деньгам в кармане"? К примеру, цель - раз в 2-3 года увеличивать доход в 2 раза, а не идти по грейду одной компании.
Пишу этот коммент под очередным обзором мессенджеров, которые сравнивают себя с аналогами и говорят, что мы безопасные :
Ребята, ребятушки...Астанавитесь. @Compass Мессенджер @Пачка , Pararam, @Jetchat , @eXpress , @Мессенджер Frisbee , Tada.team , AtChat, Росчат.
Я рад, что вы растягиваете рынок чатов, конкуренция нужна всегда, она делает рынок чище и лучше, но, каммон, если говорите о безопасности не на словах, просто дайте ответы:
1. А как устроен ваш процесс управления безопасностью , вкратце? Что для вас вообще значит понятие - мы являемся безопасным мессенджером?
2. Закрываете ли вы последние уязвимости ? с каких платформ и как быстро вы их берете и применяете ? Состав команды, которая занимается именно этим и методология этой работы? Где почитать про ваш statement по обязательству закрытия критических уязвимостей за лимитированное время? SLA ?
3. Есть ли своя программа BugBounty ?
4. Как часто и какими инструментами вы проводите внутренний аудит кода? Как часто и какие команды проводят внешний Пентест и проводят ли? Есть отчеты?
5. Банально, все ли есть на GitHub ?
Я практически уверен, этот вопрос опять останется без ответов. Потому что их нет, либо ответы на эти вопросы породят еще больше вопросов в которых успешно потонут отвечающие....