Бесплатное расширение из Chrome Web Store отправило 12 сообщений - аккаунт улетел в перманентный бан. Владелец был уверен, что дело в скорости отправки. На самом деле его выдал технический след, не имеющий отношения к скорости вообще. Большинство статей про «вычисление расширений» в WhatsApp - это смесь реальных механизмов браузера и форумных догадок, поданных как официальная позиция Meta.
WhatsApp обновляет защиту веб-клиента быстрее, чем форумы успевают обновлять мануалы: то, что «работало» полгода назад, сегодня может стоить вам номера. После этой статьи вы будете точно знать, какие из популярных объяснений подтверждены документами Meta и спецификацией браузера, а какие давно пора выбросить.
WhatsApp Web - обычная веб-страница. Расширение, которое читает чаты, подставляет текст или жмёт «Отправить» за вас, обязано выполнить JavaScript внутри этой страницы и изменить её DOM - иначе оно физически не сможет работать. Это тот же класс серого транспорта, что и автоматизация через Puppeteer или Selenium - только в виде браузерного плагина.
Здесь важно разделить два разных утверждения. Полный список ваших установленных расширений странице недоступен - браузер изолирует его от любого сайта, включая WhatsApp Web. А вот всё, что расширение делает внутри вкладки WhatsApp Web - лишние теги, перехваченные клики, программно вставленный текст - технически наблюдаемо, потому что происходит в той же среде выполнения, что и сам WhatsApp Web.
Разница тонкая, но она меняет всю картину: WhatsApp не «сканирует ваш браузер», он в лучшем случае видит последствия работы расширения внутри своей собственной страницы. Дальше - какие из этих последствий реально используются, а какие существуют только в пересказах с форумов.
Тезис «WhatsApp сверяет хеш кода через Code Verify и так вычисляет расширения» встречается почти в каждом материале на эту тему. Он неточен не в деталях, а в направлении проверки.
Было (как обычно пишут): Code Verify - механизм, которым WhatsApp проверяет код в вашем браузере и ловит посторонние изменения.
Стало (как на самом деле): Code Verify - расширение, которое пользователь добровольно ставит себе сам (Chrome, Firefox, Edge), чтобы проверить обратное: что именно ему не подменили код WhatsApp Web, например при атаке MITM или вмешательстве на уровне сети. Проверка хеша идёт локально, на стороне пользователя, против эталона, который Meta публикует через Cloudflare.
Деталь, которая разваливает миф целиком: по официальному описанию Meta, расширение не передаёт данные о своей работе ни в WhatsApp, ни в Meta - там прямо указано, что компания не узнает, установлен ли у вас Code Verify вообще. Технически Code Verify не может быть инструментом обнаружения рассылочных расширений: он работает в обратную сторону, это проверка для пользователя, а не слежка за пользователем.
Отсюда логически разваливается и популярный совет «отключите Code Verify, чтобы рассылка заработала». Это бессмысленное действие: расширение, которое физически не сообщает о себе WhatsApp, не может влиять на то, забанят вас или нет - оно никогда не было инструментом слежки.
Подтверждено практикой: рассылочные расширения добавляют свои UI-элементы - кнопки запуска, поля для текста - либо читают и вставляют данные напрямую в разметку чата. Иначе они просто не могут выполнять свою функцию.
Не подтверждено: что фронтенд WhatsApp Web использует MutationObserver специально для поиска рассылочных расширений и автоматически банит по факту обнаружения чужого DOM-узла. Версия популярна на форумах, но официального подтверждения у неё нет - как нет и опровержения.
Там же встречается более смелая теория: если расширение прячет элементы интерфейса (например, левую панель чатов через display: none), чтобы освободить место под свой UI, WhatsApp мгновенно обрывает сессию. Это инсайд с форумов вроде BlackHatWorld, а не задокументированный факт - относитесь к нему как к гипотезе, не как к инструкции.
Практический вывод блока: чем сильнее расширение перестраивает страницу, тем больше у него технических примет - независимо от того, использует их WhatsApp прямо сейчас или нет. Антиспам-системы обновляются быстрее, чем форумные мануалы.
Это самая надёжная часть всей темы - и единственная, где можно говорить уверенно, без оговорок.
Когда расширение программно вызывает click() на кнопке «Отправить» или вставляет текст через DOM API, браузер создаёт событие со значением Event.isTrusted = false. Это свойство выставляет сам браузер на уровне спецификации - обычный JavaScript страницы или content script расширения переписать его не может в принципе. Часть общей логики поведенческого антиспама.
| Сигнал | Человек | Расширение базового уровня |
|---|---|---|
Event.isTrusted |
true |
false |
| Движение курсора перед действием | есть, неравномерное | чаще отсутствует |
| Задержка между нажатиями клавиш | случайная, 80–300+ мс | часто 0 мс - мгновенная вставка |
| Фокус поля перед вводом | естественный | может отсутствовать |
В технических аудитах, которые я видел, эта цепочка повторяется почти всегда: аккаунты, через которые идёт заметный объём сообщений с isTrusted = false, ловят бан в среднем за 5–15 минут после старта рассылки. Это не официальная цифра Meta, а наблюдение из практики - но оно повторяется достаточно стабильно, чтобы на него ориентироваться.
Отсюда вырос целый рынок «эмуляции человека»: разработчики продвинутых инструментов настраивают задержку набора символов в районе 50–150 мс и случайные паузы между сообщениями 15–45 секунд. Это снижает один конкретный риск, но не отменяет факт: isTrusted остаётся false, если клик создан внутри обычного content script расширения без доступа к более низкоуровневым API браузера.
У каждого расширения в Chrome или Firefox есть собственный Extension ID. Теория, которая ходит по форумам: страница может обратиться к ресурсу расширения через схему chrome-extension:// и по факту или скорости ответа через PerformanceResourceTiming API определить, что именно у вас установлено.
Сама методика fingerprinting расширений через web_accessible_resources технически существует и описана исследователями браузерной безопасности - это не выдумка. Но утверждение «WhatsApp Web целенаправленно сканирует ID конкретных рассылочных расширений» подтверждения не имеет. Это могло бы объяснять часть банов, а могло быть совпадением с другими сигналами вроде того же isTrusted.
Косвенный довод в пользу того, что в этой области идёт реальная борьба: разработчики «серых» расширений всё чаще обфусцируют пути в web_accessible_resources и меняют Extension ID при каждой переустановке - именно для того, чтобы такой fingerprinting не сработал. Если бы метод был совершенно бесполезен, на обход не тратили бы ресурсы.
В моей практике большинство провалов на старте выглядят почти одинаково - вот характерный пример из этой же категории.
Кейс 1 - провал. Маркетолог поставил бесплатное расширение из Chrome Web Store, загрузил холодную базу на 200 номеров и запустил рассылку. После 12 сообщений страница перезагрузилась, аккаунт ушёл в перманентный бан. Технический разбор показал: расширение вставляло текст напрямую в DOM и вызывало click() программно - классическая цепочка isTrusted = false без какой-либо маскировки.
Кейс 2 - сложная эмуляция. Другой оператор настроил связку антидетект-браузера и Puppeteer со stealth-плагином вроде puppeteer-extra-plugin-stealth, который подменяет значения через CDP (Chrome DevTools Protocol) на уровне самого браузера, а не страницы, и добавил движение курсора по кривым Безье. На прогретой базе аккаунты продержались дольше и отправляли 80–100 сообщений в день.
Это не инструкция и не гарантия результата. Доступ к debugger-протоколу делает расширение тяжёлым, заметным для самого браузера и нестабильным при каждом обновлении Chrome. Технический успех здесь не равен безопасности бизнеса - это просто более дорогой раунд той же гонки, который тоже рано или поздно устареет.
Это же подсвечивает маркетинговый тезис, который любят продавцы рассылочных расширений: «работает абсолютно незаметно для WhatsApp». Ни один независимый аудит такое заявление не подтверждал, а сама архитектура isTrusted и Code Verify говорит об обратном - полная незаметность технически не доказана и противоречит тому, как устроены браузерные события.
Пока вся индустрия спорит про DOM и isTrusted, в стороне остаётся канал детекта, задокументированный куда лучше всего перечисленного выше: жалобы получателей.
WhatsApp Business присваивает номеру рейтинг качества - зелёный, жёлтый, красный - на основе того, сколько получателей заблокировали номер или пожаловались на сообщение. Падение рейтинга ограничивает доставку и может привести к блокировке независимо от того, насколько технически чист ваш isTrusted. Подробнее - пороги метрик и жалоб.
Это значит, что даже идеально замаскированная техническая сторона рассылки не спасает, если получатели вашей холодной базы массово жалуются. Жалоба - самый скучный и самый недооценённый сигнал во всей этой теме.
| Механизм | Статус | Что это значит на практике |
|---|---|---|
| Code Verify проверяет код клиента | Подтверждено, но в обратную сторону | Проверка для пользователя, не слежка за ним |
Event.isTrusted различает клики |
Подтверждено спецификацией браузера | Самый надёжный технический сигнал из всех |
| Рейтинг качества по жалобам | Подтверждено политикой WhatsApp Business | Канал детекта, никак не связанный с кодом |
MutationObserver ищет расширения |
Не подтверждено | Правдоподобная, но недоказанная теория |
| Resource Timing вычисляет Extension ID | Не подтверждено | Метод существует технически, применение WhatsApp - нет |
| Мгновенный logout при скрытии CSS | Не подтверждено | Анекдот с форумов, не задокументированный факт |
Бан строго по одному isTrusted = false |
Не подтверждено как единственная причина | Скорее один из набора сигналов, а не триггер сам по себе |
В пользовательском соглашении WhatsApp массовая и автоматизированная рассылка через неавторизованные инструменты прямо запрещена отдельным пунктом - независимо от того, насколько хорошо расширение маскируется технически.
Это значит, что даже идеально замаскированный isTrusted не делает рассылку «легальной» в смысле правил площадки - он просто отодвигает момент обнаружения. Гонка между разработчиками обхода и антиспам-системой не имеет финального победителя: каждый удачный обход рано или поздно перестаёт работать после очередного обновления.
Это особенно ощутимо, если вы управляете не одним аккаунтом, а целой мультиаккаунт-инфраструктурой: каждый дополнительный аккаунт умножает не только охват, но и площадь риска - один и тот же технический след повторяется на всех номерах сразу. См. распределение аккаунтов и фермы.
Строить инфраструктуру бизнеса на предположении, что конкретный обход будет работать без сбоев бесконечно, - стратегически слабое решение, даже если сегодня всё работает гладко.
Возьмите расширение, которым пользуетесь сейчас, и проверьте его по таблице сигналов выше: вставляет ли оно текст напрямую, вызывает ли click() без эмуляции, насколько сильно перестраивает интерфейс. Это покажет реальный уровень риска без гадания на форумах.
Если объёмы рассылки выросли за рамки личного использования - присмотритесь к официальному WhatsApp Business Platform. Это единственный канал, где масштаб и автоматизация не противоречат правилам площадки сами по себе.
Практическое правило:
Расширение не обманывает WhatsApp - оно просто пока не поймано. Стройте процесс так, будто это случится завтра, а не рассчитывайте, что не случится никогда.
