ການວິພາກວິຈານການລວມເອົາ Idle Detection API ໃນ Chrome 94. ການທົດລອງກັບ Rust ໃນ Chrome

ການລວມຄ່າເລີ່ມຕົ້ນຂອງ Idle Detection API ໃນ Chrome 94 ໄດ້ເຮັດໃຫ້ເກີດການວິພາກວິຈານ, ອ້າງເຖິງການຄັດຄ້ານຈາກນັກພັດທະນາ Firefox ແລະ WebKit/Safari.

Idle Detection API ອະນຸຍາດໃຫ້ເວັບໄຊທ໌ກວດຫາເວລາທີ່ຜູ້ໃຊ້ບໍ່ເຄື່ອນໄຫວ, i.e. ບໍ່ໂຕ້ຕອບກັບແປ້ນພິມ/ເມົາສ໌ ຫຼືເຮັດວຽກຢູ່ໃນຈໍພາບອື່ນ. API ຍັງອະນຸຍາດໃຫ້ທ່ານຊອກຫາວ່າຕົວຮັກສາຫນ້າຈໍກໍາລັງເຮັດວຽກຢູ່ໃນລະບົບຫຼືບໍ່. ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ການ​ບໍ່​ມີ​ການ​ເຄື່ອນ​ໄຫວ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ໂດຍ​ການ​ສົ່ງ​ການ​ແຈ້ງ​ການ​ຫຼັງ​ຈາກ​ການ​ບັນ​ລຸ​ເປົ້າ​ຫມາຍ​ການ​ບໍ່​ມີ​ການ​ເຄື່ອນ​ໄຫວ​ທີ່​ກໍາ​ນົດ​ໄວ້​, ມູນ​ຄ່າ​ຕໍາ​່​ສຸດ​ທີ່​ແມ່ນ​ກໍາ​ນົດ​ໄວ້ 1 ນາ​ທີ​.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າການນໍາໃຊ້ Idle Detection API ຮຽກຮ້ອງໃຫ້ມີການອະນຸຍາດຂອງຜູ້ໃຊ້ຢ່າງຈະແຈ້ງ, i.e. ຖ້າແອັບພລິເຄຊັນພະຍາຍາມກວດພົບຄວາມບໍ່ເຄື່ອນໄຫວເປັນຄັ້ງທໍາອິດ, ຜູ້ໃຊ້ຈະຖືກນໍາສະເຫນີດ້ວຍປ່ອງຢ້ຽມທີ່ຖາມວ່າຈະໃຫ້ການອະນຸຍາດຫຼືຂັດຂວາງການດໍາເນີນງານ. ເພື່ອປິດການນຳໃຊ້ Idle Detection API ຢ່າງສົມບູນ, ທາງເລືອກພິເສດ (“chrome://settings/content/idleDetection”) ໄດ້ຖືກສະໜອງໃຫ້ຢູ່ໃນພາກສ່ວນການຕັ້ງຄ່າ “ຄວາມເປັນສ່ວນຕົວ ແລະຄວາມປອດໄພ”.

ພື້ນທີ່ແອັບພລິເຄຊັນປະກອບມີການສົນທະນາ, ເຄືອຂ່າຍສັງຄົມແລະການສື່ສານທີ່ສາມາດປ່ຽນສະຖານະຂອງຜູ້ໃຊ້ໄດ້ໂດຍອີງຕາມການປະກົດຕົວຂອງລາວຢູ່ໃນຄອມພິວເຕີຫຼືການຊັກຊ້າຂອງການແຈ້ງເຕືອນຂໍ້ຄວາມໃຫມ່ຈົນກ່ວາຜູ້ໃຊ້ມາຮອດ. API ຍັງສາມາດຖືກໃຊ້ໃນແອັບພລິເຄຊັນ kiosk ເພື່ອກັບຄືນສູ່ຫນ້າຈໍຕົ້ນສະບັບຫຼັງຈາກໄລຍະເວລາທີ່ບໍ່ມີການເຄື່ອນໄຫວ, ຫຼືປິດການທໍາງານການໂຕ້ຕອບທີ່ເນັ້ນໃສ່ຊັບພະຍາກອນ, ເຊັ່ນ: ການແຕ້ມຄືນໃຫມ່, ການປັບປຸງຕາຕະລາງຢ່າງຕໍ່ເນື່ອງ, ເມື່ອຜູ້ໃຊ້ບໍ່ໄດ້ຢູ່ໃນຄອມພິວເຕີ.

ຕໍາແຫນ່ງຂອງ opponents ຂອງການເປີດໃຊ້ Idle Detection API ແມ່ນວ່າຂໍ້ມູນກ່ຽວກັບວ່າຜູ້ໃຊ້ຢູ່ໃນຄອມພິວເຕີຫຼືບໍ່ສາມາດໄດ້ຮັບການພິຈາລະນາເປັນຄວາມລັບ. ນອກເຫນືອຈາກຄໍາຮ້ອງສະຫມັກທີ່ເປັນປະໂຫຍດ, API ນີ້ຍັງສາມາດຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງທີ່ບໍ່ດີ, ຕົວຢ່າງເຊັ່ນ, ເພື່ອພະຍາຍາມໃຊ້ຊ່ອງໂຫວ່ໃນຂະນະທີ່ຜູ້ໃຊ້ບໍ່ຢູ່ຫຼືເພື່ອເຊື່ອງກິດຈະກໍາທີ່ເປັນອັນຕະລາຍທີ່ເຫັນໄດ້ຊັດເຈນ, ເຊັ່ນ: ການຂຸດຄົ້ນບໍ່ແຮ່. ການນໍາໃຊ້ API ໃນຄໍາຖາມ, ຂໍ້ມູນກ່ຽວກັບຮູບແບບພຶດຕິກໍາຂອງຜູ້ໃຊ້ແລະຈັງຫວະປະຈໍາວັນຂອງການເຮັດວຽກຂອງລາວຍັງສາມາດເກັບກໍາໄດ້. ຕົວຢ່າງ, ທ່ານສາມາດຊອກຫາເວລາທີ່ຜູ້ໃຊ້ມັກຈະໄປກິນເຂົ້າທ່ຽງຫຼືອອກຈາກບ່ອນເຮັດວຽກ. ໃນບໍລິບົດຂອງຄໍາຮ້ອງຂໍການບັງຄັບສໍາລັບການຢັ້ງຢືນການອະນຸຍາດ, ຄວາມກັງວົນເຫຼົ່ານີ້ຖືກຮັບຮູ້ໂດຍ Google ວ່າບໍ່ສໍາຄັນ.

ນອກຈາກນັ້ນ, ທ່ານສາມາດສັງເກດບັນທຶກຈາກຜູ້ພັດທະນາ Chrome ກ່ຽວກັບການສົ່ງເສີມເຕັກນິກໃຫມ່ສໍາລັບການຮັບປະກັນການດໍາເນີນງານທີ່ປອດໄພກັບຫນ່ວຍຄວາມຈໍາ. ອີງຕາມກູໂກ, 70% ຂອງບັນຫາຄວາມປອດໄພໃນ Chrome ແມ່ນເກີດມາຈາກຄວາມຜິດພາດຂອງຫນ່ວຍຄວາມຈໍາ, ເຊັ່ນ: ການນໍາໃຊ້ buffer ຫຼັງຈາກການປົດປ່ອຍຫນ່ວຍຄວາມຈໍາທີ່ກ່ຽວຂ້ອງກັບມັນ (ການນໍາໃຊ້ພາຍຫຼັງທີ່ບໍ່ເສຍຄ່າ). ສາມຍຸດທະສາດຕົ້ນຕໍສໍາລັບການຈັດການກັບຄວາມຜິດພາດດັ່ງກ່າວໄດ້ຖືກກໍານົດ: ການກວດສອບຄວາມເຂັ້ມແຂງໃນຂັ້ນຕອນການລວບລວມ, ການຂັດຂວາງຄວາມຜິດພາດໃນເວລາແລ່ນ, ແລະການໃຊ້ພາສາທີ່ປອດໄພໃນຫນ່ວຍຄວາມຈໍາ.

ມັນໄດ້ຖືກລາຍງານວ່າການທົດລອງໄດ້ເລີ່ມເພີ່ມຄວາມສາມາດໃນການພັດທະນາອົງປະກອບໃນພາສາ Rust ກັບຖານລະຫັດ Chromium. ລະຫັດ Rust ຍັງບໍ່ທັນຖືກລວມເຂົ້າໃນການກໍ່ສ້າງທີ່ສົ່ງໃຫ້ຜູ້ໃຊ້ແລະຕົ້ນຕໍແມ່ນແນໃສ່ການທົດສອບຄວາມເປັນໄປໄດ້ຂອງການພັດທະນາແຕ່ລະສ່ວນຂອງຕົວທ່ອງເວັບໃນ Rust ແລະການເຊື່ອມໂຍງກັບພາກສ່ວນອື່ນໆທີ່ຂຽນໃນ C ++. ໃນຂະຫນານ, ສໍາລັບລະຫັດ C ++, ໂຄງການຍັງສືບຕໍ່ພັດທະນາເພື່ອນໍາໃຊ້ປະເພດ MiraclePtr ແທນທີ່ຈະເປັນຕົວຊີ້ວັດຖຸດິບເພື່ອສະກັດຄວາມເປັນໄປໄດ້ຂອງການຂຸດຄົ້ນຊ່ອງຫວ່າງທີ່ເກີດຈາກການເຂົ້າເຖິງບລັອກຫນ່ວຍຄວາມຈໍາທີ່ຖືກປົດປ່ອຍແລ້ວ, ແລະວິທີການໃຫມ່ສໍາລັບການກວດສອບຄວາມຜິດພາດໃນຂັ້ນຕອນການລວບລວມແມ່ນຍັງສະເຫນີ.

ນອກຈາກນັ້ນ, Google ກໍາລັງເລີ່ມຕົ້ນການທົດລອງເພື່ອທົດສອບການຂັດຂວາງເວັບໄຊທ໌ທີ່ອາດຈະເກີດຂຶ້ນຫຼັງຈາກຕົວທ່ອງເວັບມາຮອດສະບັບທີ່ປະກອບດ້ວຍສາມຕົວເລກແທນທີ່ຈະເປັນສອງ. ໂດຍສະເພາະ, ໃນການປ່ອຍການທົດສອບຂອງ Chrome 96, ການຕັ້ງຄ່າ "chrome://flags#force-major-version-to-100" ປາກົດ, ເມື່ອລະບຸໄວ້ໃນສ່ວນຫົວຜູ້ໃຊ້ຕົວແທນ, ຮຸ່ນ 100 (Chrome/100.0.4650.4) ເລີ່ມຕົ້ນທີ່ຈະສະແດງ. ໃນເດືອນສິງຫາ, ການທົດລອງທີ່ຄ້າຍຄືກັນໄດ້ຖືກດໍາເນີນຢູ່ໃນ Firefox, ເຊິ່ງໄດ້ເປີດເຜີຍບັນຫາກ່ຽວກັບການປຸງແຕ່ງສະບັບສາມຕົວເລກໃນບາງເວັບໄຊທ໌.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru