La defaŭlta inkludo de la Idle Detection API en Chrome 94 kaŭzis ondon de kritiko, citante obĵetojn de Firefox kaj WebKit/Safari-programistoj.
La Idle Detection API permesas al retejoj detekti la tempon kiam uzanto estas neaktiva, t.e. Ne interagas per klavaro/muso aŭ ne faras laboron sur alia ekrano. La API ankaŭ ebligas al vi ekscii ĉu ekranŝparo funkcias en la sistemo aŭ ne. Informoj pri neaktiveco estas efektivigita sendante sciigon post atingi specifitan senaktivecsojlon, kies minimuma valoro estas agordita al 1 minuto.
Gravas noti, ke la uzo de la Idle Detection API postulas eksplicitan donadon de uzantpermesoj, t.e. Se la aplikaĵo provas detekti neaktivecon por la unua fojo, la uzanto estos prezentita kun fenestro demandanta ĉu doni permesojn aŭ bloki la operacion. Por tute malŝalti la Idle Detection API, speciala opcio ("chrome://settings/content/idleDetection") estas provizita en la sekcio de agordoj "Privateco kaj Sekureco".
Aplikaj areoj inkluzivas babilejon, sociajn retojn kaj komunikajn aplikojn, kiuj povas ŝanĝi la statuson de la uzanto depende de lia ĉeesto ĉe la komputilo aŭ prokrasti sciigon pri novaj mesaĝoj ĝis la uzanto alvenos. La API ankaŭ povas esti uzata en kioskaj aplikoj por reveni al la origina ekrano post periodo de neaktiveco, aŭ por malŝalti rimedintensajn interagajn operaciojn, kiel redesegnado de kompleksaj, konstante ĝisdatigantaj leterojn, kiam la uzanto ne estas ĉe la komputilo.
La pozicio de kontraŭuloj de ebligi la Idle Detection API estas, ke informoj pri ĉu la uzanto estas ĉe la komputilo aŭ ne povas esti konsiderataj konfidencaj. Krom utilaj aplikoj, ĉi tiu API ankaŭ povas esti uzata por malbonaj celoj, ekzemple, por provi ekspluati vundeblecojn dum la uzanto estas for aŭ por kaŝi evidentan malican aktivecon, kiel minado. Uzante la koncernan API, oni povas ankaŭ kolekti informojn pri uzantaj kondutpadronoj kaj la ĉiutaga ritmo de lia laboro. Ekzemple, vi povas ekscii, kiam la uzanto kutime iras tagmanĝi aŭ forlasas la laborejon. En la kunteksto de deviga peto por pruvo de rajtigo, ĉi tiuj zorgoj estas perceptitaj de Guglo kiel sensignifaj.
Aldone, vi povas noti la noton de la programistoj de Chrome pri la promocio de novaj teknikoj por certigi sekuran funkciadon per memoro. Laŭ Guglo, 70% de sekurecproblemoj en Chrome estas kaŭzitaj de memoreraroj, kiel ekzemple uzado de bufro post liberigo de la memoro asociita kun ĝi (use-after-free). Tri ĉefaj strategioj por trakti tiajn erarojn estas identigitaj: plifortigo de kontroloj en la kompilfazo, blokado de eraroj ĉe rultempo, kaj uzado de memorsekura lingvo.
Estas raportite ke eksperimentoj komenciĝis aldoni la kapablon evoluigi komponentojn en la Rust-lingvo al la Chromium-kodbazo. La Rust-kodo ankoraŭ ne estas inkluzivita en la konstruaĵoj liveritaj al uzantoj kaj ĉefe celas provi la eblecon evoluigi individuajn partojn de la retumilo en Rust kaj ilian integriĝon kun aliaj partoj skribitaj en C++. Paralele, por C++-kodo, daŭre disvolviĝas projekto por uzi la tipon MiraclePtr anstataŭ krudaj montriloj por bloki la eblecon ekspluati vundeblecojn kaŭzitajn de aliro al jam liberigitaj memorblokoj, kaj ankaŭ estas proponitaj novaj metodoj por detekti erarojn en la kompila stadio.
Krome, Google komencas eksperimenton por testi la eblan interrompon de retejoj post kiam la retumilo atingas version konsistantan el tri ciferoj anstataŭ du. Aparte, en la testaj eldonoj de Chrome 96, la agordo "chrome://flags#force-major-version-to-100" aperis, kiam specifite en la kaplinio de Uzanto-Agente, versio 100 (Chrome/100.0.4650.4) komencas esti montrata. En aŭgusto, simila eksperimento estis farita en Fajrovulpo, kiu malkaŝis problemojn pri prilaborado de triciferaj versioj en iuj retejoj.
fonto: opennet.ru