Standardaktiveringen af API Idle Detection i Chrome 94 har medført en bølge af kritik med henvisninger til indvendinger fra udviklere af Firefox og WebKit/Safari.
API Idle Detection gør det muligt for hjemmesider at bestemme, hvornår brugeren er inaktiv, dvs. ikke interagerer med tastaturet/musen eller arbejder på en anden skærm. API'et kan også registrere, om der kører en skærmsk saver på systemet. Information om inaktivitet gives ved at sende en meddelelse efter at en bestemt inaktivitetsgrænse er nået, hvor den minimale værdi er sat til 1 minut.
Det er vigtigt at bemærke, at brugen af API Idle Detection kræver eksplicit brugerautorisation, dvs. hvis applikationen forsøger for første gang at registrere inaktivitet, vil brugeren få vist et vindue, der beder om at give tilladelse eller blokere operationen. For at deaktivere API Idle Detection helt er der en speciel indstilling under 'Privatliv og sikkerhed' ('chrome://settings/content/idleDetection').
Anvendelsesområderne inkluderer chat-, sociale medier- og kommunikationsapplikationer, der kan ændre brugerens status afhængigt af, om han/hun er til stede ved computeren, eller udskyde visningen af meddelelser om nye beskeder, indtil brugeren er til stede. API'et kan også bruges i kiosk-applikationer til at returnere til startskærmen efter en bestemt periode med inaktivitet eller til at deaktivere ressourcekrævende interaktive operationer, såsom omtegning af komplekse, konstant opdaterede diagrammer, når brugeren ikke er ved computeren.
Modstanden mod aktiveringen af API Idle Detection er baseret på, at oplysninger om, hvorvidt en bruger er ved computeren eller ej, kan betragtes som fortrolige. Udover nyttige anvendelser kan dette API også bruges til mindre gode formål, såsom at forsøge at udnytte sårbarheder, mens brugeren ikke er til stede, eller til at skjule iøjnefaldende ondsindet aktivitet, som for eksempel mining. Dette API kan også bruges til at indsamle oplysninger om brugerens adfærdsmønstre og daglige arbejdrutiner. For eksempel kan det afsløres, hvornår en bruger typisk går til frokost eller forlader arbejdspladsen. Under betingelse af, at der er krav om bekræftelse af beføjelser, betragter Google disse bekymringer som uvæsentlige.
Derudover kan man nævne Chrome-udviklernes bemærkning om fremme af nye teknikker til sikring af sikker hukommelsesbrug. Ifølge Google skyldes 70 % af sikkerhedsproblemerne i Chrome fejl i håndteringen af hukommelsen, såsom adgang til en buffer efter frigivelsen af den tilknyttede hukommelse (use-after-free). Der er tre grundlæggende strategier til bekæmpelse af sådanne fejl: styrkede kontroller i kompileringstrinnet, blokering af fejl under kørsel og anvendelse af et sprog, der sikrer sikker hukommelsesbrug.
Det rapporteres, at eksperimenter med at integrere muligheden for at udvikle komponenter i Rust-sprog i Chromium-kodebasen er begyndt. Rust-koden indgår endnu ikke i de livsbevarende versioner til brugerne og er primært rettet mod at teste muligheden for at udvikle enkelte dele af browseren i Rust og deres integration med de andre dele, der er skrevet i C++. Samtidig fortsætter udviklingen af et projekt til C++-koden, der anvender MiraclePtr-typen i stedet for rå pointere for at forhindre udnyttelse af sårbarheder forårsaget af adgang til allerede frigivne hukommelsesblokke, ligesom der foreslås nye metoder til fejlfinding under kompilering.
Desuden påbegynder Google et eksperiment for at teste mulige driftsforstyrrelser på websteder, når browseren når en version, der består af tre cifre i stedet for to. Specifikt er der i testudgivelserne af Chrome 96 blevet tilføjet en indstilling "chrome://flags#force-major-version-to-100", som, når den aktiveres, viser version 100 (Chrome/100.0.4650.4) i User-Agent headeren. I august blev et lignende eksperiment udført i Firefox, som afslørede problemer med behandlingen af trecifrede versioner på nogle websteder.
Kilde: opennet.ru
