Chrome ປ່ອຍ 79

ກູໂກ ນຳ ສະ ເໜີ ປ່ອຍຕົວທ່ອງເວັບ Chrome 79... ພ້ອມໆກັນ ມີ ການປ່ອຍໂຄງການຟຣີທີ່ຫມັ້ນຄົງ chromium, ເຊິ່ງເຮັດຫນ້າທີ່ເປັນພື້ນຖານຂອງ Chrome. ຕົວທ່ອງເວັບ Chrome ແຕກຕ່າງ ການໃຊ້ໂລໂກ້ຂອງ Google, ການປະກົດຕົວຂອງລະບົບການສົ່ງການແຈ້ງເຕືອນໃນກໍລະນີທີ່ເກີດອຸປະຕິເຫດ, ຄວາມສາມາດໃນການດາວໂຫລດໂມດູນ Flash ຕາມຄໍາຮ້ອງຂໍ, ໂມດູນສໍາລັບການຫຼິ້ນເນື້ອຫາວິດີໂອທີ່ມີການປ້ອງກັນ (DRM), ລະບົບສໍາລັບການຕິດຕັ້ງການປັບປຸງແລະການສົ່ງຂໍ້ມູນອັດຕະໂນມັດໃນລະຫວ່າງການຄົ້ນຫາ ຕົວກໍານົດການ RLZ. ການປ່ອຍຕໍ່ໄປຂອງ Chrome 80 ແມ່ນກໍານົດສໍາລັບວັນທີ 4 ກຸມພາ.

ຕົ້ນ​ຕໍ ການປ່ຽນແປງ в Chrome 79:

• ເປີດໃຊ້ແລ້ວ ອົງປະກອບການກວດສອບລະຫັດຜ່ານ, ອອກແບບມາເພື່ອວິເຄາະຄວາມເຂັ້ມແຂງຂອງລະຫັດຜ່ານທີ່ໃຊ້ໂດຍຜູ້ໃຊ້. ໃນ​ເວ​ລາ​ທີ່​ພະ​ຍາ​ຍາມ​ເຂົ້າ​ສູ່​ລະ​ບົບ​ການ​ກວດ​ສອບ​ລະ​ຫັດ​ຜ່ານ​ເວັບ​ໄຊ​ໃດ​ຫນຶ່ງ ປະຕິບັດ ການກວດສອບການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານຕໍ່ກັບຖານຂໍ້ມູນຂອງບັນຊີທີ່ຖືກລະເມີດໂດຍມີການເຕືອນໄພຖ້າບັນຫາຖືກກວດພົບ (ການກວດສອບແມ່ນດໍາເນີນການໂດຍອີງໃສ່ຄໍານໍາຫນ້າ hash ຢູ່ຂ້າງຜູ້ໃຊ້). ການກວດສອບແມ່ນດໍາເນີນຕໍ່ກັບຖານຂໍ້ມູນທີ່ກວມເອົາຫຼາຍກວ່າ 4 ຕື້ບັນຊີທີ່ຖືກລະເມີດທີ່ປາກົດຢູ່ໃນຖານຂໍ້ມູນຜູ້ໃຊ້ທີ່ຮົ່ວໄຫຼ. ການເຕືອນໄພຍັງຖືກສະແດງຂຶ້ນເມື່ອພະຍາຍາມໃຊ້ລະຫັດຜ່ານເລັກນ້ອຍເຊັ່ນ "abc123". ເພື່ອຄວບຄຸມການລວມເອົາການກວດສອບລະຫັດຜ່ານ, ການຕັ້ງຄ່າພິເສດໄດ້ຖືກປະຕິບັດຢູ່ໃນພາກສ່ວນ “ການຊິ້ງຂໍ້ມູນ ແລະການບໍລິການຂອງ Google”.
• ເທັກໂນໂລຍີໃໝ່ໃນການກວດສອບ phishing ໃນເວລາຈິງໄດ້ຖືກນໍາສະເຫນີ. ກ່ອນຫນ້ານີ້, ການກວດສອບໄດ້ຖືກປະຕິບັດໂດຍການເຂົ້າເຖິງບັນຊີດໍາຂອງ Safe Browsing ທ້ອງຖິ່ນ, ເຊິ່ງໄດ້ຖືກປັບປຸງປະມານຫນຶ່ງຄັ້ງໃນທຸກໆ 30 ນາທີ, ເຊິ່ງປະກົດວ່າບໍ່ພຽງພໍ, ຕົວຢ່າງ, ໃນເງື່ອນໄຂຂອງການປ່ຽນໂດເມນເລື້ອຍໆໂດຍຜູ້ໂຈມຕີ. ວິທີການໃຫມ່ຊ່ວຍໃຫ້ທ່ານສາມາດກວດເບິ່ງ URLs ໃນທັນທີດ້ວຍການກວດສອບເບື້ອງຕົ້ນຕໍ່ກັບບັນຊີຂາວທີ່ປະກອບມີ hashes ຂອງຫລາຍພັນເວັບໄຊທ໌ທີ່ນິຍົມທີ່ຫນ້າເຊື່ອຖື. ຖ້າເວັບໄຊທ໌ທີ່ຖືກເປີດບໍ່ຢູ່ໃນບັນຊີລາຍຊື່ສີຂາວ, ຕົວທ່ອງເວັບຈະກວດເບິ່ງ URL ໃນເຄື່ອງແມ່ຂ່າຍຂອງ Google, ສົ່ງ 32 bits ທໍາອິດຂອງການເຊື່ອມຕໍ່ SHA-256 hash, ຈາກຂໍ້ມູນສ່ວນບຸກຄົນທີ່ເປັນໄປໄດ້ຖືກຕັດອອກ. ອີງຕາມກູໂກ, ວິທີການໃຫມ່ສາມາດປັບປຸງປະສິດທິພາບຂອງການເຕືອນໄພສໍາລັບສະຖານທີ່ phishing ໃຫມ່ 30%.
• ເພີ່ມການປົກປ້ອງຢ່າງຫ້າວຫັນຕໍ່ກັບການໂອນຂໍ້ມູນປະຈຳຕົວຂອງ Google ແລະລະຫັດຜ່ານໃດໆກໍຕາມທີ່ເກັບໄວ້ໃນຕົວຈັດການລະຫັດຜ່ານຜ່ານໜ້າ phishing. ຖ້າທ່ານພະຍາຍາມໃສ່ລະຫັດຜ່ານທີ່ບັນທຶກໄວ້ໃນເວັບໄຊທີ່ລະຫັດຜ່ານນັ້ນບໍ່ໄດ້ຖືກນໍາໃຊ້ເປັນປົກກະຕິ, ຜູ້ໃຊ້ຈະຖືກເຕືອນກ່ຽວກັບການກະທໍາທີ່ອາດຈະເປັນອັນຕະລາຍ.
• ການເຊື່ອມຕໍ່ທີ່ໃຊ້ TLS 1.0 ແລະ 1.1 ຕອນນີ້ສະແດງຕົວຊີ້ບອກການເຊື່ອມຕໍ່ທີ່ບໍ່ປອດໄພ. ຮອງຮັບ TLS 1.0 ແລະ 1.1 ຢ່າງສົມບູນ ຈະຖືກປິດໃຊ້ງານ ໃນ Chrome 81, ກໍານົດສໍາລັບ 17 ມີນາ 2020.
• ເພີ່ມຄວາມສາມາດໃນການຈຶ້ງແຖບທີ່ບໍ່ເຄື່ອນໄຫວ, ຊ່ວຍໃຫ້ທ່ານສາມາດຍົກເລີກການໂຫຼດອັດຕະໂນມັດຈາກແທັບຫນ່ວຍຄວາມຈໍາທີ່ຢູ່ໃນພື້ນຫລັງຫຼາຍກວ່າ 5 ນາທີແລະບໍ່ດໍາເນີນການທີ່ສໍາຄັນ. ການຕັດສິນໃຈກ່ຽວກັບຄວາມເຫມາະສົມຂອງແຖບສະເພາະໃດຫນຶ່ງສໍາລັບການ freezing ແມ່ນອີງໃສ່ heuristics. ການເປີດໃຊ້ງານແມ່ນຄວບຄຸມຜ່ານທຸງ “chrome://flags/#proactive-tab-freeze”.
• ຮັບປະກັນ ການຂັດຂວາງເນື້ອຫາປະສົມຢູ່ໃນຫນ້າທີ່ເປີດຜ່ານ HTTPS ເພື່ອຮັບປະກັນວ່າຫນ້າທີ່ເປີດຜ່ານ https:// ມີພຽງແຕ່ຊັບພະຍາກອນທີ່ໂຫລດຜ່ານຊ່ອງທາງການສື່ສານທີ່ປອດໄພ. ເຖິງແມ່ນວ່າປະເພດທີ່ເປັນອັນຕະລາຍທີ່ສຸດຂອງເນື້ອຫາປະສົມເຊັ່ນ: scripts ແລະ iframes, ຖືກບລັອກໄວ້ແລ້ວໂດຍຄ່າເລີ່ມຕົ້ນ, ຮູບພາບ, ໄຟລ໌ສຽງແລະວິດີໂອຍັງສາມາດດາວໂຫລດຜ່ານ http://. ຕົວຊີ້ວັດເນື້ອຫາທີ່ປະສົມກັນທີ່ໃຊ້ໃນເມື່ອກ່ອນສໍາລັບການແຊກດັ່ງກ່າວພົບວ່າບໍ່ມີປະສິດຕິຜົນແລະເຮັດໃຫ້ເກີດຄວາມເຂົ້າໃຈຜິດຕໍ່ຜູ້ໃຊ້, ເພາະວ່າມັນບໍ່ໄດ້ສະຫນອງການປະເມີນຄວາມປອດໄພຂອງຫນ້າທີ່ບໍ່ມີຄວາມຊັດເຈນ. ຕົວຢ່າງ, ຜ່ານການຫຼອກລວງຮູບພາບ, ຜູ້ໂຈມຕີສາມາດທົດແທນ Cookies ຕິດຕາມຜູ້ໃຊ້, ພະຍາຍາມໃຊ້ຊ່ອງໂຫວ່ໃນໂປເຊດເຊີຮູບພາບ, ຫຼືເຮັດການປອມແປງໂດຍການປ່ຽນຂໍ້ມູນທີ່ໃຫ້ຢູ່ໃນຮູບພາບ. ເພື່ອປິດການລັອກຂອງອົງປະກອບປະສົມ, ການຕັ້ງຄ່າພິເສດໄດ້ຖືກເພີ່ມ, ເຊິ່ງສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜ່ານເມນູທີ່ປາກົດເມື່ອທ່ານຄລິກໃສ່ສັນຍາລັກລັອກ.
• ເພີ່ມຄວາມສາມາດໃນການທົດລອງເພື່ອແບ່ງປັນເນື້ອໃນ clipboard ລະຫວ່າງ Chrome ເວີຊັ່ນເດັສທັອບ ແລະມືຖື. ໃນກໍລະນີຂອງ Chrome ທີ່ເຊື່ອມໂຍງກັບບັນຊີຫນຶ່ງ, ຕອນນີ້ທ່ານສາມາດເຂົ້າເຖິງເນື້ອຫາຂອງ clipboard ຂອງອຸປະກອນອື່ນ, ລວມທັງການແບ່ງປັນ clipboard ລະຫວ່າງມືຖືແລະ desktop. ເນື້ອໃນຂອງຄລິບບອດຖືກເຂົ້າລະຫັດໂດຍໃຊ້ການເຂົ້າລະຫັດແບບຕົ້ນທາງຮອດທ້າຍ, ເຊິ່ງປ້ອງກັນການເຂົ້າເຖິງຂໍ້ຄວາມໃນເຊີບເວີຂອງ Google. ຟັງຊັນຖືກເປີດໃຊ້ຜ່ານຕົວເລືອກ chrome://flags#shared-clipboard-receiver, chrome://flags#shared-clipboard-ui ແລະ chrome://flags#sync-clipboard-service.
• ໃນແຖບທີ່ຢູ່ໃນຊ່ວງເວລາທີ່ແນ່ນອນ (ຕົວຢ່າງ, ເມື່ອບັນທຶກລະຫັດຜ່ານ) ເມື່ອປິດການຊິ້ງຂໍ້ມູນໂປຣໄຟລ໌, ນອກເຫນືອຈາກຮູບແທນຕົວ, ຊື່ຂອງບັນຊີ Google ປະຈຸບັນຈະສະແດງເພື່ອໃຫ້ຜູ້ໃຊ້ສາມາດກໍານົດບັນຊີທີ່ໃຊ້ໃນປັດຈຸບັນໄດ້ຢ່າງຖືກຕ້ອງ.
• ເປີດໃຊ້ສໍາລັບ 1% ຂອງຜູ້ໃຊ້ ສະຫນັບສະຫນູນ “DNS ຜ່ານ HTTPS” (DoH, DNS over HTTPS). ການທົດລອງກ່ຽວຂ້ອງກັບຜູ້ໃຊ້ທີ່ການຕັ້ງຄ່າລະບົບໄດ້ລະບຸຜູ້ໃຫ້ບໍລິການ DNS ທີ່ຮອງຮັບ DoH ແລ້ວ. ຕົວຢ່າງ, ຖ້າຜູ້ໃຊ້ມີ DNS 8.8.8.8 ທີ່ລະບຸໄວ້ໃນການຕັ້ງຄ່າລະບົບ, ຫຼັງຈາກນັ້ນບໍລິການ DoH ຂອງ Google (“https://dns.google.com/dns-query”) ຈະຖືກເປີດໃຊ້ໃນ Chrome; ຖ້າ DNS ແມ່ນ 1.1.1.1. XNUMX, ຈາກນັ້ນບໍລິການ DoH Cloudflare (“https://cloudflare-dns.com/dns-query”), ແລະອື່ນໆ. ເພື່ອຄວບຄຸມວ່າຈະເປີດ DoH ຫຼືບໍ່, ການຕັ້ງຄ່າ “chrome://flags/#dns-over-https” ໄດ້ຖືກສະໜອງໃຫ້. ສາມ​ຮູບ​ແບບ​ການ​ປະ​ຕິ​ບັດ​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​: ຄວາມ​ປອດ​ໄພ​, ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ປິດ​. ໃນໂຫມດ "ປອດໄພ", ໂຮດຖືກກໍານົດພຽງແຕ່ອີງໃສ່ຄ່າຄວາມປອດໄພທີ່ເກັບໄວ້ໃນອະດີດ (ໄດ້ຮັບຜ່ານການເຊື່ອມຕໍ່ທີ່ປອດໄພ) ແລະການຮ້ອງຂໍຜ່ານ DoH; ການກັບຄືນໄປຫາ DNS ປົກກະຕິແມ່ນບໍ່ຖືກນໍາໃຊ້. ໃນໂຫມດ "ອັດຕະໂນມັດ", ຖ້າ DoH ແລະ cache ທີ່ປອດໄພບໍ່ສາມາດໃຊ້ໄດ້, ຂໍ້ມູນສາມາດດຶງຂໍ້ມູນຈາກ cache ທີ່ບໍ່ປອດໄພແລະເຂົ້າເຖິງຜ່ານ DNS ແບບດັ້ງເດີມ. ໃນໂຫມດ "ປິດ", ແຄດທີ່ໃຊ້ຮ່ວມກັນໄດ້ຖືກກວດສອບຄັ້ງທໍາອິດແລະຖ້າບໍ່ມີຂໍ້ມູນ, ການຮ້ອງຂໍຈະຖືກສົ່ງຜ່ານ DNS ຂອງລະບົບ.
• ເພີ່ມການທົດລອງ ສະຫນັບສະຫນູນ caching ຂອງເນື້ອຫາທີ່ສະແດງເມື່ອປ່ຽນຫນ້າໂດຍໃຊ້ປຸ່ມສົ່ງຕໍ່ແລະກັບຄືນ, ເຊິ່ງສາມາດຫຼຸດຜ່ອນຄວາມລ່າຊ້າຢ່າງຫຼວງຫຼາຍໃນລະຫວ່າງການນໍາທາງປະເພດນີ້ເນື່ອງຈາກການເກັບຂໍ້ມູນຂອງຫນ້າທັງຫມົດ, ເຊິ່ງບໍ່ຈໍາເປັນຕ້ອງມີການສະແດງຄືນໃຫມ່ແລະການໂຫຼດຊັບພະຍາກອນ. ການເພີ່ມປະສິດທິພາບແມ່ນສັງເກດເຫັນໂດຍສະເພາະໃນຮຸ່ນສໍາລັບອຸປະກອນມືຖື, ບ່ອນທີ່ປະສິດທິພາບເພີ່ມຂຶ້ນໃນລະຫວ່າງການນໍາທາງເຖິງ 19%. ໂໝດຖືກເປີດໃຊ້ໂດຍໃຊ້ຕົວເລືອກ “chrome://flags#back-forward-cache”.
• ລຶບແລ້ວ ການຕັ້ງຄ່າ "chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains", ເຊິ່ງອະນຸຍາດໃຫ້ສົ່ງຄືນການສະແດງໂປໂຕຄອນໃນແຖບທີ່ຢູ່ (ຕອນນີ້ທຸກລິ້ງຖືກສະແດງຢູ່ສະເຫມີໂດຍບໍ່ມີ https. // ແລະ http: // /, ແລະບໍ່ມີ "www.").
• ການສ້າງສໍາລັບ Windows ປະກອບມີ sandboxing ຂອງການບໍລິການຫຼິ້ນສຽງ. ເພື່ອຄວບຄຸມວ່າຈະເປີດໃຊ້ການໂດດດ່ຽວຫຼືບໍ່, ຄຸນສົມບັດ AudioSandboxEnabled ຖືກສະເໜີໃຫ້.
• ເຄື່ອງມືການບໍລິຫານສູນກາງສໍາລັບວິສາຫະກິດປະກອບມີຄວາມສາມາດໃນການກໍານົດກົດລະບຽບທີ່ຄວບຄຸມຄວາມຈໍາຫຼາຍປານໃດຂອງຕົວທ່ອງເວັບທີ່ສາມາດບໍລິໂພກກ່ອນທີ່ແຖບພື້ນຫລັງຈະຖືກຍົກເລີກ. ໜ່ວຍຄວາມຈຳທີ່ປ່ອຍອອກມາຫຼັງຈາກຍົກເລີກການໂຫຼດແຖບນັ້ນຈະສາມາດໃຊ້ໄດ້, ແລະເນື້ອໃນຂອງແຖບຈະຖືກໂຫຼດອີກຄັ້ງເມື່ອປ່ຽນໄປໃຊ້ມັນ.
• Linux ໃຊ້ໂປເຊດເຊີການຢັ້ງຢືນໃບຢັ້ງຢືນທີ່ມີໃນຕົວ, ເຊິ່ງແທນທີ່ລະບົບ NSS ທີ່ໃຊ້ໃນເມື່ອກ່ອນ. ໃນກໍລະນີນີ້, ໂປເຊດເຊີທີ່ສ້າງມາຍັງສືບຕໍ່ໃຊ້ຮ້ານ NSS ໃນລະຫວ່າງການກວດສອບ, ແຕ່ກໍານົດຄວາມຕ້ອງການທີ່ເຂັ້ມງວດກວ່າເມື່ອການປຸງແຕ່ງການເຂົ້າລະຫັດບໍ່ຖືກຕ້ອງແລະໃບຢັ້ງຢືນແຍກຕ່າງຫາກ (ໃບຢັ້ງຢືນທັງຫມົດຕ້ອງໄດ້ຮັບການຢັ້ງຢືນໂດຍເຈົ້າຫນ້າທີ່ການຢັ້ງຢືນ).
• ໃນ​ສະ​ບັບ​ສໍາ​ລັບ​ເວ​ທີ Android​ ເພີ່ມ ຄວາມສາມາດໃນການກໍານົດໄອຄອນປັບຕົວສໍາລັບຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ຕິດຕັ້ງຢູ່ໃນໂຫມດ Progressive Web Apps (PWA). ໄອຄອນປັບຕົວສາມາດປັບຕົວເຂົ້າກັບສ່ວນຕິດຕໍ່ທີ່ໃຊ້ໂດຍຜູ້ຜະລິດອຸປະກອນ, ຕົວຢ່າງ, ເປັນຮູບກົມ, ສີ່ຫຼ່ຽມມົນ, ຫຼືມຸມລຽບ.
• ເພີ່ມແລ້ວ API ອຸປະກອນ WebXR, ເຊິ່ງສະຫນອງການເຂົ້າເຖິງອົງປະກອບສໍາລັບການສ້າງ virtual ແລະ augmented ຄວາມເປັນຈິງ. API ອະນຸຍາດໃຫ້ທ່ານສາມາດປະສົມປະສານການເຮັດວຽກກັບອຸປະກອນຕ່າງໆ, ຈາກຊຸດຫູຟັງ virtual reality ເຊັ່ນ Oculus Rift, HTC Vive ແລະ Windows Mixed Reality, ໄປຫາວິທີແກ້ໄຂໂດຍອີງໃສ່ອຸປະກອນມືຖືເຊັ່ນ Google Daydream View ແລະ Samsung Gear VR. ແອັບພລິເຄຊັ່ນທີ່ API ໃໝ່ອາດຈະນຳໃຊ້ໄດ້ລວມມີບັນດາໂຄງການສຳລັບການເບິ່ງວິດີໂອໃນໂໝດ 360°, ລະບົບການເບິ່ງເຫັນຊ່ອງສາມມິຕິ, ການສ້າງໂຮງຮູບເງົາສະເໝືອນສຳລັບການນຳສະເໜີວິດີໂອ, ທົດລອງສ້າງການໂຕ້ຕອບ 3 ມິຕິສຳລັບຮ້ານຄ້າ ແລະຫ້ອງວາງສະແດງ;
  

• ຢູ່ໃນໂໝດການທົດລອງຕົ້ນສະບັບ (ລັກສະນະການທົດລອງທີ່ຕ້ອງການແຍກຕ່າງຫາກ ການເປີດໃຊ້ງານ) APIs ໃຫມ່ຈໍານວນຫນຶ່ງໄດ້ຖືກສະເຫນີ. ການທົດລອງຕົ້ນສະບັບຫມາຍເຖິງຄວາມສາມາດໃນການເຮັດວຽກກັບ API ທີ່ລະບຸໄວ້ຈາກແອັບພລິເຄຊັນທີ່ດາວໂຫລດຈາກ localhost ຫຼື 127.0.0.1, ຫຼືຫຼັງຈາກລົງທະບຽນແລະໄດ້ຮັບ token ພິເສດທີ່ຖືກຕ້ອງສໍາລັບເວລາຈໍາກັດສໍາລັບສະຖານທີ່ສະເພາະ.
  • ສໍາລັບອົງປະກອບ HTML ທັງຫມົດ, ຄຸນລັກສະນະ "rendersubtree" ຖືກສະເຫນີ, ເຊິ່ງຮັບປະກັນວ່າການສະແດງອົງປະກອບ DOM ຖືກແກ້ໄຂ. ການຕັ້ງຄ່າຄຸນສົມບັດເປັນ "ເບິ່ງບໍ່ເຫັນ" ຈະປ້ອງກັນບໍ່ໃຫ້ເນື້ອຫາຂອງອົງປະກອບຖືກສະແດງ ຫຼືກວດສອບ, ອະນຸຍາດໃຫ້ມີການສະແດງຜົນທີ່ດີທີ່ສຸດ. ເມື່ອຕັ້ງເປັນ "ເປີດໃຊ້ໄດ້", ຕົວທ່ອງເວັບຈະເອົາຄຸນລັກສະນະທີ່ເບິ່ງບໍ່ເຫັນອອກ, ສະແດງເນື້ອຫາແລະເຮັດໃຫ້ມັນເຫັນໄດ້.
  • ເພີ່ມທາງເລືອກ API ລັອກປຸກ ອີງໃສ່ກົນໄກ Promise, ເຊິ່ງໃຫ້ວິທີທີ່ປອດໄພກວ່າໃນການຄວບຄຸມການປິດໜ້າຈໍລັອກອັດຕະໂນມັດ ແລະ ການສະຫຼັບອຸປະກອນໄປສູ່ໂໝດປະຢັດພະລັງງານ.
• ປະຕິບັດຄວາມສາມາດໃນການນໍາໃຊ້ຄຸນລັກສະນະ ໂຟກັດອັດຕະໂນມັດ ສໍາລັບອົງປະກອບ HTML ແລະ SVG ທັງຫມົດທີ່ສາມາດມີຈຸດສຸມການປ້ອນຂໍ້ມູນ.
• ສໍາລັບຮູບພາບແລະວິດີໂອ ຮັບປະກັນ ການຄິດໄລ່ອັດຕາສ່ວນພາບໂດຍອີງໃສ່ຄຸນລັກສະນະ Width ຫຼື Height, ເຊິ່ງສາມາດນໍາໃຊ້ເພື່ອກໍານົດຂະຫນາດຂອງຮູບພາບໂດຍໃຊ້ CSS ໃນຂັ້ນຕອນໃນເວລາທີ່ຮູບພາບຍັງບໍ່ທັນໄດ້ໂຫລດ (ແກ້ໄຂບັນຫາກັບການສ້າງຫນ້າໃຫມ່ຫຼັງຈາກຮູບພາບຖືກໂຫລດ).
• ເພີ່ມຄຸນສົມບັດ CSS ການປັບຂະ ໜາດ ຕົວ ໜັງ ສື, ເຊິ່ງກໍານົດອັດຕະໂນມັດຂະຫນາດຕົວອັກສອນຕົວແປໃນພິກັດ optical "opsz", ຖ້າຕົວອັກສອນສະຫນັບສະຫນູນພວກເຂົາ. ຮູບແບບດັ່ງກ່າວອະນຸຍາດໃຫ້ທ່ານເລືອກຮູບຮ່າງ glyph ທີ່ດີທີ່ສຸດສໍາລັບຂະຫນາດທີ່ກໍານົດໄວ້, ຕົວຢ່າງ, ໃຊ້ glyphs ກົງກັນຂ້າມຫຼາຍສໍາລັບຫົວຂໍ້.
• ເພີ່ມຄຸນສົມບັດ CSS list-style-type, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານໃຊ້ສັນຍາລັກໃດໆແທນທີ່ຈະເປັນໄລຍະເວລາໃນລາຍການ, ຕົວຢ່າງ, "-", "+", "★" ແລະ "▸".
• ຖ້າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະປະຕິບັດ Worklet.addModule(), ຕອນນີ້ວັດຖຸຖືກສົ່ງຄືນໂດຍມີຂໍ້ມູນລະອຽດກ່ຽວກັບລັກສະນະຂອງຄວາມຜິດພາດ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດປະເມີນສາເຫດຂອງຄວາມຜິດພາດໄດ້ຢ່າງຖືກຕ້ອງ (ບັນຫາກ່ຽວກັບການເຊື່ອມຕໍ່ເຄືອຂ່າຍ, syntax ທີ່ບໍ່ຖືກຕ້ອງ, ແລະອື່ນໆ. .).
• ຢຸດການປະມວນຜົນອົງປະກອບ ເມື່ອຍ້າຍພວກມັນລະຫວ່າງເອກະສານ. ໃນ​ເວ​ລາ​ທີ່​ການ​ໂອນ​ລະ​ຫວ່າງ​ເອ​ກະ​ສານ​, ການ​ປະ​ຕິ​ບັດ​ຂອງ​ກິດ​ທີ່​ກ່ຽວ​ຂ້ອງ​ກັບ script "error​" ແລະ "ໂຫຼດ​" ແມ່ນ​ຍັງ​ປິດ​.
• ໃນເຄື່ອງຈັກ JavaScript V8 ປະຕິບັດ ການເພີ່ມປະສິດທິພາບຂອງການຈັດການການປ່ຽນແປງການເປັນຕົວແທນຂອງທົ່ງນາໃນວັດຖຸ, ສົ່ງຜົນໃຫ້ການປະຕິບັດລະຫັດ AngularJS ໃນຊຸດທົດສອບ Speedometer ແລ່ນໄວຂຶ້ນ 4%.
  

• V8 ຍັງເພີ່ມປະສິດທິພາບການປະມວນຜົນຂອງ getters ທີ່ກໍານົດໄວ້ໃນ APIs ທີ່ມີໃນຕົວ, ເຊັ່ນ Node.nodeType ແລະ Node.nodeName, ໃນກໍລະນີທີ່ບໍ່ມີຕົວຈັດການ IC (inline caching). ການປ່ຽນແປງໄດ້ຫຼຸດລົງເວລາທີ່ໃຊ້ໃນ IC runtime ປະມານ 12% ເມື່ອແລ່ນການທົດສອບ Backbone ແລະ jQuery ຈາກຊຸດ Speedometer.
  

• ຜົນໄດ້ຮັບຂອງກົນໄກການ OSR (ເອີ້ນວ່າ on-stack replacement) ຖືກເກັບໄວ້ໃນຖານຄວາມຈໍາ, ເຊິ່ງແທນທີ່ລະຫັດ optimized ໃນລະຫວ່າງການປະຕິບັດຫນ້າທີ່ (ຊ່ວຍໃຫ້ທ່ານສາມາດເລີ່ມຕົ້ນໃຊ້ລະຫັດ optimized ສໍາລັບຟັງຊັນທີ່ເຮັດວຽກຍາວໂດຍບໍ່ຕ້ອງລໍຖ້າໃຫ້ເຂົາເຈົ້າດໍາເນີນການອີກເທື່ອຫນຶ່ງ). OSR caching ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະນໍາໃຊ້ຜົນໄດ້ຮັບການເພີ່ມປະສິດທິພາບໃນເວລາທີ່ດໍາເນີນການຟັງຊັນໃຫມ່, ໂດຍບໍ່ຈໍາເປັນຕ້ອງຜ່ານການເພີ່ມປະສິດທິພາບໃຫມ່.
  ໃນບາງການທົດສອບ, ການປ່ຽນແປງໄດ້ເພີ່ມປະສິດທິພາບສູງສຸດໂດຍ 5-18%.
  

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

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

  • ການອອກແບບຂອງແຖບການຄຸ້ມຄອງໄດ້ຖືກປັບປຸງໃຫ້ທັນສະໄຫມ, ຊ່ວຍໃຫ້ທ່ານສາມາດປະເມີນລະຫັດທີ່ໃຊ້ແລະບໍ່ໄດ້ໃຊ້. ເພີ່ມຄວາມສາມາດໃນການກັ່ນຕອງຂໍ້ມູນຕາມປະເພດຂອງມັນ (JavaScript, CSS). ຂໍ້​ມູນ​ການ​ນໍາ​ໃຊ້​ລະ​ຫັດ​ແມ່ນ​ເພີ່ມ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ທີ່​ການ​ສະ​ແດງ​ຂໍ້​ຄວາມ​ທີ່​ມາ​.
    

  • ເພີ່ມຄວາມສາມາດໃນການແກ້ໄຂເຫດຜົນສໍາລັບການຮ້ອງຂໍຊັບພະຍາກອນເຄືອຂ່າຍໂດຍສະເພາະຫຼັງຈາກບັນທຶກກິດຈະກໍາເຄືອຂ່າຍ (ທ່ານສາມາດເບິ່ງການຕິດຕາມການເອີ້ນລະຫັດ JavaScript ທີ່ນໍາໄປສູ່ການໂຫຼດຂອງຊັບພະຍາກອນ).
    

  • ເພີ່ມການຕັ້ງຄ່າ “ການຕັ້ງຄ່າ > ການຕັ້ງຄ່າ > ແຫຼ່ງທີ່ມາ > ການຫຍໍ້ໜ້າເລີ່ມຕົ້ນ” ເພື່ອກຳນົດປະເພດຂອງການຫຍໍ້ໜ້າ (2/4/8 ຍະຫວ່າງ ຫຼືແຖບ) ໃນລະຫັດທີ່ສະແດງຢູ່ໃນແຜງຄອນໂຊນ ແລະແຫຼ່ງທີ່ມາ.

ນອກເຫນືອຈາກການປະດິດສ້າງແລະການແກ້ໄຂຂໍ້ບົກພ່ອງ, ສະບັບໃຫມ່ໄດ້ກໍາຈັດ 51 ຊ່ອງໂຫວ່. ຫຼາຍໆຊ່ອງໂຫວ່ໄດ້ຖືກລະບຸວ່າເປັນຜົນມາຈາກການທົດສອບອັດຕະໂນມັດໂດຍໃຊ້ AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer ແລະ AFL tools. ສອງບັນຫາ (CVE-2019-13725, ການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາທີ່ຖືກປົດປ່ອຍແລ້ວໃນລະຫັດສໍາລັບການສະຫນັບສະຫນູນ Bluetooth, ແລະ CVE-2019-13726, heap overflow ໃນຕົວຈັດການລະຫັດຜ່ານ) ຖືກຫມາຍວ່າສໍາຄັນ, i.e. ອະນຸຍາດໃຫ້ທ່ານຂ້າມທຸກລະດັບຂອງການປົກປ້ອງຕົວທ່ອງເວັບແລະປະຕິບັດລະຫັດໃນລະບົບນອກສະພາບແວດລ້ອມ sandbox. ນີ້​ແມ່ນ​ຄັ້ງ​ທໍາ​ອິດ​ທີ່​ສອງ​ບັນ​ຫາ​ທີ່​ສໍາ​ຄັນ​ໄດ້​ຖືກ​ກໍາ​ນົດ​ຢູ່​ໃນ​ວົງ​ຈອນ​ການ​ພັດ​ທະ​ນາ​ດຽວ​ກັນ​ໃນ Chrome​. ຊ່ອງໂຫວ່ທໍາອິດໄດ້ຖືກພົບເຫັນໂດຍນັກຄົ້ນຄວ້າຈາກ Tencent Keen Security Lab ແລະ ສະແດງໃຫ້ເຫັນ ໃນການແຂ່ງຂັນເຕະບານ Tianfu, ແລະຄັ້ງທີສອງໄດ້ພົບເຫັນໂດຍ Sergei Glazunov ຈາກ Google Project Zero.

ເປັນສ່ວນຫນຶ່ງຂອງໂຄງການລາງວັນເງິນສົດສໍາລັບການຄົ້ນພົບຊ່ອງໂຫວ່ສໍາລັບການເປີດຕົວໃນປະຈຸບັນ, Google ໄດ້ຈ່າຍ 37 ລາງວັນມູນຄ່າ $ 80000 (ຫນຶ່ງລາງວັນ $ 20000, ຫນຶ່ງ $ 10000 ລາງວັນ, ສອງ $ 7500 ລາງວັນ, ສີ່ $ 5000 ລາງວັນ, $ 3000 ລາງວັນຫນຶ່ງ, ສອງ $ 2000 ລາງວັນ, ສອງ $ 1000 ແລະສອງ $ 500. $15 ລາງວັນ). ຂະຫນາດຂອງ XNUMX ລາງວັນຍັງບໍ່ທັນໄດ້ຖືກກໍານົດ.

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