Reaction
Замер
Что записывает трекер и чего не достаёт вкладка браузера
Два прогона, одна граница. На Windows-машине, которую никто не трогал, мы посекундно прочитали лог самого клиента Hubstaff. На Linux-машине, которую тоже никто не трогал, запустили одновременно шесть браузерных джиглеров против системного таймера простоя. Ниже — обе серии показаний, методика и то, чего они не доказывают.
Замерено 11–13 августа 2026 года. Последнее обновление — 23 августа 2026 г.
40
минут брошенного рабочего места с подтверждённо работавшим движком
76,8%
средняя активность, которую трекер записал по этим блокам
6
браузерных джиглеров, запущенных разом на нетронутой машине
0
сбросов таймера простоя от любого из них за пять минут
Коротко
Трекер меряет ввод, который дошёл до операционной системы. Когда он доходит — трекер его пишет: 4 десятиминутных блока за брошенной машиной, где движок подтверждённо работал каждую минуту, дали от 74% до 80%, в среднем 76,8%. Когда не доходит — никакая анимация на веб-странице числа не меняет: шесть одновременно работающих браузерных джиглеров позволили системному счётчику простоя вырасти на 303,6 секунды за пятиминутный прогон — то есть за весь прогон целиком — и не сбросили его ни разу.
Это одна и та же граница с двух сторон, и второй вывод относится к нашему собственному бесплатному браузерному инструменту ровно так же, как к остальным в таблице. Вкладка умеет не давать погаснуть экрану. Убедить трекер, что вы на месте, она не умеет.
Прогон первый
Что живой Hubstaff записал за столом, за которым никто не сидел
С 11 по 13 августа 2026 года Reaction работал на Windows-машине под живым аккаунтом Hubstaff, после чего мы посекундно прочитали лог клиента трекера — по тем интервалам, когда машины действительно никто не касался. Всем критериям ниже отвечают 4 десятиминутных блока, и только они и составляют результат этого прогона.
Методика
Цифры взяты не из веб-кабинета и не из выгруженного отчёта, а из собственного лог-файла клиента Hubstaff: он пишет посекундно, и десятиминутный блок по нему восстанавливается точнее, чем по округлённой плитке в браузере. Одна строка лога отмечает каждую секунду, в которую был ввод; вторая — те секунды, в которые ввод был исключительно инъектированным. Секунда с первой строкой и без второй — это живой человек за клавиатурой.
Именно это различие делает возможным критерий отбора, а критерий и есть весь замер:
- Блок засчитан, только если трекер записал в нём ноль секунд реального человеческого ввода — все десять минут машины никто не трогал.
- Блок засчитан, только если он целиком внутри одной сессии трекинга: иначе знаменатель в 600 секунд нечестен.
- Блок засчитывается, только если по собственному heartbeat-логу Reaction движок работал каждую его минуту. Именно этого критерия не было в первой редакции страницы, и только он отвечает на вопрос, относится ли показание к этой программе вообще.
- Активность блока = секунды с вводом ÷ 600, с округлением. Среднее = все секунды с вводом ÷ все наблюдавшиеся секунды, то есть его можно проверить, сложив столбец. Ничего не сглаживается, не взвешивается и не выбрасывается за неудобный вид.
Это стоит сказать прямо, потому что большинство продавцов на эту тему говорит туманно: клиент Hubstaff на Windows отличает инъектированный ввод от настоящего — он прямо пишет это в лог. Прогоны показывают, что такие секунды всё равно были засчитаны как ввод, а не отброшены.
Все 4 опубликованных блока, по порядку
4 блока, прошедшие все три критерия, без сортировки и без отбора. Пунктир — среднее 76,8%.
Блоки, из которых сложились числа
| Дата | Блок | Секунд с вводом из 600 | Активность |
|---|---|---|---|
| 2026-08-13 | 12:40 | 465 | 78% |
| 2026-08-13 | 15:20 | 458 | 76% |
| 2026-08-13 | 15:30 | 442 | 74% |
| 2026-08-13 | 15:40 | 478 | 80% |
По 4 опубликованным блокам: среднее 76,8%, разброс 74–80%, 40 минут. Первые два критерия за три дня прошли 21 блока; третий — только эти четыре, а что стало с остальными, сказано в заметке рядом.
Что означает разброс
Разброс здесь важнее среднего. Ровная полка на одном числе — ровно та форма, которую детектор и высматривает: ни один человек не выдаёт ввод в одинаковой доле каждого десятиминутного окна своего дня. Ряд 74–80% без повторов даёт дюти-цикл с джиттером, а не константа, — правда, на 4 блоках это наблюдение об этих показаниях, а не доказательство того, что такая форма сходит за человека.
Поэтому мы и публикуем диапазон, а не целевое число. Тот, кто обещает фиксированный процент, либо ничего не мерил, либо выдаёт единственный паттерн, которого стоит избегать.
Поправка, которую несёт эта страница
В первой редакции этой страницы, опубликованной 14 августа 2026 года, в таблице выше стоял двадцать один блок и назывались 52–85% при среднем 71,5%. Это было неверно, и ошибка не в округлении. Критерий отбора спрашивал, трогали ли машину и лежит ли блок внутри сессии трекинга. Он ни разу не спросил, работала ли в эти минуты наша собственная программа.
Работала — в четырёх из них. В остальных движок стоял на паузе, а ввод, который трекер записал в те минуты, шёл от чего-то, что мы не опознали. Это делает их открытым вопросом про ту машину и вовсе не доказательством про этот продукт, поэтому в таблице их нет — не потому, что они неудобны, а потому, что необъяснённое показание, оставленное внутри, завысило бы наши же числа.
Осталось меньше и скучнее: 4 блока, 40 минут, 74–80%. Эта заметка остаётся здесь навсегда, вместо того чтобы тихо переписать числа: исследование, прячущее свои поправки, стоит меньше, чем исследование с меньшим количеством чисел.
Прогон второй
Что шесть браузерных джиглеров сделали с таймером простоя
Вторая половина границы, снята 13 августа 2026 года. Шесть браузерных mouse jiggler открыты одновременно — включая наш собственный бесплатный инструмент, — каждый запущен своей кнопкой, после чего машину пять минут не трогали, снимая системный счётчик простоя раз в пять секунд.
Почему запуск всех шести разом — честная проверка
Из-за формы вывода. Если счётчик простоя растёт монотонно весь прогон, значит ни один из шести не создал ввода, который система засчитала бы, — один прогон закрывает сразу все шесть, и спорить о порядке запуска не о чем.
Сам счётчик — тот, по которому рабочий стол решает, что вас нет: он читается напрямую у монитора простоя GNOME через D-Bus. Ровно это показание используют Teams, Slack и трекеры, когда переводят вас в «Отошёл».
Три более ранних прогона стенд забраковал сам, и их здесь нет: в одном контрольная страница не исполнила свой скрипт, в двух счётчик простоя падал — машину в это время трогали. Падение выглядит в точности как находка («инструмент создал ввод!»), и именно поэтому оно обязано аннулировать прогон автоматически.
Показания
| Что мерилось | Значение |
|---|---|
| Базовый простой до открытия вкладок, мс | 2 521 |
| Простой в начале прогона, мс | 71 628 |
| Простой в конце прогона, мс | 375 277 |
| Прирост простоя за 61 сэмпл, мс | 303 649 |
| Блокировок гашения экрана, min–max | 2–2 |
| Сбросов системного таймера простоя | 0 |
Прирост совпадает с настенными часами секунда в секунду: 303,6 секунды засчитанного простоя за прогон длиной около 303,6 секунд. Ни один из шести не вернул системе ни одной миллисекунды.
Шесть инструментов и что каждый сделал на самом деле
| Инструмент | Удержал экран | Сбросил таймер простоя |
|---|---|---|
| Reaction (control) | Да | Нет |
| movemycursor.com | Перепроверить нельзя | Нет |
| keepawake.app | Да | Нет |
| mousemover.me | Да | Нет |
| mousejiggler.live | Да | Нет |
| mouse-jiggler.com | Нет | Нет |
Обе половины получены в одном прогоне: экран всё это время не гас — две блокировки простоя держались от первого сэмпла до последнего, — а таймер простоя шёл так, будто за компьютером никого нет. Не давать погаснуть экрану и выглядеть присутствующим для трекера — разные вещи, и веб-странице доступна только первая.
- 1. movemycursor.com удерживал экран, когда мы мерили его 30 июля 2026 года, и перепроверить тем же способом его больше нельзя: кнопка старта продаёт первый клик рекламной сети. Три чистые загрузки подряд увели вкладку соответственно на промо игры с партнёрской меткой, на трейдинговый сайт и на страницу магазина — то есть пришедший включить джиглер получает чужую рекламу, а инструмент запускается в лучшем случае со второй попытки.
- 2. mouse-jiggler.com — единственный честный: он и не выдаёт себя за программу. Страница рисует движущийся узор на экране телефона, вы кладёте на стекло настоящую мышь, и её сенсор видит движение. Это действительно работает — потому что двигается настоящая мышь, — и требует второго устройства.
Находка, которая оказалась важнее самого замера
Браузерная блокировка простоя снимается в момент, когда вкладка перестаёт быть видимой, и берётся заново при возврате. Мы наблюдали это на своей же странице: две блокировки при вкладке на экране, одна после переключения на соседнюю, снова две при возврате.
Так и написано в спецификации, но следствие для тех, кто полагается на вкладку, жёсткое: джиглер, оставленный в фоновой вкладке, не держит вообще ничего. Он работает, только пока вы на него смотрите, — то есть ровно в те минуты, когда он не нужен.
Чего эти прогоны не доказывают
- Они показывают, что записал клиент трекера на этой машине. Сверка с веб-кабинетом делалась 30 и 31 июля 2026 года и совпала, но 13 августа её повторить не удалось, поэтому формулировка везде одна: «трекер записал», а не «в кабинете показано».
- По одной машине и одной операционной системе на прогон: цифры трекера — это Windows, цифры таймера простоя — Ubuntu 24.04 с GNOME на Wayland и Chrome 150. Учёт простоя в разных средах устроен по-разному, а macOS мы не мерили вовсе.
- В первом прогоне измерялся Reaction, а не джиглеры вообще. О донглах и других приложениях он не говорит ничего и не обещает, что на вашей машине и в вашем аккаунте выйдет тот же процент.
- 4 блока и 40 минут — маленькая выборка. Мы отвечаем за разброс; среднее обобщает четыре показания и не является величиной, которую кто-то должен ожидать на своей машине или в своём аккаунте.
Повторите сами
Оба инструмента обычные и бесплатные. Чтобы всё это проверить, наша программа не нужна.
Системный таймер простоя (GNOME)
busctl --user call org.gnome.Mutter.IdleMonitor /org/gnome/Mutter/IdleMonitor/Core org.gnome.Mutter.IdleMonitor GetIdletimeВозвращает миллисекунды с момента последнего ввода, который система засчитала. Снимите, подождите, снимите ещё раз: если инструмент создаёт ввод, видимый ОС, второе число окажется меньше. Следите, чтобы вкладка браузера всё это время оставалась видимой, — скрытой вкладке в блокировке простоя отказывают, и проверка разваливается целиком.
Блокировки гашения экрана
busctl --user call org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager GetInhibitorsПоказывает, что прямо сейчас не даёт экрану погаснуть, — так блокировка отличается от настоящего ввода. Браузерный джиглер добавляет сюда запись и не меняет ничего в показании выше.
Лог самого трекера
%APPDATA%\Hubstaff\logs\hubstaff.log
WindowsInput.cpp:349 Mouse: …/R…/I…/LI…
WindowsInput.cpp:293 Only injected input. Mouse: 0/R0/I17/LI0
На Windows клиент Hubstaff пишет посекундные строки в свой каталог логов. Первая строка ниже появляется у каждой секунды с вводом, вторая отмечает секунды, где весь ввод был инъектированным. Секунда с первой и без второй — человек.
Как ссылаться
Цифры можно свободно цитировать со ссылкой на эту страницу. Журналистам и исследователям вышлем сырые данные прогонов — посекундную выборку блоков, вывод стенда со всеми сэмплами и забракованные прогоны, — напишите на support@getreaction.app. Заодно честно скажем, чего мы не измеряли: обычно это более полезная половина ответа.
Приложение, которое измерял первый прогон
Reaction создаёт обычный ввод операционной системы, пока машина простаивает, — с разной траекторией и разными паузами вместо фиксированного интервала — и уходит в сторону, как только вы коснулись мыши. Цифры выше — это то, как он выглядит со стороны трекера.