De standaardopname van de Idle Detection API in Chrome 94 heeft geleid tot een golf van kritiek, waarbij bezwaren van Firefox- en WebKit/Safari-ontwikkelaars werden aangehaald.
Met de Idle Detection API kunnen sites het tijdstip detecteren waarop een gebruiker inactief is, d.w.z. Heeft geen interactie met toetsenbord/muis en voert geen werkzaamheden uit op een andere monitor. Met de API kunt u ook achterhalen of er een schermbeveiliging op het systeem actief is of niet. Informatie over inactiviteit wordt uitgevoerd door het verzenden van een melding na het bereiken van een gespecificeerde inactiviteitsdrempel, waarvan de minimumwaarde is ingesteld op 1 minuut.
Het is belangrijk op te merken dat het gebruik van de Idle Detection API expliciete toekenning van gebruikersrechten vereist, d.w.z. Als de toepassing voor de eerste keer inactiviteit probeert te detecteren, krijgt de gebruiker een venster te zien waarin wordt gevraagd of hij toestemming moet verlenen of de bewerking moet blokkeren. Om de Idle Detection API volledig uit te schakelen, is er een speciale optie (“chrome://settings/content/idleDetection”) beschikbaar in het instellingengedeelte “Privacy en beveiliging”.
Toepassingsgebieden zijn onder meer chat-, sociale netwerken- en communicatietoepassingen die de status van de gebruiker kunnen veranderen afhankelijk van zijn aanwezigheid op de computer of de notificatie van nieuwe berichten kunnen uitstellen totdat de gebruiker arriveert. De API kan ook worden gebruikt in kiosktoepassingen om na een periode van inactiviteit terug te keren naar het oorspronkelijke scherm, of om resource-intensieve interactieve bewerkingen uit te schakelen, zoals het opnieuw tekenen van complexe, voortdurend bijgewerkte grafieken, wanneer de gebruiker niet achter de computer zit.
Het standpunt van tegenstanders van het inschakelen van de Idle Detection API is dat informatie over of de gebruiker achter de computer zit of niet als vertrouwelijk kan worden beschouwd. Naast nuttige toepassingen kan deze API ook voor slechte doeleinden worden gebruikt, bijvoorbeeld om kwetsbaarheden te misbruiken terwijl de gebruiker weg is of om opvallende kwaadaardige activiteiten, zoals mining, te verbergen. Met behulp van de betreffende API kan ook informatie over gebruikersgedragspatronen en het dagelijkse ritme van zijn werk worden verzameld. U kunt bijvoorbeeld achterhalen wanneer de gebruiker gewoonlijk gaat lunchen of de werkplek verlaat. In het kader van een verplicht verzoek om een bewijs van autorisatie worden deze zorgen door Google als onbeduidend ervaren.
Bovendien kunt u kennis nemen van de opmerking van de Chrome-ontwikkelaars over de promotie van nieuwe technieken om een veilige werking met geheugen te garanderen. Volgens Google wordt 70% van de beveiligingsproblemen in Chrome veroorzaakt door geheugenfouten, zoals het gebruik van een buffer na het vrijmaken van het bijbehorende geheugen (use-after-free). Er worden drie hoofdstrategieën voor het omgaan met dergelijke fouten geïdentificeerd: het versterken van de controles in de compilatiefase, het blokkeren van fouten tijdens runtime en het gebruik van een geheugenveilige taal.
Er wordt gemeld dat er experimenten zijn begonnen om de mogelijkheid toe te voegen om componenten in de Rust-taal aan de Chromium-codebase toe te voegen. De Rust-code is nog niet opgenomen in de builds die aan gebruikers worden geleverd en is vooral gericht op het testen van de mogelijkheid om afzonderlijke delen van de browser in Rust te ontwikkelen en hun integratie met andere delen geschreven in C++. Tegelijkertijd wordt voor C++-code een project ontwikkeld om het MiraclePtr-type te gebruiken in plaats van onbewerkte pointers om de mogelijkheid te blokkeren om kwetsbaarheden te misbruiken die worden veroorzaakt door toegang te krijgen tot reeds vrijgemaakte geheugenblokken, en er worden ook nieuwe methoden voorgesteld voor het detecteren van fouten in de compilatiefase.
Daarnaast start Google een experiment om de mogelijke verstoring van sites te testen nadat de browser een versie bereikt die bestaat uit drie cijfers in plaats van twee. In de testversies van Chrome 96 verscheen met name de instelling ‘chrome://flags#force-major-version-to-100’, indien gespecificeerd in de User-Agent-header, versie 100 (Chrome/100.0.4650.4) begint te worden weergegeven. In augustus werd een soortgelijk experiment uitgevoerd in Firefox, waarbij problemen aan het licht kwamen bij het verwerken van driecijferige versies op sommige sites.
Bron: opennet.ru