Idle Detection API: control, permisos y privacidad

Idle Detection API informa si el usuario y el dispositivo parecen inactivos. Sirve para pausar indicadores de colaboración o actualizaciones costosas, pero no demuestra que alguien se haya ido, esté disponible o acepte ser observado. Requiere permiso y activación del usuario, ofrece un estado general y no entrega un historial de actividad. BotBrowser puede repetir pruebas con un perfil autorizado; no puede conceder permisos, crear intención ni convertir la inactividad en una credencial.

TL;DR

Usa esta API después de una acción clara, acepta el rechazo del permiso y no confundas la señal con identidad o consentimiento. BotBrowser prueba un contexto de navegador explícitamente configurado con un perfil autorizado, pero no concede el permiso ni demuestra presencia humana.

Contents

• Qué informa la API
• Permisos y activación
• Privacidad y comportamiento seguro
• Capacidades y límites de BotBrowser
• Conclusión

Puntos clave

• Explica el propósito y solicita idle-detection desde un clic o una activación real.
• Trata active, idle y locked como señales breves, no como prueba de presencia, identidad, consentimiento o atención.
• Detén la detección al terminar, usa un umbral acotado y no guardes toda la línea temporal.
• Detecta la capacidad y ofrece una ruta alternativa visible para navegadores, contextos o políticas no compatibles.
• BotBrowser puede repetir un perfil autorizado y registrar resultados; la página debe explicar, minimizar datos y ofrecer una ruta alternativa.

Qué informa la API

IdleDetector informa userState (active o idle) y screenState (locked o unlocked). Solo empieza después de que start() tiene éxito. El límite de inactividad son milisegundos antes de que el navegador pueda clasificarla; no es la hora de la última entrada ni identifica su tipo. El evento change informa una nueva combinación.

Es un modelo del navegador, no una persona verificada. El usuario puede leer sin escribir, otra persona puede usar el dispositivo y la tecnología de asistencia puede generar entradas distintas. Una pantalla bloqueada tampoco demuestra propiedad. Úsalo para pausar vistas previas o actualizaciones, nunca para autenticación, asistencia o vigilancia.

Permisos y activación

Cuando exista, consulta navigator.permissions.query({ name: 'idle-detection' }) y explica el motivo. El aviso debe seguir una acción como “pausar cuando me vaya”, no la carga, un temporizador ni un clic simulado. granted, denied y prompt son estados distintos; prompt no es autorización.

La activación dura poco. Llama a IdleDetector.requestPermission() directamente desde el manejador mientras siga activa y trata el rechazo como una ruta normal. El navegador, un iframe, el modo privado o una política empresarial pueden rechazarlo. No repitas avisos.

Ejemplo mínimo controlado por el usuario

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;
}

Llámalo desde una activación real y ofrece un control para detenerlo. Si no está disponible, conserva el estado de producto en memoria y no guardes texto de errores con datos de cuenta o página.

Privacidad y comportamiento seguro

Incluso una secuencia general puede convertirse en un registro de conducta. No envíes cada cambio a analítica, no deduzcas rutinas y no guardes marcas temporales más tiempo del necesario. Prefiere una marca en memoria y, si debes informar, conserva solo la agregación esperada.

La inactividad no es consentimiento. Una pantalla bloqueada no autoriza una operación y active no demuestra que se leyó un mensaje. Comprueba de nuevo antes de acciones irreversibles, conserva controles de cuenta tras un tiempo de espera y exige un gesto nuevo para cambios sensibles. No cierres sesión ni expongas contenido privado silenciosamente por esta señal.

El API está pensado para contextos seguros y puede no estar disponible en iframes o bajo Permissions Policy. Frames de otro origen, modo privado, ahorro de energía y perfiles gestionados cambian los resultados. unsupported y denied son rutas previstas, no evidencia de actividad.

Capacidades y límites de BotBrowser

BotBrowser puede cargar un perfil autorizado y mantener explícitos navegador, proxy, modo visible o oculto y display. El registro puede incluir versión, sistema objetivo, familia de perfil, permiso, ruta de activación, resultado de inicio y ruta alternativa visible.

BotBrowser no concede idle-detection, crea activación, evita Permissions Policy ni convierte un clic simulado en consentimiento informado. No garantiza el clasificador de la plataforma, el bloqueo, la política de iframe ni la interpretación de terceros. La aplicación debe explicar, controlar, minimizar y recuperar.

Matriz de evidencia y ruta alternativa

Observación	Interpretación segura	Siguiente paso
unsupported	El API no existe en este contexto	Mantén pausa manual o temporizador
permission-denied	Navegador o usuario rechazó el acceso	No monitorices ni repitas avisos
active-idle tras started	Hubo un cambio general	Pausa la función y conserva controles
locked	El navegador informa pantalla bloqueada	Protege la interfaz; no infieras identidad
Inicio rechazado tras activación	Política, contexto o plataforma lo impidió	Registra el fallo acotado y muestra la ruta alternativa

Repite el fixture en los modos y perfiles de despliegue. Separa plataformas y no recojas capturas ni datos de cuenta para probar un único cambio.

Conclusión

Idle Detection es una señal de conveniencia limitada. Solicita permiso tras una acción significativa, trata el rechazo normalmente, detén la detección al terminar y no la uses para identidad o vigilancia. Valida la ruta autorizada y la ruta alternativa. Consulta también privacidad básica del navegador y validación de interacciones.

FAQ

¿idle significa que el usuario se fue?

No. Es una señal general; puede estar leyendo o el dispositivo puede tener otro usuario.

¿Se puede pedir permiso al cargar la página?

Pídelo desde una activación del usuario después de explicar el propósito. El rechazo es una ruta normal.

¿BotBrowser puede forzar el permiso?

No. Puede repetir un flujo autorizado; el navegador y el usuario controlan permiso, activación y política.

¿Se deben enviar los cambios a analítica?

Normalmente no. Procésalos localmente y conserva solo la agregación esperada.

¿Cuál es la conclusión práctica?

Mantén el detector activo solo el tiempo necesario, explica su objetivo y conserva un control manual cuando no esté disponible.

Sources and next reading

• WICG Idle Detection
• MDN: Idle Detection API
• MDN: IdleDetector
• Permissions Policy

Sources

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