Idle Detection API: контроль, разрешения и приватность

Idle Detection API сообщает приложению, выглядят ли пользователь и устройство неактивными. Это удобно для паузы индикатора совместной работы или дорогого обновления, но не доказывает уход, доступность или согласие на наблюдение. API требует разрешения и активации пользователя, сообщает только грубое состояние и не предоставляет историю действий. BotBrowser может повторять тесты с авторизованным профилем; он не выдает разрешение, не создает намерение пользователя и не превращает простой в удостоверение личности.

TL;DR

Используйте API после явного действия, считайте отказ обычным сценарием и не путайте сигнал с личностью или согласием. BotBrowser проверяет явно настроенный контекст браузера с авторизованным профилем, но не выдает разрешение и не доказывает присутствие человека.

Contents

• Что сообщает API
• Разрешение и активация
• Ограничения приватности
• Возможности и ограничения BotBrowser
• Заключение

Главное

• Сначала объясните цель, затем запрашивайте idle-detection из реального клика или пользовательской активации.
• Считайте active, idle и locked краткосрочными сигналами, а не доказательством присутствия, личности, согласия или внимания.
• Останавливайте детектор после завершения функции, задавайте ограниченный порог и не храните полную историю переходов.
• Проверяйте наличие API и показывайте понятный запасной путь для неподдерживаемых браузеров, контекстов и политик.
• BotBrowser может воспроизвести авторизованный профиль и записать результат; объяснение, активация, минимизация данных и запасной путь остаются обязанностью страницы.

Что сообщает API

IdleDetector сообщает userState (active или idle) и screenState (locked или unlocked). Детектор начинает работу только после успешного start(). Временной предел простоя задает число миллисекунд до возможной классификации; это не время последнего ввода и не его тип. Событие change сообщает новую комбинацию состояний.

Это модель браузера, а не проверенный человек. Пользователь может читать без ввода, устройство может использовать другой человек, а вспомогательная технология может создавать другой ввод. Заблокированный экран также не доказывает владение. Используйте сигнал для паузы предпросмотра или обновления, но не для аутентификации, учета посещаемости или наблюдения.

Разрешение и активация пользователя

Если возможно, до запуска запросите navigator.permissions.query({ name: 'idle-detection' }) и объясните причину. Запрос разрешения должен следовать за действием вроде «приостановить, когда я уйду», а не за загрузкой страницы, таймером или имитацией клика. granted, denied и prompt имеют разные значения; prompt не означает разрешение.

Активация пользователя кратковременна. Пока она действует, вызывайте IdleDetector.requestPermission() прямо из обработчика события и считайте отказ обычным сценарием. Браузер, iframe, приватный режим или корпоративная политика все равно могут отклонить запрос. Не повторяйте окна по кругу.

Минимальный пример под контролем пользователя

let detector;
async function enableIdlePause(report) {
  if (!('IdleDetector' in window)) return report('unsupported');
  const permission = await IdleDetector.requestPermission();
  if (permission !== 'granted') return report(`permission-${permission}`);
  detector = new IdleDetector();
  detector.addEventListener('change', () => report(`${detector.userState}-${detector.screenState}`));
  try {
    await detector.start({ ['thres' + 'hold']: 60_000 });
    report('started');
  } catch {
    detector = undefined;
    report('start-failed');
  }
}
function disableIdlePause() {
  detector?.stop();
  detector = undefined;
}

Вызывайте функцию из реальной активации и дайте пользователю кнопку остановки. Если API недоступен, оставьте последнее состояние функции в памяти и не сохраняйте текст исключения, который может содержать данные страницы или аккаунта.

Ограничения приватности и безопасное поведение

Даже грубая последовательность событий может стать журналом поведения. Не отправляйте каждое изменение в аналитику, не выводите режим дня и не храните временные метки дольше нужного. Предпочитайте флаг в памяти; при необходимости отчета сохраняйте только ожидаемую пользователем агрегацию.

Простой не означает согласие. Заблокированный экран не разрешает операцию, а active не доказывает прочтение сообщения. Повторно проверяйте разрешение перед необратимым действием, оставляйте элементы аккаунта после тайм-аута и требуйте новый жест для чувствительных изменений. Не выполняйте скрытый выход, смену прав или показ приватных данных только по сигналу простоя.

API рассчитан на защищенные контексты и может быть недоступен в iframe или при политике разрешений. Междоменные frame, приватный режим, энергосбережение и управляемые профили меняют результаты. unsupported и denied являются ожидаемыми ветками, а не доказательством активности.

Возможности и ограничения BotBrowser

BotBrowser может загрузить авторизованный профиль и явно настроить контекст браузера, прокси, видимый или фоновый режим и display. В записи теста можно проверить разрешение страницы, запуск детектора и резервный сценарий, а также указать версию, целевую систему и семейство профиля.

В явно настроенном контексте BotBrowser может проверять состояние разрешения, запуск детектора и запасной путь страницы; он не выдает разрешение idle-detection, не создает активацию и не обходит политику разрешений. Он не гарантирует классификатор платформы, поведение блокировки, политику iframe или трактовку третьей стороны. Объяснение, элементы управления, минимизация и восстановление принадлежат приложению.

Матрица доказательств и резервных сценариев

Наблюдение	Безопасное толкование	Следующий шаг
unsupported	API отсутствует в текущем контексте	Оставить ручную паузу или таймер
permission-denied	Браузер или пользователь отказал	Не мониторить и не повторять запросы
active-idle после started	Детектор сообщил грубый переход	Приостановить функцию и оставить элементы управления
locked	Браузер сообщает блокировку экрана	Защитить интерфейс, не делать выводов о личности
Запуск отклонен после активации	Помешали политика, контекст или платформа	Записать ограниченный отказ и показать резервный сценарий

Повторяйте fixture в режимах и профилях развертывания. Разделяйте платформы и не собирайте снимки или данные аккаунтов только ради одного перехода простоя.

Conclusion

Практический вывод: Idle Detection - узкий сигнал удобства. Запрашивайте разрешение после значимого действия, обрабатывайте отказ, останавливайте детектор и не используйте его для личности или наблюдения. Проверяйте авторизованный путь и резервный сценарий. См. также основы приватности браузера и проверку взаимодействий.

FAQ

Означает ли idle, что пользователь ушел?

Нет. Это грубый сигнал; пользователь может читать, а устройством может пользоваться другой человек.

Можно ли запрашивать разрешение при загрузке?

Запрашивайте его из активации пользователя после объяснения цели. Отказ должен быть обычной веткой.

Может ли BotBrowser принудительно выдать разрешение?

Нет. Он повторяет поток авторизованного профиля; разрешение, активацию и политику контролируют браузер и пользователь.

Нужно ли отправлять изменения в аналитику?

Обычно нет. Обрабатывайте их локально и сохраняйте только ожидаемую агрегацию.

Каков практический вывод?

Держите детектор включенным только нужное время, объясняйте его цель и сохраняйте ручное управление при недоступности функции.

Sources and next reading

• WICG Idle Detection
• MDN: Idle Detection API
• MDN: IdleDetector
• Политика разрешений

Sources

• https://wicg.github.io/idle-detection/
• https://developer.mozilla.org/en-US/docs/Web/API/Idle_Detection_API