door Martin Brinkmann op 22 september 2021 in Google Chrome – 4 reacties
Google Chrome 94 is uit en met de browser komt een nieuwe controversiële functie: de Idle Detection API. Zoals de naam al doet vermoeden, kan het door sites worden geïmplementeerd om erachter te komen of een gebruiker inactief is. Inactief betekent dat de gebruiker geen interactie heeft gehad met het apparaat of specifieke hardware, zoals het toetsenbord of de muis, of via bepaalde systeemgebeurtenissen, zoals het starten van een schermbeveiliging of vergrendelde status.
Voorbeelden van use-cases zijn het gebruik van de API om te weten of contacten in chat of op sociale netwerksites op dat moment bereikbaar zijn, automatisch herstarten van kiosk-applicaties als er gedurende een bepaalde periode geen gebruikersinteractie wordt opgemerkt, of “apps die dure berekeningen vereisen” die deze beperken tot momenten met gebruikersinteractie. De nieuwste versie van de API vereist expliciete toestemming van de gebruiker voordat sites deze kunnen gebruiken.
< p>Google implementeerde de functionaliteit in Chrome 94, die het bedrijf deze week uitbracht. Mozilla en Apple hebben bezwaar tegen de integratie van de Idle Detection API en zullen deze niet implementeren in Firefox en Safari.
Mozilla heeft “zorgen voor gebruikerstoezicht en gebruikerscontrole” over de API, omdat het ” kan worden gebruikt om de gebruikspatronen van een gebruiker te controleren en dienovereenkomstig te manipuleren”.
Zoals het momenteel is gespecificeerd, beschouw ik de Idle Detection API als een te verleidelijke mogelijkheid voor door surveillancekapitalisme gemotiveerde websites om een aspect van de fysieke privacy van de gebruiker binnen te vallen, langdurige registraties bij te houden van fysiek gebruikersgedrag, het onderscheiden van dagelijkse ritmes (bijv. lunchtijd) en het gebruik van dat voor proactieve psychologische manipulatie (bijv. honger, emotie, keuze [1][2][3]). Bovendien kunnen dergelijke grove patronen door websites worden gebruikt om op slinkse wijze lokale computerbronnen te benutten voor proof-of-work-berekeningen, waarbij elektriciteit wordt verspild (kosten voor de gebruiker, grotere ecologische voetafdruk) zonder de toestemming van de gebruiker of misschien zelfs wel bewust.
Mozilla publiceerde een formele afwijzing van het voorstel. Daarin stelt de organisatie voor om verzoeken te laten vallen waarin slechts één implementeerder interesse heeft getoond, en stelt dat de situatie zou kunnen evolueren naar een “single-implementation spec”.
We verzoeken om het schrappen van specs die interesse hebben getoond van slechts één implementeerder, anders lopen we het risico van een single-implementatie specificatie, die alleen zal dienen als documentatie (dwz niet een echte open standaard), omdat we weten dat op monocultuur gebaseerde standaarden uiteindelijk wordt het de facto, op basis van de details, bugs, interpretaties van die ene specifieke implementatie, en niet wat er in een specificatie is geschreven.
Apple publiceerde zijn officiële reactie op de Webkit-mailinglijst. Het WebKit-team van het bedrijf ziet geen “sterk genoeg” gebruiksscenario's voor het implementeren van de API.
Ik stop op dit moment met reageren op deze thread omdat geen van de hier gepresenteerde gebruiksscenario's of elders zijn dwingend, en geen van de privacy- of beveiligingsbeperkingen die u hier hebt gepresenteerd en die ik elders heb gevonden, is voldoende. Het niet reageren op deze thread of toekomstige thread over dit onderwerp betekent echter niet dat we ons standpunt zouden heroverwegen. Tenzij er een significante nieuwe ontwikkeling wordt gemaakt in een van de problemen die we hebben aangekaart, blijft ons standpunt om bezwaar te maken tegen de toevoeging van deze API, tenzij anders vermeld, ongeacht of we dit in het openbaar blijven zeggen of niet.
Chromium-gebaseerde browsers zullen uiteindelijk de nieuwe API ondersteunen, tenzij deze handmatig wordt verwijderd door het ontwikkelteam of wordt uitgeschakeld.