Google ຢືນຢັນຂໍ້ຈໍາກັດຂອງ webRequest API ທີ່ໃຊ້ໂດຍຜູ້ສະກັດກັ້ນການໂຄສະນາ

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

ແຮງຈູງໃຈຂອງ Google:

• ໂໝດປິດກັ້ນ API ຄຳຮ້ອງຂໍເວັບ ນໍາໄປສູ່ການບໍລິໂພກຊັບພະຍາກອນສູງ.
  ເມື່ອນໍາໃຊ້ API ນີ້, ຕົວທ່ອງເວັບທໍາອິດຈະສົ່ງ add-on ຂໍ້ມູນທັງຫມົດທີ່ບັນຈຸຢູ່ໃນຄໍາຮ້ອງຂໍເຄືອຂ່າຍ, add-on ວິເຄາະມັນແລະສົ່ງຄືນສະບັບດັດແກ້ສໍາລັບການປຸງແຕ່ງຕໍ່ໄປໃນຕົວທ່ອງເວັບຫຼືບັນຫາການຂັດຂວາງຄໍາແນະນໍາ. ໃນກໍລະນີນີ້, ຄວາມລ່າຊ້າຕົ້ນຕໍແມ່ນບໍ່ໄດ້ຢູ່ໃນຂັ້ນຕອນຂອງການປຸງແຕ່ງການຈະລາຈອນໂດຍ add-on, ແຕ່ເນື່ອງຈາກຄ່າໃຊ້ຈ່າຍເກີນຂອງການປະສານງານການປະຕິບັດຂອງ add-on. ໂດຍສະເພາະ, ການຫມູນໃຊ້ດັ່ງກ່າວຮຽກຮ້ອງໃຫ້ມີການເປີດຕົວຂອງຂະບວນການແຍກຕ່າງຫາກເພື່ອປະກອບ, ເຊັ່ນດຽວກັນກັບການນໍາໃຊ້ IPC ເພື່ອພົວພັນກັບຂະບວນການນີ້ແລະກົນໄກ serialization ຂໍ້ມູນ;

• Add-on ຢ່າງສົມບູນຄວບຄຸມການຈະລາຈອນທັງຫມົດໃນລະດັບຕ່ໍາ, ເຊິ່ງເປີດໂອກາດອັນໃຫຍ່ຫຼວງສໍາລັບການລ່ວງລະເມີດແລະການລະເມີດຄວາມເປັນສ່ວນຕົວ. ອີງຕາມສະຖິຕິຂອງ Google, 42% ຂອງທັງຫມົດທີ່ກວດພົບວ່າ add-ons ທີ່ເປັນອັນຕະລາຍໄດ້ໃຊ້ webRequest API. ມັນໄດ້ຖືກສັງເກດເຫັນວ່າທຸກໆເດືອນ, ຄວາມພະຍາຍາມທີ່ຈະຈັດວາງໂດຍສະເລ່ຍຂອງ 1800 add-ons ທີ່ເປັນອັນຕະລາຍຖືກບລັອກຢູ່ໃນລາຍການ Chrome Web Store. ແຕ່ຫນ້າເສຍດາຍ, ການທົບທວນຄືນບໍ່ອະນຸຍາດໃຫ້ພວກເຮົາຈັບ add-ons ທີ່ເປັນອັນຕະລາຍທັງຫມົດໂດຍບໍ່ມີຂໍ້ຍົກເວັ້ນ, ດັ່ງນັ້ນເພື່ອເສີມຂະຫຍາຍການປົກປ້ອງ, ມັນໄດ້ຖືກຕັດສິນໃຈຈໍາກັດ add-ons ໃນລະດັບ API. ແນວຄວາມຄິດຕົ້ນຕໍແມ່ນເພື່ອໃຫ້ add-ons ເຂົ້າເຖິງບໍ່ແມ່ນການເຂົ້າຊົມທັງຫມົດ, ແຕ່ວ່າພຽງແຕ່ຂໍ້ມູນທີ່ຈໍາເປັນເພື່ອປະຕິບັດຫນ້າທີ່ມີຈຸດປະສົງ. ໂດຍສະເພາະ, ເພື່ອສະກັດເນື້ອຫາ, ມັນບໍ່ຈໍາເປັນຕ້ອງໃຫ້ add-on ເຂົ້າເຖິງຂໍ້ມູນຜູ້ໃຊ້ທີ່ເປັນຄວາມລັບທັງຫມົດ;
• API ປະກາດການທົດແທນທີ່ສະເໜີ declarativeNetRequest ເບິ່ງແຍງທຸກໆວຽກງານຂອງການກັ່ນຕອງເນື້ອຫາທີ່ມີປະສິດທິພາບສູງແລະພຽງແຕ່ຕ້ອງການ add-ons ເພື່ອໂຫລດກົດລະບຽບການກັ່ນຕອງ. ສ່ວນເສີມບໍ່ສາມາດແຊກແຊງການຈະລາຈອນໄດ້ ແລະຂໍ້ມູນສ່ວນຕົວຂອງຜູ້ໃຊ້ຍັງຄົງບໍ່ສາມາດລະເມີດໄດ້;
• Google ໄດ້ພິຈາລະນາຫຼາຍໆຄໍາຄິດຄໍາເຫັນກ່ຽວກັບການຂາດການທໍາງານຂອງ declarativeNetRequest API ແລະຂະຫຍາຍຂອບເຂດຈໍາກັດກ່ຽວກັບຈໍານວນກົດລະບຽບການກັ່ນຕອງຈາກການສະເຫນີໃນເບື້ອງຕົ້ນ 30 ພັນຕໍ່ສ່ວນຂະຫຍາຍໄປສູ່ລະດັບສູງສຸດທົ່ວໂລກຂອງ 150 ພັນ, ແລະຍັງໄດ້ເພີ່ມຄວາມສາມາດໃນການເຄື່ອນໄຫວແບບເຄື່ອນໄຫວ. ປ່ຽນແປງແລະເພີ່ມກົດລະບຽບ, ເອົາແລະປ່ຽນແທນ HTTP headers (Referer, Cookie, Set-Cookie) ແລະຕົວກໍານົດການຮ້ອງຂໍ;
• ສໍາລັບວິສາຫະກິດ, ສາມາດນໍາໃຊ້ຮູບແບບການຂັດຂວາງການເຮັດວຽກຂອງ webRequest API, ເນື່ອງຈາກວ່ານະໂຍບາຍສໍາລັບການນໍາໃຊ້ add-ons ຖືກກໍານົດໂດຍຜູ້ບໍລິຫານທີ່ເຂົ້າໃຈລັກສະນະຂອງໂຄງສ້າງພື້ນຖານແລະຮູ້ເຖິງຄວາມສ່ຽງ. ຕົວຢ່າງ, API ທີ່ກໍານົດໄວ້ສາມາດຖືກນໍາໃຊ້ໃນວິສາຫະກິດເພື່ອບັນທຶກການໄຫຼວຽນຂອງການຈະລາຈອນຂອງພະນັກງານແລະປະສົມປະສານກັບລະບົບພາຍໃນ;
• ເປົ້າຫມາຍຂອງ Google ບໍ່ແມ່ນການທໍາລາຍຫຼືສະກັດກັ້ນການສະກັດກັ້ນການໂຄສະນາ add-ons, ແຕ່ເພື່ອໃຫ້ສາມາດສ້າງຕົວບລັອກໂຄສະນາທີ່ປອດໄພແລະມີອໍານາດຫຼາຍ;
• ຄວາມບໍ່ເຕັມໃຈທີ່ຈະອອກຈາກຮູບແບບການຂັດຂວາງການເຮັດວຽກຂອງ webRequest API ພ້ອມກັບ declarativeNetRequest ໃຫມ່ໄດ້ຖືກອະທິບາຍໂດຍຄວາມປາຖະຫນາທີ່ຈະຈໍາກັດການເຂົ້າເຖິງຂອງ add-ons ກັບຂໍ້ມູນລັບ. ຖ້າທ່ານອອກຈາກ webRequest API ຄືກັນ, addons ສ່ວນໃຫຍ່ຈະບໍ່ໃຊ້ declarativeNetRequest ທີ່ປອດໄພກວ່າ, ເພາະວ່າເມື່ອເລືອກລະຫວ່າງຄວາມປອດໄພແລະຫນ້າທີ່, ຜູ້ພັດທະນາສ່ວນໃຫຍ່ມັກຈະເລືອກຟັງຊັນ.

ຄັດຄ້ານ ນັກພັດທະນາ ເພີ່ມເຕີມ:

• ດໍາເນີນການໂດຍນັກພັດທະນາ add-on ການທົດສອບ ສະແດງໃຫ້ເຫັນຜົນກະທົບໂດຍລວມທີ່ບໍ່ສໍາຄັນຕໍ່ການປະຕິບັດຂອງ add-ons ສະກັດການໂຄສະນາ (ໃນລະຫວ່າງການທົດສອບ, ການປະຕິບັດຂອງ add-ons ຕ່າງໆໄດ້ຖືກປຽບທຽບ, ແຕ່ໂດຍບໍ່ມີການຄໍານຶງເຖິງ overhead ຂອງຂະບວນການເພີ່ມເຕີມທີ່ປະສານງານການປະຕິບັດຂອງ handlers ໃນຮູບແບບການສະກັດ. webRequest API);
• ມັນບໍ່ແມ່ນການປະຕິບັດຢ່າງສົມບູນທີ່ຈະຢຸດການສະຫນັບສະຫນູນ API ທີ່ຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນໃນ add-ons. ແທນທີ່ຈະເອົາມັນອອກ, ທ່ານສາມາດເພີ່ມການອະນຸຍາດແຍກຕ່າງຫາກແລະຄວບຄຸມຢ່າງເຂັ້ມງວດກ່ຽວກັບຄວາມພຽງພໍຂອງການນໍາໃຊ້ຂອງມັນໃນ add-ons, ເຊິ່ງຈະຊ່ວຍປະຢັດຜູ້ຂຽນຂອງ add-ons ທີ່ນິຍົມຫລາຍຈາກການ reworking ຜະລິດຕະພັນຂອງເຂົາເຈົ້າຢ່າງສົມບູນແລະຫຼີກເວັ້ນການທໍາງານຂອງການຕັດ;
• ເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍເກີນ, ທ່ານບໍ່ສາມາດລຶບ API ໄດ້, ແຕ່ remake ມັນໂດຍອີງໃສ່ກົນໄກການ Promise, ຄ້າຍຄືກັບການປະຕິບັດ webRequest ໃນ Firefox;
• ທາງເລືອກທີ່ສະເຫນີ, declarativeNetRequest, ບໍ່ໄດ້ກວມເອົາຄວາມຕ້ອງການຂອງນັກພັດທະນາ add-on ທັງຫມົດສໍາລັບການສະກັດການໂຄສະນາແລະຄວາມປອດໄພ / ຄວາມເປັນສ່ວນຕົວ, ເນື່ອງຈາກວ່າມັນບໍ່ສະຫນອງການຄວບຄຸມການຮ້ອງຂໍເຄືອຂ່າຍຢ່າງເຕັມທີ່, ບໍ່ອະນຸຍາດໃຫ້ນໍາໃຊ້ລະບົບການກັ່ນຕອງແບບກໍານົດເອງ, ແລະບໍ່ອະນຸຍາດໃຫ້. ການ​ນໍາ​ໃຊ້​ລະ​ບຽບ​ສະ​ລັບ​ສັບ​ຊ້ອນ​ທີ່​ຊ້ອນ​ກັນ​ໂດຍ​ອີງ​ໃສ່​ເງື່ອນ​ໄຂ​;
• ກັບສະຖານະປະຈຸບັນຂອງ declarativeNetRequest API, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະສ້າງການເຮັດວຽກທີ່ມີຢູ່ແລ້ວຂອງ uBlock Origin ແລະ uMatrix add-ons ທີ່ບໍ່ປ່ຽນແປງ, ແລະຍັງເຮັດໃຫ້ການພັດທະນາເພີ່ມເຕີມຂອງພອດ NoScript ສໍາລັບ Chrome ບໍ່ມີຈຸດຫມາຍ;
• ຄວາມກັງວົນກ່ຽວກັບຄວາມເປັນສ່ວນຕົວແມ່ນເປັນເລື່ອງໄກຫຼາຍ, ນັບຕັ້ງແຕ່ຮູບແບບການອ່ານເທົ່ານັ້ນ, ບໍ່ປິດກັ້ນຂອງ webRequest API ແມ່ນຖືກປະໄວ້ແລະຍັງອະນຸຍາດໃຫ້ add-ons ທີ່ເປັນອັນຕະລາຍເພື່ອຄວບຄຸມການເຂົ້າຊົມທັງຫມົດ, ແຕ່ບໍ່ໃຫ້ຄວາມສາມາດທີ່ຈະແຊກແຊງມັນຢູ່ໃນ. fly (ປ່ຽນເນື້ອໃນ, ວາງໂຄສະນາຂອງທ່ານ, ດໍາເນີນການຂຸດຄົ້ນບໍ່ແຮ່ແລະການວິເຄາະເນື້ອໃນຂອງແບບຟອມການປ້ອນຂໍ້ມູນສາມາດນໍາໃຊ້ໄດ້ຫຼັງຈາກຫນ້າສໍາເລັດການໂຫຼດ);
• ນັກພັດທະນາຕົວທ່ອງເວັບ Brave, Opera и Vivaldi, ສ້າງຢູ່ໃນເຄື່ອງຈັກ Chromium, ຕັ້ງໃຈທີ່ຈະອອກຈາກການສະຫນັບສະຫນູນສໍາລັບຮູບແບບການສະກັດ webRequest ໃນຜະລິດຕະພັນຂອງພວກເຂົາ.

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