API voor inactieve detectie in Chrome 94 heeft geleid tot een golf van kritiek

Bij de lancering van Chrome-versie 94 se maakte de standaard opname van de inactieve detectie-API, dat heeft geleid tot een golf van kritiek met links naar bezwaren van de ontwikkelaars van Firefox en WebKit/Safari.

De API voor inactieve detectie stelt sites in staat om te detecteren wanneer een gebruiker inactief is, dat wil zeggen, het heeft geen interactie met het toetsenbord / de muis of werkt op een andere monitor. De API laat u ook weten of de schermbeveiliging op het systeem actief is of niet. Inactiviteitsmelding wordt gedaan door een melding te verzenden na het bereiken van een vooraf bepaalde inactiviteitsdrempel, waarvan de minimumwaarde is ingesteld op 1 minuut.

Het is belangrijk om in gedachten te houden dat het gebruik van de API voor inactieve detectie vereist expliciete toekenning van gebruikersreferenties, dat wil zeggen, als de toepassing voor de eerste keer probeert vast te stellen of er sprake is van inactiviteit, krijgt de gebruiker een venster te zien met een voorstel om machtigingen te verlenen of de bewerking te blokkeren.

Chat-applicaties, sociale netwerken en communicatie worden toepassingen genoemd, die: kan de status van de gebruiker wijzigen op basis van hun aanwezigheid op de computer of de weergave van meldingen uitstellen van nieuwe berichten tot de komst van de gebruiker.

De API kan ook in andere toepassingen worden gebruikt om terug te keren naar het oorspronkelijke scherm na een bepaalde periode van inactiviteit, of om interactieve, resource-intensieve bewerkingen uit te schakelen, zoals het opnieuw tekenen van complexe grafieken die voortdurend worden bijgewerkt wanneer de gebruiker niet op het scherm is. computer.

De positie van degenen die zich verzetten tegen het inschakelen van de API inactieve detectie het komt erop neer dat informatie over het al dan niet achter de computer zitten van de gebruiker als vertrouwelijk kan worden beschouwd. Naast nuttig gebruik kan deze API ook niet voor goede doeleinden worden gebruikt, bijvoorbeeld om te proberen kwetsbaarheden te misbruiken terwijl de gebruiker weg is of om zichtbare kwaadwillende activiteiten, zoals mining, te verbergen.

Met behulp van de betreffende API, informatie over gedragspatronen kan ook worden verzameld van de gebruiker en het dagelijkse ritme van zijn werk. U kunt bijvoorbeeld achterhalen wanneer een gebruiker meestal gaat lunchen of de werkplek verlaat. In het kader van een verplicht bevestigingsverzoek voor autorisatie beschouwt Google deze zorgen als irrelevant.

Om de API voor inactieve detectie volledig uit te schakelen, is er een speciale optie voorzien in het gedeelte "Privacy en beveiliging" van de instellingen ("chrome: // settings / content / idleDetection").

Bovendien heeft We moeten rekening houden met een opmerking van de Chrome-ontwikkelaars over de vooruitgang van nieuwe technieken om veilig geheugenbeheer te garanderen. Volgens Google wordt 70% van de beveiligingsproblemen in Chrome veroorzaakt door geheugenfouten, zoals gebruik na vrije toegang tot een buffer. Er worden drie hoofdstrategieën onderscheiden om met dergelijke fouten om te gaan: het aanscherpen van de compile-time-controles, het blokkeren van runtime-fouten en het gebruik van een geheugenveilige taal.

Het is gemeld dat experimenten zijn begonnen met het toevoegen van de mogelijkheid om componenten in de Rust-taal te ontwikkelen aan de Chromium-codebase. De Rust-code is nog niet opgenomen in de compilaties die aan gebruikers worden geleverd en het belangrijkste doel is om de mogelijkheid te testen om afzonderlijke delen van de browser in Rust te ontwikkelen en deze te integreren met de rest van de delen die zijn geschreven in C ++.

Tegelijkertijd blijft het project voor de C ++ -code zich ontwikkelen met behulp van het MiraclePtr-type in plaats van onbewerkte aanwijzers om de mogelijkheid van misbruik van kwetsbaarheden te blokkeren die worden veroorzaakt door toegang tot reeds vrijgemaakte geheugenblokken, en worden nieuwe methoden voorgesteld om fouten in de fase te detecteren compilatie.

Bovendien heeft Google start een experiment om mogelijke uitval van de site te testen nadat de browser een driecijferige versie heeft bereikt in plaats van twee.

In het bijzonder verscheen de instelling "chrome: // flags # force-major-version-to-100" in de Chrome 96-proefversies, indien gespecificeerd in de User-Agent-header, zal versie 100 (Chrome / 100.0.4650.4. XNUMX) zijn weergegeven. In augustus werd een soortgelijk experiment uitgevoerd in Firefox, dat problemen aan het licht bracht met de verwerking van driecijferige versies op sommige sites.


Een opmerking, laat de jouwe achter

Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: Miguel Ángel Gatón
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.

  1.   jero zei

    Hallo. Heel erg bedankt voor deze route chrome://settings/content/idleDetection, dat is de sleutel tot de kern, daar deactiveer je het of laat je het geactiveerd, maar als het niet via die route is, om het te vinden, zie je ze en je wilt ze, het is super verborgen.

    Groeten.

    chrome://settings/content/idleDetection