Политика конфиденциальности Typhon

Редакция от 11 октября 2026 года

Документ описывает, какие данные Typhon хранит на устройстве пользователя и какие передаёт наружу. Описано фактическое поведение текущей версии приложения, а не намерения.

Typhon разрабатывается и поддерживается независимым разработчиком (далее — оператор проекта Typhon). Оператор отвечает за обработку данных в серверных сервисах Typhon: сервисе учётной записи, сервисе метаданных, службе поддержки, отправке писем по электронной почте и раздаче обновлений приложения.

Оператор не управляет сетью BitTorrent, узлами DHT, обменом списками участников (PEX), сторонними источниками, добавленными пользователем, и сторонними сервисами. Что происходит с данными там, описано в разделе 7, но повлиять на это оператор не может.

Утверждение «мы не собираем никаких данных» было бы неверным, поэтому ниже приведено разделение: что не покидает устройство, что уходит сервисам Typhon и что уходит третьим сторонам.

1. Данные, которые остаются на устройстве

Следующие данные хранятся только локально и сервисам Typhon не передаются:

  • Источники релизов — адреса добавленных источников и содержимое их фидов. Фид запрашивается напрямую с хоста источника, соединение идёт с устройства пользователя без промежуточных серверов Typhon.
  • Загрузки — magnet-ссылки, infohash, списки файлов раздачи, содержимое загруженных файлов, история и состояние загрузок.
  • Установки — пути установки, состав установленных файлов, история установок и удалений, манифесты обновлений.
  • Библиотека — список игр, пути к исполняемым файлам, время и длительность игровых сессий. Если включена синхронизация между устройствами (раздел 2.3), часть этих сведений — идентификатор игры во внешнем каталоге IGDB, дата последнего запуска, наигранное время, отметка «любимая» и статус прохождения — передаётся сервису; пути, имена файлов и названия релизов не передаются.
  • Настройки приложения, включая параметры BitTorrent. При включённой синхронизации часть настроек передаётся сервису (раздел 2.3); пути к каталогам, лимиты скорости и согласия на сбор данных не передаются.
  • Журнал работы typhon.log и его предыдущие копии typhon.log.1 … typhon.log.5 — остаются на устройстве и целиком автоматически никуда не отправляются: пользователь может выгрузить очищенный архив журнала сам, по кнопке (разделы 2.10 и 2.11). Журнал ограничен по объёму: 10 МБ на файл и не больше шести файлов, старые перезаписываются.
  • Журнал игровых сессий — какая игра и когда была запущена и завершена, за последние 90 дней — хранится только на этом компьютере и на сервер не отправляется. Отметки «любимая» и статус прохождения хранятся на этом компьютере и передаются сервису только при включённой синхронизации (раздел 2.3).
  • Журнал совместимости — какие игры на этом компьютере запускаются, а какие нет: число попыток, число неудач, самая долгая сессия, код и текст последней ошибки. Ведётся всегда и никуда не отправляется сам по себе; при включённой статистике использования наружу уходит производная от него обезличенная запись, описанная в разделе 8.5. Текст ошибки не отправляется никогда.

Сами эти списки, пути и содержимое с устройства не уходят. Если пользователь включил анонимную статистику использования (раздел 8.2), наружу передаются только обезличенные сведения об исходе операции — например, что установка завершилась успешно и сколько секунд заняла, — но не перечисленное выше. Если пользователь включил анонимную диагностику (раздел 8.3), наружу передаётся обезличенный отчёт об ошибке — но не сам журнал и не его фрагменты.

Локальное состояние хранится в каталоге %APPDATA%\Typhon в файлах settings.json, account.json, profile.json, sync.json, library.json, playlog.json, sources.json, downloads.json, installations.json, removals.json, catalog.json, match_overrides.json, installation.json, compat.json, compat-client.json, compat-stats.json, а также в подкаталогах releases/, manifests/ и кэше метаданных.

В installation.json хранится только идентификатор установки — случайный UUIDv4, созданный при первом запуске приложения. Он не выводится из характеристик устройства и не является персональными данными сам по себе; куда он передаётся, описано в разделе 8.

В compat-client.json хранится отдельный идентификатор — тоже случайный UUIDv4, и намеренно не тот же самый. Отчёт о совместимости везёт версию системы, семейство процессора и перечень игр, по которым есть вердикт; общий идентификатор с обычной статистикой использования позволил бы сложить два набора в один профиль, заметно более подробный, чем каждый по отдельности. Разные идентификаторы этого не позволяют.

В compat-stats.json лежит скачанная общая статистика — те же цифры, что видят все остальные. Это входящие данные, ничего о владельце устройства они не содержат.

Удаление этого каталога удаляет все перечисленные локальные данные.

2. Данные, передаваемые сервисам Typhon

Адрес сервиса задаётся при сборке приложения. Токен доступа передаётся только по HTTPS; исключение сделано только для локального адреса при разработке.

2.1. Учётная запись

Приложение может работать без учётной записи, в гостевом режиме. В этом режиме запросы к сервису учётной записи не выполняются, локально хранится только признак гостевого режима.

При использовании учётной записи сервису передаются:

  • при регистрации — адрес электронной почты, имя пользователя, отображаемое имя, пароль и редакция Условий использования, которую пользователь принял; на указанный адрес уходит письмо с просьбой его подтвердить (раздел 2.12);
  • при принятии новой редакции Условий — её дата-версия;
  • при входе — имя пользователя либо адрес электронной почты и пароль;
  • при восстановлении пароля — адрес электронной почты, затем токен из присланного письма и новый пароль (раздел 2.12);
  • при работе с профилем — запросы на чтение и изменение профиля, загрузку и удаление аватара.

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

Принятие Условий использования хранится как запись: редакция, время принятия и где оно сделано — на сайте или в приложении. Записи только добавляются: при принятии новой редакции появляется новая, прежние остаются. IP-адрес и сведения о браузере или устройстве в эту запись не попадают.

Токен сессии хранится на устройстве в системном хранилище учётных данных Windows (Credential Manager), а не в файле настроек.

Та же учётная запись работает на сайте typhon-launcher.com: там можно зарегистрироваться, войти, написать в поддержку и подтвердить адрес или сменить пароль по ссылке из письма. Сессия на сайте — такая же запись о сессии, как в приложении (хеш токена, время создания, срок действия, длительность выдачи, отметка об отзыве), а сам токен лежит не в хранилище Windows, а в cookie браузера (раздел 8.4). При регистрации на сайте флажком принимаются Условия использования и подтверждается, что пользователь ознакомлен с Политикой: без флажка аккаунт не создаётся, а принятая редакция и время записываются на сервере. В приложении принятая редакция записывается в настройки на устройстве и, если пользователь вошёл в учётную запись, передаётся на сервер — при регистрации, при принятии новой редакции, а также при входе и запуске, если на сервере ещё нет записи о принятой текущей редакции; неудачная отправка повторяется, пока запись не появится. Учётные записи, созданные до появления этих записей, получают её при следующем принятии в приложении.

2.2. Метаданные игр

Чтобы показать обложки, описания и год выпуска, приложение обращается к сервису метаданных:

  • поиск по названию игры;
  • разрешение списка названий в идентификаторы игр;
  • получение карточки игры по идентификатору.

Метаданные доступны и без учётной записи: в гостевом режиме эти запросы выполняются так же, просто без токена.

Важные особенности, которые следует понимать:

  • Сервису передаётся название игры. При автоматическом поиске уже установленных игр название формируется из имени папки на диске. Если папка названа произвольно, это произвольное название будет отправлено как поисковый запрос.
  • Запросы метаданных из учётной записи содержат её токен. Это означает, что сервис технически может связать учётную запись с тем, какие названия игр запрашивались. Запросы из гостевого режима токена не содержат.
  • Названия игр из фидов источников тоже передаются сервису — для того же подбора обложек и описаний. Из названия записи фида приложение выделяет название игры (без имени сборщика, версии и прочих пометок) и год, и отправляет только их. Сервер сопоставляет их с каталогом и ничего из этого запроса не сохраняет.
  • Сервису метаданных не передаются: адреса источников, ссылки из фидов, magnet-ссылки, infohash, содержимое загрузок, история загрузок и пути установки.

2.3. Синхронизация между устройствами

Синхронизация выключена по умолчанию и включается вручную в настройках приложения. Пока она выключена, запросы к этой части сервиса не выполняются вовсе.

Когда она включена, сервису передаются и хранятся на сервере:

  • часть настроек приложения — тема оформления, масштаб интерфейса, анимации, сворачивание в трей, Discord Rich Presence, политики установки, проверки и очистки, интервал обновления источников, параметры обновления игр, раздача после загрузки. Перечень ограничен схемой базы данных: каждое значение лежит в отдельном поле заранее заданного типа, а перечислимые значения — с ограничением на список допустимых вариантов;
  • список игр — только числовой идентификатор игры во внешнем каталоге IGDB, отметка о том, что установкой управляет приложение, дата последнего запуска, наигранное время, отметка «любимая», статус прохождения и даты их изменения;
  • идентификаторы устройств — случайный UUIDv4, создаваемый при первом включении синхронизации на каждом устройстве, и отметки времени первого и последнего обращения. Этот идентификатор не совпадает с идентификатором установки из installation.json (раздел 1) и с ним не связывается.

Наигранное время хранится отдельным счётчиком на каждое устройство: иначе два компьютера затирали бы результат друг друга.

Синхронизация не передаёт адреса источников и содержимое фидов, названия релизов, magnet-ссылки, infohash, пути на диске, имена файлов, состав установки и историю загрузок. Не передаются и согласия на анонимную статистику и диагностику: эти переключатели остаются локальными на каждом устройстве и между устройствами не переносятся.

Игра, для которой приложение не определило идентификатор IGDB, не синхронизируется вообще — запасного варианта «отправить название» не предусмотрено. Идентификатор игры на сервере хранится числовым полем с внешним ключом на каталог, поэтому записать в него произвольную строку, ссылку или имя файла невозможно.

2.4. Проверка обновлений приложения

Приложение само проверяет, не вышла ли новая версия: запрашивает манифест обновлений у сервиса Typhon при запуске и далее примерно раз в шесть часов. Запрос выполняется без учётной записи и без токена. Как и любой запрос приложения к сервису (раздел 2.5), он несёт в заголовках установленную версию: по ней сервис выбирает манифест в формате, который эта версия умеет прочитать, а решение об обновлении принимается на устройстве. Если обновление принято, файл новой версии скачивается с того же сервиса.

Как и при любом сетевом запросе, серверу видны IP-адрес устройства и факт обращения.

2.5. Журналы и ограничение частоты запросов

Сервер записывает в журнал метод, путь запроса, код ответа и длительность обработки. Поисковые запросы, содержимое тела запроса и IP-адрес в этот журнал не попадают. Каждый запрос приложения к сервису несёт в заголовках версию приложения, операционную систему и архитектуру процессора; в этот журнал они тоже не записываются.

Перед сервисом и сайтом стоит обратный прокси, и у него свой журнал обращений: время, IP-адрес, метод, адрес запроса вместе со строкой параметров (в ней бывает и поисковый запрос), код ответа, длительность и заголовки запроса. Токен учётной записи и cookie в этот журнал не попадают: прокси заменяет их пометкой. Журнал прокси нужен для разбора сбоев и защиты от злоупотреблений, он хранится не дольше 7 дней и затем удаляется.

IP-адрес используется как временный ключ ограничения частоты запросов для обращений без учётной записи: он хранится в оперативной памяти сервиса, не записывается в базу данных и не связывается с учётной записью. Для запросов с учётной записью таким ключом служит её идентификатор, а не адрес. Такой же временный ключ по IP-адресу, с коротким сроком жизни, используется для состояния сессии (раздел 8.1), чтобы один адрес не мог насчитать тысячу запущенных лаунчеров; он живёт в оперативном хранилище и исчезает вместе с состоянием.

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

2.6. Состояние сессии, анонимная статистика использования и анонимная диагностика

Помимо перечисленного выше, приложение может передавать сервису Typhon состояние текущей сессии — пока включён переключатель «Онлайн-статус лаунчера», — а также анонимные события об исходах операций и обезличенные отчёты об ошибках, если пользователь включил соответствующие переключатели. Это три разных механизма с разным составом данных и разными сроками хранения; они описаны в разделе 8.

Переключателей три, и они независимы. «Онлайн-статус лаунчера» включён по умолчанию: в базовом виде он не содержит ничего, что указывало бы на устройство или пользователя (раздел 8.1), и выключается в настройках, в разделе «Приватность». Анонимная статистика использования и анонимная диагностика по умолчанию выключены: при первом запуске приложение задаёт вопрос о них прямо, оба варианта в вопросе не отмечены, и до ответа ни события, ни отчёты об ошибках не отправляются. Ответ — в том числе отказ — сохраняется, и повторно вопрос не задаётся.

У вопроса есть версия. Когда состав собираемых данных расширяется, версия повышается, и вопрос задаётся заново — с прошлым ответом, отмеченным заранее. До нового ответа новые данные не собираются, а прежний ответ продолжает действовать для того, на что он давался. Так произошло со статистикой совместимости игр (раздел 8.5) и с идентификатором установки и идентификатором игры в состоянии сессии (раздел 8.1): они входят в переключатель анонимной статистики использования, но у тех, кто отвечал на прошлую версию вопроса, не собираются, пока они не ответят на нынешнюю.

2.7. Чего сервисы Typhon не получают

Адреса добавленных пользователем источников, содержимое фидов источников, magnet-ссылки, infohash раздач, адреса трекеров и участников раздачи, адреса скачивания релизов, содержимое загружаемых файлов, имена файлов, локальные пути установки и локальная история загрузок сервисам Typhon не передаются. Это верно и при включённой синхронизации между устройствами (раздел 2.3).

Это верно и при включённой анонимной статистике использования. В её события попадают только исход операции, идентификатор игры из каталога и обезличенные числовые характеристики — длительность, объём, средняя скорость — с нормализованным кодом ошибки. Иначе говоря, сервису может стать известно, что загрузка завершилась неудачей за столько-то секунд с такой-то ошибкой, но не то, откуда она велась, что именно загружалось и куда на диске это писалось (раздел 8.2).

Это верно и для отчётов о совместимости (раздел 8.5). В них попадает прозвище сборщика репака — одно слово из закрытого списка, который зашит в приложение, — и номер версии сборки, но не сырое название релиза, не адрес источника, откуда он взят, и не infohash раздачи.

2.8. Друзья и профиль

Функции друзей работают только при включённой синхронизации между устройствами (раздел 2.3): пока она выключена, приложение не обращается к этой части сервиса — ни в фоне, ни при открытии раздела «Друзья», ни при открытии профиля. Вместо списка друзей раздел предлагает включить синхронизацию и по нажатию показывает отдельный экран согласия с перечнем того, что уходит с устройства; синхронизация включается только по подтверждению на этом экране. До подтверждения отправить заявку в друзья и узнать свой код друга нельзя.

Сервис хранит и обрабатывает:

  • список друзей и заявки в друзья — входящие и исходящие, с отметками времени;
  • список заблокированных пользователей;
  • код друга — восемь случайных символов, привязанных к учётной записи, для добавления в друзья без поиска по имени; код заводится на сервере при первом обращении за ним — когда пользователь при включённой синхронизации открывает свой профиль или нажимает «Мой код» в разделе «Друзья»; пользователь может в любой момент сгенерировать новый, прежний перестаёт действовать;
  • биографию профиля — текст до 150 символов, вводимый пользователем;
  • статус — один эмодзи и текст до 60 символов, вводимые пользователем;
  • тексты блоков профиля — то, что пользователь пишет в раскладке профиля сам: заголовки и текст текстовых блоков (до 40 и до 1000 символов, не больше четырёх блоков), подпись к закреплённой игре (до 140 символов), названия своих подборок игр (до 40 символов).

Что из профиля видят другие пользователи, определяется уровнем видимости («Кто видит профиль» в настройках: «Все», «Друзья» или «Никто», по умолчанию «Друзья») и отдельными переключателями поверх него: статус «В сети», текущая игра, наигранное время, библиотека (список игр, общие игры, «друзья играли» на странице игры), недавняя активность и статистика (игры, часы, пройдено). Каждый переключатель выключается независимо и скрывает только своё — например, выключенное наигранное время оставляет список игр видимым, но прячет часы. Пользователю за пределами уровня видимости эти сведения не отдаются вовсе: сервер не включает их в ответ, а не прячет на экране. Блоки раскладки подчиняются тем же переключателям: закреплённая игра, подборки и недавние игры — переключателю библиотеки, жанры и игровой отпечаток — статистике и наигранному времени (доли жанров считаются из часов), недавняя активность — активности; скрытый блок сервер в ответ не включает. Статус и тексты блоков видны тем же, кому видна биография. В списках друзей, заявок, общих друзей и в ленте рядом с именем показывается карточка игрока: оформление (цвет, рамка аватара, стиль имени) видно всем, кто видит пользователя в этом списке, а статус, обложка и закреплённая игра — только тем, кому виден профиль.

Заблокированный пользователь не может найти профиль через поиск или по коду друга и не видит его при прямом обращении — сервер отвечает так же, как на несуществующий профиль. Блокировка снимает существующую дружбу и удаляет все заявки между обоими пользователями, входящие и исходящие, независимо от того, кто заблокировал.

Отвязать себя от конкретного человека можно без обращения к оператору: удалить из друзей, заблокировать или сгенерировать новый код друга — прежние заявки и связи при этом исчезают. Данные о друзьях, заявках, блокировках, коде друга и биографии удаляются вместе с учётной записью (раздел 5).

Пока включена синхронизация между устройствами (раздел 2.3) и пользователь вошёл в учётную запись, приложение передаёт сервису статус в сети — раз в 30 секунд и дополнительно сразу при запуске или завершении игры. В статусе передаются: выбранный пользователем статус («В сети», «Отошёл», «Не беспокоить» или «Невидимка»), идентификатор запущенной игры в каталоге IGDB и версия приложения. Сервис хранит это в оперативном хранилище с коротким сроком жизни — как и у состояния сессии (раздел 8.1): примерно через 90 секунд без нового сигнала запись исчезает, историческая таблица «кто и когда был в сети» не ведётся. Отдельно от неё сервис хранит отметку «последняя активность»: она обновляется не чаще раза в 5 минут и не обновляется вовсе, пока выбран статус «Невидимка». Кроме этой отметки, дольше 90-секундного окна ничего о статусе в сети не хранится. Пока синхронизация выключена или пользователь не вошёл в учётную запись, статус не отправляется вовсе — ни в фоне, ни при запуске игры, ни при выходе из приложения.

Кому виден статус, определяется так же, как остальные поля профиля (выше): уровнем видимости и переключателями «В сети» и «Во что играю» — выключенный переключатель прячет соответственно статус или игру. Статус «Невидимка» — исключение: он показывается всем как «не в сети», без времени последней активности, независимо от уровня видимости и переключателей.

Отдельно от статуса в сети сервис ведёт ленту активности друзей. Событие в ней появляется только по итогам синхронизации между устройствами (раздел 2.3) и только для игры, уже числящейся в библиотеке аккаунта на сервере, — видов события три: переход статуса игры в «пройдено», первое наигранное время на игре (до синхронизации по ней нигде не было накоплено времени, после — появилось) и добавление в «любимые». У только что добавленной на сервер игры нет предыдущего состояния для сравнения, поэтому импорт библиотеки — первая синхронизация каждой новой игры — событий не создаёт: они возникают только на последующих синхронизациях, когда для игры уже есть с чем сравнивать. Событие одного вида для одной и той же игры не создаётся чаще раза в 30 дней: повторное срабатывание того же перехода в этом окне новую запись не добавляет. Хранятся события 90 дней, затем удаляются вместе с реакциями на них (ниже).

Видна лента активности только друзьям и только пока у автора события включён переключатель «Показывать активность» — тот же переключатель, что скрывает виджет «Недавняя активность» на странице профиля (выше). Уровень видимости «Никто» скрывает события полностью, в том числе от друзей; уровни «Все» и «Друзья» для ленты равнозначны — лента доступна только тем, кто состоит в друзьях с автором события. Заблокированный пользователь ленту не видит: блокировка снимает дружбу (выше), а вместе с ней и доступ к событиям.

На событие в ленте можно поставить реакцию — один из восьми фиксированных значков. Реакция хранится как связка события, пользователя и значка; видна она всем, кому видно само событие, и пользователь может убрать свою реакцию в любой момент.

К своему событию в ленте автор может добавить подпись — короткий текст, вводимый вручную. Подпись хранится вместе с событием, видна тем же, кому видно событие, и удаляется вместе с ним; автор может убрать или изменить её в любой момент.

2.9. Отзывы, чат, обложка профиля

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

Отзывы об играх. Отзыв состоит из оценки «рекомендую» или «не рекомендую» и текста от 20 до 5000 символов без ссылок. Отзыв публичен: он показывается на странице игры всем пользователям приложения, в том числе без учётной записи, вместе с отображаемым именем автора, его аватаром и наигранным временем в этой игре по данным синхронизации. Оставить отзыв можно после 30 минут в игре через Typhon и не раньше, чем через сутки после регистрации. Другие пользователи могут отметить отзыв полезным или пожаловаться на него; жалоба хранится с причиной из фиксированного списка и идентификатором пожаловавшегося. Отзыв, собравший пять жалоб, скрывается автоматически; отзыв также может скрыть или удалить оператор. Автор может изменить или удалить свой отзыв в любой момент. Отзывы хранятся, пока автор их не удалит, либо до удаления учётной записи.

Сообщения между друзьями. Переписка возможна только между пользователями, состоящими в друзьях. Сообщение — текст до 4000 символов; к нему можно поставить реакцию. Сообщения хранятся на сервере 7 дней с момента отправки и затем удаляются вместе с реакциями и отметками о прочтении; сервер не ведёт архива переписки. Содержимое сообщений не анализируется и не используется ни для чего, кроме доставки.

Обложка профиля. Изображение JPG, PNG, WebP или GIF до 8 МБ, которое пользователь загружает для оформления своего профиля. Хранится файлом в объектном хранилище и доступно по прямой ссылке тем, кто эту ссылку знает, — так же, как аватар. При замене и при удалении предыдущий файл удаляется; при удалении учётной записи удаляются все её файлы. GIF остаётся анимированным только у учётных записей, которым разрешены анимированные изображения; у остальных сервер сохраняет первый кадр как обычную обложку.

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

2.10. Выгрузка журнала по запросу пользователя

В настройках, в разделе «О программе», в карточке «Логи лаунчера» есть кнопки «Скачать логи» и «Отправить нам». Первая сохраняет архив в папку «Загрузки» на устройстве, вторая отправляет такой же архив на сервер Typhon. Отправка происходит только по нажатию и после подтверждения; само по себе приложение журнал никуда не передаёт (раздел 8.4). Этот же архив можно приложить к обращению в поддержку (раздел 2.11).

Что в архиве. Файл info.txt и журнал работы — typhon.log и его предыдущие копии, из каждого файла берутся не больше последних 16 МБ. В info.txt записаны версия приложения, время сборки архива, платформа и архитектура, каталог данных (путь заменяется пометкой), название операционной системы, модель процессора, число потоков и объём оперативной памяти.

Что очищается. Каждая строка проходит те же правила замены, что и отчёты об ошибках (раздел 8.3), и заменяется пометками: локальные пути — <path>; имя пользователя операционной системы, которое берётся из имени домашней папки, — <user>, имя компьютера — <host>; IP-адреса — <ip>; адреса электронной почты — <email>; MAC-адреса — <mac>; magnet-ссылки, infohash и длинные шестнадцатеричные строки — <hash>; значения полей с токенами, паролями и ключами — <token>. У web-адреса остаются схема и имя хоста, путь и параметры отбрасываются. Имя пользователя короче трёх символов и общие имена вроде user или admin не заменяются: иначе они вырезали бы обычные слова.

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

В отличие от отчётов об ошибках, у архива нет проверки «отказать, а не пропустить» (раздел 8.3): если после очистки в тексте осталось что-то похожее на чувствительное значение, архив всё равно собирается и отправляется. Поэтому перед отправкой приложение предупреждает о составе архива, а сам архив можно сначала скачать и просмотреть: отправляется архив того же состава.

Архив ограничен 8 МБ в сжатом виде; что не поместилось (старые копии журнала), отбрасывается, и приложение показывает, какие файлы не вошли.

На сервере архив, отправленный отдельно, хранится 72 часа и затем удаляется. Учётная запись к нему не привязывается: он описывается только идентификатором установки, идентификатором сессии, версией приложения и операционной системой. Приложенный к обращению архив связывается с обращением и хранится дольше (разделы 2.11 и 4). Оператор использует его только для разбора присланной ошибки.

2.11. Обращения в поддержку

Это то, что пользователь пишет сам: пока он не отправил обращение, ничего из описанного ниже не существует. Из приложения обращение создаётся из учётной записи. На сайте его можно оставить и из учётной записи, и без входа — гостем, с подтверждённым адресом электронной почты.

Что передаётся и хранится. Тема обращения (до 120 символов) и текст (до 5000 символов в сообщении), все следующие сообщения пользователя и ответы поддержки с отметками времени; раздел из закрытого списка (установка, запуск игры, учётная запись, лаунчер, другое); статус обращения; язык интерфейса — русский или английский, — на котором придут письма. Из приложения к обращению добавляются версия приложения, операционная система и архитектура, а если пользователь выбрал игру — её числовой идентификатор в каталоге IGDB. Обращение из учётной записи связано с ней. Гостевое обращение связано с адресом электронной почты, который гость указал: он хранится в обращении, рядом с ним — его нормализованная форма (строчные буквы, без метки после «+», у Gmail без точек), по которой сервер ограничивает число неподтверждённых обращений с одного адреса. Ключ, который открывает гостевое обращение, сервер хранит только в виде хеша: повторно выдать его или вставить в другое письмо он не может.

Журнал. К обращению и к следующим сообщениям из приложения можно приложить архив журнала — отдельной отметкой, после подтверждения. Это тот же очищенный архив с тем же составом, что при ручной отправке (раздел 2.10). Он загружается на сервер как отдельный файл, который описывается только идентификатором установки, идентификатором сессии, версией приложения и операционной системой, а приложенный к обращению связывается с этим обращением и через него с учётной записью. С сайта и из гостевого обращения журнал приложить нельзя. На одно обращение можно приложить не больше пяти архивов.

Кто видит. Обращение и приложенный архив видят сотрудники поддержки и администратор проекта. Адрес электронной почты учётной записи рядовому сотруднику поддержки не показывается, его видит администратор; адрес гостя видят оба, потому что другого способа ответить нет. Содержимое обращений не анализируется автоматически и ни для чего, кроме ответа на обращение, не используется. Не вставляйте в обращение пароли, ссылки для входа и сброса пароля из писем, платёжные данные и адреса источников: поддержке они не нужны, а текст видят люди.

Уведомления. Когда поддержка отвечает, на адрес электронной почты приходит письмо с номером обращения и ссылкой на страницу, где его можно прочитать; текст ответа в письмо не попадает (раздел 2.12). Сроки хранения — в разделе 4.

2.12. Электронная почта

Сервис отправляет письма только в связи с действием пользователя и только в четырёх случаях: подтверждение адреса после регистрации (ссылка действует 48 часов); сброс пароля по запросу (ссылка действует 2 часа); подтверждение гостевого обращения (ссылка — единственный путь к переписке, неподтверждённое обращение удаляется через 48 часов); уведомление об ответе поддержки. Рекламных и информационных рассылок, писем о продукте нет.

Письмо сначала записывается в очередь отправки в базе сервиса: адрес получателя, тип письма, язык и данные для шаблона, то есть ссылка и, при наличии, имя пользователя. После отправки или окончательной неудачи данные для шаблона стираются сразу, а запись остаётся на срок из раздела 4. Токены подтверждения адреса и сброса пароля сервер хранит в виде хеша вместе с назначением, адресом и сроком действия.

Письма отправляются через почтовую службу Spaceship (Spacemail), с адреса no-reply@typhon-launcher.com, по зашифрованному соединению. Поставщик видит адрес получателя и текст письма, включая ссылку; серверы поставщика находятся в США. Подробности — в разделе 7.1.

3. Зачем обрабатываются данные

Серверные сервисы Typhon обрабатывают данные только для следующего:

  • создание учётной записи и вход в неё;
  • проверка прав доступа при обращении к серверным функциям;
  • профиль: имя пользователя, отображаемое имя, адрес электронной почты, аватар;
  • друзья и видимость профиля: заявки в друзья, список друзей и заблокированных, код друга, показ профиля другим пользователям по уровню видимости (раздел 2.8);
  • выдача игровых метаданных по запросу приложения;
  • выдача манифеста и файлов обновления приложения;
  • ответы на обращения в поддержку (раздел 2.11);
  • отправка писем, без которых не работают учётная запись и поддержка: подтверждение адреса, сброс пароля, подтверждение гостевого обращения, уведомление об ответе (раздел 2.12);
  • ограничение частоты запросов, чтобы сервисы оставались доступными;
  • агрегированный подсчёт в реальном времени: сколько лаунчеров сейчас запущено, сколько из них в игре, в какие игры играют и какие версии приложения в ходу (раздел 8.1);
  • при явно включённом пользователем переключателе — продуктовая аналитика использования: насколько часто загрузки, установки и обновления завершаются успешно и на каких операциях приложение чаще ошибается (раздел 8.2).

Данные не используются для рекламы, маркетинга и профилирования: рекламных или маркетинговых профилей пользователя из них не строят и третьим сторонам их не передают. Аналитика ограничена тем, что описано в разделе 8: агрегированным состоянием сессий и — только с явного согласия пользователя — исходами операций приложения. Нажатия, переходы по экранам и прочее поведение в интерфейсе не отслеживаются. Списков рассылки нет: адрес электронной почты нужен для входа, подтверждения адреса, восстановления доступа к учётной записи и уведомлений об ответах поддержки, а не для писем о продукте.

4. Сроки хранения

Данные учётной записи и профиля, включая записи о принятии Условий, хранятся, пока существует учётная запись.

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

Журнал обращений обратного прокси (раздел 2.5) хранится не дольше 7 дней.

Аватар хранится в объектном хранилище, пока не заменён на новый или не удалён. При замене и при удалении предыдущий файл удаляется сразу.

Состояние сессии (раздел 8.1) хранится в оперативном хранилище с коротким сроком жизни: примерно через 90 секунд без нового сигнала запись исчезает. Историческая таблица «кто и когда был в сети» не ведётся, на диск эти записи не сохраняются.

Синхронизированные настройки и список игр (раздел 2.3) хранятся, пока существует учётная запись, либо пока пользователь не удалит их сам.

Записи о друзьях, заявках в друзья и блокировках (раздел 2.8) хранятся, пока существует учётная запись, либо пока пользователь не удалит их сам: отклонит или отменит заявку, удалит из друзей, разблокирует.

События анонимной статистики использования (раздел 8.2) хранятся на сервере 30 дней — срок задаётся настройкой сервиса, — после чего удаляются.

Отчёты о совместимости игр (раздел 8.5) хранятся на сервере 180 дней — срок задаётся настройкой сервиса. Срок отсчитывается от последнего обновления записи, а не от её создания: приложение периодически присылает вердикт заново, и, пока игра на устройстве остаётся, её запись обновляется и не удаляется. Как только приложение перестаёт присылать вердикт — потому что игру удалили, переключатель выключили или устройством перестали пользоваться, — запись доживает свои 180 дней и удаляется. Срок здесь длиннее, чем у статистики использования, потому что доля удачных запусков имеет смысл только накопленной: за 30 дней по большинству игр не набралось бы наблюдений даже на то, чтобы показать цифру.

Отчёты анонимной диагностики (раздел 8.3) хранятся на сервере 30 дней — срок задаётся настройкой сервиса, — после чего удаляются. Одинаковые ошибки хранятся не по отдельности, а группой: у группы есть отпечаток, счётчик, время первого и последнего появления и набор затронутых версий приложения.

Архивы журнала, отправленные вручную (раздел 2.10) и не приложенные к обращению, хранятся 72 часа. Сообщения между друзьями (раздел 2.9) — 7 дней с момента отправки. События ленты активности и подписи к ним (раздел 2.8) — 90 дней. Отзывы и обложка профиля (раздел 2.9) — пока пользователь их не удалит, либо до удаления учётной записи. Кэш поисковых строк каталога (раздел 2.5) — сутки.

Обращения в поддержку (раздел 2.11) хранятся так:

  • открытое обращение — пока его не закроют пользователь или поддержка; срока хранения у такого обращения нет;
  • обращение, на которое поддержка ответила, а пользователь молчит 14 суток, закрывается автоматически;
  • закрытое обращение вместе со всей перепиской хранится 365 суток с момента закрытия и затем удаляется; ответ пользователя в закрытом обращении открывает его заново, и срок отсчитывается от следующего закрытия;
  • неподтверждённое гостевое обращение, которое никто не видел, удаляется через 48 часов после создания; у подтверждённого гостевого те же сроки, что у остальных;
  • архив журнала, приложенный к обращению, хранится, пока обращение открыто, и ещё 30 суток после его закрытия; если обращение открыли заново, архив остаётся при нём. Проверка идёт раз в час.

Письма (раздел 2.12): после отправки или окончательной неудачи текст письма стирается из очереди сразу, а запись о нём — адрес получателя, тип письма, язык, время и служебная отметка об ошибке отправки — хранится 30 суток и удаляется. Токены подтверждения адреса и сброса пароля хранятся в виде хеша и удаляются не позднее чем через 7 суток после использования или истечения срока (сами ссылки действуют 48 часов и 2 часа). Копии отправленных писем у почтовой службы хранятся по её собственным правилам (раздел 7.1).

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

5. Удаление аккаунта и данных

Локальные данные удаляются удалением каталога %APPDATA%\Typhon (раздел 1). Аватар удаляется в приложении, в настройках профиля.

Синхронизированные между устройствами данные (раздел 2.3) удаляются с сервера в приложении, в настройках синхронизации. Само по себе выключение синхронизации их не удаляет; вместе с учётной записью они удаляются автоматически.

Учётная запись удаляется самим пользователем в приложении, в настройках профиля, по кнопке «Удалить аккаунт» с подтверждением паролем. Удаление выполняется сразу и необратимо: с сервера удаляются запись учётной записи, хеш пароля, все сессии, записи о принятии Условий, профиль и биография, файлы аватара и обложки, синхронизированные настройки и список игр, друзья, заявки и блокировки, события ленты с подписями и реакциями, сообщения чата, отзывы, голоса и жалобы на отзывы, обращения в поддержку со всей перепиской, токены подтверждения адреса и сброса пароля и все записи очереди писем, адресованные на адрес электронной почты учётной записи. Сессии сайта — те же записи, что сессии приложения, и удаляются вместе с ними. Архивы журнала, приложенные к удалённым обращениям, отсоединяются от них и удаляются очередной ежечасной очисткой, но не раньше, чем пройдёт 72 часа с их получения. Записи во внутреннем журнале действий оператора, если они были, сохраняют только имя пользователя на момент действия (раздел 2.9). Обезличенные данные из раздела 8 с учётной записью не связаны и удалением не затрагиваются.

С удалением учётной записи не удаляются гостевые обращения, оставленные с того же адреса электронной почты до регистрации или без входа: они не связаны с учётной записью и хранятся по общим срокам раздела 4. Просьбу удалить их раньше можно направить на abuse@typhon-launcher.com с того же адреса; оператор рассматривает её в порядке, описанном в разделе 6. Пользователь с учётной записью может закрыть своё обращение сам, в приложении или на сайте; удалить отдельное обращение из интерфейса нельзя. Удалить конкретное обращение или отдельное сообщение в нём раньше срока можно по запросу на abuse@typhon-launcher.com с адреса учётной записи или гостевого обращения: администратор удаляет в панели управления либо обращение целиком — со всей перепиской и приложенными архивами журнала, — либо одно сообщение вместе с его архивом; архивы удаляются сразу. Само удаление отмечается во внутреннем журнале действий оператора: кто и когда удалил, причина, если её указали, имя пользователя, если обращение было из учётной записи, и служебные отметки — номер обращения, его раздел и статус, признак гостевого обращения, число сообщений, идентификаторы удалённых сообщений и архивов, кем написано удалённое сообщение (пользователем или поддержкой) и основание, если удаление выполнено по обращению о нарушении. Тема, текст обращения и сообщений и адрес гостя в журнал не попадают.

Если войти в приложение невозможно (утерян пароль или устройство), запрос на удаление принимается на abuse@typhon-launcher.com с адреса электронной почты, связанного с аккаунтом; его выполняет оператор проекта вручную тем же механизмом.

6. Права пользователя

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

Имя пользователя, отображаемое имя, адрес электронной почты и аватар можно посмотреть и изменить в приложении, в настройках профиля; там же учётная запись удаляется целиком (раздел 5). По остальным запросам — abuse@typhon-launcher.com. Оператор отвечает по существу, в разумный срок и без платы за это.

Запрос о данных за пределами серверных сервисов Typhon — например, о данных в сети BitTorrent или на стороннем источнике — оператор выполнить не может: этими данными он не управляет.

7. Третьи стороны

Здесь важно различать три разных случая: что сервисы Typhon передают дальше, что уходит с устройства напрямую в обход Typhon и что происходит в сети BitTorrent.

7.1. Кому передают данные сервисы Typhon

  • Хостинг и инфраструктура. Сервисы работают на арендованном сервере, данные учётных записей — в базе данных, файлы аватаров — в объектном хранилище. Поставщики этой инфраструктуры технически имеют доступ к размещённым у них данным.
  • IGDB (Twitch). Сервис метаданных не держит собственную базу игр: получив запрос, он обращается к IGDB и возвращает ответ приложению. Туда уходит поисковая строка — то есть название игры или имя папки. Данные учётной записи в IGDB не передаются.
  • Почтовая служба Spaceship (Spacemail). Все письма сервиса (раздел 2.12) отправляются через неё с адреса no-reply@typhon-launcher.com. Поставщику передаются адрес получателя и полный текст письма, включая ссылку с токеном или ключом, которая в нём есть; копии отправленных писем он хранит по собственным правилам, и оператор на это не влияет. Серверы поставщика находятся в США, поэтому адрес электронной почты и содержание писем передаются за пределы страны пользователя, в том числе за пределы Украины и Европейского союза. Передача — часть действия, которое пользователь сам запросил (регистрация, восстановление пароля, обращение в поддержку): без неё письмо дойти не может.

Других получателей нет: данные учётных записей не передаются рекламным сетям, аналитическим сервисам и брокерам данных и не продаются.

7.2. Что уходит с устройства напрямую, минуя сервисы Typhon

Эти передачи выполняет само устройство. Сервисы Typhon в них не участвуют и их содержимого не видят.

  • Хосты источников. При обновлении источника приложение выполняет HTTP-запрос напрямую к хосту, указанному пользователем. Хост источника видит IP-адрес пользователя и факт запроса. Прокси не используется.
  • Изображения метаданных. Обложки и скриншоты приложение загружает напрямую с сети доставки контента IGDB (images.igdb.com) по адресам из ответа сервиса метаданных. Владелец этой сети видит IP-адрес пользователя и запрошенные изображения.
  • Discord. Показ статуса в Discord по умолчанию выключен. Если он включён, приложение передаёт данные локальному клиенту Discord через именованный канал операционной системы — по сети со стороны Typhon эти данные не отправляются. Передаются название запущенной игры, округлённая длительность сессии и, при наличии, адрес обложки. Дальше эти данные обрабатывает клиент Discord по правилам Discord.

7.3. Сеть BitTorrent

При загрузке через BitTorrent приложение участвует в работе распределённой сети: включены DHT и обмен списками участников (PEX). Это означает, что трекеры, узлы DHT и другие участники раздачи видят IP-адрес пользователя и infohash раздачи. Такое поведение заложено в протокол BitTorrent.

Передача данных другим участникам управляется двумя раздельными настройками, обе по умолчанию выключены:

  • «Отдавать во время загрузки» — передача уже полученных частей во время активной загрузки;
  • «Раздавать после загрузки» — передача завершённой загрузки после её окончания.

Сеть BitTorrent работает независимо от Typhon. Оператор не ведёт её учёта, не видит, кто и что в ней передаёт, и не может изъять оттуда данные по запросу.

8. Состояние сессии, статистика использования и диагностика ошибок

Здесь описаны три механизма, по которым приложение сообщает сервису Typhon о собственной работе. У каждого свой переключатель в настройках, в разделе «Приватность», и переключатели независимы друг от друга. Состояние сессии отправляется, пока включён «Онлайн-статус лаунчера» — по умолчанию он включён; анонимная статистика использования и анонимная диагностика — только если пользователь сам их включил. При первом запуске приложение спрашивает про статистику и диагностику один раз и до ответа не отправляет ни события, ни отчёты об ошибках.

8.1. Состояние сессии

Включено по умолчанию и отключается. Переключатель «Онлайн-статус лаунчера» находится в настройках, в разделе «Приватность», и действует без перезапуска приложения: следующий сигнал уходит уже по новому положению переключателей (запрос, который в момент переключения уже отправлялся, не отзывается). Что именно уходит, зависит от него и от переключателя анонимной статистики использования (раздел 8.2):

  • «Онлайн-статус лаунчера» выключен — не отправляется ничего: ни сигнал раз в 30 секунд, ни сообщение о завершении сессии при выходе из приложения. Положение переключателя статистики здесь ничего не меняет;
  • включён, статистика использования выключена (или на нынешнюю версию вопроса о ней ещё нет ответа, раздел 2.6) — раз в 30 секунд и сразу при запуске и остановке игры уходит базовый сигнал: идентификатор сессии, состояние (idle — лаунчер запущен, playing — запущена игра), версия приложения, операционная система и архитектура. Идентификатора установки и идентификатора игры в нём нет. При выходе из приложения уходит только идентификатор сессии;
  • включён, статистика использования включена — к базовому сигналу добавляются идентификатор установки и, если игра запущена, идентификатор игры из каталога. При выходе из приложения вместе с идентификатором сессии уходит идентификатор установки.

Больше в этих запросах ничего нет.

Идентификатор сессии — случайный UUIDv4, который лаунчер создаёт при каждом запуске. Он существует только в оперативной памяти и при следующем запуске будет другим. Идентификатор установки — случайный UUIDv4, созданный при первом запуске и сохранённый на устройстве в файле %APPDATA%\Typhon\installation.json. Он постоянный, поэтому в состояние сессии попадает только с согласия на статистику использования.

Оба идентификатора — просто случайные числа. Ни один из них не выводится из характеристик устройства: ни из MAC-адреса, ни из идентификатора безопасности Windows (SID), ни из серийного номера диска, ни из идентификатора процессора, ни из данных учётной записи.

Идентификатор игры здесь — числовой идентификатор карточки игры в каталоге, а не название файла, не имя папки и не путь на диске.

Токен учётной записи в этих запросах не передаётся никогда — ни в гостевом режиме, ни при выполненном входе. Связать состояние сессии с учётной записью сервис не может.

На сервере такие записи хранятся в оперативном хранилище с коротким сроком жизни: примерно через 90 секунд без нового сигнала запись исчезает. Историческая таблица «кто и когда был в сети» не ведётся и на диск не сохраняется.

Эти данные нужны только для агрегированного счёта: сколько лаунчеров сейчас запущено, сколько из них в игре, какие версии приложения в ходу и — по сигналам с идентификатором игры — в какие игры играют.

Если отправка не удалась, приложение продолжает работать как обычно и ничего пользователю не показывает.

Это не история использования: события и действия пользователя здесь не накапливаются — передаётся только текущее состояние, которое сервер держит десятки секунд и затем теряет. Переключатель анонимной диагностики (раздел 8.3) на состояние сессии не влияет, а переключатель статистики использования влияет только на то, добавляются ли идентификатор установки и идентификатор игры.

Статус в сети для друзей (раздел 2.8) — отдельный механизм, привязанный к учётной записи: переключатель «Онлайн-статус лаунчера» на него не влияет.

8.2. Анонимная статистика использования

По умолчанию выключена. В вопросе при первом запуске она не отмечена, и включить её можно только отдельным действием — там же или позже в настройках приложения, в разделе «Приватность».

Помимо событий, описанных ниже, этот переключатель добавляет к состоянию сессии идентификатор установки и идентификатор игры из каталога (раздел 8.1), если включён и «Онлайн-статус лаунчера».

Пока переключатель выключен, не отправляется ничего: события не собираются и не накапливаются.

Когда переключатель включён, приложение отправляет пакетами, примерно раз в 25 секунд, события об исходах операций: запуск и остановка лаунчера; запуск и остановка игры; загрузка — начата, завершена, не удалась, отменена; установка — начата, завершена, не удалась; обновление, проверка и восстановление — начаты, завершены, не удались.

У события есть только: тип, отметка времени, идентификатор установки, идентификатор сессии, версия приложения, операционная система, архитектура и ограниченный набор свойств — идентификатор игры из каталога, длительность в секундах, объём в байтах, средняя скорость, тип установщика и нормализованный код ошибки (например, timeout, permission_denied, disk_full, unknown). Текст сообщения об ошибке не отправляется.

В события не попадают: magnet-ссылки, infohash, адреса источников и трекеров, адреса скачивания релизов, исходные названия релизов, имена файлов, локальные пути и IP-адреса участников раздачи. Структура события технически не позволяет им туда попасть. То же верно и для отчётов о совместимости (раздел 8.5), которые включаются этим же переключателем.

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

На сервере эти события хранятся 30 дней — срок задаётся настройкой сервиса, — после чего удаляются.

Этот же переключатель включает отчёты о совместимости игр — они описаны отдельно, в разделе 8.5, потому что состав данных у них другой.

Называть это иначе было бы неверно: это продуктовая аналитика использования. Она нужна, чтобы видеть, насколько часто загрузки, установки и обновления доходят до конца и на каких операциях приложение чаще ошибается.

8.3. Анонимная диагностика ошибок

Включается только ответом пользователя. При первом запуске приложение спрашивает, отправлять ли анонимные отчёты об ошибках. В этом вопросе диагностика не отмечена, и пока пользователь не ответил, наружу не уходит ничего. Отказ сохраняется так же, как согласие, и вопрос больше не повторяется. Переключатель остаётся в настройках приложения, в разделе «Приватность», и решение можно изменить в любой момент. Переключатель анонимной статистики использования (раздел 8.2) на диагностику не влияет, и наоборот.

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

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

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

Перед отправкой каждое текстовое поле проходит очистку: из него удаляются локальные пути целиком — записанные и через обратную косую черту, и через прямую, включая пути с пробелами в именах папок и пути установки игр, — имя устройства и имя учётной записи операционной системы, IP-адреса (IPv4 и IPv6) и MAC-адреса, magnet-ссылки, infohash, адреса источников, трекеров и релизов, а также токены доступа и сессии. Очистка устроена так, чтобы отказывать, а не пропускать: если после очистки в тексте всё ещё распознаётся чувствительное значение, отчёт не отправляется вовсе. Сервер очищает полученные поля повторно и не полагается на то, что это уже сделало приложение. У адреса остаются только схема и имя хоста: путь и строка запроса отбрасываются целиком, а не по списку известных имён параметров, поэтому подпись или временные учётные данные в адресе не могут уцелеть из-за незнакомого параметра. Удалённое заменяется пометкой (<path>, <host>, <ip>), а не вырезается молча, чтобы стек оставался читаемым. Правило «отказать, а не пропустить» относится к отчётам об ошибках; у архива журнала, который пользователь выгружает сам (раздел 2.10), такой проверки нет.

Отправляется только структурированный отчёт. Приложение не отправляет журнал целиком, не отправляет «последние N строк журнала», не прикладывает аварийные дампы и не передаёт состояние интерфейса.

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

Проверить это можно в самом приложении. В настройках, в разделе «Приватность», кнопка «Показать отправленные данные» открывает последние отправленные пакеты — и события использования, и отчёты об ошибках — ровно в том виде, в каком они ушли на сервер, уже после очистки. Список ведётся только в оперативной памяти этого запуска, ограничен сотней последних записей и никуда не передаётся; после закрытия приложения он исчезает. Любую запись можно скопировать.

Отпечаток ошибки вычисляется из нормализованных кода ошибки, подсистемы и верхних кадров стека. Локальные пути, номера строк и любые значения, специфичные для пользователя, в отпечаток не входят.

На сервере отчёты хранятся 30 дней (раздел 4), сгруппированные по отпечатку. Учётная запись в отчёт не входит.

Зачем это нужно: увидеть, что новая версия приложения ломается у пользователей, и на какой именно операции, не прося пользователя вручную присылать журнал.

8.4. Чего приложение не собирает

Ни в состоянии сессии, ни в статистике использования, ни в диагностике ошибок нет и не появляется следующего (постоянный идентификатор установки при этом попадает в состояние сессии только с согласия на статистику использования, раздел 8.1):

  • аварийные дампы — дампы памяти процесса не собираются и не отправляются; диагностика из раздела 8.3 ограничена структурированным отчётом с обезличенным стеком вызовов;
  • журналы — typhon.log остаётся на устройстве и автоматически никуда не отправляется ни целиком, ни фрагментами (раздел 1). Пользователь может выгрузить очищенный архив вручную из настроек — скачать его или нажать «Отправить нам» — либо приложить к обращению в поддержку (разделы 2.10 и 2.11); это отдельное действие, требующее явного решения;
  • телеметрия производительности — частота кадров, время отклика, загрузка процессора и подобные измерения не собираются;
  • сведения о железе — точная модель процессора, видеокарта, объём памяти, серийные номера устройств не собираются. Из свойств устройства передаются название операционной системы и архитектура, а в отчёте о совместимости на macOS — ещё версия системы с точностью до двух чисел (15.6, без номера сборки), версия CrossOver и семейство процессора одним словом из закрытого списка: apple_m1 … apple_m5, intel или unknown. Строка бренда процессора, которую сообщает система, наружу не уходит: на машинах с Intel это конкретная модель. Зачем эти три величины нужны, сказано в разделе 8.5. Исключение — архив журнала, который пользователь выгружает сам: в его info.txt есть название операционной системы, модель процессора, число потоков и объём памяти (раздел 2.10);
  • поведение в интерфейсе — нажатия, переходы по экранам и время, проведённое на экране, не отслеживаются;
  • рекламная аналитика — сторонних счётчиков, рекламных пикселей и аналитических комплектов в приложении нет.

Сайт typhon-launcher.com не использует счётчики, рекламные пиксели и сторонние шрифты. В браузере он сохраняет ровно две вещи. Первая — служебная cookie сессии __Host-typhon_session: она появляется только после входа в учётную запись или регистрации на сайте, содержит токен сессии, недоступна скриптам страницы (HttpOnly), передаётся только по HTTPS и только сайту (Secure, SameSite=Lax), живёт до конца сессии (срок задаётся настройкой сервиса, сейчас 30 суток) и удаляется выходом. Она нужна для работы входа, поэтому согласия на неё не спрашивается; рекламных и аналитических cookie нет. Вторая — выбранный язык (ru или en) в локальном хранилище браузера под ключом typhon_lang: записывается только когда пользователь сам переключает язык. Гостевое обращение (раздел 2.11) cookie не ставит: доступ к нему даёт ключ из ссылки в письме.

8.5. Статистика совместимости игр

Включается тем же переключателем, что и анонимная статистика использования (раздел 8.2), и по умолчанию выключена. Отдельно её включить нельзя, отдельно выключить — тоже: это часть той же статистики, просто с другим составом данных, и поэтому описана отдельно.

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

Зачем это нужно. На macOS windows-игры запускаются через CrossOver, и запускаются не все. Пока данных нет, каждый пользователь выясняет это сам: скачивает несколько десятков гигабайт, ставит, и только тогда узнаёт, что игра не стартует. Общая статистика позволяет показать это в каталоге до скачивания.

Локальный журнал ведётся всегда и независимо от переключателя. Приложение само замечает, запустилась игра или нет, и показывает это в списке установленных игр. Этот журнал не покидает устройство: выключенный переключатель означает, что наружу не уходит ничего, а не что приложение перестаёт помнить, какие игры на этом компьютере не идут.

Когда переключатель включён, приложение примерно раз в десять минут — и только если вердикт с прошлого раза изменился — отправляет снимок этого журнала. В снимке есть только:

  • идентификатор устройства — отдельный случайный UUIDv4, не тот, что используется для остальной статистики (раздел 1);
  • версия приложения;
  • версия macOS с точностью до двух чисел (15.6), версия CrossOver и семейство процессора одним словом из закрытого списка;
  • список игр с вердиктом, где у каждой игры: числовой идентификатор игры во внешнем каталоге IGDB, прозвище сборщика репака одним словом из закрытого списка, номер версии сборки, вердикт works или broken и, у неудачных, нормализованный код причины (launch_failed, runtime_failed, executable_missing, self_exit, unknown).

Всё. Поля произвольной формы в отчёте отсутствуют как таковые: каждое значение — либо слово из списка, зашитого в приложение, либо число, прошедшее шаблон. Текст ошибки, локальные пути, название устройства, имя учётной записи, сырое название релиза, адрес источника, magnet-ссылка и infohash попасть туда не могут — не потому, что их вычищают, а потому, что для них нет места. Сервер проверяет полученный отчёт по тем же правилам заново и не полагается на то, что это уже сделало приложение: значение вне списка приводит к отказу принять отчёт целиком, а не к его молчаливой подчистке. Заголовки самого запроса (версия приложения, операционная система и архитектура, раздел 2.5) в отчёт не записываются. Большой снимок уходит несколькими запросами, каждый в пределах лимита сервиса на размер.

Игры без вердикта в отчёт не попадают. Игра, которую поставили, но ни разу не запустили, о совместимости не говорит ничего — зато говорит, что она у человека есть.

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

Пока по игре не высказались хотя бы пять разных устройств, цифра не показывается и не отдаётся приложениям вовсе. Не «ноль процентов», а ничего: доля, посчитанная по одному-двум устройствам, — это чужая единичная неудача, выданная за общее правило.

Обратно в приложение приходит только этот агрегат — одни и те же числа для всех, кто их запрашивает. Скачивание агрегата переключателем не управляется и согласия не требует: это входящие данные, и в них нет ничего о том, кто их запросил.

Отправленные отчёты можно посмотреть там же, где остальные: в настройках, в разделе «Приватность», кнопкой «Показать отправленные данные» — ровно в том виде, в каком они ушли на сервер.

На сервере отчёты хранятся 180 дней с последнего обновления (раздел 4). Учётная запись в отчёт не входит, и отчёт с ней никак не связан.

9. Изменения

Политика может изменяться вместе с приложением. Дата редакции указана в начале документа; актуальная редакция поставляется с приложением и опубликована на сайте.

10. Связаться с оператором

По вопросам о персональных данных, а также по другим юридическим вопросам: abuse@typhon-launcher.com.

11. Связанные документы