Ang idle detection API sa Chrome 94 ay nag-umpisa ng isang pasaway

Sa paglulunsad ng Chrome bersyon 94 se ginawa ang default na pagsasama ng idle detection API, na kung saan ay sparked isang alon ng pagpuna sa mga link sa pagtutol mula sa mga developer ng Firefox at WebKit / Safari.

Ang idle detection API pinapayagan ang mga site na makita kung ang isang gumagamit ay hindi aktibo, iyon ay, hindi ito nakikipag-ugnay sa keyboard / mouse o gumagana sa ibang monitor. Ipinapaalam din sa iyo ng API kung ang screen saver ay tumatakbo sa system o hindi. Ang abiso sa hindiaktibo ay ginagawa sa pamamagitan ng pagpapadala ng isang abiso matapos maabot ang isang paunang natukoy na threshold ng hindi aktibo, ang minimum na halaga na nakatakda sa 1 minuto.

Mahalagang bigyang pansin ang paggamit ng idle detection API ay nangangailangan ng tahasang pagbibigay ng mga kredensyal ng gumagamit, iyon ay, kung susubukan ng application na matukoy ang katotohanan ng pagiging hindi aktibo sa kauna-unahang pagkakataon, ipapakita ang gumagamit ng isang window na may isang panukala upang magbigay ng mga pahintulot o harangan ang operasyon.

Mga application ng chat, ang mga social network at komunikasyon ay tinatawag na application, kung saan maaaring baguhin ang katayuan ng gumagamit batay sa kanilang pagkakaroon sa computer o ipagpaliban ang pagpapakita ng mga abiso ng mga bagong mensahe hanggang sa pagdating ng gumagamit.

Maaari ding magamit ang API sa iba pang mga application upang bumalik sa orihinal na screen pagkatapos ng isang tukoy na panahon ng kawalan ng aktibo, o upang hindi paganahin ang interactive, mapagpatakbo na mapagkukunan na mapagkukunan, tulad ng muling paggawa ng mga kumplikadong tsart na patuloy na na-update kapag ang gumagamit ay wala sa screen. computer

Ang posisyon ng mga tumututol sa pagpapagana ng API hindi aktibo na pagtuklas napupunta ito sa katotohanan na ang impormasyon tungkol sa kung ang gumagamit ay nasa computer o hindi ay maaaring maituring na kumpidensyal. Bilang karagdagan sa mga kapaki-pakinabang na paggamit, maaari ding magamit ang API na ito hindi para sa mabubuting layunin, halimbawa, upang subukang pagsamantalahan ang mga kahinaan habang wala ang gumagamit o upang maitago ang nakikitang nakakahamak na aktibidad, tulad ng pagmimina.

Gamit ang pinag-uusapan na API, ang impormasyon tungkol sa mga pattern ng pag-uugali ay maaari ding kolektahin ng gumagamit at ang pang-araw-araw na ritmo ng kanilang trabaho. Halimbawa, maaari mong malaman kapag ang isang gumagamit ay karaniwang pumupunta sa tanghalian o umalis sa lugar ng trabaho. Sa konteksto ng isang sapilitan kahilingan sa kumpirmasyon ng pagpapahintulot, nakikita ng Google ang mga alalahaning ito bilang hindi nauugnay.

Upang ganap na huwag paganahin ang idle detection API, isang espesyal na pagpipilian ang ibinigay sa seksyong "Privacy at seguridad" ng mga setting ("chrome: // setting / content / idleDetection").

Bukod dito, Dapat isaalang-alang namin ang isang tala mula sa mga developer ng Chrome tungkol sa pagsulong ng mga bagong diskarte upang matiyak ang ligtas na pamamahala ng memorya. Ayon sa Google, 70% ng mga problema sa seguridad sa Chrome ay sanhi ng mga error sa memorya, tulad ng paggamit pagkatapos ng libreng pag-access sa isang buffer. Tatlong pangunahing diskarte para sa pagharap sa mga naturang pagkakamali ay kinilala: paghihigpit ng mga tseke ng compile-time, pag-block sa mga error sa runtime, at paggamit ng isang wikang ligtas sa memorya.

Naiulat na nagsimula ang mga eksperimento sa pagdaragdag ng kakayahang bumuo ng mga sangkap sa wikang Rust sa Chromium codebase. Ang code na Rust ay hindi pa kasama sa mga compilation na ibinigay sa mga gumagamit at ang pangunahing layunin nito ay upang subukan ang posibilidad ng pagbuo ng mga indibidwal na bahagi ng browser sa Rust at isasama ang mga ito sa natitirang bahagi na nakasulat sa C ++.

Sa kahanay, para sa C ++ code, ang proyekto ay patuloy na nagkakaroon ng paggamit ng uri ng MiraclePtr sa halip na mga hilaw na pointers upang harangan ang posibilidad ng pagsamantalahan ang mga kahinaan na dulot ng pag-access sa napalaya na mga bloke ng memorya, at ang mga bagong pamamaraan ay iminungkahi upang makita ang mga error sa yugto pagtitipon.

Bukod dito, Nagsisimula ang eksperimento ng Google upang masubukan ang posibleng pagkawala ng site pagkatapos maabot ng browser ang isang tatlong-digit na bersyon sa halip na dalawa.

Sa partikular, ang setting na "chrome: // flags # force-major-version-to-100" ay lumitaw sa mga bersyon ng pagsubok sa Chrome 96, kapag tinukoy sa header ng User-Agent, ang bersyon 100 (Chrome / 100.0.4650.4. XNUMX) ay magiging ipinakita Noong Agosto, isang katulad na eksperimento ang isinagawa sa Firefox, na nagsiwalat ng mga problema sa paghawak ng mga triple-digit na bersyon sa ilang mga site.