Standardinförandet av Idle Detection API i Chrome 94 har lett till en våg av kritik, med hänvisning till invändningar från Firefox och WebKit/Safari-utvecklare.
Idle Detection API tillåter webbplatser att upptäcka tiden när en användare är inaktiv, dvs. Interagerar inte med tangentbord/mus eller utför arbete på en annan bildskärm. API:et låter dig också ta reda på om en skärmsläckare körs på systemet eller inte. Information om inaktivitet utförs genom att skicka ett meddelande efter att ha nått en specificerad inaktivitetströskel, vars lägsta värde är satt till 1 minut.
Det är viktigt att notera att användningen av Idle Detection API kräver explicit beviljande av användarbehörigheter, d.v.s. Om applikationen försöker upptäcka inaktivitet för första gången kommer användaren att visas med ett fönster som frågar om de ska bevilja behörigheter eller blockera operationen. För att helt inaktivera Idle Detection API finns ett speciellt alternativ ("chrome://settings/content/idleDetection") i avsnittet "Sekretess och säkerhet" inställningar.
Tillämpningsområden inkluderar chatt, sociala nätverk och kommunikationsapplikationer som kan ändra användarens status beroende på hans närvaro vid datorn eller fördröja meddelanden om nya meddelanden tills användaren anländer. API:et kan också användas i kioskapplikationer för att återgå till den ursprungliga skärmen efter en period av inaktivitet, eller för att inaktivera resurskrävande interaktiva operationer, som att rita om komplexa, ständigt uppdaterade diagram, när användaren inte är vid datorn.
Motståndarnas inställning till att aktivera Idle Detection API är att information om huruvida användaren är vid datorn eller inte kan betraktas som konfidentiell. Förutom användbara applikationer kan detta API även användas för dåliga syften, till exempel för att försöka utnyttja sårbarheter medan användaren är borta eller för att dölja iögonfallande skadlig aktivitet, såsom gruvdrift. Med hjälp av det aktuella API:et kan även information om användarbeteendemönster och den dagliga rytmen i hans arbete samlas in. Du kan till exempel få reda på när brukaren brukar gå på lunch eller lämna arbetsplatsen. I samband med en obligatorisk begäran om bevis på auktorisation uppfattas dessa problem av Google som obetydliga.
Dessutom kan du notera meddelandet från Chrome-utvecklarna om marknadsföring av nya tekniker för att säkerställa säker drift med minne. Enligt Google orsakas 70 % av säkerhetsproblemen i Chrome av minnesfel, som att använda en buffert efter att ha frigjort minnet som är kopplat till den (use-after-free). Tre huvudstrategier för att hantera sådana fel identifieras: förstärkning av kontroller i kompileringsstadiet, blockering av fel vid körning och användning av ett minnessäkert språk.
Det rapporteras att experiment har börjat lägga till möjligheten att utveckla komponenter i språket Rust till Chromium-kodbasen. Rustkoden ingår ännu inte i de builds som levereras till användarna och syftar främst till att testa möjligheten att utveckla enskilda delar av webbläsaren i Rust och deras integration med andra delar skrivna i C++. Parallellt, för C++-kod, fortsätter ett projekt att utvecklas för att använda MiraclePtr-typen istället för råpekare för att blockera möjligheten att utnyttja sårbarheter orsakade av att komma åt redan frigjorda minnesblock, och nya metoder för att upptäcka fel i kompileringsstadiet föreslås också.
Dessutom startar Google ett experiment för att testa eventuella störningar av webbplatser efter att webbläsaren når en version bestående av tre siffror istället för två. I synnerhet, i testversionerna av Chrome 96, dök inställningen "chrome://flags#force-major-version-to-100" upp, när den specificerades i User-Agent-huvudet, version 100 (Chrome/100.0.4650.4) börjar visas. I augusti genomfördes ett liknande experiment i Firefox, som avslöjade problem med att bearbeta tresiffriga versioner på vissa webbplatser.
Källa: opennet.ru