Безопасность и конфиденциальность

Как Babel Mesh распределяет запросы, защищает аккаунты и проверяет узлы и чего он не может.

Куда попадает то, что вы отправляете

Ваш запрос попадает на шлюз Babel Mesh, который выбирает узел по классу данных запроса и пересылает запрос ему. Узел вычисляет результат своей моделью и возвращает его через шлюз.

  • Узел, обрабатывающий запрос, может его прочитать. Сейчас это устроено именно так: чтобы ответить, узел должен прочитать запрос. Поэтому не отправляйте пароли, номера документов и коммерческие тайны.
  • Узел не видит, кто вы. Запрос, который получает узел, не содержит ни имени аккаунта, ни ключа, только анонимную метку.
  • Babel Mesh не хранит переписку. В записях шлюза остаются время запроса, модель, результат и объём использования. Переписка остаётся в вашем клиенте или браузере.
  • Исключение: правила содержимого. Шлюз проверяет входные и выходные данные по правилам содержимого. Запрос, сработавший на правило, оставляет короткий фрагмент вокруг совпадения и имя аккаунта, чтобы бороться со злоупотреблениями; полный текст не сохраняется.
  • Выборочные проверки повторяют запросы. Чтобы проверить, что возвращают участники, небольшая доля запросов публичного класса пересчитывается на собственных узлах оператора, и два результата сравниваются.

Классы данных

У каждого аккаунта и каждого запроса есть класс данных. Аккаунты, зарегистрированные самостоятельно, начинают с «публичного». Узлы участников получают только «публичные» запросы. Более высокие классы идут только на собственные узлы оператора. Изображения и видео пока тоже обслуживаются только узлами оператора, потому что их результаты нельзя проверять выборочно, как текст.

  • Сайт и API используют HTTPS. Компоненты за ними (контроллер, шлюз, реестр, ретранслятор, узлы) общаются по шифрованным соединениям с взаимной проверкой сертификатов; личность узла записана в его сертификате.
  • Узлы подключаются только наружу. Они не открывают входящий порт и работают через ретранслятор.
  • Клиент хранит ваш ключ API на вашем компьютере, и читать его может только ваша системная учётная запись. Страница клиента никогда не получает ключ; запросы отправляет сам клиент.
  • Обновления клиента проверяются по подписанному манифесту: открытый ключ встроен в клиент, а неверная подпись или версия, которая не новее, не устанавливаются никогда.

Учёт и проверка

  • Квитанции, подписанные обеими сторонами. По каждому запросу шлюз и узел подписывают одну и ту же квитанцию, и реестр записывает её, только если подписи совпали. В квитанции есть хеши запроса и результата и объём использования, но нет содержимого.
  • Случайные проверки. Новые узлы проверяют чаще, узлы с долгой безупречной историей — реже. Узел, чьи результаты не совпадают, помещается на карантин; когда оператор подтверждает обман, заработок аннулируется и взыскивается штраф по правилам.
  • Заработок удерживается. Доход участника ждёт несколько дней, и всё это время проверки продолжаются.

Чего он не может

  • Доверенной среды выполнения (TEE) пока нет: она не может гарантировать, что узел не видит содержимого, поэтому у запросов есть классы.
  • Он не проходил сторонний аудит безопасности.
  • Доступность не гарантируется: узлы могут исчезнуть в любой момент, а запрос повторяется на другом узле, но успех не гарантирован.
  • Правила содержимого несовершенны: они могут заблокировать по ошибке и могут кое-что пропустить.

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