Standardinkluderingen av Idle Detection API i Chrome 94 har ført til en bølge av kritikk, med henvisning til innvendinger fra Firefox og WebKit/Safari-utviklere.
Idle Detection API lar nettsteder oppdage tidspunktet når en bruker er inaktiv, dvs. Samhandler ikke med tastatur/mus eller utfører arbeid på en annen skjerm. API-en lar deg også finne ut om en skjermsparer kjører på systemet eller ikke. Informasjon om inaktivitet utføres ved å sende et varsel etter å ha nådd en spesifisert inaktivitetsterskel, hvis minimumsverdi er satt til 1 minutt.
Det er viktig å merke seg at bruk av Idle Detection API krever eksplisitt tildeling av brukertillatelser, dvs. Hvis applikasjonen prøver å oppdage inaktivitet for første gang, vil brukeren bli presentert med et vindu som spør om de skal gi tillatelser eller blokkere operasjonen. For å deaktivere Idle Detection API fullstendig, er et spesielt alternativ ("chrome://settings/content/idleDetection") gitt i delen "Personvern og sikkerhet"-innstillinger.
Applikasjonsområder inkluderer chat, sosiale nettverk og kommunikasjonsapplikasjoner som kan endre brukerens status avhengig av hans tilstedeværelse ved datamaskinen eller forsinke varsling av nye meldinger til brukeren kommer. API-en kan også brukes i kioskapplikasjoner for å gå tilbake til den opprinnelige skjermen etter en periode med inaktivitet, eller for å deaktivere ressurskrevende interaktive operasjoner, som å tegne komplekse, stadig oppdatere diagrammer, når brukeren ikke er ved datamaskinen.
Posisjonen til motstandere av å aktivere Idle Detection API er at informasjon om hvorvidt brukeren er ved datamaskinen eller ikke kan betraktes som konfidensiell. I tillegg til nyttige applikasjoner kan denne API-en også brukes til dårlige formål, for eksempel for å prøve å utnytte sårbarheter mens brukeren er borte eller for å skjule iøynefallende ondsinnet aktivitet, for eksempel gruvedrift. Ved å bruke det aktuelle API-et kan informasjon om brukeradferdsmønstre og den daglige rytmen i arbeidet hans også samles inn. Du kan for eksempel finne ut når brukeren vanligvis går til lunsj eller forlater arbeidsplassen. I sammenheng med en obligatorisk forespørsel om bevis på autorisasjon, oppfattes disse bekymringene av Google som ubetydelige.
I tillegg kan du legge merke til notatet fra Chrome-utviklerne om promotering av nye teknikker for å sikre sikker drift med minne. Ifølge Google er 70 % av sikkerhetsproblemene i Chrome forårsaket av minnefeil, for eksempel bruk av en buffer etter frigjøring av minnet knyttet til den (bruk-etter-fri). Tre hovedstrategier for å håndtere slike feil er identifisert: styrking av sjekker på kompileringsstadiet, blokkering av feil ved kjøretid og bruk av et minnesikkert språk.
Det er rapportert at eksperimenter har begynt å legge til muligheten til å utvikle komponenter i Rust-språket til Chromium-kodebasen. Rust-koden er ennå ikke inkludert i byggene som leveres til brukerne og er hovedsakelig rettet mot å teste muligheten for å utvikle individuelle deler av nettleseren i Rust og deres integrasjon med andre deler skrevet i C++. Parallelt, for C++-kode, fortsetter et prosjekt å utvikle seg for å bruke MiraclePtr-typen i stedet for råpekere for å blokkere muligheten for å utnytte sårbarheter forårsaket av tilgang til allerede frigjorte minneblokker, og nye metoder for å oppdage feil på kompileringsstadiet foreslås også.
I tillegg starter Google et eksperiment for å teste mulig forstyrrelse av nettsteder etter at nettleseren når en versjon bestående av tre sifre i stedet for to. Spesielt i testversjonene av Chrome 96 dukket "chrome://flags#force-major-version-to-100"-innstillingen opp, når angitt i User-Agent-overskriften, versjon 100 (Chrome/100.0.4650.4) begynner å vises. I august ble et lignende eksperiment utført i Firefox, som avdekket problemer med å behandle tresifrede versjoner på enkelte nettsteder.
Kilde: opennet.ru