При тестировании текущего MAX/oneme transport обнаружил серьёзную проблему, которую считаю необходимым явно указать в README.
При использовании MAX-аккаунта через OpenFlux на внешнем зарубежном VPS аккаунт получает ограничение, после которого штатное удаление аккаунта MAX блокируется. Ограничение сохраняется и после полной остановки OpenFlux.
В моём тестировании это не выглядело как случайный временный сбой: ограничение появилось именно после использования MAX transport через внешний VPS и не исчезло после прекращения работы transport.
Наиболее вероятно, что срабатывает anti-abuse система MAX из-за комбинации нескольких факторов.
Во-первых, OpenFlux фактически использует не официальный MAX-клиент, а собственную реализацию протокола. Она подключается напрямую к wss://ws-api.oneme.ru/websocket, авторизуется пользовательским token и сообщает собственные параметры устройства (deviceType: WEB, deviceName: vkmax Go, отдельный сгенерированный deviceId).
Во-вторых, текущая реализация MAX transport использует signaling нестандартным образом. При useICEInjection = true трафик OpenFlux Base64-кодируется и передаётся через transmit-data внутри поля ICE candidate. То есть signaling инфраструктура звонков используется для передачи произвольного tunnel traffic.
В-третьих, если exit запущен на зарубежном VPS, MAX одновременно видит авторизацию/активность аккаунта с datacenter IP и из другой географии. В сочетании с новым deviceId и нетипичным signaling pattern это, вероятно, является очень сильным anti-abuse сигналом.
Поэтому я бы считал текущий MAX/oneme transport небезопасным для использования с обычными аккаунтами.
В README необходимо явно предупредить пользователей:
не использовать основной или важный MAX-аккаунт;
не использовать аккаунт, удаление/доступ к которому критичны;
использование через внешний VPS может привести к ограничению аккаунта;
ограничение может сохраняться после остановки OpenFlux;
MAX transport следует считать экспериментальным до выяснения механизма блокировки.
При тестировании текущего MAX/oneme transport обнаружил серьёзную проблему, которую считаю необходимым явно указать в README.
При использовании MAX-аккаунта через OpenFlux на внешнем зарубежном VPS аккаунт получает ограничение, после которого штатное удаление аккаунта MAX блокируется. Ограничение сохраняется и после полной остановки OpenFlux.
В моём тестировании это не выглядело как случайный временный сбой: ограничение появилось именно после использования MAX transport через внешний VPS и не исчезло после прекращения работы transport.
Наиболее вероятно, что срабатывает anti-abuse система MAX из-за комбинации нескольких факторов.
Во-первых, OpenFlux фактически использует не официальный MAX-клиент, а собственную реализацию протокола. Она подключается напрямую к wss://ws-api.oneme.ru/websocket, авторизуется пользовательским token и сообщает собственные параметры устройства (deviceType: WEB, deviceName: vkmax Go, отдельный сгенерированный deviceId).
Во-вторых, текущая реализация MAX transport использует signaling нестандартным образом. При useICEInjection = true трафик OpenFlux Base64-кодируется и передаётся через transmit-data внутри поля ICE candidate. То есть signaling инфраструктура звонков используется для передачи произвольного tunnel traffic.
В-третьих, если exit запущен на зарубежном VPS, MAX одновременно видит авторизацию/активность аккаунта с datacenter IP и из другой географии. В сочетании с новым deviceId и нетипичным signaling pattern это, вероятно, является очень сильным anti-abuse сигналом.
Поэтому я бы считал текущий MAX/oneme transport небезопасным для использования с обычными аккаунтами.
В README необходимо явно предупредить пользователей:
не использовать основной или важный MAX-аккаунт;
не использовать аккаунт, удаление/доступ к которому критичны;
использование через внешний VPS может привести к ограничению аккаунта;
ограничение может сохраняться после остановки OpenFlux;
MAX transport следует считать экспериментальным до выяснения механизма блокировки.