Chrome 76 ມີ ຊ່ອງຫວ່າງໃນການປະຕິບັດ FileSystem API ທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດຈາກຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ການນໍາໃຊ້ຮູບແບບ incognito. ເລີ່ມຕົ້ນດ້ວຍ Chrome 76, ແທນທີ່ຈະປິດກັ້ນການເຂົ້າເຖິງ FileSystem API, ເຊິ່ງຖືກໃຊ້ເປັນສັນຍານຂອງການເຄື່ອນໄຫວໃນໂໝດບໍ່ເປີດເຜີຍຕົວຕົນ, ບຼາວເຊີບໍ່ຈຳກັດ FileSystem API ອີກຕໍ່ໄປ, ແຕ່ຈະທຳຄວາມສະອາດການປ່ຽນແປງທີ່ເຮັດຫຼັງຈາກກອງປະຊຸມ. ຍ້ອນວ່າມັນຫັນອອກ, ການປະຕິບັດໃຫມ່ ຂໍ້ເສຍທີ່ເຮັດໃຫ້ມັນສາມາດກໍານົດກິດຈະກໍາຂອງໂໝດບໍ່ເປີດເຜີຍຕົວຕົນຄືກັບກ່ອນ.
ໂດຍເນື້ອແທ້ແລ້ວຂອງບັນຫາແມ່ນວ່າເຊດຊັນກັບ FileSystem API ໃນຮູບແບບທີ່ບໍ່ເປີດເຜີຍຕົວຕົນແມ່ນຊົ່ວຄາວ, ແລະຂໍ້ມູນບໍ່ໄດ້ຖືກບັນທຶກໄວ້ໃນແຜ່ນແລະຖືກເກັບໄວ້ໃນ RAM. ຕາມລໍາດັບ, ເວລາຂອງການບັນທຶກຂໍ້ມູນຜ່ານ FileSystem API ແລະການບິດເບືອນທີ່ເກີດຂື້ນ (ເມື່ອບັນທຶກໃນ RAM, ລັກສະນະຄົງທີ່ຈະຖືກບັນທຶກໄວ້, ໃນຂະນະທີ່ຂຽນໃສ່ແຜ່ນ, ຄວາມຊັກຊ້າປ່ຽນແປງ) ທ່ານສາມາດຕັດສິນຢ່າງຫມັ້ນໃຈວ່າຫນ້າເວັບຈະຖືກເບິ່ງຢູ່ໃນໂຫມດບໍ່ເປີດເຜີຍຕົວຕົນຫຼືບໍ່. . ຂໍ້ເສຍຂອງວິທີການນີ້ແມ່ນຂະບວນການທີ່ຍາວນານຂອງການວັດແທກ deviations, ເຊິ່ງສາມາດໃຊ້ເວລາປະມານຫນຶ່ງນາທີ ().
ໃນຂະນະດຽວກັນ, ອີກອັນໜຶ່ງຍັງບໍ່ຖືກແກ້ໄຂໃນ Chrome 76 , ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດຕັດສິນກິດຈະກໍາຂອງຮູບແບບ incognito ໂດຍອີງໃສ່ການປະເມີນຂໍ້ຈໍາກັດທີ່ກໍານົດໄວ້ຜ່ານ API. . ສໍາລັບການເກັບຮັກສາຊົ່ວຄາວທີ່ໃຊ້ໃນໂຫມດບໍ່ເປີດເຜີຍຕົວຕົນ, ມີການກໍານົດຂອບເຂດຈໍາກັດທີ່ແຕກຕ່າງກັນກ່ວາສໍາລັບການເກັບຮັກສາເຕັມຢູ່ໃນແຜ່ນ.
ໃຫ້ພວກເຮົາເຕືອນທ່ານວ່າເວັບໄຊທ໌ທີ່ດໍາເນີນການໃນແບບຈໍາລອງການສະຫນອງການເຂົ້າເຖິງຢ່າງເຕັມທີ່ໂດຍຜ່ານການສະໝັກໃຊ້ແບບເສຍເງິນ (paywall) ມີຄວາມສົນໃຈໃນການກໍານົດຮູບແບບທີ່ບໍ່ເປີດເຜີຍຕົວຕົນ. ເພື່ອດຶງດູດຜູ້ຊົມໃຫມ່, ສະຖານທີ່ດັ່ງກ່າວໃຫ້ຜູ້ໃຊ້ໃຫມ່ທີ່ມີການເຂົ້າເຖິງການສາທິດຢ່າງເຕັມທີ່ສໍາລັບບາງເວລາ, ເຊິ່ງຖືກນໍາໃຊ້ຢ່າງຈິງຈັງເພື່ອຂ້າມ paywalls. ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຂົ້າເຖິງເນື້ອຫາທີ່ຈ່າຍໃນລະບົບດັ່ງກ່າວແມ່ນການໃຊ້ໂຫມດທີ່ບໍ່ເປີດເຜີຍຕົວຕົນ, ເຊິ່ງເວັບໄຊທ໌ເຊື່ອວ່າຜູ້ໃຊ້ໄດ້ເປີດຫນ້າເວັບທໍາອິດ. ຜູ້ເຜີຍແຜ່ບໍ່ພໍໃຈກັບພຶດຕິກໍານີ້, ດັ່ງນັ້ນເຂົາເຈົ້າໄດ້ໃຊ້ຊ່ອງຫວ່າງທີ່ກ່ຽວຂ້ອງກັບ FileSystem API ຢ່າງຈິງຈັງເພື່ອບັງຄັບໃຫ້ມີການປິດການນຳໃຊ້ໂໝດບໍ່ເປີດເຜີຍຕົວຕົນເພື່ອສືບຕໍ່ການຊອກຫາ.
ແຫຼ່ງຂໍ້ມູນ: opennet.ru
