Всем привет! Сегодня я хочу поделиться историей одного странного и затянувшегося расследования, главным героем которого стал мой компьютер, а антагонистом — веб-версия Telegram. Эта история не только о поиске прожорливого процесса, но и о глубоких аномалиях в поведении современных веб-приложений, которые вызывают серьезные вопросы.
Пролог: Внезапный враг внутри Chrome
Я не системщик и не шарю особо в безопасности и в том как бы схватить за хвост призрака, даже если он майнер, думаю в комментариях умные люди раскроют ситуацию и дадут рекомендации как действовать.
(Update 1) Ожидал, что в комментариях дадут объяснение феномена или хотя бы наводку куда копать. Но, по факту - ни одного комментария для обнаружения корня проблемы, зато куча сарказма в сторону использования ГПТ. А ГПТ дал правильные рекомендации по выявлению проблемы и устранению загрузки ЦП за пару минут и без сарказма, хотя и с небольшими галлюцинациями по поводу А-версии тг, но суть остаётся сутью - ГПТ решает проблему, а людские умы забавляются собственной токсичностью.
Все началось буднично. Я заметил, что дома слишком жарко, а кулеры процессора вышли на взлетный режим. Беглый взгляд на диспетчер задач Windows показал, что один из процессов chrome.exe стабильно отъедает около 30% моего 16-ядерного процессора, работающего на частотах 5+ ГГц. Для понимания масштаба: это нагрузка, сопоставимая с рендерингом видео в After Effects, но сейчас я просто сидел в браузере и ни одна из моих вкладок не содержала анимаций или вычислений для такой нагрузки.
Первая мысль — найти виновную вкладку. Я обратился за помощью к ChatGPT, который любезно подсказал стандартный путь: встроенный диспетчер задач Chrome по Shift + Esc.
Проблема была идентифицирована практически сразу. Процесс с PID 7136, ответственный за львиную долю нагрузки, оказался Dedicated Worker: https://web.telegram.org/k/rlottie.worker-DkltbnkR.js. То есть, виновником была вкладка с Telegram Web (которую я закрыл дня 4 тому назад), т. е. среди активных вкладок виновников не было.
Казалось бы, инцидент исчерпан. Закрыть вкладку — и дело с концом. Но тут-то и началось самое интересное.
Акт I: Неубиваемый процесс и белый экран
Я попытался зайти в Telegram Web снова, но вместо привычного интерфейса меня встретил абсолютно белый экран. Вкладка была пуста. Но процесс-воркер никуда не делся и продолжал молотить на 30% CPU.
Что я только не делал:
Несколько раз перезагружал вкладку через
Ctrl + Shift + R(жесткая перезагрузка с очисткой кэша).Закрывал и открывал вкладку заново.
Пытался зайти по прямым ссылкам на чаты.
Результат был один — белый экран и не стихающий гул кулеров. Самое странное, что процесс пережил несколько дней, две перезагрузки компьютера и два сбоя электричества. Он просто запускался вместе с Chrome и продолжал свою разрушительную деятельность.
Это первая и главная аномалия. Поведение, абсолютно нетипичное для обычного веб-скрипта. Мои подозрения переросли в паранойю: а не майнер ли это, который так хитро маскируется под системный воркер Telegram?
Акт II: Расследование. Подозрительные улики
Я снова обратился к AI-помощнику с просьбой провести более глубокое исследование и помочь собрать доказательства. В ходе нашего диалога вскрылся целый пласт странностей в архитектуре Telegram Web.
Странность №1: Феноменальная персистентность Service Worker
В чем аномалия: Service Worker (SW) — это скрипт, который браузер запускает в фоновом режиме, отдельно от веб-страниц. Он нужен для пуш-уведомлений, фоновой синхронизации и работы в офлайне. По спецификации, SW должен выгружаться из памяти после короткого периода бездействия, чтобы не расходовать ресурсы. В моем случае воркер не просто жил, а активно работал несколько суток, переживая перезагрузки ОС, несколько сбоев электричества, полное отключение от сети два раза и один раз на 8 часов!
Техническое объяснение: Такое поведение может быть вызвано либо багом в самом воркере, который входит в бесконечный цикл, либо некорректной регистрацией, из-за которой Chrome не может его "усыпить". Когда вы запускаете Chrome, он проверяет зарегистрированные SW, и если SW подписан на события (например, fetch), он может активироваться даже без открытой вкладки, перехватывая сетевые запросы. Именно поэтому процесс возрождался снова и снова.
Странность №2: Белый экран при активных воркерах
В чем аномалия: Пользовательский интерфейс (UI) не отрисовывался во время попыток входа на сайт, но когда в хроме не было открыто вкладок Telegram - в фоне работали десятки процессов, связанных с Telegram: rlottie.worker (анимации), crypto.worker (шифрование), mtproto.worker (сетевой протокол).
Техническое объяснение: Это указывает на то, что жизненный цикл SW и UI полностью рассинхронизирован. SW успешно регистрируется и запускает свои дочерние воркеры, но основной скрипт, отвечающий за отрисовку интерфейса, по какой-то причине падает или не может выполниться. В итоге мы получаем "зомби-приложение": фронтенд мертв, а бэкенд в браузере жив и потребляет ресурсы.
Странность №3: Использование blob: URL для загрузки воркеров
В чем аномалия: Многие воркеры (кроме rlottie и tinyld) загружались не с прямого URL вида https://web.telegram.org/worker.js, а через blob: ссылки.
Техническое объяснение: blob: URL — это ссылка на данные, которые сгенерированы динамически прямо в браузере из строки или массива байт. С одной стороны, это позволяет гибко управлять кодом. С другой — это усложняет аудит безопасности. Вы не можете просто посмотреть исходный код скрипта по ссылке. Он создается "на лету", и его содержимое может меняться, что является идеальной средой для маскировки вредоносного кода.
Странность №4: Активный крипто-воркер без секретных чатов
В чем аномалия: В диспетчере задач был замечен crypto.worker-BTYwgy7.js. Но ведь веб-версия Telegram не поддерживает сквозное шифрование (E2EE) и секретные чаты! Зачем ей крипто-воркер?
Техническое объяснение: Это подозрение оказалось ложным, но показательным. Как пояснил AI, протокол MTProto, на котором работает Telegram, использует шифрование не только для секретных чатов. Оно нужно для защиты канала между клиентом и сервером (шифрование Cloud Chats), для генерации ключей авторизации (обмен Диффи-Хеллмана), для шифрования медиафайлов при передаче и для проверки паролей двухфакторной аутентификации. Все эти операции ускоряются за счет выноса в WebAssembly-воркер. Так что его наличие оправдано, но для неискушенного пользователя выглядит подозрительно.
Странность №5: Неэффективность официальных каналов поддержки
В чем аномалия: Как правило техподдержка молчит. Жду их ответы на некоторые обращения уже лет 6, смысл обращаться если пользователь не из ФСБ (Французской Службы Безопасности)?
Техническое объяснение: Это, к сожалению, распространенная проблема крупных сервисов. Но когда речь идет о критическом баге, потребляющем огромное количество ресурсов и вызывающем подозрения в безопасности у обычного пользователя, такая неотзывчивость создает токсичную атмосферу недоверия. Надеюсь кто-то из команды ТГ это прочитает, Аминь!
Акт III: Вердикт — майнинг или чудовищный баг?
После глубокого анализа мы с ГПТ пришли к выводу, что это, скорее всего, не майнинг. Вот аргументы "против":
Отсутствие сторонних подключений. Анализ сетевой активности не показал соединений с известными майнинг-пулами. Все запросы шли на поддомены
telegram.org.Отсутствие кода майнера. Поиск по ключевым словам (
mine,hash,nonce,coinhive,cryptonight) в коде самогоrlottie.worker.jsничего не дал.Природа
rlottie. Это библиотека от Samsung для рендеринга сложных векторных анимаций (Lottie). Они действительно очень ресурсоемкие, и при определенных условиях (отключенное аппаратное ускорение в браузере, баг в версии) могут вызывать колоссальную нагрузку на CPU.
Скорее всего, мы столкнулись с катастрофическим багом:
Баг в жизненном цикле Service Worker, который не позволял ему выгрузиться и приводил к зацикливанию.
Эпилог: Как победить монстра и что делать, если вы столкнулись с подобным
Вот пошаговый план, который помог окончательно решить проблему и который я рекомендую всем, кто столкнется с подобным поведением любого веб-приложения.
Принудительно удалить Service Worker. Это самый важный шаг.
Откройте инструменты разработчика (
F12илиCtrl + Shift + I).Перейдите на вкладку
Application->Service Workers.Найдите в списке воркеры, связанные с
web.telegram.org, и нажмитеUnregisterдля каждого из них.Как альтернатива, можно выполнить в консоли скрипт, который убьет всех воркеров на странице:
navigator.serviceWorker.getRegistrations() .then(regs => regs.forEach(reg => reg.unregister())) .then(() => console.log('All service workers unregistered'));
Полностью очистить данные сайта.
На той же вкладке
Applicationперейдите вClear storage.Поставьте все галочки и нажмите
Clear site data.
Дополнительные рекомендации:
Включить аппаратное ускорение (в моем случае было включено, что тоже странно).
Зайдите в
Настройки Chrome->Система.Убедитесь, что включен параметр «Использовать аппаратное ускорение, если доступно».
Перейти на K-версию Telegram т к везде пишется что А-версия более нестабильная (в моем случае была K-версия, что тоже странно).
Используйте адрес
https://web.telegram.org/k/. Она значительно легче и оптимизированнее.
Заключение
Хотя прямых доказательств майнинга найдено не было (в силу моей слабой компетентности в этом деле), подозрение есть и эта история — яркий пример того, как совокупность багов, непрозрачной архитектуры (blob: URL) и неотзывчивой поддержки может породить обоснованные подозрения и доставить массу головной боли. Поведение Telegram Web было аномальным, неинтуитивным и враждебным по отношению к пользователю и его ресурсам. Дамп памяти процессора я снял, но разбираться в нем - надо найти время и в принципе большинству пользователей врядли это захочется делать. А от ТГ хотелось бы исправления багов, вместо пукающих и какающих эмоджи.
Надеюсь, мое расследование будет полезно тем, кто столкнется с необъяснимой нагрузкой от браузера. Будьте бдительны и не бойтесь копать глубоко!
(Update 2) По комментариям:
В ЯБ такого не наблюдал никогда.
Скорее всего - это Хром, он сам по себе любит откушать памяти полной ложкой. А вот в веб-версии Телеграма для Оперы - ничего подобного не наблюдается. И в версии для Vivaldi - тоже.
Лет 10 юзаю хром, в хроме такое поведение со стороны тг наблюдаю впервые, т. е. до этого я тоже никогда такого не наблюдал. Т. е. по-видимому проблема не в браузере.
А уж когда закрыл страницу пропало 200-300-500 мегабайт оперативной памяти это вообще практически поголовное явление.
Редактор статей Хабра скушал 10 гиг.
Скорее всего - это Хром, он сам по себе любит откушать памяти полной ложкой.
К тому что хром ест много памяти думаю все уже привыкли, я без удивления смотрю как он занимает 5-10 Гб оперативки при 30-40 открытых вкладках. Внимания, в данном случае, заслуживает не потребление памяти (хотя, оно тоже на одну вкладку пожирало 8 Гб), а использование 5-6 ядер процессора на частотах 5+Гц при том что:
1) аккаунт не платный, следовательно - анимодзи не использую, сторонних каналов нет
2) обычно тг в хроме вместе со всеми остальными вкладками грузит проц менее чем на 1%, даже если отжирает память.
rlottie - очень сложная библиотека, и она нужна для рендеринга анимодзи, тех самых эмодзи, которые пользователи создают сами. Возможно, клиент не учитывает, что нужно их рендерить только тогда, когда они находятся в зоне видимости, из-за этого рендерятся все сообщения с анимодзи, которые получил клиент, а если вы подписаны на множество Telegram-каналов или часто используете анимодзи в личных беседах, это приводит к высокой нагрузке на процессор
Согласен с Вами в том, что проблема может быть в rlottie, ибо это единственный претендент, которому нужна хоть какая-то мощь ЦП, но, при попытке войти в аккаунт тг - белый экран, закрытие вкладки не помогло, закрытие браузера и перезагрузка компа тоже. Каким образом rlottie может мешать загрузке экрана авторизации тг?
И ест значительно больше ресурсов, чем нужно для рендера анимодзи.
Вот список всех компонентов, мне кажется только последние два активны в момент до входа в аккаунт:
Dedicated Worker | Либа rlottie – WebAssembly-аниматор Lottie- |
Dedicated Worker | Упрощённый Lottie-воркер (TinyLottie) для некоторых анимаций. |
blob:https://web.telegram.org/976a9905-50f1-401c-b783-1bae3c52fded | Shared Worker | Общий воркер Telegram для фоновой синхронизации сообщений между вкладками. |
blob:https://web.telegram.org/f6f6226b-5df4-484d-b584-56f3ac8616ed | Shared Worker | Общий воркер для кеширования/загрузки медиа (изображения, стикеры и т. д.). |
blob:https://web.telegram.org/0ca5c47-9c11-4d84-b6e6-f581de91123c | Shared Worker | Общий воркер для вспомогательных задач (обработка очередей, уведомлений и т. д.). |
Shared Worker | WebAssembly-воркер для криптографических операций (шифрование/дешифрование). |
Shared Worker | WebAssembly-воркер для реализации MTProto-протокола (основной канал общения с серверами Telegram). |
Дополнительные советы ГПТ:
Отключить все расширения. Особенно те, что имеют доступ на
://web.telegram.org/. - в хроме расширений нет.Проследить WebSocket-подключения. Если вы найдёте соединения вне
*.telegram.org, это почти наверняка майнинг-пул или ботнет-контроллер. - таких не обнаружено.
Т. е. всё таки похоже на баг ТГ.
Тем комментаторам, которые предлагают отключить полностью или заблокировать сервис-воркеры: это как бы решение проблемы, но вы ведь не отрезаете себе часть тела когда туда попала заноза, а стараетесь найти занозу, верно? Так и тут, мне интереснее найти причину, а не блочить всё и вся. Если цель - это ноль бед от аппаратуры, то ноль можно получить и на выключенной аппаратуре.
Если у кого-то есть полезная инфа - пожалуйста поделитесь! Но, те, кому хочется написать какой-то мусор, типа этого:
<sarcasm>Спросите у ChatGPT, тут вся статья это пересказ его ответов</sarcasm>
Новый жанр: интервью нейросети у самой себя.
Пользователи торрента любят жрать хохломайнеры
Пожалуйста воздержитесь и не засоряйте интернет своим взглядом на мир.