Summary

  • Проект протокола MIMI, редакция 07, обновлённый 2 ноября 2026 года, помещает зашифрованное вложение во внешнее хранилище; HTTPS-адрес передаётся в ExternalPart сообщения.
  • Прямой запрос показывает файловому серверу IP получателя и время. Прокси хаба скрывает IP от этого сервера, но принимающий провайдер может сопоставить URL с пользователем и комнатой.
  • Oblivious HTTP делит запрос между ретранслятором и шлюзом. MIMI требует шлюз у хаба и рекомендует ретрансляторы остальным провайдерам.

Представьте комнату, участники которой пользуются тремя мессенджерами. Один отправляет фотографию. Снимок лежит на файловом сервере в зашифрованном виде; сообщение содержит ссылку для загрузки. Когда другой участник открывает его, возникает отдельное сетевое событие. У события есть время, источник и адрес назначения. Шифрование снимка не мешает владельцам этих точек наблюдать за обращением к нему.

RFC 9420 задаёт защиту группового содержимого средствами MLS. MIMI переносит обмен через границы провайдеров, а вложения обрабатывает как отдельные зашифрованные объекты. Сопутствующий проект политики комнаты использует asset_policy для разрешённых доменов хранилища. Поэтому список доменов задаёт круг операторов, которым может достаться информация о загрузках.

Прямой путь: сервер встречает каждого читателя

Первый маршрут ведёт от устройства непосредственно к серверу файла. По разделу 5.10 проекта этот сервер получает IP получателя и время запроса. Повторяющиеся обращения к одному объекту помогают судить о присутствии пользователей или их общей комнате. При загрузке между провайдерами документ помечает прямой путь NOT RECOMMENDED. Файловому оператору не требуется расшифровывать фотографию: журнал запросов уже описывает часть аудитории.

Второй маршрут проходит через провайдера получателя и хаб комнаты. Провайдер вызывает у хаба GET /proxyDownload/{downloadUrl}; хаб сам обращается к серверу файла. Сервер видит хаб вместо IP получателя. Хаб видит провайдера, запросившего URL, но в самом запросе нет прямого идентификатора человека или комнаты. Это ощутимое изменение того, кто получает исходный адрес клиента.

У провайдера получателя своя позиция: он знает клиента и требуемый URL. Проект прямо допускает сопоставление URL с пользователями и вывод о том, в какой комнате ссылку передали. Время входящего сообщения можно сравнить с временем исходящего запроса к прокси. Кэш у провайдера или хаба уменьшает часть таких совпадений: очередной просмотр не обязательно порождает новое обращение. Хаб обязан предоставлять прокси и проверять домен назначения по настроенным файловым серверам партнёрских провайдеров. Иначе служба вложений превратилась бы в открытый прокси для произвольных сайтов.

OHTTP меняет владельца сведений

Третий путь передаёт запрос клиента через OHTTP-ретранслятор принимающего провайдера к шлюзу хаба. Шлюз открывает запрос к назначению и получает файл. RFC 9458 описывает разделение: ретранслятор обслуживает исходное соединение, но не читает защищённый адрес цели; шлюз видит цель, не получая исходного соединения клиента, если роли действительно разделены. В MIMI хаб обязан поддерживать шлюз, другим провайдерам рекомендуется поддерживать ретранслятор. Шлюз также должен ограничивать цели настроенными файловыми доменами партнёров.

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

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

Проект MIMI · RFC 9458 · RFC 9420 · Политика комнаты MIMI