von Martin Brinkmann am 22. September 2021 in Google Chrome – 5 Kommentare
Google Chrome 94 ist raus und mit dem Browser kommt ein neues umstrittenes Feature: die Idle Detection API. Wie der Name schon sagt, kann es von Websites implementiert werden, um herauszufinden, ob ein Benutzer untätig ist. Inaktiv bedeutet, dass der Benutzer nicht mit dem Gerät oder bestimmter Hardware wie Tastatur oder Maus oder durch bestimmte Systemereignisse wie das Starten eines Bildschirmschoners oder den Sperrstatus interagiert hat.
Beispiele für Anwendungsfälle sind die Verwendung der API, um zu wissen, ob Kontakte im Chat oder auf Social-Networking-Sites gerade erreichbar sind, der automatische Neustart von Kiosk-Anwendungen, wenn eine Zeit lang keine Benutzerinteraktion bemerkt wird, oder „Apps, die teure Berechnungen erfordern“, die diese einschränken zu Momenten mit Benutzerinteraktion. Die neueste Iteration der API erfordert die ausdrückliche Erlaubnis des Benutzers, bevor Websites sie verwenden können.
< p>Google hat die Funktionalität in Chrome 94 implementiert, das das Unternehmen diese Woche veröffentlicht hat. Mozilla und Apple lehnen die Integration der Idle Detection API ab und werden sie nicht in Firefox und Safari implementieren.
Mozilla hat “Anliegen der Benutzerüberwachung und Benutzerkontrolle” bezüglich der API, da sie ” kann verwendet werden, um die Nutzungsmuster eines Benutzers zu überwachen und sie entsprechend zu manipulieren.”
Wie es derzeit spezifiziert ist, halte ich die Idle Detection API für eine zu verlockende Gelegenheit für vom Überwachungskapitalismus motivierte Websites, in einen Aspekt der physischen Privatsphäre des Benutzers einzudringen, langfristige Aufzeichnungen über das physische Benutzerverhalten zu führen, den Tagesrhythmus (z. B. die Mittagszeit) zu erkennen und zu verwenden das zur proaktiven psychologischen Manipulation (zB Hunger, Emotion, Wahl [1][2][3]). Darüber hinaus könnten solche groben Muster von Websites verwendet werden, um heimlich lokale Rechenressourcen für Proof-of-Work-Berechnungen auszuschöpfen, wodurch ohne Zustimmung oder vielleicht sogar Bewusstsein des Benutzers Strom verschwendet wird (Kosten für den Benutzer, Erhöhung des CO2-Fußabdrucks).
Mozilla veröffentlichte eine formelle Ablehnung des Vorschlags. Darin schlägt die Organisation vor, Anfragen, an denen nur ein Implementierer Interesse gezeigt hat, zu verwerfen, und erklärt, dass sich die Situation zu einer “Spezifikation für eine einzige Implementierung” entwickeln könnte.
Wir bitten darum, Spezifikationen zu verwerfen, die nur von einem Implementierer Interesse gezeigt haben, andernfalls laufen wir Gefahr, dass eine Spezifikation mit einer einzigen Implementierung nur als Dokumentation dient (dh kein tatsächlicher offener Standard), da wir wissen, dass auf Monokultur basierende Standards am Ende wird es de facto, basierend auf den Details, Fehlern, Interpretationen der einen spezifischen Implementierung und nicht auf dem, was in einer Spezifikation steht.
Apple hat seine offizielle Antwort auf der Webkit-Mailingliste veröffentlicht. Das WebKit-Team des Unternehmens sieht keine “stark genug” Anwendungsfälle für die Implementierung der API.
Ich werde an dieser Stelle nicht mehr auf diesen Thread antworten, da auch keiner der hier vorgestellten Anwendungsfälle oder anderswo zwingend sind, und keine der Datenschutz- oder Sicherheitsmaßnahmen, die Sie hier vorgestellt haben und die ich an anderer Stelle gefunden habe, sind angemessen. Auf diesen Thread oder zukünftige Threads zu diesem Thema nicht zu antworten, bedeutet jedoch nicht, dass wir unsere Position überdenken würden. Sofern in keinem der von uns angesprochenen Probleme eine wesentliche neue Entwicklung vorgenommen wird, werden wir der Hinzufügung dieser API weiterhin widersprechen, sofern nicht anders angegeben, unabhängig davon, ob wir dies weiterhin öffentlich sagen oder nicht.
Chromium-basierte Browser werden die neue API irgendwann unterstützen, es sei denn, sie wird manuell vom Entwicklungsteam entfernt oder deaktiviert.