Google Chrome 94 está disponible y con el navegador llega una nueva característica controvertida: la API de detección de inactividad. Como sugiere el nombre, los sitios pueden implementarlo para averiguar si un usuario está inactivo. Inactivo significa que el usuario no ha interactuado con el dispositivo o hardware específico, como el teclado o el mouse, o mediante ciertos eventos del sistema, como el inicio de un protector de pantalla o el estado de bloqueo.
Casos de uso de ejemplo incluir usar la API para saber si los contactos en el chat o en los sitios de redes sociales son accesibles en ese momento, reinicio automático de las aplicaciones de kiosco si no se nota interacción del usuario durante un período, o «aplicaciones que requieren cálculos costosos» que los limitan a momentos con el usuario Interacción. La última versión de la API requiere un permiso explícito del usuario antes de que los sitios puedan utilizarla.
Google implementó la funcionalidad en Chrome 94, que la compañía lanzó esta semana. Mozilla y Apple se oponen a la integración de la API de detección de inactividad y no la implementarán en Firefox y Safari.
Mozilla posee «preocupaciones sobre la vigilancia y el control del usuario» sobre la API, ya que «se puede utilizar para supervisar los patrones de uso de un usuario y manipularlos en consecuencia».
Como se especifica actualmente, considero que la API de Idle Detection es una oportunidad demasiado tentadora para que los sitios web motivados por el capitalismo de vigilancia invadan un aspecto de la privacidad física del usuario, mantengan registros a largo plazo de los comportamientos físicos del usuario, disciernan los ritmos diarios (por ejemplo, la hora del almuerzo) y utilicen que para la manipulación psicológica proactiva (por ejemplo, hambre, emoción, elección [1][2][3]). Además, los sitios web podrían utilizar estos patrones burdos para maximizar subrepticiamente los recursos informáticos locales para los cálculos de prueba de trabajo, desperdiciando electricidad (costo para el usuario, aumento de la huella de carbono) sin el consentimiento del usuario o tal vez incluso el conocimiento.
Mozilla publicado un rechazo formal a la propuesta. En él, la organización propone eliminar las solicitudes en las que solo un implementador ha mostrado interés, indicando que la situación podría correr el riesgo de evolucionar hacia una «especificación de implementación única».
Solicitamos que se eliminen las especificaciones que hayan mostrado interés de un solo implementador; de lo contrario, corremos el riesgo de una especificación de implementación única, que solo servirá como documentación (es decir, no como un estándar abierto real), ya que sabemos que los estándares basados en monocultivos terminan convirtiéndose de facto, en función de los detalles, errores, interpretaciones de una implementación específica y no lo que está escrito en una especificación.
manzana publicado su respuesta oficial en la lista de correo de Webkit. El equipo de WebKit de la empresa no ve casos de uso «suficientemente sólidos» para implementar la API.
Dejaré de responder a este hilo en este punto porque ninguno de los casos de uso presentados aquí o en otro lugar es convincente, y ninguna de las mitigaciones de privacidad o seguridad que ha presentado aquí y que he encontrado en otros lugares es adecuada. Sin embargo, no responder a este hilo o hilo futuro sobre este tema no significa que reconsideremos nuestra posición. A menos que se esté realizando un nuevo desarrollo significativo en cualquiera de los problemas que hemos planteado, nuestra posición seguirá siendo objetar la adición de esta API a menos que se indique lo contrario, independientemente de si seguimos diciéndolo en público o no.
Los navegadores basados en Chromium admitirán la nueva API eventualmente, a menos que el equipo de desarrollo la elimine manualmente o la desactive.