Die standardmäßige Einbindung der Idle Detection API in Chrome 94 hat zu einer Welle der Kritik geführt, in der Einwände von Firefox- und WebKit/Safari-Entwicklern angeführt wurden.
Mit der Idle Detection API können Websites die Zeit erkennen, zu der ein Benutzer inaktiv ist, d. h. Interagiert nicht mit Tastatur/Maus und führt keine Arbeit auf einem anderen Monitor aus. Über die API können Sie außerdem herausfinden, ob auf dem System ein Bildschirmschoner läuft oder nicht. Die Information über Inaktivität erfolgt durch Versenden einer Benachrichtigung nach Erreichen eines bestimmten Inaktivitätsschwellenwerts, dessen Mindestwert auf 1 Minute festgelegt ist.
Es ist wichtig zu beachten, dass die Verwendung der Idle Detection API die explizite Gewährung von Benutzerberechtigungen erfordert, d. h. Wenn die Anwendung zum ersten Mal versucht, Inaktivität zu erkennen, wird dem Benutzer ein Fenster angezeigt, in dem er gefragt wird, ob er Berechtigungen erteilen oder den Vorgang blockieren möchte. Um die Leerlauferkennungs-API vollständig zu deaktivieren, steht im Einstellungsbereich „Datenschutz und Sicherheit“ eine spezielle Option („chrome://settings/content/idleDetection“) zur Verfügung.
Zu den Anwendungsgebieten gehören Chat-, Social-Networking- und Kommunikationsanwendungen, die den Status des Benutzers abhängig von seiner Anwesenheit am Computer ändern oder die Benachrichtigung über neue Nachrichten verzögern können, bis der Benutzer eintrifft. Die API kann auch in Kioskanwendungen verwendet werden, um nach einer Zeit der Inaktivität zum ursprünglichen Bildschirm zurückzukehren oder um ressourcenintensive interaktive Vorgänge, wie das Neuzeichnen komplexer, ständig aktualisierter Diagramme, zu deaktivieren, wenn der Benutzer nicht am Computer sitzt.
Gegner der Aktivierung der Idle Detection API vertreten den Standpunkt, dass Informationen darüber, ob sich der Benutzer am Computer befindet oder nicht, als vertraulich angesehen werden können. Neben nützlichen Anwendungen kann diese API auch für böswillige Zwecke verwendet werden, beispielsweise um zu versuchen, Schwachstellen auszunutzen, während der Benutzer abwesend ist, oder um auffällige bösartige Aktivitäten wie Mining zu verbergen. Mithilfe der jeweiligen API können auch Informationen über das Verhalten des Benutzers und seinen täglichen Arbeitsrhythmus gesammelt werden. Sie können beispielsweise herausfinden, wann der Benutzer normalerweise zum Mittagessen geht oder den Arbeitsplatz verlässt. Im Rahmen einer zwingenden Anforderung eines Berechtigungsnachweises werden diese Bedenken von Google als unbedeutend angesehen.
Beachten Sie außerdem den Hinweis der Chrome-Entwickler zur Förderung neuer Techniken zur Gewährleistung eines sicheren Betriebs mit dem Speicher. Laut Google werden 70 % der Sicherheitsprobleme in Chrome durch Speicherfehler verursacht, beispielsweise durch die Verwendung eines Puffers nach der Freigabe des damit verbundenen Speichers (Use-after-free). Es werden drei Hauptstrategien für den Umgang mit solchen Fehlern identifiziert: Verstärkung der Prüfungen in der Kompilierungsphase, Blockieren von Fehlern zur Laufzeit und Verwendung einer speichersicheren Sprache.
Es wird berichtet, dass Experimente begonnen haben, um der Chromium-Codebasis die Möglichkeit hinzuzufügen, Komponenten in der Rust-Sprache zu entwickeln. Der Rust-Code ist noch nicht in den an Benutzer ausgelieferten Builds enthalten und dient hauptsächlich dazu, die Möglichkeit zu testen, einzelne Teile des Browsers in Rust zu entwickeln und mit anderen in C++ geschriebenen Teilen zu integrieren. Parallel dazu wird für C++-Code ein Projekt weiterentwickelt, das den Typ MiraclePtr anstelle von Rohzeigern verwendet, um die Möglichkeit der Ausnutzung von Schwachstellen zu blockieren, die durch den Zugriff auf bereits freigegebene Speicherblöcke entstehen, und es werden auch neue Methoden zur Fehlererkennung in der Kompilierungsphase vorgeschlagen.
Darüber hinaus startet Google ein Experiment, um die mögliche Störung von Websites zu testen, nachdem der Browser eine Version erreicht, die aus drei statt zwei Ziffern besteht. Insbesondere in den Testversionen von Chrome 96 erschien die Einstellung „chrome://flags#force-major-version-to-100“, wenn im User-Agent-Header Version 100 (Chrome/100.0.4650.4) angegeben wurde. beginnt angezeigt zu werden. Im August wurde ein ähnliches Experiment in Firefox durchgeführt, bei dem auf einigen Websites Probleme bei der Verarbeitung dreistelliger Versionen festgestellt wurden.
Source: opennet.ru