Когда сервис знакомств рассказывает о безопасности, текст обычно строится по одному шаблону: данные надежно защищены, модерация работает круглосуточно, современные алгоритмы следят за порядком. Звучит успокаивающе, но почти ничего не объясняет. Гораздо интереснее посмотреть не на обещания, а на конкретные механизмы. Что происходит с фотографией после загрузки? Где находится основной серверный контур? Может ли пользователь пожаловаться без подписки? Нужно ли сообщать собеседнику номер телефона для звонка? И что именно скрывается за словами об ИИ-модерации?
Я решил разобрать эти вопросы на примере сервиса знакомств мимолет бот. Это не полноценный аудит безопасности и не попытка проникнуть в чужую систему. Я смотрел на продукт как внешний наблюдатель: прошел обычные пользовательские сценарии, изучил доступное поведение API, сетевые ответы приложения, публичные сведения об инфраструктуре и логику видимых защитных механизмов. Административной панели, секретов системы и пользовательских данных у меня не было. Там, где внешний разбор не позволяет сделать уверенный вывод, я не выдаю предположение за доказанный факт.
Изначально я ожидал увидеть стандартную конструкцию: кнопка жалобы, простая проверка расширения загружаемого файла и несколько общих фраз в политике приватности. На практике устройство оказалось интереснее. У продукта есть спорные места, прежде всего в прозрачности хранения данных и процедуре обжалования блокировок. Но большая часть найденных решений выглядит не декоративной, а встроенной в саму логику сервиса.
Защита складывается из нескольких последовательных уровней, а не из одной универсальной функции.
Фотография не отправляется в хранилище как есть
Одна из самых недооцененных проблем социальных приложений связана с загрузкой файлов. Пользователь видит обычную кнопку выбора фотографии, а сервер получает объект, которому нельзя доверять только потому, что у него стоит расширение JPG. Название файла легко изменить. Кроме того, исходная фотография может содержать EXIF-метаданные: модель устройства, параметры камеры, дату съемки, а иногда и координаты места, где был сделан кадр.
Здесь обработка устроена разумнее. Формат определяется по фактическому содержимому файла, а не только по его названию. Перед сохранением изображение декодируется и перекодируется, метаданные удаляются, а размеры и разрешение проверяются с учетом установленных ограничений. Если файл поврежден или не распознается как допустимое изображение, загрузка отклоняется.
Для обычного человека это незаметный этап: он выбрал фотографию и увидел ее в анкете. Но сервер не принимает файл на веру и не складывает исходник в хранилище без обработки. Заодно уменьшается объем изображения и создаются версии для мобильной ленты.
Конечно, серверная перекодировка не превращает загрузку медиа в абсолютно неуязвимый процесс. Таких процессов вообще не бывает. Но это хороший базовый слой: он сокращает количество лишних данных в фотографии, отсекает часть некорректных файлов и делает поведение системы предсказуемее.
Основной контур находится в России
Вторая вещь, которую я хотел проверить отдельно, это география основной инфраструктуры. В рекламных текстах выражение «российские серверы» иногда используют слишком широко. Один узел действительно может находиться в России, а база данных, медиа, аналитика и вспомогательные сервисы при этом оказываются распределены между несколькими странами.
В данном случае подтверждается более аккуратная формулировка. Основное приложение, API и база данных размещены в российском серверном контуре. Пользовательские фотографии и другие медиа направляются в S3-сервис российского облачного провайдера. S3 в этом контексте означает объектное хранилище: файлы лежат отдельно от строк основной базы данных и выдаются приложению по ссылкам, а не записываются внутрь таблиц вместе с анкетами и сообщениями.
Отделение тяжелых медиафайлов от основной базы упрощает масштабирование и доставку изображений. Важнее другое: центральные компоненты действительно опираются на российского инфраструктурного поставщика.
При этом я бы не расширял вывод до фразы «абсолютно вся инфраструктура расположена только в России». У продукта есть вспомогательные вычислительные и транспортные компоненты за пределами основного контура. Точная физическая площадка конкретного S3-бакета также должна подтверждаться договором или настройкой региона, а не предположением по названию провайдера. Поэтому технически корректный итог звучит так: API и база данных работают в России, а медиа хранятся в S3 российского облачного провайдера.
ИИ здесь не сводится к запросу в чужой чат-бот
Сейчас почти любое приложение может добавить кнопку с ИИ, отправляя запрос стороннему поставщику. Для пользователя разницы почти не видно, зато для архитектуры и контроля над обработкой данных она существенна. Если основная модель работает на выделенной инфраструктуре под управлением команды, разработчики контролируют маршрутизацию, обновления, доступность и большую часть технических журналов. Если каждый запрос уходит во внешний публичный API, появляется еще одна сторона обработки и еще одна зависимость.
У mimolet bot основной путь устроен по первому варианту. Языковые функции, распознавание речи, построение векторных представлений и проверка изображений в первую очередь обслуживаются выделенной GPU-инфраструктурой, которой управляет команда продукта. Связь с ней проходит через защищенный технический канал, а не через открытый для всего интернета endpoint модели.
Сервис не полностью изолирован от внешних ИИ-провайдеров. Предусмотрен резервный путь на случай недоступности основной модели. Это разумное резервирование, но формулировка должна быть точной: основные ИИ-функции выполняются на выделенной инфраструктуре под управлением продукта, а внешний провайдер остается запасным вариантом.
Проверка изображений происходит до публикации
Автоматическая модерация бывает двух типов. В первом случае подозрительный материал уже появился в общей ленте или чате, после чего алгоритм пытается его найти. Во втором проверка встроена в сам путь загрузки: изображение должно пройти контроль до того, как будет сохранено и показано другим людям. Для публичных пространств второй вариант заметно полезнее.
Изображение проходит обработку и независимые проверки до попадания в публичное пространство.
Профильные фотографии и изображения, отправляемые в публичные групповые чаты, здесь проверяются синхронно до сохранения. Групповой чат — это общая тематическая или городская беседа, в которой публикацию могут увидеть сразу многие участники. Поэтому требования к такому контенту логично делать строже, чем к обычной личной переписке.
В проверке участвуют две разные системы. Первая специализируется на визуальном распознавании нежелательного контента. Вторая анализирует смысл изображения как отдельная мультимодальная модель. Дополнительно система может внимательнее рассмотреть отдельные фрагменты кадра. Это многоуровневая схема, но называть ее тремя независимыми ИИ было бы неточно: дополнительный анализ повторно использует одну из двух основных моделей.
Если запрещенное содержание подтверждается с высокой уверенностью, фотография не публикуется. В серьезном сценарии блокируется не только загрузка, но и сам аккаунт вместе со связанными устройствами. При менее однозначном сигнале система может остановить публикацию без необратимой санкции. Это важная деталь. Автоматическая модерация должна быть строгой к явному нарушению и осторожной там, где модель не уверена.
Алгоритмы здесь работают первым фильтром, а пользовательские сигналы и ручная модерация дополняют их там, где нужно учитывать контекст. Такая комбинация надежнее надежды на одну модель, которая якобы понимает все случаи без ошибок.
Жалоба не спрятана за оплатой
В сервисах знакомств платными могут быть дополнительные показы, расширенная видимость или косметические возможности. Но базовые средства самозащиты не должны зависеть от тарифа. Здесь жалоба и блокировка доступны обычному авторизованному пользователю без подписки.
Причины жалобы сформулированы не одной общей кнопкой «другое». Отдельно выделены скам, криптовалютные и инвестиционные предложения, интимные услуги, запрещенные вещества и другие нарушения. Это удобно пользователю и полезно модерации: структурированный сигнал проще анализировать, чем свободный текст из нескольких слов.
После жалобы анкета сразу исчезает из ленты конкретного человека. Ему не приходится ждать решения модератора, продолжая видеть того, с кем он не хочет взаимодействовать. Независимые повторные жалобы влияют на видимость подозрительного аккаунта, а информация передается ручной модерации. Сотрудник может увидеть историю сигналов, применить ограничение или удалить аккаунт. Административные действия при этом записываются в отдельный журнал.
Последний пункт особенно понравился. Модерация часто выглядит черным ящиком, а журнал действий создает внутреннюю проверяемость: можно понять, какое административное действие было выполнено и когда.
Отдельного автоматического классификатора для каждой категории жалоб я не обнаружил. Скам, сомнительные инвестиции и предложения запрещенных веществ обрабатываются через пользовательские обращения, накопительные сигналы и ручную проверку. Это не так эффектно звучит, как обещание «ИИ находит всех мошенников», зато ближе к реальности. Текст анкеты или переписки часто требует контекста, а слишком агрессивный автоматический фильтр неизбежно начинает наказывать нормальные разговоры.
Звонок не требует обмена номером
У сервисов знакомств есть странный переходный момент. Люди уже готовы поговорить голосом, но еще не готовы раскрывать номер телефона или переводить общение в другой мессенджер. Встроенный звонок закрывает этот разрыв.
Прямой голосовой вызов разрешен только между пользователями, у которых существует действующий личный чат и нет взаимной блокировки. Для соединения используются внутренние идентификаторы сервиса, WebRTC и временные технические данные для установления связи. Номер телефона в API звонка не участвует и собеседнику не передается.
Это не полная сетевая анонимность. При любом интернет-звонке серверы и сетевые посредники обрабатывают техническую информацию, необходимую для соединения. Зато решается понятная бытовая задача: можно услышать человека и решить, хочется ли продолжать общение, не раскрывая ему личный номер.
Первое замечание: сроки хранения описаны слишком общо
Теперь о том, к чему действительно можно придраться. В политике приватности используются знакомые формулировки вроде «не дольше необходимого» и «в разумный срок». Юридически и редакционно это привычный язык, но пользователю он почти ничего не сообщает. Разумный срок для фотографии, резервной копии, жалобы и истории общения с ИИ может означать совершенно разные периоды.
Особенно полезно было бы отдельно описать жизненный цикл истории взаимодействия с ИИ: что сохраняется для продолжения диалога, что может использоваться для аналитики и улучшения моделей, когда записи удаляются или обезличиваются, что происходит после удаления аккаунта. Аналогичная конкретика нужна для материалов модерации и резервных копий.
Это не утечка и не найденная «дыра». Речь о прозрачности и дисциплине хранения. Нужны автоматическое удаление или обезличивание и понятная таблица сроков в публичной политике.
Второе замечание: апелляция существует, но выглядит как обычное обращение в поддержку
Автоматическая модерация неизбежно ошибается, даже если несколько моделей снижают вероятность случайного решения. Поэтому важен не только механизм блокировки, но и понятный путь назад для человека, который считает санкцию ошибочной.
Заблокированный пользователь получает возможность обратиться в поддержку. Однако отдельной формы апелляции, номера обращения, статуса рассмотрения и понятного срока ответа в текущем пользовательском сценарии не видно. Нельзя быстро понять, было решение автоматическим или ручным и на каком этапе находится пересмотр.
Исправление здесь не требует менять всю систему модерации. Достаточно выделить апелляцию в отдельный процесс: присваивать обращению номер, показывать статус и сообщать обезличенную категорию причины. Это одновременно улучшит пользовательский опыт и даст команде измеримые данные о ложных блокировках.
Почему общее впечатление осталось положительным
Безопасность социального продукта редко держится на одной выдающейся функции. Это цепочка небольших решений, каждое из которых закрывает свой участок: файл проверяется и очищается перед сохранением, публичная фотография проходит автоматический контроль до публикации, жалоба немедленно убирает нежелательную анкету из личной ленты, повторные сигналы доходят до модератора, действия администратора фиксируются, а голосовой контакт не требует раскрывать номер.
По отдельности ни один из этих пунктов не дает права сказать, что сервис невозможно обмануть или взломать. Вместе они показывают более зрелый подход, чем установка одной кнопки «Пожаловаться» ради формального присутствия. Видно, что защитные механизмы встраивали в пользовательские маршруты, а не добавляли отдельной презентационной страницей после запуска.
Мне также понравилась сдержанная архитектурная логика. Основной серверный контур и база данных находятся в России. Медиа вынесены в объектное хранилище российского провайдера. Главный путь ИИ-функций проходит через выделенные вычислительные мощности под управлением команды. Для публичных фотографий используется проверка до сохранения, а не запоздалая реакция после распространения. Бесплатные жалобы сочетаются с ручным рассмотрением и внутренним аудитом действий.
При этом продукту полезно избегать слишком широких обещаний. Не вся вспомогательная инфраструктура российская. Внешний ИИ-провайдер предусмотрен как резерв. Проверка касается профильных и групповых фотографий, а не буквально каждого возможного файла во всех каналах. Обработка жалоб в тот же день пока не подтверждается измеримым публичным показателем. Эти уточнения не обесценивают систему, а делают рассказ о ней убедительнее.
В сухом остатке у мимолет получилась защита, которую можно обсуждать предметно. Здесь есть серверная очистка фотографий, российский основной контур, раздельное хранение медиа, управляемая ИИ-инфраструктура, многоуровневая проверка публичных изображений, бесплатные жалобы, ручная модерация с журналом действий и звонки без обмена телефонными номерами. Два главных вопроса относятся не к отсутствию защиты, а к ее прозрачности: сервису стоит назвать конкретные сроки хранения и превратить обращение по поводу блокировки в полноценную отслеживаемую апелляцию.
Для молодого социального продукта это неожиданно основательный набор. Он еще не дает оснований употреблять слова «абсолютно безопасно», но показывает правильную инженерную привычку: защита должна работать в момент действия пользователя, а не начинаться после того, как проблема уже разошлась по системе.
ссылка на оригинал статьи https://habr.com/ru/articles/1060460/