Idle Detection API：用户控制、权限与隐私边界
在明确用户意图、正确处理权限并区分浏览器空闲状态与应用在线状态的前提下使用 Idle Detection API。
BotBrowser Team
Idle Detection API 可以告诉应用用户和设备是否处于空闲状态。它适合暂停协作状态或高成本刷新，但不能证明用户离开、可用或同意被观察。该 API 需要权限和用户激活，只提供粗粒度状态，不提供个人活动历史。BotBrowser 可以用授权配置重复兼容性测试；它不能授予权限、制造用户意图，也不能把空闲状态变成身份凭据。
TL;DR
只在明确用户操作后使用该 API，把拒绝视为正常路径，并将空闲信号与身份和同意严格区分。BotBrowser 可以测试显式配置的浏览器上下文和授权 Profile，但不能授予权限或证明真人在场。
Contents
要点
- 先解释用途，再从真实点击或键盘激活中请求
idle-detection权限。 - 将
active、idle、locked视为短期产品信号，不要当作在场、身份、同意或注意力的证明。 - 功能结束时停止检测，使用有界阈值，不保存完整状态变化时间线。
- 做能力检测，并为浏览器、上下文或策略不支持的情况提供可见 fallback。
- BotBrowser 可以复现授权配置并记录测试结果；权限说明、用户激活、数据最小化和 fallback 仍由页面负责。
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 或 Permissions Policy 下可能不可用。跨源 frame、隐私模式、节能策略和托管 profile 都可能改变结果。把 unsupported 与 denied 当作预期分支，而不是用户活跃的证据。
BotBrowser 能力与限制
BotBrowser 可以加载授权 profile，并在检查时保持浏览器、代理、有头或无头模式及 display 的明确配置一致。测试记录可以包含版本、目标系统、profile 家族、权限结果、激活路径、检测器启动结果和可见 fallback。
BotBrowser 不会授予 idle-detection 权限，不会创建用户激活，不会绕过 Permissions Policy，也不会把模拟点击变成知情同意。它无法保证平台空闲分类器、锁屏行为、iframe 策略或第三方解释。权限说明、控件、最小化和恢复路径由应用负责。
证据与 fallback 矩阵
| 观察 | 安全解释 | 下一步 |
|---|---|---|
unsupported | 当前上下文没有该 API | 保留手动暂停或定时器 |
permission-denied | 浏览器或用户拒绝访问 | 不监测并避免循环请求 |
started 后出现 active-idle | 检测器发出了粗粒度状态变化 | 暂停目标功能并保留控件 |
locked | 浏览器报告屏幕锁定 | 保护界面，不推断身份或同意 |
| 激活后启动仍被拒绝 | 策略、上下文或平台阻止 | 记录有界失败并显示 fallback |
在真实部署的模式和 profile 中重复 fixture。按平台分开记录，不要为了证明一次空闲变化而收集截图或账户数据。
结论
Idle Detection 是范围很窄的便利信号。应在有意义的用户操作后请求权限，处理拒绝，结束时停止检测，并避免用于身份判断或监控。验证授权路径，也验证拒绝或不支持时的 fallback。另请参阅浏览器隐私基础与浏览器交互验证。
FAQ
idle 是否表示用户离开了？
不是。这是浏览器的粗粒度信号，用户可能在阅读，也可能由他人使用设备。
能否在页面加载时请求权限？
应从用户激活的操作请求，并先说明目的。拒绝应是正常分支。
BotBrowser 能强制授予权限吗？
不能。它只能重复授权 profile 流程；权限、激活、策略和平台行为仍由浏览器与用户控制。
是否应把变化发送到分析系统？
通常不应。尽量本地处理，只保留用户预期的聚合结果。
实际结论是什么？
让检测器只在需要时运行，解释用途，并在不可用时保留手动控制。