ການແຈ້ງເຕືອນການຊຸກຍູ້ທີ່ປອດໄພ: ຈາກທິດສະດີໄປສູ່ການປະຕິບັດ

Hey Habr!

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

ຂ້ອຍ ກຳ ລັງເຜີຍແຜ່ການແປຂອງພວກເຮົາ ບົດຄວາມຈາກ Medium ດ້ວຍການເພີ່ມເຕີມເລັກນ້ອຍຈາກຕົວຂ້ອຍເອງ. ມັນປະກອບດ້ວຍຜົນໄດ້ຮັບຂອງ "ການສືບສວນ" ແລະເລື່ອງກ່ຽວກັບວິທີແກ້ໄຂບັນຫາ.

ພວກເຮົາກວດເບິ່ງອຸປະກອນການ

ໃນຮູບແບບຄລາສສິກ, ການແຈ້ງເຕືອນເຮັດໃຫ້ຜູ້ສົ່ງຂ່າວມີຄວາມສ່ຽງຕໍ່ການໂຈມຕີ MITM (Man-in-the-middle). ຕົວຢ່າງເຊັ່ນ, ກັບ Google, Microsoft, ແລະ iMessage ຮຸ່ນເກົ່າ, ແອັບພລິເຄຊັນຈະສົ່ງລະຫັດການເຂົ້າລະຫັດໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ Apple - ໃນເຊີຟເວີ, ຜູ້ໃຊ້ຖືກກວດສອບແລະສ່ວນຫົວຂໍ້ຄວາມ (ຫຼືເນື້ອຫາຂອງມັນ) ຖືກຖອດລະຫັດ.

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

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

Paranoia ແລະຄວາມຮູ້ສຶກທົ່ວໄປ

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

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

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

ມັນເຮັດວຽກແນວໃດ: ວິດີໂອ.

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

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

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

ພວກ​ເຮົາ​ຍອມ​ຮັບ​ເວີ​ຊັນ​ນີ້​ວ່າ​ໃຊ້​ໄດ້​ແລະ​ປະ​ຕິ​ບັດ​ມັນ​ໃນ​ການ​ປັບ​ປຸງ​ຫລ້າ​ສຸດ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ iOS​.
ຜູ້ທີ່ສົນໃຈໃນດ້ານດ້ານວິຊາການສາມາດເບິ່ງລະຫັດແຫຼ່ງ: github.com/Adamant-im/adamant-notificationService.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com