Standardinkluderingen af Idle Detection API i Chrome 94 har ført til en bølge af kritik, med henvisning til indvendinger fra Firefox og WebKit/Safari-udviklere.
Idle Detection API giver websteder mulighed for at registrere tidspunktet, hvor en bruger er inaktiv, dvs. Interagerer ikke med tastatur/mus eller udfører arbejde på en anden skærm. API'et giver dig også mulighed for at finde ud af, om en pauseskærm kører på systemet eller ej. Information om inaktivitet udføres ved at sende en meddelelse efter at have nået en specificeret inaktivitetstærskel, hvis minimumsværdi er sat til 1 minut.
Det er vigtigt at bemærke, at brugen af Idle Detection API kræver eksplicit tildeling af brugertilladelser, dvs. Hvis applikationen forsøger at opdage inaktivitet for første gang, vil brugeren blive præsenteret for et vindue, der spørger, om han vil give tilladelser eller blokere handlingen. For fuldstændigt at deaktivere Idle Detection API, findes der en særlig mulighed ("chrome://settings/content/idleDetection") i afsnittet "Privatliv og sikkerhed".
Applikationsområder omfatter chat-, sociale netværks- og kommunikationsapplikationer, der kan ændre brugerens status afhængigt af hans tilstedeværelse ved computeren eller forsinke underretning om nye beskeder, indtil brugeren ankommer. API'et kan også bruges i kioskapplikationer til at vende tilbage til den originale skærm efter en periode med inaktivitet eller til at deaktivere ressourcekrævende interaktive operationer, såsom gentegning af komplekse, konstant opdatering af diagrammer, når brugeren ikke er ved computeren.
Holdningen for modstandere af at aktivere Idle Detection API er, at oplysninger om, hvorvidt brugeren er ved computeren eller ej, kan betragtes som fortrolige. Ud over nyttige applikationer kan denne API også bruges til dårlige formål, for eksempel til at forsøge at udnytte sårbarheder, mens brugeren er væk, eller til at skjule iøjnefaldende ondsindet aktivitet, såsom minedrift. Ved hjælp af det pågældende API kan der også indsamles oplysninger om brugeradfærdsmønstre og den daglige rytme i hans arbejde. Du kan for eksempel finde ud af, hvornår brugeren normalt går til frokost eller forlader arbejdspladsen. I forbindelse med en obligatorisk anmodning om bevis for autorisation opfattes disse bekymringer af Google som ubetydelige.
Derudover kan du notere notatet fra Chrome-udviklerne om promovering af nye teknikker til at sikre sikker drift med hukommelse. Ifølge Google er 70 % af sikkerhedsproblemerne i Chrome forårsaget af hukommelsesfejl, såsom brug af en buffer efter frigørelse af den hukommelse, der er knyttet til den (brug-efter-fri). Tre hovedstrategier til håndtering af sådanne fejl er identificeret: styrkelse af kontroller på kompileringsstadiet, blokering af fejl under kørsel og brug af et hukommelsessikkert sprog.
Det er rapporteret, at eksperimenter er begyndt at tilføje evnen til at udvikle komponenter i Rust-sproget til Chromium-kodebasen. Rust-koden er endnu ikke inkluderet i de builds, der leveres til brugerne og er hovedsageligt rettet mod at teste muligheden for at udvikle individuelle dele af browseren i Rust og deres integration med andre dele skrevet i C++. Parallelt hermed, for C++-kode, fortsætter et projekt med at udvikle sig for at bruge MiraclePtr-typen i stedet for rå pointere til at blokere muligheden for at udnytte sårbarheder forårsaget af adgang til allerede frigjorte hukommelsesblokke, og nye metoder til at opdage fejl på kompileringsstadiet foreslås også.
Derudover starter Google et eksperiment for at teste den mulige forstyrrelse af websteder, efter at browseren når en version bestående af tre cifre i stedet for to. Især i testudgivelserne af Chrome 96 optrådte indstillingen "chrome://flags#force-major-version-to-100", når den var angivet i User-Agent-headeren, version 100 (Chrome/100.0.4650.4) begynder at blive vist. I august blev der udført et lignende eksperiment i Firefox, som afslørede problemer med at behandle trecifrede versioner på nogle websteder.
Kilde: opennet.ru