ລາຍລະອຽດດ້ານວິຊາການກ່ຽວກັບການປິດການໃຊ້ງານຫຼ້າສຸດຂອງ add-ons ໃນ Firefox

ຫມາຍ​ເຫດ​ ຜູ້ແປພາສາ: ເພື່ອຄວາມສະດວກຂອງຜູ້ອ່ານ, ວັນທີແມ່ນໃຫ້ຢູ່ໃນເວລາ Moscow

ເມື່ອບໍ່ດົນມານີ້ພວກເຮົາພາດການໝົດອາຍຸຂອງໜຶ່ງໃນໃບຢັ້ງຢືນທີ່ໃຊ້ເພື່ອເຊັນສ່ວນເສີມ. ອັນນີ້ສົ່ງຜົນໃຫ້ສ່ວນເສີມຖືກປິດການນຳໃຊ້ສຳລັບຜູ້ໃຊ້. ໃນປັດຈຸບັນບັນຫາໄດ້ຖືກແກ້ໄຂສ່ວນໃຫຍ່ແລ້ວ, ຂ້າພະເຈົ້າຢາກແບ່ງປັນລາຍລະອຽດຂອງສິ່ງທີ່ເກີດຂຶ້ນແລະວຽກງານທີ່ໄດ້ເຮັດ.

ຄວາມ​ເປັນ​ມາ​: ການ​ເພີ່ມ​ເຕີມ​ແລະ​ລາຍ​ເຊັນ​

ເຖິງແມ່ນວ່າຫຼາຍຄົນໃຊ້ຕົວທ່ອງເວັບອອກຈາກກ່ອງ, Firefox ສະຫນັບສະຫນູນການຂະຫຍາຍທີ່ເອີ້ນວ່າ "add-ons." ດ້ວຍການຊ່ວຍເຫຼືອຂອງພວກເຂົາ, ຜູ້ໃຊ້ເພີ່ມລັກສະນະຕ່າງໆໃຫ້ກັບຕົວທ່ອງເວັບ. ມີຫຼາຍກວ່າ 15 ພັນ add-ons: ຈາກ ການຂັດຂວາງການໂຄສະນາ ການ ຈັດການຫຼາຍຮ້ອຍແຖບ.

ສ່ວນເສີມທີ່ຕິດຕັ້ງຕ້ອງມີ ລາຍເຊັນດິຈິຕອນ, ເຊິ່ງປົກປ້ອງຜູ້ໃຊ້ຈາກ add-ons ທີ່ເປັນອັນຕະລາຍແລະຮຽກຮ້ອງໃຫ້ມີການທົບທວນຄືນຫນ້ອຍສຸດຂອງ add-ons ໂດຍພະນັກງານ Mozilla. ພວກເຮົາໄດ້ແນະນໍາຄວາມຕ້ອງການນີ້ໃນປີ 2015 ເພາະວ່າພວກເຮົາປະສົບ ບັນຫາຮ້າຍແຮງ ກັບ add-ons ທີ່ເປັນອັນຕະລາຍ.

ມັນເຮັດວຽກແນວໃດ: ທຸກໆສໍາເນົາຂອງ Firefox ມີ "ໃບຢັ້ງຢືນຮາກ". ກຸນແຈຂອງ "ຮາກ" ນີ້ຖືກເກັບໄວ້ໃນ ໂມດູນຄວາມປອດໄພຂອງຮາດແວ (HSM)ໂດຍ​ບໍ່​ມີ​ການ​ເຂົ້າ​ເຖິງ​ເຄືອ​ຂ່າຍ​. ທຸກໆສອງສາມປີ, "ໃບຮັບຮອງລະດັບປານກາງ" ໃຫມ່ຖືກເຊັນດ້ວຍກະແຈນີ້, ເຊິ່ງຖືກນໍາໃຊ້ໃນເວລາລົງນາມໃນ add-ons. ເມື່ອນັກພັດທະນາສົ່ງສ່ວນເສີມ, ພວກເຮົາສ້າງ "ໃບຢັ້ງຢືນການສິ້ນສຸດ" ຊົ່ວຄາວແລະເຊັນມັນໂດຍໃຊ້ໃບຢັ້ງຢືນລະດັບກາງ. Add-on ຕົວຂອງມັນເອງຫຼັງຈາກນັ້ນໄດ້ເຊັນດ້ວຍໃບຢັ້ງຢືນສຸດທ້າຍ. ຕາມແຜນການ ມັນເບິ່ງຄືວ່ານີ້.

ກະລຸນາຮັບຊາບວ່າໃບຢັ້ງຢືນແຕ່ລະອັນມີ "ວິຊາ" (ຜູ້ທີ່ອອກໃບຢັ້ງຢືນ) ແລະ "ຜູ້ອອກ" (ຜູ້ທີ່ອອກໃບຢັ້ງຢືນ). ໃນກໍລະນີຂອງໃບຢັ້ງຢືນຮາກ, "ວິຊາ" = "ຜູ້ອອກ", ແຕ່ສໍາລັບໃບຢັ້ງຢືນອື່ນໆ, ຜູ້ອອກໃບຢັ້ງຢືນແມ່ນຫົວຂໍ້ຂອງໃບຢັ້ງຢືນຂອງພໍ່ແມ່ໂດຍທີ່ມັນຖືກເຊັນ.

ຈຸດສໍາຄັນ: ແຕ່ລະ add-on ແມ່ນເຊັນໂດຍໃບຢັ້ງຢືນການສິ້ນສຸດທີ່ເປັນເອກະລັກ, ແຕ່ເກືອບສະເຫມີໃບຢັ້ງຢືນການສິ້ນສຸດເຫຼົ່ານີ້ຖືກເຊັນໂດຍໃບຢັ້ງຢືນລະດັບກາງດຽວກັນ.

ບັນທຶກຂອງຜູ້ຂຽນ: ຂໍ້ຍົກເວັ້ນແມ່ນການເພີ່ມເກົ່າຫຼາຍ. ໃນເວລານັ້ນ, ໃບຢັ້ງຢືນລະດັບປານກາງຕ່າງໆໄດ້ຖືກນໍາໃຊ້.

ໃບຢັ້ງຢືນລະດັບປານກາງນີ້ເຮັດໃຫ້ເກີດບັນຫາ: ແຕ່ລະໃບຢັ້ງຢືນແມ່ນຖືກຕ້ອງໃນໄລຍະເວລາທີ່ແນ່ນອນ. ກ່ອນ ຫຼືຫຼັງຈາກໄລຍະເວລານີ້, ໃບຢັ້ງຢືນບໍ່ຖືກຕ້ອງ ແລະຕົວທ່ອງເວັບຈະບໍ່ໃຊ້ add-ons ທີ່ເຊັນໂດຍໃບຢັ້ງຢືນນີ້. ແຕ່ຫນ້າເສຍດາຍ, ໃບຢັ້ງຢືນລະດັບປານກາງຫມົດອາຍຸໃນວັນທີ 4 ພຶດສະພາເວລາ 4 ໂມງເຊົ້າ.

ຜົນສະທ້ອນບໍ່ປາກົດໃນທັນທີ. Firefox ບໍ່ໄດ້ກວດເບິ່ງລາຍເຊັນຂອງ add-ons ທີ່ຕິດຕັ້ງຢູ່ສະເຫມີ, ແຕ່ປະມານຫນຶ່ງຄັ້ງໃນທຸກໆ 24 ຊົ່ວໂມງ, ແລະເວລາກວດສອບແມ່ນສ່ວນບຸກຄົນສໍາລັບຜູ້ໃຊ້ແຕ່ລະຄົນ. ດັ່ງນັ້ນ, ບາງຄົນປະສົບບັນຫາທັນທີ, ໃນຂະນະທີ່ຄົນອື່ນປະສົບບັນຫາຫຼາຍຕໍ່ມາ. ພວກເຮົາທໍາອິດໄດ້ຮັບຮູ້ບັນຫາປະມານເວລາທີ່ໃບຢັ້ງຢືນຫມົດອາຍຸແລະທັນທີເລີ່ມຕົ້ນຊອກຫາວິທີແກ້ໄຂ.

ການຫຼຸດຜ່ອນຄວາມເສຍຫາຍ

ເມື່ອພວກເຮົາຮັບຮູ້ສິ່ງທີ່ເກີດຂຶ້ນ, ພວກເຮົາພະຍາຍາມປ້ອງກັນບໍ່ໃຫ້ສະຖານະການຮ້າຍແຮງຂຶ້ນ.

ກ່ອນອື່ນ ໝົດ, ພວກເຂົາຢຸດເຊົາການຍອມຮັບແລະເຊັນບົດບັນທຶກຕື່ມ. ບໍ່ມີຈຸດໃດທີ່ຈະໃຊ້ໃບຮັບຮອງໝົດອາຍຸສຳລັບສິ່ງນີ້. ເມື່ອເບິ່ງຄືນ, ຂ້ອຍຈະເວົ້າວ່າພວກເຮົາສາມາດປະຖິ້ມທຸກຢ່າງຕາມທີ່ມັນເປັນ. ດຽວນີ້ພວກເຮົາໄດ້ສືບຕໍ່ຮັບເອົາການເສີມ.

ອັນທີສອງ, ພວກເຂົາເຈົ້າທັນທີທັນໃດໄດ້ສົ່ງການແກ້ໄຂທີ່ປ້ອງກັນບໍ່ໃຫ້ລາຍເຊັນຈາກການກວດສອບປະຈໍາວັນ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ບັນທຶກຜູ້ໃຊ້ທີ່ຕົວທ່ອງເວັບຍັງບໍ່ທັນມີເວລາທີ່ຈະກວດສອບ add-ons ໃນ XNUMX ຊົ່ວໂມງທີ່ຜ່ານມາ. ການແກ້ໄຂນີ້ໄດ້ຖືກຖອນອອກໃນປັດຈຸບັນແລະບໍ່ຈໍາເປັນ.

ການດໍາເນີນງານຂະຫນານ

ໃນທາງທິດສະດີ, ການແກ້ໄຂບັນຫາເບິ່ງຄືງ່າຍດາຍ: ສ້າງໃບຢັ້ງຢືນລະດັບປານກາງທີ່ຖືກຕ້ອງໃຫມ່ແລະລົງຊື່ໃຫມ່ໃນແຕ່ລະ add-on. ແຕ່ຫນ້າເສຍດາຍ, ນີ້ຈະບໍ່ເຮັດວຽກ:

• ພວກ​ເຮົາ​ບໍ່​ສາ​ມາດ​ໄດ້​ຢ່າງ​ວ່ອງ​ໄວ re-sign 15 ພັນ add-ons ໃນ​ເວ​ລາ​ດຽວ, ລະ​ບົບ​ບໍ່​ໄດ້​ຖືກ​ອອກ​ແບບ​ສໍາ​ລັບ​ການ​ໂຫຼດ​ດັ່ງ​ກ່າວ
• ຫຼັງຈາກທີ່ພວກເຮົາເຊັນການເພີ່ມ, ສະບັບປັບປຸງຈໍາເປັນຕ້ອງໄດ້ສົ່ງໃຫ້ຜູ້ໃຊ້. ສ່ວນເສີມສ່ວນໃຫຍ່ຖືກຕິດຕັ້ງຈາກເຊີບເວີ Mozilla, ດັ່ງນັ້ນ Firefox ຈະຊອກຫາການປັບປຸງພາຍໃນ XNUMX ຊົ່ວໂມງຕໍ່ໄປ, ແຕ່ນັກພັດທະນາບາງຄົນແຈກຢາຍ add-ons ທີ່ເຊັນຜ່ານຊ່ອງທາງພາກສ່ວນທີສາມ, ດັ່ງນັ້ນຜູ້ໃຊ້ຈະຕ້ອງອັບເດດ add-ons ດັ່ງກ່າວດ້ວຍຕົນເອງ.

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

ຂ້ອນຂ້າງໄວ, ພວກເຮົາມາຮອດສອງຍຸດທະສາດຕົ້ນຕໍ, ທີ່ພວກເຮົາໃຊ້ໃນຂະຫນານກັນ:

• ອັບເດດ Firefox ເພື່ອປ່ຽນໄລຍະເວລາຂອງໃບຢັ້ງຢືນ. ນີ້ຈະເຮັດໃຫ້ add-ons ທີ່ມີຢູ່ແລ້ວເຮັດວຽກໄດ້ຢ່າງມະຫັດສະຈັນ, ແຕ່ຈະຮຽກຮ້ອງໃຫ້ມີການປ່ອຍແລະຈັດສົ່ງການກໍ່ສ້າງໃຫມ່ຂອງ Firefox
• ສ້າງໃບຢັ້ງຢືນທີ່ຖືກຕ້ອງແລະບາງອັນໃຫ້ Firefox ຍອມຮັບມັນແທນທີ່ຈະເປັນໃບຮັບຮອງທີ່ມີຢູ່ແລ້ວທີ່ຫມົດອາຍຸ

ພວກເຮົາຕັດສິນໃຈໃຊ້ທາງເລືອກທໍາອິດກ່ອນ, ເຊິ່ງເບິ່ງດີຫຼາຍ. ໃນຕອນທ້າຍຂອງມື້, ພວກເຂົາເຈົ້າໄດ້ອອກການແກ້ໄຂທີສອງ (ໃບຢັ້ງຢືນໃຫມ່), ເຊິ່ງພວກເຮົາຈະເວົ້າກ່ຽວກັບຕໍ່ມາ.

ການປ່ຽນໃບຮັບຮອງ

ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາຂ້າງເທິງ, ມັນຈໍາເປັນຕ້ອງມີ:

• ສ້າງໃບຢັ້ງຢືນທີ່ຖືກຕ້ອງໃຫມ່
• ຕິດຕັ້ງມັນຫ່າງໄກສອກຫຼີກໃນ Firefox

ເພື່ອເຂົ້າໃຈວ່າເປັນຫຍັງອັນນີ້ຈຶ່ງເຮັດວຽກໄດ້, ລອງພິຈາລະນາເບິ່ງຂັ້ນຕອນການຢັ້ງຢືນສ່ວນເສີມ. Add-on ຕົວຂອງມັນເອງມາເປັນຊຸດຂອງໄຟລ໌, ລວມທັງລະບົບຕ່ອງໂສ້ຂອງໃບຢັ້ງຢືນທີ່ໃຊ້ສໍາລັບການເຊັນ. ດັ່ງນັ້ນ, add-on ສາມາດກວດສອບໄດ້ຖ້າຕົວທ່ອງເວັບຮູ້ໃບຢັ້ງຢືນຮາກ, ເຊິ່ງຖືກສ້າງຢູ່ໃນ Firefox ໃນເວລາສ້າງ. ຢ່າງໃດກໍຕາມ, ດັ່ງທີ່ພວກເຮົາຮູ້ແລ້ວ, ໃບຢັ້ງຢືນລະດັບກາງໄດ້ຫມົດອາຍຸ, ດັ່ງນັ້ນມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະກວດສອບ add-on.

ເມື່ອ Firefox ພະຍາຍາມກວດສອບ add-on, ມັນບໍ່ຈໍາກັດພຽງແຕ່ການນໍາໃຊ້ໃບຢັ້ງຢືນທີ່ມີຢູ່ໃນ add-on ຕົວຂອງມັນເອງ. ແທນທີ່ຈະ, ຕົວທ່ອງເວັບພະຍາຍາມສ້າງລະບົບຕ່ອງໂສ້ໃບຢັ້ງຢືນທີ່ຖືກຕ້ອງ, ເລີ່ມຕົ້ນດ້ວຍໃບຢັ້ງຢືນສຸດທ້າຍແລະສືບຕໍ່ຈົນກ່ວາມັນມາຮອດຮາກ. ໃນລະດັບທໍາອິດ, ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍໃບຢັ້ງຢືນການສິ້ນສຸດແລະຫຼັງຈາກນັ້ນຊອກຫາໃບຢັ້ງຢືນທີ່ມີວິຊາທີ່ເປັນຜູ້ອອກໃບຢັ້ງຢືນການສິ້ນສຸດ (ນັ້ນແມ່ນໃບຢັ້ງຢືນລະດັບປານກາງ). ໂດຍປົກກະຕິໃບຮັບຮອງລະດັບປານກາງນີ້ແມ່ນສະໜອງໃຫ້ກັບສ່ວນເສີມ, ແຕ່ໃບຢັ້ງຢືນໃດໆກໍຕາມຈາກບ່ອນເກັບຂໍ້ມູນຂອງບຣາວເຊີຍັງສາມາດໃຊ້ເປັນໃບຮັບຮອງລະດັບປານກາງນີ້ໄດ້. ຖ້າພວກເຮົາຫ່າງໄກສອກຫຼີກສາມາດເພີ່ມໃບຢັ້ງຢືນທີ່ຖືກຕ້ອງໃຫມ່ໃຫ້ກັບຮ້ານໃບຢັ້ງຢືນ, Firefox ຈະພະຍາຍາມໃຊ້ມັນ. ສະຖານະການກ່ອນແລະຫຼັງຈາກການຕິດຕັ້ງໃບຢັ້ງຢືນໃຫມ່.

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

ຫມາຍເຫດຂອງຜູ້ຂຽນ: ຜູ້ອ່ານທີ່ຄຸ້ນເຄີຍກັບ WebPKI ຈະສັງເກດວ່າໃບຢັ້ງຢືນຂ້າມຜ່ານເຮັດວຽກໃນແບບດຽວກັນ.

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

Normandy ແລະລະບົບການຄົ້ນຄວ້າ

Ironically, ບັນຫານີ້ແມ່ນການແກ້ໄຂໂດຍ add-on ພິເສດທີ່ເອີ້ນວ່າ "ລະບົບ". ເພື່ອດໍາເນີນການຄົ້ນຄ້ວາ, ພວກເຮົາໄດ້ພັດທະນາລະບົບທີ່ເອີ້ນວ່າ Normandy ທີ່ສະຫນອງການຄົ້ນຄວ້າໃຫ້ກັບຜູ້ໃຊ້. ການສຶກສາເຫຼົ່ານີ້ຖືກປະຕິບັດໂດຍອັດຕະໂນມັດໃນຕົວທ່ອງເວັບ, ແລະໄດ້ປັບປຸງການເຂົ້າເຖິງ APIs ພາຍໃນຂອງ Firefox. ການຄົ້ນຄວ້າສາມາດເພີ່ມໃບຢັ້ງຢືນໃຫມ່ໃຫ້ກັບຮ້ານໃບຢັ້ງຢືນ.

ບັນທຶກຂອງຜູ້ຂຽນ: ພວກເຮົາບໍ່ໄດ້ເພີ່ມໃບຢັ້ງຢືນທີ່ມີສິດທິພິເສດໃດໆ; ມັນໄດ້ຖືກເຊັນໂດຍໃບຢັ້ງຢືນຮາກ, ດັ່ງນັ້ນ Firefox ໄວ້ວາງໃຈມັນ. ພວກເຮົາພຽງແຕ່ເພີ່ມມັນໃສ່ສະນຸກເກີຂອງໃບຢັ້ງຢືນທີ່ສາມາດນໍາໃຊ້ໄດ້ໂດຍຕົວທ່ອງເວັບ.

ດັ່ງນັ້ນການແກ້ໄຂແມ່ນເພື່ອສ້າງການສຶກສາ:

• ການຕິດຕັ້ງໃບຢັ້ງຢືນໃຫມ່ທີ່ພວກເຮົາສ້າງສໍາລັບຜູ້ໃຊ້
• ບັງຄັບໃຫ້ຕົວທ່ອງເວັບກວດເບິ່ງ add-ons ທີ່ຖືກປິດໃຊ້ງານໃຫມ່ເພື່ອໃຫ້ພວກມັນເຮັດວຽກອີກເທື່ອຫນຶ່ງ

"ແຕ່ລໍຖ້າ," ທ່ານເວົ້າວ່າ, "ສ່ວນເສີມບໍ່ເຮັດວຽກ, ຂ້ອຍຈະເປີດຕົວ add-on ຂອງລະບົບໄດ້ແນວໃດ?" ມາເຊັນໃບຮັບຮອງໃໝ່!

ເອົາມັນທັງຫມົດ ... ເປັນຫຍັງມັນໃຊ້ເວລາຫຼາຍ?

ດັ່ງນັ້ນ, ແຜນການ: ອອກໃບຢັ້ງຢືນໃຫມ່ເພື່ອທົດແທນໃບເກົ່າ, ສ້າງລະບົບ add-on ແລະຕິດຕັ້ງໃຫ້ຜູ້ໃຊ້ຜ່ານ Normandy. ບັນຫາ, ດັ່ງທີ່ຂ້າພະເຈົ້າເວົ້າ, ໄດ້ເລີ່ມຕົ້ນໃນວັນທີ 4 ພຶດສະພາເວລາ 4:00, ແລະແລ້ວໃນເວລາ 12:44 ຂອງມື້ດຽວກັນ, ຫນ້ອຍກວ່າ 9 ຊົ່ວໂມງຕໍ່ມາ, ພວກເຮົາໄດ້ສົ່ງການແກ້ໄຂໄປ Normandy. ມັນໃຊ້ເວລາອີກ 6-12 ຊົ່ວໂມງເພື່ອໃຫ້ມັນເຂົ້າເຖິງຜູ້ໃຊ້ທັງໝົດ. ບໍ່ດີເລີຍ, ແຕ່ຄົນໃນ Twitter ກໍາລັງຖາມວ່າເປັນຫຍັງພວກເຮົາບໍ່ສາມາດປະຕິບັດໄດ້ໄວຂຶ້ນ.

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

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

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

ຂັ້ນຕອນສຸດທ້າຍ

ການຄົ້ນຄວ້າຄວນແກ້ໄຂບັນຫາສໍາລັບຜູ້ໃຊ້ສ່ວນໃຫຍ່, ແຕ່ບໍ່ມີໃຫ້ກັບທຸກຄົນ. ຜູ້ໃຊ້ບາງຄົນຕ້ອງການວິທີການພິເສດ:

• ຜູ້ໃຊ້ທີ່ມີຄວາມພິການການຄົ້ນຄວ້າຫຼື telemetry
• ຜູ້​ໃຊ້​ສະ​ບັບ Android (Fennec​)​, ບ່ອນ​ທີ່​ການ​ຄົ້ນ​ຄວ້າ​ແມ່ນ​ບໍ່​ໄດ້​ສະ​ຫນັບ​ສະ​ຫນູນ​ທັງ​ຫມົດ​
• ຜູ້ໃຊ້ສ້າງ Firefox ESR ແບບກຳນົດເອງໃນວິສາຫະກິດທີ່ບໍ່ສາມາດເປີດໃຊ້ telemetry ໄດ້
• ຜູ້ໃຊ້ທີ່ນັ່ງຢູ່ຫລັງ MitM proxies, ເນື່ອງຈາກວ່າລະບົບການຕິດຕັ້ງ add-on ຂອງພວກເຮົາໃຊ້ key pinning, ເຊິ່ງໃຊ້ບໍ່ໄດ້ກັບ proxies ດັ່ງກ່າວ.
• ຜູ້ໃຊ້ Firefox ລຸ້ນເກົ່າທີ່ບໍ່ຮອງຮັບການຄົ້ນຄວ້າ

ພວກເຮົາບໍ່ສາມາດເຮັດຫຍັງໄດ້ກ່ຽວກັບຜູ້ໃຊ້ປະເພດສຸດທ້າຍ - ພວກເຂົາຍັງຄວນອັບເດດເປັນ Firefox ລຸ້ນໃໝ່, ເພາະວ່າຜູ້ທີ່ລ້າສະໄຫມມີຊ່ອງໂຫວ່ທີ່ບໍ່ໄດ້ຮັບການປັບປຸງ. ພວກເຮົາຮູ້ວ່າບາງຄົນຢູ່ໃນ Firefox ລຸ້ນເກົ່າຍ້ອນວ່າພວກເຂົາຕ້ອງການໃຊ້ add-ons ເກົ່າ, ແຕ່ add-ons ເກົ່າຈໍານວນຫຼາຍໄດ້ຖືກ ported ໄປຫາ browser ຮຸ່ນໃຫມ່ແລ້ວ. ສໍາລັບຜູ້ໃຊ້ອື່ນໆ, ພວກເຮົາໄດ້ພັດທະນາ patch ທີ່ຈະຕິດຕັ້ງໃບຢັ້ງຢືນໃຫມ່. ມັນໄດ້ຖືກປ່ອຍອອກມາເປັນການປ່ອຍ bugfix (ຫມາຍເຫດຂອງຜູ້ແປພາສາ: Firefox 66.0.5), ດັ່ງນັ້ນປະຊາຊົນຈະໄດ້ຮັບມັນ - ສ່ວນຫຼາຍອາດຈະໄດ້ຮັບມັນແລ້ວ - ຜ່ານຊ່ອງທາງການປັບປຸງປົກກະຕິ. ຖ້າທ່ານກໍາລັງໃຊ້ການສ້າງ Firefox ESR ແບບກໍານົດເອງ, ກະລຸນາຕິດຕໍ່ຜູ້ຮັກສາຂອງທ່ານ.

ພວກເຮົາເຂົ້າໃຈວ່ານີ້ບໍ່ເຫມາະສົມ. ໃນບາງກໍລະນີ, ຜູ້ໃຊ້ສູນເສຍຂໍ້ມູນ add-on (ຕົວຢ່າງ, ຂໍ້ມູນ add-on ບັນຊີບັນຊີຫຼາຍບັນຊີ).

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

ບົດຮຽນ

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

ແນ່ນອນ, ບໍ່ມີອັນໃດອັນໜຶ່ງອັນນີ້ບໍ່ຄວນເກີດຂຶ້ນເລີຍ. ມັນຄຸ້ມຄ່າຢ່າງຊັດເຈນທີ່ຈະປັບຂະບວນການຂອງພວກເຮົາເພື່ອຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງເຫດການດັ່ງກ່າວແລະເຮັດໃຫ້ການແກ້ໄຂງ່າຍຂຶ້ນ.

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

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

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

ໃນອາທິດຕໍ່ໄປພວກເຮົາຈະເບິ່ງຜົນໄດ້ຮັບຂອງການວິເຄາະຢ່າງລະອຽດກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ, ແຕ່ໃນຂະນະນີ້ຂ້ອຍຈະຍິນດີທີ່ຈະຕອບຄໍາຖາມທາງອີເມວ: [email protected]

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