Standardaktiveringen af API Idle Detection i Chrome 94 har medf\u00f8rt en b\u00f8lge af kritik med henvisninger til indvendinger fra udviklere af Firefox og WebKit\/Safari. <\/p>\n
API Idle Detection g\u00f8r det muligt for hjemmesider at bestemme, hvorn\u00e5r brugeren er inaktiv, dvs. ikke interagerer med tastaturet\/musen eller arbejder p\u00e5 en anden sk\u00e6rm. API'et kan ogs\u00e5 registrere, om der k\u00f8rer en sk\u00e6rmsk saver p\u00e5 systemet. Information om inaktivitet gives ved at sende en meddelelse efter at en bestemt inaktivitetsgr\u00e6nse er n\u00e5et, hvor den minimale v\u00e6rdi er sat til 1 minut. <\/p>\n
Det er vigtigt at bem\u00e6rke, at brugen af API Idle Detection kr\u00e6ver en eksplicit bevilgning fra brugeren. Det vil sige, hvis applikationen fors\u00f8ger at bestemme inaktivitet for f\u00f8rste gang, vil brugeren se et vindue, der beder om at give bevilgning eller blokere operationen. For helt at deaktivere API Idle Detection er der en specifik mulighed i indstillingsafsnittet \"Privatliv og sikkerhed\" (\"chrome:\/\/settings\/content\/idleDetection\"). <\/p>\n
Anvendelsesomr\u00e5derne inkluderer chat-, sociale medier- og kommunikationsapplikationer, der kan \u00e6ndre brugerens status afh\u00e6ngigt 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\u00e5 bruges i kiosk-applikationer til at returnere til startsk\u00e6rmen efter en bestemt periode med inaktivitet eller til at deaktivere ressourcekr\u00e6vende interaktive operationer, s\u00e5som omtegning af komplekse, konstant opdaterede diagrammer, n\u00e5r brugeren ikke er ved computeren. <\/p>\n
Modstanden mod aktiveringen af API Idle Detection er baseret p\u00e5, at oplysninger om, hvorvidt en bruger er ved computeren eller ej, kan betragtes som fortrolige. Udover nyttige anvendelser kan dette API ogs\u00e5 bruges til mindre gode form\u00e5l, s\u00e5som at fors\u00f8ge at udnytte s\u00e5rbarheder, mens brugeren ikke er til stede, eller til at skjule i\u00f8jnefaldende ondsindet aktivitet, som for eksempel mining. Dette API kan ogs\u00e5 bruges til at indsamle oplysninger om brugerens adf\u00e6rdsm\u00f8nstre og daglige arbejdrutiner. For eksempel kan det afsl\u00f8res, hvorn\u00e5r en bruger typisk g\u00e5r til frokost eller forlader arbejdspladsen. Under betingelse af, at der er krav om bekr\u00e6ftelse af bef\u00f8jelser, betragter Google disse bekymringer som uv\u00e6sentlige. <\/p>\n
Derudover kan man n\u00e6vne Chrome-udviklernes bem\u00e6rkning om fremme af nye teknikker til sikring af sikker hukommelsesbrug. If\u00f8lge Google skyldes 70 % af sikkerhedsproblemerne i Chrome fejl i h\u00e5ndteringen af hukommelsen, s\u00e5som adgang til en buffer efter frigivelsen af den tilknyttede hukommelse (use-after-free). Der er tre grundl\u00e6ggende strategier til bek\u00e6mpelse af s\u00e5danne fejl: styrkede kontroller i kompileringstrinnet, blokering af fejl under k\u00f8rsel og anvendelse af et sprog, der sikrer sikker hukommelsesbrug. <\/p>\n
Det rapporteres, at eksperimenter med at integrere muligheden for at udvikle komponenter i Rust-sprog i Chromium-kodebasen er begyndt. Rust-koden indg\u00e5r endnu ikke i de livsbevarende versioner til brugerne og er prim\u00e6rt 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\u00e6tter udviklingen af et projekt til C++-koden, der anvender MiraclePtr-typen i stedet for r\u00e5 pointere for at forhindre udnyttelse af s\u00e5rbarheder for\u00e5rsaget af adgang til allerede frigivne hukommelsesblokke, ligesom der foresl\u00e5s nye metoder til fejlfinding under kompilering. <\/p>\n