Всем привет! Сегодня я хочу поделиться историей одного странного и затянувшегося расследования, главным героем которого стал мой компьютер, а антагонистом — веб-версия Telegram. Эта история не только о поиске прожорливого процесса, но и о глубоких аномалиях в поведении современных веб-приложений, которые вызывают серьезные вопросы.

Пролог: Внезапный враг внутри Chrome

Я не системщик и не шарю особо в безопасности и в том как бы схватить за хвост призрака, даже если он майнер, думаю в комментариях умные люди раскроют ситуацию и дадут рекомендации как действовать.

Все началось буднично. Я заметил, что дома слишком жарко, а кулеры процессора вышли на взлетный режим. Беглый взгляд на диспетчер задач 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: Вердикт — майнинг или чудовищный баг?

После глубокого анализа мы с ГПТ пришли к выводу, что это, скорее всего, не майнинг. Вот аргументы "против":

1. Отсутствие сторонних подключений. Анализ сетевой активности не показал соединений с известными майнинг-пулами. Все запросы шли на поддомены telegram.org.

2. Отсутствие кода майнера. Поиск по ключевым словам (mine, hash, nonce, coinhive, cryptonight) в коде самого rlottie.worker.js ничего не дал.

3. Природа rlottie. Это библиотека от Samsung для рендеринга сложных векторных анимаций (Lottie). Они действительно очень ресурсоемкие, и при определенных условиях (отключенное аппаратное ускорение в браузере, баг в версии) могут вызывать колоссальную нагрузку на CPU.

Скорее всего, мы столкнулись с катастрофическим багом, усугубленным несколькими факторами:

• "A"-версия Telegram Web, которая использует более тяжелый рендерер анимаций (в отличие от более легкой "K"-версии).

• Баг в жизненном цикле Service Worker, который не позволял ему выгрузиться и приводил к зацикливанию.

Эпилог: Как победить монстра и что делать, если вы столкнулись с подобным

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

1. Принудительно удалить 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'));
     

2. Полностью очистить данные сайта.

   • На той же вкладке Application перейдите в Clear storage.

   • Поставьте все галочки и нажмите Clear site data.

3. Включить аппаратное ускорение (в моем случае было включено, что тоже странно).

   • Зайдите в Настройки Chrome -> Система.

   • Убедитесь, что включен параметр «Использовать аппаратное ускорение, если доступно».

4. Перейти на K-версию Telegram.

   • Используйте адрес https://web.telegram.org/k/. Она значительно легче и оптимизированнее.

Заключение

Хотя прямых доказательств майнинга найдено не было (в силу моей слабой компетентности в этом деле), подозрение есть и эта история — яркий пример того, как совокупность багов, непрозрачной архитектуры (blob: URL) и неотзывчивой поддержки может породить обоснованные подозрения и доставить массу головной боли. Поведение Telegram Web было аномальным, неинтуитивным и враждебным по отношению к пользователю и его ресурсам. Дамп памяти процессора я снял, но разбираться в нем - надо найти время и в принципе большинству пользователей врядли это захочется делать. А от ТГ хотелось бы исправления багов, вместо пукающих и какающих эмоджи.

Надеюсь, мое расследование будет полезно тем, кто столкнется с необъяснимой нагрузкой от браузера. Будьте бдительны и не бойтесь копать глубоко!