Kritiek op die aktivering van die Idle Detection API in Chrome 94. Eksperimenteer met roes in Chrome

Die verstek-insluiting van die Idle Detection API in Chrome 94 het gelei tot 'n golf van kritiek, met verwysing na besware van Firefox en WebKit/Safari-ontwikkelaars.

Die Idle Detection API laat webwerwe toe om die tyd op te spoor wanneer 'n gebruiker onaktief is, d.w.s. Werk nie met sleutelbord/muis of werk op 'n ander monitor nie. Die API laat jou ook toe om uit te vind of 'n skermbewaarder op die stelsel loop of nie. Inligting oor onaktiwiteit word uitgevoer deur 'n kennisgewing te stuur nadat 'n gespesifiseerde onaktiwiteitsdrempel bereik is, waarvan die minimum waarde op 1 minuut gestel is.

Dit is belangrik om daarop te let dat die gebruik van die Idle Detection API eksplisiete toekenning van gebruikertoestemmings vereis, d.w.s. As die toepassing vir die eerste keer probeer om onaktiwiteit op te spoor, sal die gebruiker 'n venster kry wat vra of toestemming moet verleen of die operasie moet blokkeer. Om die Idle Detection API heeltemal te deaktiveer, word 'n spesiale opsie ("chrome://settings/content/idleDetection") in die "Privaatheid en sekuriteit" instellings afdeling verskaf.

Toepassingsareas sluit klets-, sosiale netwerk- en kommunikasietoepassings in wat die gebruiker se status kan verander na gelang van sy teenwoordigheid by die rekenaar of kennisgewing van nuwe boodskappe kan vertraag totdat die gebruiker opdaag. Die API kan ook in kiosk-toepassings gebruik word om na 'n tydperk van onaktiwiteit terug te keer na die oorspronklike skerm, of om hulpbron-intensiewe interaktiewe bedrywighede te deaktiveer, soos om komplekse te herteken, konstante opdatering van kaarte, wanneer die gebruiker nie by die rekenaar is nie.

Die posisie van teenstanders om die Idle Detection API te aktiveer, is dat inligting oor of die gebruiker by die rekenaar is of nie as vertroulik beskou kan word. Benewens nuttige toepassings, kan hierdie API ook vir slegte doeleindes gebruik word, byvoorbeeld om kwesbaarhede te probeer uitbuit terwyl die gebruiker weg is of om opvallende kwaadwillige aktiwiteite, soos mynbou, te verberg. Deur die betrokke API te gebruik, kan inligting oor gebruikersgedragspatrone en die daaglikse ritme van sy werk ook ingesamel word. Jy kan byvoorbeeld uitvind wanneer die gebruiker gewoonlik middagete gaan eet of die werkplek verlaat. In die konteks van 'n verpligte versoek om bewys van magtiging, word hierdie bekommernisse deur Google as onbeduidend beskou.

Daarbenewens kan u kennis neem van die nota van die Chrome-ontwikkelaars oor die bevordering van nuwe tegnieke om veilige werking met geheue te verseker. Volgens Google word 70% van sekuriteitsprobleme in Chrome deur geheuefoute veroorsaak, soos om 'n buffer te gebruik nadat die geheue wat daarmee geassosieer is vrygestel is (gebruik-na-vry). Drie hoofstrategieë vir die hantering van sulke foute word geïdentifiseer: versterking van kontroles by die samestellingstadium, blokkering van foute tydens looptyd en die gebruik van 'n geheue-veilige taal.

Daar word berig dat eksperimente begin het om die vermoë om komponente in die Rust-taal te ontwikkel by die Chromium-kodebasis te voeg. Die Rust-kode is nog nie ingesluit by die bouwerk wat aan gebruikers gelewer word nie en is hoofsaaklik daarop gemik om die moontlikheid te toets om individuele dele van die blaaier in Rust te ontwikkel en hul integrasie met ander dele wat in C++ geskryf is. Terselfdertyd, vir C++-kode, gaan 'n projek voort om te ontwikkel om die MiraclePtr-tipe te gebruik in plaas van rou wysers om die moontlikheid te blokkeer om kwesbaarhede wat veroorsaak word deur toegang te verkry tot reeds vrygemaakte geheueblokke, te blokkeer, en nuwe metodes om foute by die samestellingstadium op te spoor word ook voorgestel.

Boonop begin Google 'n eksperiment om die moontlike ontwrigting van werwe te toets nadat die blaaier 'n weergawe bereik wat uit drie syfers in plaas van twee bestaan. Veral, in die toetsvrystellings van Chrome 96, het die "chrome://flags#force-major-version-to-100"-instelling verskyn, wanneer gespesifiseer in die User-Agent-opskrif, weergawe 100 (Chrome/100.0.4650.4) begin vertoon word. In Augustus is 'n soortgelyke eksperiment in Firefox uitgevoer, wat probleme met die verwerking van driesyferweergawes op sommige werwe aan die lig gebring het.

Bron: opennet.ru

Voeg 'n opmerking