Domyślne włączenie interfejsu Idle Detection API w Chrome 94 wywołało falę krytyki, powołując się na zastrzeżenia twórców Firefoksa i WebKit/Safari.
Idle Detection API umożliwia witrynom wykrywanie czasu, kiedy użytkownik jest nieaktywny, tj. Nie współpracuje z klawiaturą/myszą ani nie wykonuje pracy na innym monitorze. API pozwala również dowiedzieć się, czy w systemie działa wygaszacz ekranu, czy nie. Informacja o braku aktywności realizowana jest poprzez wysłanie powiadomienia po osiągnięciu określonego progu braku aktywności, którego minimalna wartość ustawiona jest na 1 minutę.
Należy pamiętać, że korzystanie z API Idle Detection wymaga wyraźnego przyznania uprawnień użytkownika, tj. Jeżeli aplikacja po raz pierwszy spróbuje wykryć brak aktywności, użytkownikowi wyświetli się okno z pytaniem, czy przyznać uprawnienia, czy zablokować operację. Aby całkowicie wyłączyć interfejs API wykrywania bezczynności, w sekcji ustawień „Prywatność i bezpieczeństwo” dostępna jest specjalna opcja („chrome://settings/content/idleDetection”).
Obszary zastosowań obejmują czaty, sieci społecznościowe i aplikacje komunikacyjne, które mogą zmieniać status użytkownika w zależności od jego obecności przy komputerze lub opóźniać powiadamianie o nowych wiadomościach do czasu przybycia użytkownika. Interfejsu API można także używać w aplikacjach kiosku do powrotu do pierwotnego ekranu po pewnym okresie bezczynności lub do wyłączenia interaktywnych operacji wymagających dużych zasobów, takich jak ponowne rysowanie złożonych i stale aktualizowanych wykresów, gdy użytkownik nie jest przy komputerze.
Przeciwnicy włączenia API Idle Detection stoją na stanowisku, że informację o tym, czy użytkownik jest przy komputerze, czy też nie, można uznać za poufną. Oprócz przydatnych aplikacji, ten interfejs API może być również wykorzystywany do złych celów, na przykład do próby wykorzystania luk w zabezpieczeniach, gdy użytkownik jest nieobecny, lub do ukrycia rzucającej się w oczy złośliwej aktywności, takiej jak eksploracja. Za pomocą omawianego API można także zbierać informacje o wzorcach zachowań użytkownika i codziennym rytmie jego pracy. Możesz na przykład dowiedzieć się, kiedy użytkownik zwykle idzie na lunch lub opuszcza miejsce pracy. W kontekście obowiązkowego żądania dowodu autoryzacji obawy te są postrzegane przez Google jako nieistotne.
Dodatkowo można zauważyć notatkę twórców Chrome o promowaniu nowych technik zapewniających bezpieczną pracę z pamięcią. Według Google 70% problemów z bezpieczeństwem w przeglądarce Chrome wynika z błędów pamięci, np. użycia bufora po zwolnieniu powiązanej z nim pamięci (use-after-free). Zidentyfikowano trzy główne strategie radzenia sobie z takimi błędami: wzmocnienie kontroli na etapie kompilacji, blokowanie błędów w czasie wykonywania i używanie języka bezpiecznego dla pamięci.
Poinformowano, że rozpoczęły się eksperymenty mające na celu dodanie możliwości tworzenia komponentów w języku Rust do bazy kodu Chromium. Kod Rusta nie jest jeszcze zawarty w kompilacjach dostarczanych użytkownikom i ma na celu głównie przetestowanie możliwości rozwoju poszczególnych części przeglądarki w Rust i ich integracji z innymi częściami napisanymi w C++. Równolegle, dla kodu C++, rozwijany jest projekt wykorzystania typu MiraclePtr zamiast surowych wskaźników do blokowania możliwości wykorzystania podatności spowodowanych dostępem do już zwolnionych bloków pamięci, proponowane są także nowe metody wykrywania błędów na etapie kompilacji.
Ponadto Google rozpoczyna eksperyment mający na celu przetestowanie możliwych zakłóceń działania witryn po osiągnięciu przez przeglądarkę wersji składającej się z trzech cyfr zamiast dwóch. W szczególności w testowych wersjach przeglądarki Chrome 96 pojawiło się ustawienie „chrome://flags#force-major-version-to-100”, jeśli zostało określone w nagłówku User-Agent, wersja 100 (Chrome/100.0.4650.4) zaczyna być wyświetlany. W sierpniu podobny eksperyment przeprowadzono w przeglądarce Firefox, który ujawnił problemy z przetwarzaniem wersji trzycyfrowych w niektórych witrynach.
Źródło: opennet.ru