av Martin Brinkmann 22. september 2021 i Google Chrome – 12 kommentarer
Google Chrome 94 er ute, og med nettleseren kommer en ny kontroversiell funksjon: Idle Detection API. Som navnet antyder, kan det implementeres av nettsteder for å finne ut om en bruker er inaktiv. Inaktiv betyr at brukeren ikke har interagert med enheten eller spesifikk maskinvare, for eksempel tastaturet eller musen, eller gjennom visse systemhendelser, for eksempel lansering av en skjermsparer eller låst status.
Eksempel på brukstilfeller inkluderer bruk av API for å vite om kontakter i chat eller på sosiale nettverk kan nås på den tiden, automatisk omstart av kioskapplikasjoner hvis det ikke blir lagt merke til brukerinteraksjon i en periode, eller “apper som krever dyre beregninger” som begrenser disse til øyeblikk med brukerinteraksjon. Den siste iterasjonen av API krever eksplisitt tillatelse fra brukeren før nettstedene kan bruke den.
< p>Google implementerte funksjonaliteten i Chrome 94, som selskapet ga ut denne uken. Mozilla og Apple protesterer mot integreringen av Idle Detection API, og vil ikke implementere det i Firefox og Safari.
Mozilla har “brukerovervåking og brukerkontroll bekymringer” om API, som det ” kan brukes til å overvåke en brukers bruksmønstre, og manipulere dem deretter “.
Som det er spesifisert for øyeblikket, anser jeg Idle Detection API som for fristende for en mulighet for overvåkningskapitalismemotiverte nettsteder til å invadere et aspekt av brukerens fysiske personvern, føre langsiktige registreringer av fysisk brukeratferd, kresne daglige rytmer (f.eks. Lunsjtid) og bruke det for proaktiv psykologisk manipulasjon (f.eks. sult, følelser, valg [1] [2] [3]). I tillegg kan slike grove mønstre brukes av nettsteder for å maksimalt maksimere lokale beregningsressurser for beregninger som kan bevises på arbeidet, sløse med strøm (kostnad for bruker, øke karbonavtrykk) uten brukerens samtykke eller kanskje til og med bevissthet.
Mozilla publiserte en formell avvisning av forslaget. I den foreslår organisasjonen å droppe forespørsler som bare én implementer har vist interesse for, og uttaler at situasjonen kan risikere å utvikle seg til en “spesifikasjon for enkelt implementering”.
Vi ber om at spesifikasjoner som har vist interesse fra bare én implementer, slippes, ellers risikerer vi en spesifikasjon for én implementering, som bare noen gang vil tjene som dokumentasjon (dvs. ikke en faktisk åpen standard), ettersom vi vet at monokulturbaserte standarder ende opp med å bli de facto, basert på den spesifikke implementeringens detaljer, feil, tolkninger og ikke det som er skrevet i en spesifikasjon.
Apple publiserte sitt offisielle svar på Webkit-postlisten. Selskapets WebKit -team ser ikke “sterk nok” brukstilfeller for implementering av API.
Jeg kommer til å slutte å svare på denne tråden på dette tidspunktet, fordi ingen av brukstilfellene presenteres her eller andre steder er overbevisende, og ingen av personvern- eller sikkerhetsreduseringene du har presentert her, og jeg fant andre steder, er tilstrekkelige. Imidlertid betyr ikke å svare på denne tråden eller fremtidig tråd om dette emnet ikke at vi ville revurdere vår posisjon. Med mindre det blir gjort en betydelig ny utvikling i et av problemene vi har tatt opp, vil vår posisjon fortsatt være å protestere mot tillegg av denne API -en med mindre annet er angitt, uansett om vi fortsetter å si det offentlig eller ikke.
Krombaserte nettlesere støtter det nye API-et til slutt, med mindre det fjernes manuelt av utviklingsteamet eller deaktiveres.