Kritik an der Einführung der API Idle Detection in Chrome 94. Experimente mit Rust in Chrome

Die standardmäßige Aktivierung der API Idle Detection in Chrome 94 führte zu einer Welle der Kritik, die auf Einwände von Entwicklern von Firefox und WebKit/Safari verweist.

Die API Idle Detection ermöglicht es Websites, die Zeit zu bestimmen, in der der Benutzer inaktiv ist, d.h. nicht mit der Tastatur/Maus interagiert oder an einem anderen Monitor arbeitet. Die API ermöglicht auch festzustellen, ob ein Bildschirmschoner im System aktiv ist. Die Benachrichtigung über die Inaktivität erfolgt durch das Senden einer Mitteilung, nachdem ein festgelegter Inaktivitätszeitraum erreicht wurde, dessen Mindestwert auf 1 Minute festgelegt ist.

Es ist wichtig zu beachten, dass die Verwendung der API Idle Detection die ausdrückliche Zustimmung des Benutzers erfordert, d.h. wenn eine Anwendung zum ersten Mal versucht, Inaktivität zu erkennen, wird dem Benutzer ein Fenster angezeigt, in dem er darum gebeten wird, die Berechtigungen zu erteilen oder den Vorgang zu blockieren. Um die API Idle Detection vollständig zu deaktivieren, gibt es in den Einstellungen unter „Datenschutz und Sicherheit“ eine spezielle Option („chrome://settings/content/idleDetection“).

Anwendungsbereiche sind Chat- und soziale Netzwerke sowie Kommunikationsanwendungen, die den Status des Benutzers basierend auf seiner Anwesenheit am Computer ändern oder die Anzeige von Benachrichtigungen über neue Nachrichten bis zur Rückkehr des Benutzers hinauszögern können. Die API kann auch in Kiosk-Anwendungen verwendet werden, um nach einer bestimmten Inaktivitätszeit zum Startbildschirm zurückzukehren oder ressourcenintensive interaktive Vorgänge zu deaktivieren, wie die Neuzeichnung komplexer, ständig aktualisierter Diagramme, wenn der Benutzer nicht am Computer ist.

Die Position der Gegner der Integration der API Idle Detection ist, dass Informationen darüber, ob ein Benutzer am Computer sitzt oder nicht, als vertraulich betrachtet werden können. Neben nützlichen Anwendungen könnte diese API auch für weniger wohlwollende Zwecke verwendet werden, beispielsweise zur Ausnutzung von Sicherheitsanfälligkeiten während der Abwesenheit des Benutzers oder zum Verbergen auffälliger schädlicher Aktivitäten wie Mining. Mit der besprochenen API können auch Informationen über das Verhalten und den täglichen Arbeitsrhythmus des Benutzers gesammelt werden. Zum Beispiel kann ermittelt werden, wann der Benutzer normalerweise zum Mittagessen geht oder seinen Arbeitsplatz verlässt. Unter den Anforderungen einer obligatorischen Bestätigung der Berechtigungsvergabe werden diese Bedenken von Google als irrelevant angesehen.

Zusätzlich sei auf eine Anmerkung der Chrome-Entwickler hingewiesen, die neue Techniken zur Sicherstellung eines sicheren Umgangs mit Speicher vorantreiben. Laut Google sind 70 % der Sicherheitsprobleme in Chrome auf Fehler im Umgang mit Speicher zurückzuführen, wie etwa den Zugriff auf einen Puffer nach der Freigabe des zugehörigen Speichers (use-after-free). Es werden drei Hauptstrategien zur Bekämpfung solcher Fehler definiert: Verstärkung der Prüfungen zur Compile-Zeit, Blockieren von Fehlern zur Laufzeit und die Verwendung einer Sprache, die einen sicheren Umgang mit Speicher gewährleistet.

Berichte über den Beginn von Experimenten zur Integration der Möglichkeit, Komponenten in der Programmiersprache Rust in den Code von Chromium zu entwickeln, liegen vor. Rust-Code ist derzeit nicht in den an die Benutzer gelieferten Builds enthalten und zielt hauptsächlich darauf ab, die Möglichkeiten zur Entwicklung einzelner Teile des Browsers in Rust und deren Integration mit anderen in C++ geschriebenen Teilen zu testen. Gleichzeitig entwickelt sich weiterhin das Projekt zur Verwendung des Typs MiraclePtr statt raw-Zeigern für die Verhinderung von Sicherheitsanfälligkeiten, die durch den Zugriff auf bereits freigegebene Speicherblöcke verursacht werden, und es werden neue Methoden zur Fehlererkennung zur Compile-Zeit vorgeschlagen.

Darüber hinaus beginnt das Unternehmen Google mit einem Experiment, um mögliche Funktionsstörungen von Websites zu testen, nachdem der Browser eine Version erreicht hat, die aus drei Ziffern anstelle von zwei besteht. Insbesondere in den Testversionen von Chrome 96 wurde die Einstellung „chrome://flags#force-major-version-to-100“ eingeführt, bei der im User-Agent-Header die Version 100 (Chrome/100.0.4650.4) ausgegeben wird. Im August wurde ein ähnliches Experiment in Firefox durchgeführt, das Probleme mit der Verarbeitung von dreiziffrigen Versionen auf bestimmten Websites aufdeckte.

Quelle: opennet.ru