ຄໍາ​ຖາມ​ທີ່​ຖືກ​ຖາມ​ເລື້ອຍໆ

• ເປັນຫຍັງເວັບໄຊທ໌ນີ້ຈຶ່ງແປໄດ້ບໍ່ດີ? ⎃
• ບໍລິການນີ້ປອດໄພແນວໃດ?
• ເປັນຫຍັງຂ້ອຍຈຶ່ງໄດ້ຮັບລິ້ງຢູ່ບ່ອນນີ້ໂດຍມີທາງເລືອກທີ່ຈະຖອດລະຫັດຂໍ້ຄວາມ?
• ທ່ານລຶບທຸກສິ່ງທຸກຢ່າງທີ່ສົ່ງເຂົ້າເວັບນີ້ບໍ?
• ເປັນຫຍັງໃຊ້ບໍລິການນີ້?
• ນີ້ແມ່ນບໍລິການສົ່ງຂໍ້ຄວາມບໍ?
• ຄະດີການ ນຳ ໃຊ້ທີ່ມີຈຸດປະສົງແມ່ນຫຍັງ?
• ບໍລິການນີ້ບໍ່ຄວນໃຊ້ເພື່ອຫຍັງ?
• ເປັນຫຍັງບໍ່ພຽງແຕ່ໃຊ້ PGP / Signal / OMEMO / Matrix / ແລະອື່ນໆ?
• ມີຂໍ້ ກຳ ນົດຫຍັງແດ່?
• ຜູ້ຮັບສາມາດເຮັດ ສຳ ເນົາຂໍ້ຄວາມໄດ້ບໍ່?
• ມີການເກັບ ກຳ ຂໍ້ມູນສ່ວນຕົວບໍ່?
• ຂໍ້ມູນໃດທີ່ຖືກບັນທຶກໄວ້?
• ທ່ານກໍາລັງເຮັດຫຍັງເພື່ອຮັບປະກັນເຄື່ອງແມ່ຂ່າຍ?
• ມີຄວາມສ່ຽງດ້ານຄວາມປອດໄພຫຍັງແດ່ໃນເວລາ ນຳ ໃຊ້ເວັບໄຊທ໌້ນີ້?
• ທ່ານ ກຳ ລັງເຮັດຫຍັງກ່ຽວກັບການໂຈມຕີຂອງຜູ້ຊາຍໃນກາງ (MITM)?
• ຂໍ້ສະ ເໜີ ຂອງການຂະຫຍາຍໂປແກຼມທ່ອງເວັບມີຂໍ້ດີຫຍັງແດ່?
• ຂ້ອຍສາມາດຮູ້ໄດ້ຢ່າງແນ່ນອນວ່າທຸກຢ່າງທີ່ສົ່ງມາຈະຖືກເຂົ້າລະຫັດໃນຕອນທ້າຍແນວໃດ?
• ການເຂົ້າລະຫັດແບບສຸດທ້າຍຈະເຮັດວຽກຢູ່ໃນເວັບໄຊທ໌ນີ້ໄດ້ແນວໃດ?
• ລະຫັດຜ່ານການຖອດລະຫັດສາມາດຢູ່ໃນ URL ໄດ້ບໍ?
• ແຕ່ລະຫັດຖອດລະຫັດບໍ່ຈໍາເປັນຕ້ອງຢູ່ໃນ URL ບໍ?
• ບໍລິການນີ້ບໍ່ສົ່ງລິ້ງໃຫ້ຜູ້ຮັບບໍ?
• ຂ້ອຍສາມາດປົກປ້ອງຄວາມເປັນສ່ວນຕົວຂອງຂ້ອຍໃຫ້ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ແນວໃດໃນຂະນະທີ່ໃຊ້ບໍລິການນີ້?
• ຈະເປັນແນວໃດຖ້າຂ້ອຍບໍ່ເຊື່ອໃຈສະຫະລັດ?
• ທ່ານ ກຳ ລັງເຮັດຫຍັງເພື່ອປ້ອງກັນສະແປມ?
• ເປັນຫຍັງຈຶ່ງມີທາງເລືອກທີ່ຈະຮຽກຮ້ອງໃຫ້ຜູ້ຮັບເຮັດ CAPTCHA ສຳ ເລັດ?
• ໃຜ ກຳ ລັງໃຊ້ບໍລິການນີ້ແລະເປັນຫຍັງມັນບໍ່ເສຍຄ່າ?
• ຂ້ອຍຈະເຊື່ອ ຄຳ ຕອບຕໍ່ ຄຳ ຖາມຂ້າງເທິງນີ້ໄດ້ແນວໃດ?

ເປັນຫຍັງເວັບໄຊທ໌ນີ້ຈຶ່ງແປໄດ້ບໍ່ດີ? ⎃

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

ບໍລິການນີ້ປອດໄພແນວໃດ?

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

• ໃນຂະນະທີ່ ພວກເຮົາບໍ່ສາມາດອ່ານຂໍ້ຄວາມຂອງທ່ານໄດ້ເນື່ອງຈາກການເຂົ້າລະຫັດແບບສິ້ນສຸດ , ການເຊື່ອມຕໍ່ແບບເລີ່ມຕົ້ນທີ່ ບັນຈຸມີລະຫັດລັບ / ລະຫັດຖອດລະຫັດ ; ແລະດັ່ງນັ້ນ, ຜູ້ໃດທີ່ມີລິ້ງສາມາດອ່ານຂໍ້ຄວາມຂອງທ່ານ - ລວມທັງຜູ້ໃດທີ່ສາມາດສະກັດກັ້ນມັນໄດ້.
• ການບໍລິການນີ້ແມ່ນພຽງແຕ່ເຄື່ອງມືຊ່ວຍໃຫ້ການສົ່ງການສື່ສານແບບຖາວອນ ໜ້ອຍ ລົງ (ໝາຍ ເຖິງຂໍ້ຄວາມທີ່ຖືກເຂົ້າລະຫັດທີ່ຖືກລຶບຖິ້ມເມື່ອກັບມາ) ໂດຍຜ່ານການຂົນສົ່ງແບບດັ້ງເດີມທີ່ມີຄວາມຖາວອນກວ່າເກົ່າ (ຕົວຢ່າງ: ອີເມວ / ຂໍ້ຄວາມ / ການສົ່ງຂໍ້ຄວາມ / ເວບໄຊທ໌ / ອື່ນໆ). ນີ້ຫມາຍຄວາມວ່າ ບັນຫາຄວາມປອດໄພ / ຄວາມເປັນສ່ວນຕົວໃດໆກ່ຽວຂ້ອງກັບການຂົນສົ່ງທີ່ເລືອກ (ຕົວຢ່າງ: ອີເມວ) ແມ່ນຖືກສືບທອດມາເມື່ອທ່ານໃຊ້ເຄື່ອງມືນີ້ .
• ມີ ວິທີແກ້ໄຂອື່ນອີກ ທີ່ສະ ເໜີ ຄວາມປອດໄພດີຂື້ນກັບຄວາມຕ້ອງການແລະສະພາບແວດລ້ອມຂອງທ່ານ. ປະໂຫຍດຕົ້ນຕໍທີ່ບໍລິການນີ້ສະ ເໜີ ໃຫ້ທຽບກັບຄົນອື່ນ, ແມ່ນ ຂໍ້ ກຳ ນົດທີ່ ຕ່ ຳ ກວ່າ ສຳ ລັບຜູ້ຮັບ (ເຊັ່ນວ່າພວກເຂົາພຽງແຕ່ຕ້ອງການຕົວທ່ອງເວັບແລະຄວາມສາມາດທີ່ຈະກົດລິ້ງ).
• ໃນຂະນະທີ່ການຕັ້ງຄ່າເລີ່ມຕົ້ນແມ່ນການລຶບຂໍ້ຄວາມເມື່ອກັບມາ, ມັນບໍ່ມີຫຍັງທີ່ຈະຢຸດຢັ້ງຜູ້ຮັບຈາກການເຮັດ ສຳ ເນົາ . ຈົ່ງຈື່ໄວ້ວ່າສິ່ງນີ້ ນຳ ໃຊ້ກັບທຸກໆການແກ້ໄຂຂໍ້ຄວາມຊົ່ວຄາວ - ຖ້າຜູ້ຮັບສາມາດເບິ່ງຂໍ້ຄວາມໄດ້, ມັນສາມາດຖືກຄັດລອກໄດ້.
• ທຸກໆການສື່ສານທາງອິນເຕີເນັດສາມາດປະນີປະນອມຄວາມເປັນສ່ວນຕົວຂອງທ່ານ - ທ່ານ ກຳ ລັງຊື້ຂາຍຄວາມປອດໄພບາງຢ່າງເພື່ອຄວາມສະດວກສະບາຍ.
• ເວັບແມ່ນສະພາບແວດລ້ອມທີ່ທ້າທາຍເມື່ອເວົ້າເຖິງຄວາມປອດໄພ ຍ້ອນບັນຫາພື້ນຖານບາງຢ່າງ - ນີ້ໃຊ້ໄດ້ກັບທຸກເວັບໄຊທ໌້. ເຖິງຢ່າງໃດກໍ່ຕາມ, ການໃຊ້ເວບໄຊທ໌ແມ່ນເຮັດໃຫ້ ການຢັ້ງຢືນ ຄຳ ຮຽກຮ້ອງຂອງພວກເຮົາວ່າພວກເຮົາບໍ່ສາມາດອ່ານຂໍ້ຄວາມຂອງທ່ານໄດ້ງ່າຍຂຶ້ນ .
• ເວບໄຊທ໌ນີ້ແລະຖານຂໍ້ມູນຂອງມັນຖືກຈັດຢູ່ໃນສະຫະລັດອາເມລິກາ. ພວກເຮົາ ນຳ ໃຊ້ Cloudflare, ເຊິ່ງເປັນບໍລິສັດທີ່ຕັ້ງຢູ່ໃນສະຫະລັດອາເມລິກາ, ເປັນເຄືອຂ່າຍເນື້ອຫາຂອງພວກເຮົາ - ການຈັດສົ່ງເຄືອຂ່າຍ (ທຸກການຈາລະຈອນທາງເວັບຜ່ານເຄືອຂ່າຍນີ້).

ເປົ້າ ໝາຍ ຂອງພວກເຮົາແມ່ນໃຫ້ບໍລິການນີ້ໃນແບບທີ່ມີທາງເລືອກຕ່າງໆເພື່ອເພີ່ມຄວາມເປັນສ່ວນຕົວແລະຄວາມປອດໄພຂອງທ່ານ. ນີ້ແມ່ນບາງບາດກ້າວທີ່ພວກເຮົາໄດ້ປະຕິບັດເພື່ອປົກປ້ອງຂໍ້ມູນຂອງທ່ານ:

• ການ ນຳ ໃຊ້ບໍລິການບໍ່ ຈຳ ເປັນຕ້ອງມີຂໍ້ມູນສ່ວນຕົວໃດໆ (ເຊັ່ນ: ຊື່ / ອີເມວ / ໂທລະສັບ / ອື່ນໆ.) ບໍ່ມີລະບົບບັນຊີ (ເຊັ່ນການເຂົ້າລະບົບ / ລະຫັດຜ່ານ / ອື່ນໆ.); ດັ່ງນັ້ນ, ການລະເມີດຂໍ້ມູນໃດໆກໍ່ບໍ່ສາມາດຮົ່ວໄຫລຂໍ້ມູນນີ້.
• ເນື້ອໃນຂອງຂໍ້ຄວາມທັງ ໝົດ ແມ່ນຖືກເຂົ້າລະຫັດຈົນເຖິງສິ້ນສຸດ . ເວົ້າອີກຢ່າງ ໜຶ່ງ, ລະຫັດຖອດລະຫັດ / ລະຫັດຜ່ານບໍ່ເຄີຍຖືກສົ່ງມາຫາພວກເຮົາເລີຍ. ດັ່ງນັ້ນ, ພວກເຮົາ, ຫລືຜູ້ອື່ນທີ່ເປັນເຈົ້າຂອງຖານຂໍ້ມູນ, ບໍ່ມີວິທີໃດທີ່ຈະຖອດລະຫັດແລະເບິ່ງເນື້ອໃນຂໍ້ຄວາມ.
• ທຸກໆການເຂົ້າໃນຖານຂໍ້ມູນຂອງພວກເຮົາມີການໃຊ້ເວລາໃນການ ດຳ ລົງຊີວິດຕັ້ງແຕ່ 1 ນາທີເຖິງ 2 ອາທິດ (ຄ່າເລີ່ມຕົ້ນເຖິງ 1 ອາທິດ). ເມື່ອເວລານີ້ຜ່ານໄປ, ບັນທຶກຈະຖືກລຶບໂດຍອັດຕະໂນມັດ. ເພາະສະນັ້ນ, ຂໍ້ມູນໃດໆໃນຖານຂໍ້ມູນຂອງພວກເຮົາຈະຖືກລຶບອອກໄວໆຫລັງຈາກສ້າງ .
• ພວກເຮົາຮັກສາພຽງ 24 ຊົ່ວໂມງສຸດທ້າຍຂອງບັນທຶກຂອງເວັບເຊີຟເວີ . ຂໍ້ມູນຂ່າວສານ IP ໃດໆທີ່ເກັບໄວ້ໃນຖານຂໍ້ມູນແມ່ນເຮັດໃຫ້ມີຄວາມປອດໄພເຮັດໃຫ້ບໍ່ສາມາດສະກັດ IP ເດີມໄດ້.
• ລະຫັດທັງ ໝົດ ທີ່ເຮັດໃຫ້ການບໍລິການນີ້ແມ່ນແຫຼ່ງເປີດແລະມີການທົບທວນຄືນ. ທ່ານສາມາດເບິ່ງລະຫັດທີ່ເຮັດວຽກການເຂົ້າລະຫັດໄດ້ງ່າຍ - ເຊິ່ງມັນມີຈຸດປະສົງສັ້ນ, ສະຫລຸບແລະມີ ຄຳ ເຫັນ.
• ລະມັດລະວັງດ້ານວິຊາການໄດ້ຖືກປະຕິບັດເພື່ອຊ່ວຍສ້າງຄວາມເຂັ້ມແຂງໃນການຮັກສາຄວາມປອດໄພ - ເຊິ່ງບາງຢ່າງປະກອບມີ:
  • ເວບໄຊທ໌ທັງ ໝົດ ນີ້ນອກ ເໜືອ ຈາກ / api ແມ່ນຄົງທີ່ແລະບໍ່ສະ ໜັບ ສະ ໜູນ ລະຫັດເຊີບເວີໃນ ໜ້າ ຕ່າງໆ (ເຊັ່ນ: PHP / JSP / ASP / etc.)
  • Web Crypto API , ເຊິ່ງເປັນສ່ວນ ໜຶ່ງ ຂອງໂປຣແກຣມທ່ອງເວັບ, ຖືກໃຊ້ເພື່ອເຂົ້າລະຫັດເນື້ອຫາຂອງຂໍ້ຄວາມທັງ ໝົດ.
  • TLS ຖືກໃຊ້ເພື່ອເຂົ້າລະຫັດການສື່ສານລະຫວ່າງ browser ແລະ server ຂອງພວກເຮົາ. ມັນຊ່ວຍໃຫ້ແນ່ໃຈວ່າລະຫັດບໍ່ສາມາດສະກັດຫລືດັດແກ້ໃນການຂົນສົ່ງ. TLS 1.3 ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ, ແຕ່ພວກເຮົາຍັງສະ ໜັບ ສະ ໜູນ TLS 1.2 ສຳ ລັບອຸປະກອນເກົ່າ. ລຸ້ນເກົ່າຂອງ TLS ຖືກປິດໃຊ້ງານເພາະວ່າມັນບໍ່ປອດໄພ.
  • ບັນທຶກຄວາມໂປ່ງໃສຂອງໃບຢັ້ງຢືນ ຖືກຕິດຕາມກວດກາ ສຳ ລັບການກວດສອບທີ່ບໍ່ຖືກຕ້ອງຂອງໃບຢັ້ງຢືນ. ນອກຈາກນັ້ນພວກເຮົາເຜີຍແຜ່ ນະໂຍບາຍການອະນຸຍາດຂອງເຈົ້າ ໜ້າ ທີ່ກ່ຽວກັບການຢັ້ງຢືນ (CAA) ເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການອອກໃບຢັ້ງຢືນທີ່ບໍ່ໄດ້ຕັ້ງໃຈຫຼືເປັນອັນຕະລາຍ.
  • ພວກເຮົາ ນຳ ໃຊ້ ຄວາມປອດໄພດ້ານການຂົນສົ່ງທີ່ເຄັ່ງຄັດ HTTP (HSTS) ເພື່ອຮັບປະກັນວ່າຕົວທ່ອງເວັບຕ່າງໆຕິດຕໍ່ສື່ສານກັບເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາສະ ເໝີ ໂດຍໃຊ້ໂປຣແກຣມ TLS. ນອກຈາກນັ້ນ, ພວກເຮົາລວມເອົາໂດເມນຂອງພວກເຮົາໃນບັນຊີ preload .
  • ນະໂຍບາຍຄວາມປອດໄພດ້ານເນື້ອຫາ ທີ່ເຄັ່ງຄັດຖືກບັງຄັບໃຊ້ເພື່ອປ້ອງກັນ ການໂຈມຕີ Cross Site Scripting (XSS) .
  • ໂດຍການ ນຳ ໃຊ້ ນະໂຍບາຍຊັບພະຍາກອນຂ້າມຕົ້ນ ກຳ ເນີດ , ນະໂຍບາຍຂ້າມຕົ້ນ ກຳ ເນີດ , ແລະ ນະໂຍບາຍເປີດຕົ້ນ ກຳ ເນີດ , ພວກເຮົາຫ້າມລະຫັດຕົ້ນ ກຳ ເນີດຂ້າມແດນເພື່ອຊ່ວຍຫຼຸດຜ່ອນການໂຈມຕີທາງຂ້າງທີ່ຄາດເດົາເຊັ່ນ Spectre ແລະ Meltdown. ນີ້ຍັງໃຫ້ການປົກປ້ອງຕໍ່ກັບ ຄຳ ຮ້ອງຂໍທີ່ເປັນອັນຕະລາຍທີ່ມາຈາກຕົ້ນ ກຳ ເນີດອື່ນໆໂດຍແຍກສະພາບການຊອກຫາໂດຍສະເພາະກັບເອກະສານຕົ້ນສະບັບດຽວກັນ.
  • ພວກເຮົາ ນຳ ໃຊ້ ນະໂຍບາຍການອະນຸຍາດ ເພື່ອປ້ອງກັນຕົວທ່ອງເວັບຈາກການໂຫຼດຊັບພະຍາກອນທີ່ສາມາດ ທຳ ລາຍຄວາມເປັນສ່ວນຕົວຂອງທ່ານເຊັ່ນ: ສະຖານທີ່ຂອງທ່ານ, web-cam, microphone, ແລະອື່ນໆ.
  • DNSSEC ຖືກ ນຳ ໃຊ້ໃນທຸກໆໂດເມນຂອງພວກເຮົາເພື່ອຊ່ວຍຫຼຸດຜ່ອນການໂຈມຕີ MITM ທີ່ອີງໃສ່ DNS.
  • ພວກເຮົາປະຕິບັດການລະມັດລະວັງຫຼາຍຢ່າງເພື່ອຮັບປະກັນເຄື່ອງແມ່ຂ່າຍ.
  • ບໍ່ມີລະຫັດຂອງບຸກຄົນທີ 3 ທີ່ຖືກໂຫລດ (ຕົວຢ່າງ jQuery) ແລະມີຊັບພະຍາກອນຫນ້ອຍທີ່ສຸດທີ່ຖືກໂຫລດ (ສືບຕໍ່ເດີນຫນ້າແລະເປີດແຖບ Network ໃນ Dev Tools ເພື່ອກວດສອບ) - ນີ້ຊ່ວຍຫຼຸດຜ່ອນຄວາມພະຍາຍາມທີ່ ຈຳ ເປັນໃນການກວດສອບ. ຂໍ້ຍົກເວັ້ນອັນ ໜຶ່ງ ແມ່ນຖ້າຕ້ອງການ CAPTCHA - ເຊິ່ງໂຫລດລະຫັດຂອງບຸກຄົນທີ 3 ຈາກ hCaptcha . ເຖິງຢ່າງໃດກໍ່ຕາມ, ລະຫັດ hCaptcha ຈະໂຫລດຢູ່ໃນ URL ຂອງມັນຢູ່ພາຍໃນກົດລະບຽບ CSP ຂອງມັນເອງແລະບໍ່ມີເວລາໃດທີ່ສາມາດເຂົ້າເຖິງຂໍ້ຄວາມໃດໆເລີຍ.
  • ໃນຖານະເປັນວິທີການເພື່ອຊ່ວຍປ້ອງກັນຄວາມປອດໄພຈາກ ການໂຈມຕີຂອງ MITM , ມີ ການຂະຫຍາຍໂປແກຼມທ່ອງເວັບຕ່າງໆ .

ເປັນຫຍັງຂ້ອຍຈຶ່ງໄດ້ຮັບລິ້ງຢູ່ບ່ອນນີ້ໂດຍມີທາງເລືອກທີ່ຈະຖອດລະຫັດຂໍ້ຄວາມ?

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

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

ທ່ານລຶບທຸກສິ່ງທຸກຢ່າງທີ່ສົ່ງເຂົ້າເວັບນີ້ບໍ?

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

• ຂໍ້ຄວາມເຂົ້າລະຫັດທີ່ພວກເຮົາບໍ່ມີວິທີໃດທີ່ຈະຖອດລະຫັດເນື້ອໃນ
• ຂໍ້ມູນອື່ນໆທີ່ມີຢູ່ໃນການສົ່ງສິ່ງໃດສິ່ງ ໜຶ່ງ ໃນເວັບ (ເຊັ່ນ: ທີ່ຢູ່ IP ຂອງທ່ານ, ແລະອື່ນໆ)

ໃນກໍລະນີຂອງຂໍ້ຄວາມ, ທ່ານສາມາດຄວບຄຸມໄດ້ເມື່ອພວກເຮົາລຶບພວກມັນໂດຍລະບຸ:

• ພວກເຮົາຄວນຈະຮັກສາຂ່າວສານໄວ້ດົນປານໃດຖ້າບໍ່ມີໃຜເອົາຂ່າວສານນັ້ນ (ຕັ້ງແຕ່ 1 ນາທີເຖິງ 2 ອາທິດ - ເລີ່ມຕົ້ນຈົນເຖິງ 1 ອາທິດ).
• ມີ ຈຳ ນວນເທົ່າໃດໃນການສົ່ງຂໍ້ຄວາມ (ນັບແຕ່ 1 ເຖິງ 100 ຄັ້ງ - ຄ່າເລີ່ມຕົ້ນເຖິງ 1 ຄັ້ງ)

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

ເປັນຫຍັງໃຊ້ບໍລິການນີ້?

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

ນີ້ແມ່ນບໍລິການສົ່ງຂໍ້ຄວາມບໍ?

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

ຄະດີການ ນຳ ໃຊ້ທີ່ມີຈຸດປະສົງແມ່ນຫຍັງ?

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

• ທ່ານໄດ້ຕິດຕໍ່ສື່ສານຜ່ານເວບໄຊທ໌ທ້ອງຖິ່ນກ່ຽວກັບການຂີ່ລົດຖີບຕາມພູໃນບໍລິເວນນັ້ນແລະບາງຄັ້ງກໍ່ພົບປະກັບຜູ້ຄົນໃນເວທີສົນທະນາເພື່ອກວດກາເສັ້ນທາງ ໃໝ່ ນຳ ກັນ. ມີບາງຄົນຈາກຫ້ອງສົນທະນາຢາກໃຫ້ທ່ານໄປສະຖານທີ່ຂອງທ່ານທີ່ຈະຈອດລົດໄປກັບເສັ້ນທາງໃນທ້າຍອາທິດນີ້. ທ່ານບໍ່ຕ້ອງການໃຫ້ທີ່ຢູ່ເຮືອນຂອງທ່ານນັ່ງຢູ່ໃນຖານຂໍ້ມູນເວບໄຊທ໌ເວບນີ້ຕະຫຼອດໄປ. ພຽງແຕ່ສົ່ງທີ່ຢູ່ຜ່ານບໍລິການນີ້ - ລິ້ງແມ່ນສິ່ງທີ່ຢູ່ໃນຖານຂໍ້ມູນເວບໄຊທ໌ເວບໄຊທ໌, ແຕ່ເມື່ອອ່ານໂດຍຜູ້ຮັບ, ຂໍ້ຄວາມ / ທີ່ຢູ່ຈະຖືກລຶບອອກ.
• ທ່ານ ຈຳ ເປັນຕ້ອງສົ່ງນ້ອງຊາຍເຂົ້າລະບົບ Netflix ຂອງທ່ານເພາະວ່ານ້ອງສາວຂອງທ່ານ ກຳ ລັງເຮັດໃຫ້ລາວເປັນບ້າຍ້ອນການປິດລ້ອມ COVID ແລະລາວຍັງບໍ່ມີບັນຊີຂອງລາວຢູ່. ທ່ານບໍ່ສົນໃຈການເຂົ້າສູ່ລະບົບນີ້ຫລາຍເກີນໄປ, ແຕ່ອ້າຍຂອງທ່ານບໍ່ດີໂດຍສະເພາະສິ່ງທີ່ຂ້າພະເຈົ້າພຽງແຕ່ຈະເອີ້ນວ່າ "ສຸຂະອະນາໄມດິຈິຕອລ" ແລະເຄີຍມີການທົດລອງຫລາຍຢ່າງກັບການເຂົ້າສູ່ລະບົບທີ່ຖືກ ທຳ ລາຍ. ຄວາມພະຍາຍາມຕໍ່ມາເພື່ອເຮັດໃຫ້ລາວ ທຳ ຄວາມສະອາດການກະ ທຳ ຂອງລາວແລະແມ່ນແຕ່ການຕິດຕັ້ງການສົ່ງຂໍ້ຄວາມທີ່ປອດໄພ ສຳ ລັບລາວກໍ່ບໍ່ໄດ້ຕິດຂັດ. ການສົ່ງຂໍ້ຄວາມງ່າຍໆຜ່ານທາງຂໍ້ຄວາມອາດຈະເປັນທາງເລືອກທີ່ດີທີ່ສຸດ (ໜ້າ ເສົ້າໃຈ), ແຕ່ວ່າທ່ານບໍ່ສະບາຍໃຈທີ່ມີການເຂົ້າສູ່ລະບົບນັ້ນໃນປະຫວັດຂໍ້ຄວາມຂອງລາວຍ້ອນປະສົບການທີ່ຜ່ານມາ. ການໃຊ້ບໍລິການນີ້ເພື່ອສົ່ງເຂົ້າສູ່ລະບົບຜ່ານທາງລິງໃນຂໍ້ຄວາມທີ່ພໍໃຈບໍ່ໃຫ້ການເຂົ້າສູ່ລະບົບຖືກປິດຕະຫຼອດໄປໃນປະຫວັດການສົນທະນາຂອງລາວ.
• ບາງຄັ້ງທ່ານເຮັດວຽກຢູ່ຫ້ອງການທີ່ມີຜູ້ເຊົ່າເຮືອນຫຼາຍຄົນທີ່ມາແລະໄປຕະຫຼອດເວລາ. ມີ WiFi ສາມາດໃຊ້ໄດ້, ແຕ່ລະຫັດລັບຖືກ ໝູນ ວຽນທຸກໆອາທິດນັບຕັ້ງແຕ່ມີບັນຫາໃນການລ່ວງລະເມີດ. ຜູ້ເຊົ່າຫຼາຍຄົນອີເມວ / ຂໍ້ຄວາມທີ່ຖາມຫາລະຫັດຜ່ານ WiFi ເຖິງແມ່ນວ່າມັນຈະຢູ່ທີ່ໂຕະທາງ ໜ້າ ເພາະວ່າສ່ວນໃຫຍ່ບໍ່ເຂົ້າຜ່ານທາງເຂົ້າຫລັກ. ການ ນຳ ໃຊ້ບໍລິການນີ້, ຜູ້ຈັດການຫ້ອງການສາມາດສົ່ງລະຫັດຜ່ານ WiFi ຜ່ານທາງລິງໃນອີເມວ / ຂໍ້ຄວາມຕອບກັບຄວາມພໍໃຈບໍ່ໃຫ້ລະຫັດຜ່ານລະຫັດຜ່ານ, ແລະຍັງຊ່ວຍໃຫ້ຜູ້ຮັບເອົາລະຫັດຜ່ານໄດ້ທັນທີໂດຍກົດປຸ່ມ ສຳ ເນົາເຊິ່ງບໍ່ຄ່ອຍເວົ້າກ່ຽວກັບອຸປະກອນມືຖື.
• ໜຶ່ງ ໃນຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງຂອງທ່ານ ກຳ ລັງຮ້ອງຂໍໃຫ້ທ່ານມີລາຍລະອຽດກ່ຽວກັບເຊີບເວີທີ່ທ່ານໄດ້ລາຍງານມາແມ່ນສະແດງອາການຂອງຮາດດິດທີ່ປະກົດວ່າບໍ່ດີ. ບາງຂໍ້ມູນທີ່ພວກເຂົາຕ້ອງການແມ່ນມີຄວາມລະອຽດອ່ອນ - ທ່ານບໍ່ຕ້ອງການໃຫ້ມັນນັ່ງຕະຫຼອດໄປໃນລະບົບປີ້ພັກທີ 3 ທີ່ພວກເຂົາໃຊ້. ການ ນຳ ໃຊ້ບໍລິການນີ້, ທ່ານສາມາດສົ່ງຂໍ້ມູນໄປຫານັກວິຊາການທີ່ໃຫ້ການສະ ໜັບ ສະ ໜູນ ໂດຍບໍ່ ຈຳ ເປັນຕ້ອງອາໄສຢູ່ໃນລະບົບປີ້. ເນື່ອງຈາກນັກວິຊາການຫຼາຍຄົນອາດຈະຕ້ອງອ້າງອີງເຖິງຂໍ້ມູນຫຼາຍໆຄັ້ງ, ໃຫ້ຕັ້ງຄ່າການອ່ານເພື່ອ ດຳ ລົງຊີວິດທີ່ໃຫຍ່ກວ່າ 1 (ເຊັ່ນວ່າອາດຈະເປັນ 20 ປີ) ເພື່ອບໍ່ໃຫ້ຂໍ້ຄວາມຖືກລຶບອອກໃນຄັ້ງ ທຳ ອິດ.
• ທ່ານຕ້ອງການສົ່ງຂໍ້ຄວາມສ່ວນຕົວໃຫ້ຜູ້ໃຊ້ອື່ນໃນ Reddit ເພື່ອແຈ້ງໃຫ້ພວກເຂົາຮູ້ເບີໂທລະສັບຂອງທ່ານເພື່ອໃຫ້ພວກເຂົາໂທຫາທ່ານ. Reddit, ຄືກັບຜູ້ໃຫ້ບໍລິການອື່ນໆ, ໄດ້ຮົ່ວຂໍ້ມູນຜູ້ໃຊ້ໃນອະດີດແລະທ່ານບໍ່ຕ້ອງການເບີໂທລະສັບຂອງທ່ານພຽງແຕ່ນັ່ງຢູ່ໃນຖານຂໍ້ມູນຂອງ Reddit ເປັນເວລາຫຼາຍປີຈົນກວ່າຈະມີການຮົ່ວໄຫຼຄັ້ງຕໍ່ໄປ. ພຽງແຕ່ສົ່ງເບີໂທລະສັບຂອງທ່ານຜ່ານບໍລິການນີ້.
• ຄູ່ສົມລົດຂອງທ່ານສົ່ງຂໍ້ຄວາມໃຫ້ທ່ານໃນຂະນະທີ່ທ່ານຢູ່ບ່ອນເຮັດວຽກຕ້ອງການໃຫ້ຜູ້ໃຊ້ເຂົ້າໃຊ້ງານເພາະວ່າເພື່ອນຂອງນາງພຽງແຕ່ພະຍາຍາມໃຊ້ໂປແກຼມ ໃໝ່ ທີ່ຊ່ວຍປະຢັດເງິນຂອງທ່ານໃນໃບເກັບເງິນຄ່າໄຟຟ້າຂອງນາງແລະນາງຕ້ອງການກວດສອບມັນ. ມີຜູ້ຈັດການລະຫັດຜ່ານຂອງຄອບຄົວທີ່ທ່ານໄດ້ເຕືອນທ່ານ, ແຕ່ນາງພຽງແຕ່ຕ້ອງການໃຫ້ທ່ານສົ່ງລະບົບເຂົ້າສູ່ລະບົບ. OMEMO ມີວຽກເຮັດງານ ທຳ ໃນການສົ່ງຂໍ້ຄວາມດ່ວນກັບຄູ່ສົມລົດຂອງທ່ານແລະດັ່ງນັ້ນທ່ານຈຶ່ງຮູ້ສຶກ ໝັ້ນ ໃຈວ່າການຂົນສົ່ງຂໍ້ຄວາມມີຄວາມປອດໄພ; ເຖິງຢ່າງໃດກໍ່ຕາມ, ປະຫວັດການສົນທະນາຂອງມັນເອງຖືກເກັບໄວ້ໂດຍບໍ່ໄດ້ເຂົ້າລະຫັດ. ຄູ່ສົມລົດຂອງທ່ານບໍ່ມີຄວາມລະມັດລະວັງກ່ຽວກັບການດາວໂຫຼດ, ອີເມວ, ແລະອື່ນໆແລະໃບບິນຄ່າໃຊ້ຈ່າຍແມ່ນມີຄວາມລະອຽດອ່ອນຫຼາຍເພາະວ່າພວກມັນສາມາດຖືກ ນຳ ໃຊ້ເພື່ອລັກຂະໂມຍຕົວຕົນເພື່ອພິສູດທີ່ຢູ່ອາໄສ. ທ່ານສາມາດສົ່ງລາຍລະອຽດເຂົ້າສູ່ລະບົບຂອງນາງໂດຍໃຊ້ບໍລິການນີ້ເພື່ອຫລີກລ້ຽງ ສຳ ເນົາທີ່ຖືກເກັບຢູ່ໃນຄອມພິວເຕີ້ຂອງນາງ.

ບໍລິການນີ້ບໍ່ຄວນໃຊ້ເພື່ອຫຍັງ?

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

• ຢ່າໃຊ້ບໍລິການນີ້ເພື່ອເຮັດໃຫ້ການຂົນສົ່ງຂໍ້ຄວາມທີ່ບໍ່ ເໝາະ ສົມ“ ປອດໄພກວ່າ”. ເນື່ອງຈາກວ່າການຕັ້ງຄ່າເລີ່ມຕົ້ນແມ່ນການໃສ່ລະຫັດຜ່ານໃນ URL ທີ່ສາມາດອ່ານຂໍ້ຄວາມໄດ້, ທຸກຄົນທີ່ມີລິ້ງສາມາດອ່ານຂໍ້ຄວາມໄດ້. ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ບັນຫາດ້ານຄວາມປອດໄພ / ຄວາມເປັນສ່ວນຕົວໃດໆທີ່ກ່ຽວຂ້ອງກັບການຂົນສົ່ງທີ່ເລືອກ (ເຊັ່ນຂໍ້ຄວາມ) ແມ່ນຖືກສືບທອດມາເມື່ອທ່ານໃຊ້ເຄື່ອງມືນີ້. ດັ່ງນັ້ນ, ຕົວຢ່າງ, ຖ້າທ່ານບໍ່ເຄີຍຄິດທີ່ຈະໃຊ້ອີເມວເພື່ອສົ່ງຂໍ້ມູນສະເພາະເນື່ອງຈາກລັກສະນະທີ່ເກົ່າແກ່ຂອງມັນແລ້ວທ່ານບໍ່ຄວນໃຊ້ບໍລິການນີ້ເພື່ອ "ຮັບປະກັນ" ສ່ວນນັ້ນຂອງອີເມວ.
• ຢ່າໃຊ້ບໍລິການນີ້ເພື່ອຮັບປະກັນວ່າບໍ່ມີການເຮັດ ສຳ ເນົາຂໍ້ຄວາມໃດໆ. ພຽງແຕ່ຍ້ອນວ່າພວກເຮົາລົບລ້າງ ສຳ ເນົາຂໍ້ຄວາມທີ່ຖືກເຂົ້າລະຫັດທັນທີຫລັງຈາກການດຶງຂໍ້ມູນຄືນ ໃໝ່ ແລະພວກເຮົາກໍ່ເຮັດໃຫ້ມັນຍາກທີ່ຈະເຮັດ ສຳ ເນົາ, ບໍ່ໄດ້ ໝາຍ ຄວາມວ່າຂໍ້ຄວາມບໍ່ສາມາດຖືກຄັດລອກໄດ້. ຈະເປັນແນວໃດຖ້າຜູ້ຮັບຖ່າຍຮູບ ໜ້າ ຈໍຂອງພວກເຂົາ? ຈະເປັນແນວໃດຖ້າພວກເຂົາພຽງແຕ່ຂຽນຂໍ້ຄວາມລົງ? ໃນທີ່ສຸດ, ຖ້າຜູ້ຮັບສາມາດອ່ານຂໍ້ຄວາມ - ສາມາດເຮັດ ສຳ ເນົາໄດ້.
• ຢ່າໃຊ້ບໍລິການນີ້ເພື່ອຮັບປະກັນວ່າຂໍ້ຄວາມບໍ່ສາມາດຕິດຕາມທ່ານໄດ້. ບໍລິການນີ້ແມ່ນຂື້ນກັບຜູ້ໃຫ້ບໍລິການຂົນສົ່ງຂໍ້ຄວາມອື່ນ (ເຊັ່ນ: ອີເມວ, ການສົນທະນາ, ແລະອື່ນໆ) ເພື່ອໃຫ້ໄດ້ຂໍ້ຄວາມຈາກຈຸດ ໜຶ່ງ ຫາອີກຈຸດ ໜຶ່ງ. ການຂົນສົ່ງຂໍ້ຄວາມທີ່ຈ້າງເຂົ້າເຮັດວຽກສາມາດຕິດຕາມຂ່າວສານກັບທ່ານໄດ້ດີ.
• ຢ່າໃຊ້ບໍລິການນີ້ເພື່ອສົ່ງສິ່ງທີ່ທ່ານຕ້ອງການປະຕິເສດການສົ່ງຕໍ່. ພຽງແຕ່ຍ້ອນວ່າຂໍ້ຄວາມຕົວມັນເອງຖືກລຶບອອກ, ບໍ່ໄດ້ ໝາຍ ຄວາມວ່າລິ້ງທີ່ຊີ້ໄປຫາຂໍ້ຄວາມທີ່ຖືກລຶບອອກຈະຖືກລຶບອອກ. ຖ້າທ່ານສົ່ງອີເມວໄປຫາເພື່ອນຂອງທ່ານແລະສ່ວນ ໜຶ່ງ ຂອງອີເມວນັ້ນມີການເຊື່ອມຕໍ່ກັບຂໍ້ຄວາມຈາກບໍລິການນີ້, ຜູ້ອ່ານ ທຳ ມະດາຈະຮູ້ວ່າມີສິ່ງອື່ນອີກໃນຂ່າວສານ. ເຖິງແມ່ນວ່າຂໍ້ຄວາມທີ່ກ່າວເຖິງໂດຍການເຊື່ອມຕໍ່ນັ້ນຫາຍໄປດົນນານ - ມັນເປັນທີ່ຈະແຈ້ງວ່າມີສິ່ງອື່ນອີກທີ່ຖືກສົ່ງໄປແລະວ່າມັນຖືກສົ່ງໂດຍທ່ານໄປຫາເພື່ອນຂອງທ່ານ.

ເປັນຫຍັງບໍ່ພຽງແຕ່ໃຊ້ PGP / Signal / OMEMO / Matrix / ແລະອື່ນໆ?

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

ມີຂໍ້ ກຳ ນົດຫຍັງແດ່?

ຕົວທ່ອງເວັບເວັບໄຊຕ໌ທີ່ທັນສະໄຫມແລະທັນສະໄຫມທີ່ປະຕິບັດມາດຕະຖານທີ່ຖືກຕ້ອງລວມທັງ Web Crypto API ແມ່ນຕ້ອງການ. ຕົວຢ່າງລວມມີ: Chrome, Firefox, Edge, ແລະ Safari (ປະມານປີ 2020 ຫຼືຫຼັງຈາກນັ້ນ).

ຜູ້ຮັບສາມາດເຮັດ ສຳ ເນົາຂໍ້ຄວາມໄດ້ບໍ່?

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

• ປຸ່ມ Copy ຖືກລຶບອອກ. ປຸ່ມນີ້ຕັ້ງຄ່າເລີ່ມຕົ້ນທີ່ຈະເຮັດໃຫ້ຜູ້ຮັບສາມາດຄັດລອກຂໍ້ຄວາມທັງ ໝົດ ເຂົ້າໃນ clipboard ຂອງພວກເຂົາ.
• ປຸ່ມດາວໂລດຖືກຖອດອອກ. ປຸ່ມນີ້ຕັ້ງຄ່າເລີ່ມຕົ້ນເພື່ອໃຫ້ຜູ້ຮັບດາວໂຫລດຂໍ້ຄວາມເປັນເອກະສານຂໍ້ຄວາມ.
• ຄວາມສາມາດໃນການເລືອກຂໍ້ຄວາມພາຍໃນກ່ອງຂໍ້ຄວາມຂອງຂໍ້ຄວາມຖືກຖອດອອກ.

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

ມີການເກັບ ກຳ ຂໍ້ມູນສ່ວນຕົວບໍ່?

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

ຂໍ້ມູນໃດທີ່ຖືກບັນທຶກໄວ້?

ເຄື່ອງແມ່ຂ່າຍເວັບຂອງພວກເຮົາຮັກສາ ຮູບແບບການບັນທຶກທົ່ວໄປ ເຖິງ 24 ຊົ່ວໂມງໃນທຸກໆກິດຈະ ກຳ ຂອງເວັບ. ນີ້ປະກອບມີການເຂົ້າສູ່ລະບົບທີ່ຢູ່ IP ເຕັມຂອງລູກຄ້າ HTTP. ຫຼັງຈາກ 24 ຊົ່ວໂມງ, ຂໍ້ມູນທີ່ເຂົ້າສູ່ລະບົບນີ້ຈະຖືກລຶບໂດຍອັດຕະໂນມັດ. ການຮ້ອງຂໍທັງ ໝົດ ທີ່ຖືກສົ່ງໄປຫາ / api ແມ່ນ POSTed ທີ່ມີຄວາມ ໝາຍ ວ່າບໍ່ມີຂໍ້ມູນສະເພາະໃດໆທີ່ຖືກບັນທຶກໂດຍເຄື່ອງແມ່ຂ່າຍເວັບ. ນອກຈາກນັ້ນ, ຂໍ້ມູນໃດໆທີ່ບັນທຶກໄວ້ໃນຖານຂໍ້ມູນແມ່ນຖືກບັນທຶກຢ່າງມີປະສິດຕິຜົນ. ທຸກໆຂໍ້ມູນໃນຖານຂໍ້ມູນ, ລວມທັງທີ່ຢູ່ IP ທີ່ບໍ່ລະບຸຊື່ແລະ hashed, ມີເວລາ ໝົດ ອາຍຸ (TTL) ຫຼັງຈາກທີ່ພວກມັນຖືກລຶບໂດຍອັດຕະໂນມັດ. ເວລາ ໝົດ ອາຍຸຂອງ TTL ແຕກຕ່າງກັນລະຫວ່າງ 1 ນາທີແລະ 2 ອາທິດ.

ທ່ານກໍາລັງເຮັດຫຍັງເພື່ອຮັບປະກັນເຄື່ອງແມ່ຂ່າຍ?

ຄວາມປອດໄພຂອງເຄື່ອງແມ່ຂ່າຍແມ່ນຄວາມກັງວົນທີ່ຈະແຈ້ງ. ມັນມີສອງຂົງເຂດຕົ້ນຕໍທີ່ພວກເຮົາສຸມໃສ່ເພື່ອຮັກສາຄວາມປອດໄພ:

• ກ່ອນອື່ນ ໝົດ, ພວກເຮົາເກັບຮັກສາໄວ້ໃຫ້ ໜ້ອຍ ທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້ ສຳ ລັບເວລາ ໜ້ອຍ ທີ່ສຸດເທົ່ານັ້ນ, ຖ້າວ່າເຄື່ອງແມ່ຂ່າຍມີການປະນີປະນອມ, ການຮົ່ວໄຫຼຂອງຂໍ້ມູນໃດໆກໍ່ຈະບໍ່ເປັນຜົນເສຍຫາຍຕໍ່ຜູ້ໃຊ້ຂອງພວກເຮົາ. ທຸກໆຂໍ້ຄວາມທີ່ເກັບໄວ້ໃນຖານຂໍ້ມູນແມ່ນຖືກເຂົ້າລະຫັດໂດຍບໍ່ມີການຖອດລະຫັດພວກມັນ. ບໍ່ມີຫຍັງເກັບຮັກສາໄວ້ໃນການເຊື່ອມໂຍງຂໍ້ຄວາມໃດໆກັບຜູ້ໃຊ້ຂອງພວກເຮົາເນື່ອງຈາກວ່າພວກເຮົາບໍ່ເກັບ ກຳ ຂໍ້ມູນສ່ວນຕົວຈາກຜູ້ໃຊ້ຂອງພວກເຮົາ. ບັນທຶກທັງ ໝົດ ໃນຖານຂໍ້ມູນມີເວລາ ໝົດ ອາຍຸ (TTL) ຕັ້ງແຕ່ 1 ນາທີເຖິງ 2 ອາທິດ - ຫລັງຈາກເວລານີ້ຜ່ານໄປແລ້ວບັນທຶກຈະຖືກລຶບໂດຍອັດຕະໂນມັດ. ສະນັ້ນ, ຂໍ້ມູນສ່ວນໃຫຍ່ທີ່ເຄີຍມີໃນຖານຂໍ້ມູນຖືກລຶບອອກມາດົນແລ້ວຕັ້ງແຕ່ດົນແລ້ວ.
• ພວກເຮົາໃຊ້ຫຼາຍມາດຕະການເພື່ອປ້ອງກັນການປະນີປະນອມແລະມີການປະນີປະນອມໃດໆທີ່ເກີດຂື້ນ:
  • ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌, nginx , ຖືກດໍາເນີນການໃນຖັງທີ່ໂດດດ່ຽວເປັນຜູ້ໃຊ້ທີ່ບໍ່ມີປະໂຫຍດໂດຍບໍ່ມີການເຂົ້າເຖິງສິ່ງອື່ນນອກເຫນືອຈາກບັນທຶກ. ຕູ້ຄອນເທນເນີແລ່ນຢູ່ໃນສະພາບແວດລ້ອມ SELinux ຂອງຕົວເອງຕື່ມອີກເພື່ອປ້ອງກັນບໍ່ໃຫ້ມີການປ່ຽນແປງໃດໆຂອງລະບົບແຟ້ມເອກະສານຫລືການຫລົບ ໜີ ຈາກຕູ້ຄອນເທນເນີ. ບໍ່ມີການສະ ໜັບ ສະ ໜູນ ສຳ ລັບ PHP / ASP / JSP / etc. - ພຽງແຕ່ຮັບໃຊ້ຊັບພະຍາກອນຄົງທີ່.
  • ລະຫັດແລ່ນ / api ຖືກຂຽນໄວ້ໃນ Go ເຊິ່ງຄວນເຮັດໃຫ້ມັນສາມາດຕ້ານທານກັບຄວາມອ່ອນແອທີ່ມີຄວາມບົກຜ່ອງດ້ານຄວາມໄວເກີນໄປ (vector ໂຈມຕີທົ່ວໄປ). ຂະບວນການ Go ຍັງແລ່ນຢູ່ໃນຖັງທີ່ໂດດດ່ຽວເປັນຜູ້ໃຊ້ທີ່ບໍ່ໄດ້ປະຕິບັດໂດຍບໍ່ຕ້ອງຂຽນເຂົ້າເຖິງສິ່ງອື່ນນອກ ເໜືອ ຈາກຖານຂໍ້ມູນ. ຕູ້ຄອນເທນເນີແລ່ນຢູ່ໃນສະພາບແວດລ້ອມ SELinux ຂອງຕົວເອງຕື່ມອີກເພື່ອປ້ອງກັນບໍ່ໃຫ້ມີການປ່ຽນແປງໃດໆຂອງລະບົບແຟ້ມເອກະສານຫລືການຫລົບ ໜີ ຈາກຕູ້ຄອນເທນເນີ. ຖານຂໍ້ມູນ, badgerdb , ແມ່ນສ່ວນ ໜຶ່ງ ຂອງຂະບວນການ Go (ບໍ່ມີການເພິ່ງພາ / ຂະບວນການຂອງຖານຂໍ້ມູນພາຍນອກ).
  • ອັນຕະລາຍຕົ້ນຕໍຂອງການປະນີປະນອມເຊີຟເວີແມ່ນຜູ້ໂຈມຕີສາມາດດັດແປງແຟ້ມເອກະສານໃນທາງທີ່ຈະ ທຳ ລາຍຄວາມເປັນສ່ວນຕົວ / ຄວາມປອດໄພຂອງຜູ້ໃຊ້ຂອງພວກເຮົາ. ຂະບວນການອຸທິດຕົນຕິດຕາມກວດກາເອກະສານເວບໄຊທ໌ທັງ ໝົດ ສຳ ລັບການປ່ຽນແປງຕ່າງໆແລະແຈ້ງເຕືອນພວກເຮົາທັນທີໃນກໍລະນີມີການປ່ຽນແປງໃດໆ.
  • ການເຂົ້າເຖິງການບໍລິຫານທັງ ໝົດ ແມ່ນຖືກປົກປ້ອງແລະ ຈຳ ກັດຕໍ່ເຄືອຂ່າຍທີ່ໄດ້ຮັບອະນຸຍາດ.

ມີຄວາມສ່ຽງດ້ານຄວາມປອດໄພຫຍັງແດ່ໃນເວລາ ນຳ ໃຊ້ເວັບໄຊທ໌້ນີ້?

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

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

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

• ບາງທີຄວາມສ່ຽງທີ່ໃຫຍ່ທີ່ສຸດແລະສິ່ງທີ່ເປັນເອກະລັກທີ່ສຸດ ສຳ ລັບການບໍລິການນີ້ແມ່ນຜູ້ໃຊ້ຂອງພວກເຮົາຈະບໍ່ໃຊ້ຄວາມຕັດສິນໃຈທີ່ດີໃນເວລາທີ່ແນມເບິ່ງລະຫວ່າງ ສິ່ງທີ່ ເໝາະ ສົມໃນການສົ່ງ ແລະ ສິ່ງທີ່ບໍ່ ເໝາະ ສົມທີ່ຈະສົ່ງ . ບາງຄັ້ງຄວາມແຕກຕ່າງລະຫວ່າງ "ຂ້ອຍສະດວກສະບາຍໃນການສົ່ງຂໍ້ມູນນີ້ - ຂ້ອຍພຽງແຕ່ປາດຖະ ໜາ ວ່າອີເມວຈະຖືກລຶບຖິ້ມຫຼັງຈາກອ່ານ" ແລະ "ຂ້ອຍບໍ່ສະດວກໃນການສົ່ງຂໍ້ມູນນີ້ - ອີເມວແມ່ນການຂົນສົ່ງທີ່ບໍ່ ເໝາະ ສົມ" ສາມາດເວົ້າໄດ້ງ່າຍ.
• ມີໄພຂົ່ມຂູ່ຢູ່ສະ ເໝີ ວ່າຜູ້ປະຕິບັດງານຂອງເວບໄຊທ໌ນີ້ແມ່ນຕົວຈິງແລ້ວນັກສະແດງທີ່ບໍ່ດີທີ່ຊັກຊວນຜູ້ຄົນໃຫ້ໃຊ້ບໍລິການເພື່ອໃຫ້ມີຈຸດ ໝາຍ ປາຍທາງທີ່ມືດມົນ. ພວກເຮົາມາພົບກັນຢ່າງ ໜ້າ ເຊື່ອຖື - ເຮັດໃຫ້ທຸກຢ່າງງ່າຍແລະບໍ່ເສຍຄ່າ - ເຮັດໃຫ້ຫລາຍໆຄົນໃຊ້ບໍລິການ - ຕະຫຼອດເວລາດ້ວຍເຈດຕະນາຮ້າຍ. Bwhahahahaha! ທ່ານສາມາດໄວ້ວາງໃຈພວກເຮົາໄດ້ແນວໃດ?
• ມີໂອກາດທີ່ລະຫັດຂອງພວກເຮົາມີຂໍ້ບົກພ່ອງທີ່ສົ່ງຜົນກະທົບຕໍ່ຄວາມປອດໄພຫຼືພວກເຮົາພຽງແຕ່ບໍ່ໄດ້ຄິດເຖິງສິ່ງທີ່ດີແລະຂໍ້ບົກຜ່ອງຂອງພວກເຮົາໃນປັດຈຸບັນເຮັດໃຫ້ຜູ້ໃຊ້ຂອງພວກເຮົາມີອັນຕະລາຍທີ່ບໍ່ ຈຳ ເປັນ. ພວກເຮົາແນ່ໃຈວ່າພວກເຮົາຫວັງບໍ່ໄດ້ - ແຕ່ພວກເຮົາບໍ່ສາມາດ ກຳ ຈັດມັນໄດ້.
• ບໍ່ຄືກັບເຕັກໂນໂລຍີ - ເຕັກໂນໂລຢີ (ເຊັ່ນ Google / Facebook / Whatsapp) ທີ່ມີຂໍ້ມູນທີ່ເຂົ້າລະຫັດເຂົ້າມາເລື້ອຍໆແລະອອກຈາກເຄືອຂ່າຍທີ່ກວ້າງໃຫຍ່ໄພສານ, ບ່ອນທີ່ມັນງ່າຍທີ່ຈະມີການສື່ສານສ່ວນຕົວເຂົ້າກັນກັບການຈະລາຈອນອື່ນໆ, ການບໍລິການເປັນສູນກາງແບບດຽວ (ເຊັ່ນສັນຍານ, Telegram, ແລະພວກເຮົາ) ໂດດເດັ່ນ. ມັນງ່າຍ ສຳ ລັບຜູ້ປະຕິບັດການເຄືອຂ່າຍຫລືແມ້ກະທັ້ງອົງກອນ / ລັດຖະບານທີ່ໃຫຍ່ທີ່ຈະເຫັນວ່າ IP address xxxx ກຳ ລັງໃຊ້ບໍລິການ XYZ.
• ໃນຂະນະທີ່ບໍ່ມີຄວາມແນ່ນອນຕໍ່ເວັບໄຊທ໌້ນີ້, ເພາະວ່າມັນສາມາດ ນຳ ໃຊ້ກັບເວັບໄຊທ໌ໃດກໍ່ໄດ້, ການໂຈມຕີຂອງຜູ້ຊາຍໃນກາງ (MITM) ແມ່ນຄວາມກັງວົນທີ່ຖືກຕ້ອງ .

ທ່ານ ກຳ ລັງເຮັດຫຍັງກ່ຽວກັບການໂຈມຕີຂອງຜູ້ຊາຍໃນກາງ (MITM)?

ຜູ້ ນຳ ໃຊ້ເວັບໄຊທ໌້ທຸກຄົນສາມາດເປັນຜູ້ເຄາະຮ້າຍຈາກການໂຈມຕີຂອງ MITM - ເວບໄຊທ໌ນີ້ບໍ່ແຕກຕ່າງຈາກຄົນອື່ນໆທີ່ຢູ່ໃນເວັບໃນເລື່ອງນີ້. ການ ໂຈມຕີ MITM ແມ່ນເວລາທີ່ຜູ້ໂຈມຕີສາມາດສະກັດກັ້ນແລະແກ້ໄຂການສື່ສານລະຫວ່າງ browser ຂອງຜູ້ໃຊ້ແລະ server ຂອງເວັບໄຊທ໌້. ສິ່ງນີ້ຊ່ວຍໃຫ້ຜູ້ໂຈມຕີສາມາດດັດແປງລະຫັດ / ເນື້ອຫາຂອງເວັບໄຊທ໌ໃດ ໜຶ່ງ ໃນຂະນະທີ່ຍັງປະກົດຕົວໃຫ້ຜູ້ໃຊ້ສຸດທ້າຍເປັນເວັບໄຊທ໌ທີ່ພວກເຂົາເຄີຍໃຊ້. ພວກເຮົາປະຕິບັດບາງມາດຕະການເພື່ອເຮັດໃຫ້ການໂຈມຕີ MITM ມີຄວາມຫຍຸ້ງຍາກຫຼາຍ:

• HSTS ຖືກໃຊ້ເພື່ອບັງຄັບໃຫ້ຕົວທ່ອງເວັບພຽງແຕ່ເຊື່ອມຕໍ່ຜ່ານ TLS ເທົ່ານັ້ນ. ເຊີບເວີຂອງພວກເຮົາຖືກຕັ້ງຄ່າໃຫ້ລະເວັ້ນການສື່ສານທີ່ບໍ່ແມ່ນ TLS ນອກ ເໜືອ ຈາກການປ່ຽນເສັ້ນທາງ. ມີພຽງແຕ່ TLS 1.2 ຫຼືສູງກວ່າເທົ່ານັ້ນທີ່ຮອງຮັບ.
• DNSSEC ຖືກໃຊ້ເພື່ອລົງທະບຽນເຂດໂດເມນຂອງພວກເຮົາ. ນີ້ສາມາດຢຸດເຊົາການໂຈມຕີ MITM ທີ່ຖືກປະຕິບັດໃນການຫຼອກລວງ DNS ຖ້າຜູ້ໃຊ້ ກຳ ລັງໃຊ້ DNSSEC ທີ່ມີການຮັບຮູ້ຕົວຈິງ.
• ພວກເຮົາໃຊ້ບໍລິການເພື່ອກວດສອບເຈົ້າ ໜ້າ ທີ່ໃບຢັ້ງຢືນທີ່ອອກໃບຢັ້ງຢືນ TLS ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໂດຍອ້າງອີງໃສ່ໂດເມນຂອງພວກເຮົາ.
• ພວກເຮົາໄດ້ເຜີຍແຜ່ການຂະຫຍາຍຂອງເບົາເຊີ ເພື່ອສະ ໜັບ ສະ ໜູນ ການເຂົ້າລະຫັດຂໍ້ຄວາມໂດຍໃຊ້ລະຫັດທີ່ເກັບໄວ້ໃນອຸປະກອນຂອງຜູ້ໃຊ້ສຸດທ້າຍ.

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

ຂໍ້ສະ ເໜີ ຂອງການຂະຫຍາຍໂປແກຼມທ່ອງເວັບມີຂໍ້ດີຫຍັງແດ່?

ພວກເຮົາສະ ເໜີ ການຂະຫຍາຍໂປແກຼມທ່ອງເວັບ ເປັນວິທີເພື່ອໃຫ້ຄວາມສະດວກສະບາຍແລະຄວາມປອດໄພເພີ່ມເຕີມ. ເວົ້າງ່າຍໆ ... ສ່ວນຂະຫຍາຍເຮັດໃຫ້ການສົ່ງຂໍ້ຄວາມຊົ່ວຄາວໄວແລະງ່າຍຂຶ້ນ. ຄວາມປອດໄພບາງຢ່າງກໍ່ໄດ້ຮັບເພາະວ່າລະຫັດທັງ ໝົດ ທີ່ໃຊ້ໃນການເຂົ້າລະຫັດແລະການກະກຽມຂໍ້ຄວາມຈະຖືກເກັບຢູ່ໃນທ້ອງຖິ່ນພາຍໃນສ່ວນຂະຫຍາຍ. ເນື່ອງຈາກວ່າລະຫັດດັ່ງກ່າວຖືກເກັບຢູ່ໃນທ້ອງຖິ່ນ, ນີ້ໄດ້ໃຫ້ຜູ້ສົ່ງການປົກປ້ອງບາງຢ່າງຕໍ່ກັບ ການໂຈມຕີຂອງ MITM . ເຖິງຢ່າງໃດກໍ່ຕາມ, ມັນເປັນມູນຄ່າທີ່ຊີ້ໃຫ້ເຫັນວ່າໃນຂະນະທີ່ການຂະຫຍາຍການສະຫນອງການປ້ອງກັນເພີ່ມເຕີມຕໍ່ກັບການໂຈມຕີ MITM ທີ່ປະນີປະນອມເນື້ອໃນຂອງຂໍ້ຄວາມ, ການໂຈມຕີ MITM ຍັງສາມາດມີປະສິດຕິຜົນໄດ້ (ເຊັ່ນການ ກຳ ນົດທີ່ຢູ່ IP ຂອງຜູ້ສົ່ງຖ້າບໍ່ໃຊ້ TOR / VPN / ແລະອື່ນໆ).

ຂ້ອຍສາມາດຮູ້ໄດ້ຢ່າງແນ່ນອນວ່າທຸກຢ່າງທີ່ສົ່ງມາຈະຖືກເຂົ້າລະຫັດໃນຕອນທ້າຍແນວໃດ?

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

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

ການເຂົ້າລະຫັດແບບສຸດທ້າຍຈະເຮັດວຽກຢູ່ໃນເວັບໄຊທ໌ນີ້ໄດ້ແນວໃດ?

ໃນເວລານີ້, ພວກເຮົາ ກຳ ລັງ ນຳ ໃຊ້ການເຂົ້າລະຫັດທີ່ມີຄວາມ ຈຳ ເປັນ (AES-GCM 256bit) ພ້ອມດ້ວຍລະຫັດທີ່ມາຈາກລະຫັດຜ່ານ (ຕຳ ່ສຸດທີ່ 150,000 iterations ຂອງ PBKDF2 / SHA-256). ການເຂົ້າລະຫັດ Asymmetric ບໍ່ໄດ້ຖືກ ນຳ ໃຊ້ເພາະວ່າຂໍ້ ກຳ ນົດຕ່າງໆມີຢູ່ ສຳ ລັບ 1) ຜູ້ສົ່ງຂໍ້ມູນເລີ່ມຕົ້ນການສື່ສານ 2) ຜູ້ສົ່ງແລະຜູ້ຮັບບໍ່ໄດ້ຢູ່ໃນອິນເຕີເນັດໃນເວລາດຽວກັນແລະ 3) ບໍ່ມີຂໍ້ມູນກ່ຽວກັບຜູ້ຮັບແລະ 4) ພວກເຮົາ ກຳ ລັງພະຍາຍາມຮັກສາສິ່ງທີ່ລຽບງ່າຍແລະການຈັດການທີ່ ສຳ ຄັນແມ່ນ ສັບສົນ. Web Crypto API ມາດຕະຖານຖືກໃຊ້ ສຳ ລັບການ ທຳ ງານຂອງລະຫັດທັງ ໝົດ ລວມທັງ RNG. ໂດຍພື້ນຖານແລ້ວ, ນີ້ແມ່ນສິ່ງທີ່ເກີດຂື້ນ:

1. ຜູ້ໃຊ້ສຸດທ້າຍເລືອກລະຫັດຜ່ານຫຼື ໜຶ່ງ ແມ່ນຜະລິດໂດຍອັດຕະໂນມັດ
2. ການໂທຫາ API ແມ່ນເພື່ອໃຫ້ໄດ້ ຈຳ ນວນຕົວເລກທີ່ ຈຳ ເປັນ PBKDF2 / SHA-256 ( ຂັ້ນຕອນນີ້ ຈຳ ເປັນ ສຳ ລັບການຄວບຄຸມສະແປມ )
3. ເກືອ 32 ບິດແມ່ນຜະລິດ
4. ຄີແມ່ນມາຈາກເກືອແລະລະຫັດຜ່ານ
5. vector 12 ເລີ່ມຕົ້ນ ໄບຕ໌ (IV) ຖືກສ້າງຂຶ້ນ
6. ຂໍ້ຄວາມຖືກເຂົ້າລະຫັດໂດຍໃຊ້ປຸ່ມ + IV
7. ຕົວເລກການສົ່ງອອກ, ເກືອ, IV ແລະ ciphertext ຖືກສົ່ງໄປຫາເຊີບເວີ (ພ້ອມກັບຂໍ້ມູນອື່ນບາງຢ່າງເຊັ່ນ TTL, RTL, ແລະອື່ນໆ)
8. ເຄື່ອງແມ່ຂ່າຍສົ່ງຄືນ ID ແບບສຸ່ມໂດຍອ້າງອີງໃສ່ຂໍ້ຄວາມ
9. ຕົວທ່ອງເວັບຫຼັງຈາກນັ້ນ ນຳ ສະ ເໜີ ຜູ້ໃຊ້ສຸດທ້າຍດ້ວຍລິ້ງທີ່ ມີ ID ແລະລະຫັດຜ່ານທີ່ຖືກສົ່ງຄືນ ຫຼື ເຊື່ອມຕໍ່ໂດຍບໍ່ມີລະຫັດລັບ (ໃນກໍລະນີຜູ້ຮັບຈະຕ້ອງຮູ້ແລະໃສ່ລະຫັດຜ່ານ)
10. ຖ້າລະຫັດຜ່ານແມ່ນສ່ວນ ໜຶ່ງ ຂອງລິ້ງ, ມັນຢູ່ໃນ URL hash , ແລະດັ່ງນັ້ນບໍ່ເຄີຍຖືກສົ່ງໄປຫາເຊີບເວີເມື່ອຜູ້ຮັບໄດ້ເຮັດການຮ້ອງຂໍ GET
11. ຜູ້ຮັບຈະຖືກກະຕຸ້ນເຕືອນຖ້າພວກເຂົາຕ້ອງການຖອດລະຫັດແລະເບິ່ງຂໍ້ຄວາມ
12. ຕົວທ່ອງເວັບເຮັດການຮ້ອງຂໍໂດຍລະບຸ ID ຂໍ້ຄວາມ
13. ຖ້າຜູ້ສົ່ງຮຽກຮ້ອງໃຫ້ CAPTCHA ປະຕິບັດ ສຳ ເລັດ, ຜູ້ຮັບຈະຖືກສົ່ງໄປຫາ URL ອື່ນເພື່ອພິສູດວ່າພວກເຂົາເປັນມະນຸດ (ເມື່ອພວກເຂົາຜ່ານໄປພວກເຂົາຖືກສົ່ງກັບຄືນ)
14. ເຊີຟເວີສົ່ງຂໍ້ຄວາມທີ່ຖືກເຂົ້າລະຫັດແລະໂດຍ ທຳ ມະດາແລ້ວຈະລຶບຂໍ້ຄວາມໃນຈຸດນີ້ຖ້າວ່າ reads-to-live (RTL) ແມ່ນ ໜຶ່ງ
15. ຜູ້ຮັບຈະຖອດລະຫັດຂໍ້ຄວາມດ້ວຍລະຫັດຜ່ານ (ແລະຈະຖືກຖາມໃຫ້ລະຫັດລັບຖ້າບໍ່ຢູ່ໃນ URL)

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

ລະຫັດຜ່ານການຖອດລະຫັດສາມາດຢູ່ໃນ URL ໄດ້ບໍ?

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

ແຕ່ລະຫັດຖອດລະຫັດບໍ່ຈໍາເປັນຕ້ອງຢູ່ໃນ URL ບໍ?

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

1. ເຂົ້າລະຫັດລະຫັດລັບໃນຂໍ້ຄວາມດ້ວຍການຕັ້ງຄ່າເລີ່ມຕົ້ນແລະສົ່ງລິ້ງນີ້ໄປຫາຜູ້ຮັບ.
2. ເມື່ອຜູ້ຮັບຄລິກທີ່ລິ້ງແລະຖອດລະຫັດຂໍ້ຄວາມ, ເຂົາເຈົ້າຮູ້ວ່າບໍ່ມີໃຜອື່ນໄດ້ຮັບລະຫັດຜ່ານມາກ່ອນເພາະວ່າຂໍ້ຄວາມທີ່ມີລະຫັດຜ່ານແມ່ນຖືກລຶບອອກເມື່ອໄປເອົາຄືນ. ແນວໃດກໍ່ຕາມ, ຖ້າມີການ ໂຈມຕີ MITM ທີ່ ມີການເຄື່ອນໄຫວຫຼືຖ້າອຸປະກອນຂອງເຈົ້າຫຼືອຸປະກອນຂອງຜູ້ຮັບໄດ້ຖືກທໍາລາຍ, ຈາກນັ້ນມັນກໍ່ຍັງເປັນໄປໄດ້ວ່າອີກcan່າຍ ໜຶ່ງ ສາມາດເອົາລະຫັດຜ່ານໄດ້.
3. ຢືນຢັນກັບຜູ້ຮັບວ່າເຂົາເຈົ້າໄດ້ຮັບລະຫັດຜ່ານຢ່າງສໍາເລັດຜົນ. ຕົວຢ່າງ, ຖ້າຜູ້ຮັບແຈ້ງໃຫ້ເຈົ້າຮູ້ວ່າເມື່ອເຂົາເຈົ້າໄປເອົາລະຫັດຜ່ານຄືນມາ, ວ່າຂໍ້ຄວາມໄດ້ຖືກລຶບໄປແລ້ວ, ຫຼັງຈາກນັ້ນເຈົ້າຮູ້ວ່າຄົນອື່ນໄດ້ຮັບລະຫັດຜ່ານກ່ອນຜູ້ຮັບແລະດັ່ງນັ້ນລະຫັດຜ່ານຈຶ່ງຖືກລະເມີດແລະບໍ່ຄວນໃຊ້.
4. ການໃຊ້ລະຫັດຜ່ານທີ່ຜູ້ຮັບໄດ້ຢືນຢັນວ່າມີຢູ່, ດຽວນີ້ເຈົ້າສາມາດສົ່ງຂໍ້ຄວາມໂດຍໃຊ້ລະຫັດຜ່ານອັນດຽວກັນສໍາລັບການເຂົ້າລະຫັດ - ພຽງແຕ່ແບ່ງປັນລຸ້ນຂອງລິ້ງທີ່ບໍ່ມີລະຫັດຜ່ານ.

ບໍລິການນີ້ບໍ່ສົ່ງລິ້ງໃຫ້ຜູ້ຮັບບໍ?

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

ຂ້ອຍສາມາດປົກປ້ອງຄວາມເປັນສ່ວນຕົວຂອງຂ້ອຍໃຫ້ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ແນວໃດໃນຂະນະທີ່ໃຊ້ບໍລິການນີ້?

ດັ່ງທີ່ໄດ້ປຶກສາຫາລືຢູ່ບ່ອນອື່ນໃນ FAQ ນີ້, ເຖິງແມ່ນວ່າພວກເຮົາໄດ້ເຮັດ ຫຼາຍຢ່າງເພື່ອປົກປ້ອງຄວາມເປັນສ່ວນຕົວຂອງທ່ານ ແລະເຖິງແມ່ນວ່າພວກເຮົາບໍ່ໄດ້ເກັບ ກຳ ຂໍ້ມູນສ່ວນຕົວ, ບາງ ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບ log ແມ່ນຖືກສົ່ງແລະລວບລວມໂດຍພວກເຮົາແລະຄົນອື່ນໂດຍຄຸນງາມຄວາມດີຂອງທ່ານໂດຍໃຊ້ຕົວທ່ອງເວັບ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ມີຫລາຍວິທີໃນການປົກປ້ອງຄວາມເປັນສ່ວນຕົວຂອງທ່ານໃຫ້ຫລາຍຂື້ນ. ວິທີ ໜຶ່ງ ທີ່ສາມາດ ນຳ ໃຊ້ໄດ້ໂດຍບໍ່ເສຍຄ່າ, ອີງໃສ່ຊອບແວແຫຼ່ງເປີດ, ແລະເຮັດວຽກຂ້ອນຂ້າງດີຄືການໃຊ້ Tor Browser . ຕົວທ່ອງເວັບນີ້ຖືກອອກແບບມາເພື່ອປົກປ້ອງຄວາມເປັນສ່ວນຕົວຂອງທ່ານໃນຫລາຍໆລະດັບ - ລວມທັງການ ນຳ ໃຊ້ ເຄືອຂ່າຍ Tor . ເວັບໄຊທ໌້ຂອງພວກເຮົາສາມາດເຂົ້າເຖິງໄດ້ຜ່ານເຄືອຂ່າຍຜັກບົ່ວ Tor ເຊິ່ງ ໝາຍ ຄວາມວ່າການເຂົ້າໃຊ້ເວັບໄຊທ໌ຂອງພວກເຮົາຜ່ານ Tor ບໍ່ ຈຳ ເປັນຕ້ອງໃຊ້ລະບົບທາງອອກ, ເຊິ່ງເຮັດໃຫ້ຜູ້ໃດຜູ້ ໜຶ່ງ ເຊົາຕິດຕາມການຈະລາຈອນທາງອອກ . ເຖິງຢ່າງໃດກໍ່ຕາມ, ຈົ່ງຈື່ໄວ້ວ່າເຖິງແມ່ນວ່າໃນສະຖານະການນີ້, ISP ຂອງທ່ານສາມາດເຫັນໄດ້ວ່າທ່ານ ກຳ ລັງໃຊ້ Tor ຢູ່ - ເຖິງແມ່ນວ່າມັນບໍ່ແມ່ນຫຍັງ. ທ່ານຍັງສາມາດເຊື່ອມຕໍ່ກັບ VPN ແລະຫຼັງຈາກນັ້ນເປີດຕົວ Tor Browser ສຳ ລັບສອງຂັ້ນຕອນຂອງການປິດລັບ; ເຖິງຢ່າງໃດກໍ່ຕາມ, ຈົ່ງຈື່ໄວ້ວ່າ ISP ຂອງທ່ານຍັງສາມາດເຫັນທ່ານໃຊ້ VPN ໃນສະຖານະການນີ້ - ເຖິງແມ່ນວ່າມັນບໍ່ແມ່ນຫຍັງ. ຖ້າທ່ານບໍ່ຕ້ອງການໃຫ້ ISP ຂອງທ່ານຮູ້ກ່ຽວກັບໂປໂຕຄອນທີ່ທ່ານ ກຳ ລັງໃຊ້, ທ່ານສາມາດເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍ WiFi ສາທາລະນະຂະ ໜາດ ໃຫຍ່ເຊັ່ນ: ຫ້ອງສະ ໝຸດ, ໂຮງຮຽນ, ແລະອື່ນໆແລະຫຼັງຈາກນັ້ນໃຊ້ Tor browser.

ຈະເປັນແນວໃດຖ້າຂ້ອຍບໍ່ເຊື່ອໃຈສະຫະລັດ?

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

ທ່ານ ກຳ ລັງເຮັດຫຍັງເພື່ອປ້ອງກັນສະແປມ?

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

• ພວກເຮົາກຽດຊັງ CAPTCHAs - ພວກເຂົາໃຊ້ເວລາແລະຫນ້າຮໍາຄານ
• ການໂຫລດ javascript ຂອງບຸກຄົນທີ 3 ສາມາດສະແດງໃຫ້ເຫັນເຖິງຄວາມເປັນສ່ວນຕົວແລະຄວາມປອດໄພ
• ແລ່ນ CAPTCHA ຂອງພວກເຮົາເອງ ໝາຍ ຄວາມວ່າພວກເຮົາ ກຳ ລັງລົງທະບຽນ ສຳ ລັບເກມທີ່ບໍ່ເຄີຍສິ້ນສຸດຂອງ whack-a-mole
• ໃນທີ່ສຸດປະຊາຊົນອາດຈະຕ້ອງການທີ່ຈະສາມາດພົວພັນກັບບໍລິການນີ້ຜ່ານ API

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

• ການເພີ່ມຈໍານວນຂອງການປ່ຽນແປງທີ່ຕ້ອງການ PBKDF2 / SHA-256
  ທຸກໆຂໍ້ຄວາມສາມາດຖືກດຶງມາ ຈຳ ນວນຄັ້ງ ໜ້ອຍ ໜຶ່ງ ເທົ່ານັ້ນ - ເປັນຄຸນລັກສະນະທີ່ບໍ່ ໜ້າ ສົນໃຈ ສຳ ລັບ spammer ນັບຕັ້ງແຕ່ພວກເຂົາອີງໃສ່ການສົ່ງຂໍ້ຄວາມຫຼາຍ. ເນື່ອງຈາກຜູ້ສົ່ງສະແປມຈະຕ້ອງສ້າງຂໍ້ຄວາມຫຼາຍ ສຳ ລັບການໂຄສະນາສະແປມທີ່ໃຫ້ - ພວກເຮົາໄດ້ເລືອກທີ່ຈະເຮັດໃຫ້ວຽກງານດັ່ງກ່າວມີລາຄາຖືກທີ່ສົມຄວນທີ່ຈະເຮັດໃຫ້ການໃຊ້ບໍລິການນີ້ສວຍໃຊ້ ສຳ ລັບສະແປມເປັນສິ່ງທີ່ບໍ່ ທຳ ມະດາ. ສິ່ງນີ້ປະສົບຜົນ ສຳ ເລັດໂດຍການຕິດຕາມເຄືອຂ່າຍການໂພດຂໍ້ຄວາມ - ວັດແທກໃນແງ່ຂອງການດຶງຂໍ້ມູນທັງ ໝົດ ທີ່ເປັນໄປໄດ້. ຂໍ້ມູນຂອງເຄືອຂ່າຍຕົວມັນເອງແມ່ນຖືກສ້າງຂື້ນຢ່າງປອດໄພເພື່ອວ່າພວກເຮົາບໍ່ສາມາດເຈາະຈົງເຄືອຂ່າຍທີ່ແທ້ຈິງຈາກ hash. ໃນຖານະເປັນເຄືອຂ່າຍທີ່ໄດ້ຮັບຂໍ້ຄວາມເພີ່ມເຕີມ, ພວກເຮົາຍົກ ຈຳ ນວນ ຈຳ ນວນຂອງ PBKDF2 / SHA-256 iterations ທີ່ຕ້ອງການລົງຂໍ້ຄວາມຕໍ່ໄປ. ສິ່ງນີ້ຢ່າງໄວວາສົ່ງຜົນໃຫ້ເວລາ CPU ຈຳ ນວນຫຼວງຫຼາຍຖືກຮຽກຮ້ອງພຽງແຕ່ຂຽນຂໍ້ຄວາມດຽວ. ຫວັງວ່າວິທີການນີ້ຈະພຽງພໍເພື່ອສະກັດກັ້ນການລ່ວງລະເມີດຂອງສະແປມແລະໃນເວລາດຽວກັນ, ບໍ່ສົ່ງຜົນກະທົບຕໍ່ຜູ້ໃຊ້ທີ່ແທ້ຈິງ.
• ຮວບຮວມລາຍງານສະແປມຈາກຜູ້ໃຊ້ໃນເວລາທີ່ພວກເຂົາດຶງຂໍ້ຄວາມ
  ມີປຸ່ມ "ລາຍງານສະແປມ" ຢູ່ທາງລຸ່ມຂໍ້ຄວາມເມື່ອຜູ້ໃຊ້ດຶງຂໍ້ຄວາມ. ຖ້າຂໍ້ຄວາມສະແປມ, ຫວັງວ່າບາງຄົນຈະໃຊ້ເວລາ 3 ວິນາທີທີ່ຕ້ອງການກົດປຸ່ມນັ້ນ. ໃນເວລາທີ່ພວກເຮົາໄດ້ຮັບບົດລາຍງານສະແປມ, ມັນເຕືອນພວກເຮົາແລະມັນກໍ່ເປັນປັດໃຈທີ່ສົ່ງຜົນກະທົບຕໍ່ຄວາມຕ້ອງການ PBKDF2 / SHA-256 ທີ່ ຈຳ ເປັນ ສຳ ລັບເຄືອຂ່າຍທີ່ໃຫ້.

ຖ້າທ່ານຮູ້ວ່າ spammers ກຳ ລັງສວຍໃຊ້ບໍລິການນີ້, ກະລຸນາຍື່ນບົດລາຍງານການລ່ວງລະເມີດ .

ເປັນຫຍັງຈຶ່ງມີທາງເລືອກທີ່ຈະຮຽກຮ້ອງໃຫ້ຜູ້ຮັບເຮັດ CAPTCHA ສຳ ເລັດ?

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

ໃຜ ກຳ ລັງໃຊ້ບໍລິການນີ້ແລະເປັນຫຍັງມັນບໍ່ເສຍຄ່າ?

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

ຂ້ອຍຈະເຊື່ອ ຄຳ ຕອບຕໍ່ ຄຳ ຖາມຂ້າງເທິງນີ້ໄດ້ແນວໃດ?

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