কুকি, স্থানীয় স্টোরেজ, ক্যাশ ও ব্রাউজার ফিঙ্গারপ্রিন্ট ব্যাখ্যা

গোপনীয়তার সেটিং, ডিবাগিং নির্দেশনা ও ব্রাউজার-প্রোফাইল পণ্যে এই ধারণাগুলো প্রায়ই পাশাপাশি আসে। কিন্তু এগুলোর আচরণ এত আলাদা যে “ব্রাউজার পরিষ্কার করুন” বলা অসম্পূর্ণ নির্দেশনা।

কাজের একটি মানসিক মডেল

ব্যবস্থা	কে তৈরি বা নিয়ন্ত্রণ করে	সাধারণ সীমা	সাধারণ উদ্দেশ্য	অনুরোধের সঙ্গে স্বয়ংক্রিয়ভাবে যায়?
HTTP কুকি	সার্ভার সেট করে; ব্রাউজার সীমার নিয়ম মেনে রাখে ও ফেরত দেয়	হোস্ট বা ডোমেইন, পথ, মেয়াদ ও সংযোগের শর্ত	সেশন শনাক্তকারী, পছন্দ, অপব্যবহার-রোধের অবস্থা	হ্যাঁ, অনুরোধের সীমার সঙ্গে মিললে
localStorage	সাইটের JavaScript	উৎস, ব্রাউজারের পার্টিশন ও নীতির অধীন	স্থায়ী কী-মানের অ্যাপ্লিকেশন অবস্থা	না
sessionStorage	সাইটের JavaScript	শীর্ষ-স্তরের ব্রাউজিং সেশনের ভেতরের উৎস	অস্থায়ী ট্যাব বা কাজের অবস্থা	না
HTTP ক্যাশ	ব্রাউজার ও HTTP ক্যাশের নিয়ম	ক্যাশ কী, উত্তরের নির্দেশনা, ব্রাউজারের নীতি	বিলম্ব ও ট্রাফিক কমাতে উত্তর পুনর্ব্যবহার	অনুরোধ মেটাতে বা আবার যাচাই করতে পারে
Cache Storage API	সাইট বা সার্ভিস-ওয়ার্কারের JavaScript	উৎস বা স্টোরেজ পার্টিশন	অফলাইন সম্পদ ও অ্যাপ্লিকেশন-নিয়ন্ত্রিত উত্তর	স্বয়ংক্রিয়ভাবে যুক্ত হয় না; স্ক্রিপ্ট ব্যবহার নিয়ন্ত্রণ করে
ব্রাউজার ফিঙ্গারপ্রিন্ট	সাইট বা অন্য পর্যবেক্ষক সংকেত মাপে	পর্যবেক্ষক ও সংকেত অনুযায়ী	নিরাপত্তা, জালিয়াতি শনাক্তকরণ, বিশ্লেষণ বা ট্র্যাকিং	কিছু সংকেত অনুরোধে দেখা যায়; কিছুতে সক্রিয় কোড দরকার

প্রথম পাঁচটি সারি সংরক্ষিত অবস্থা বোঝায়। শেষটি পর্যবেক্ষণ ও মিল খোঁজার পদ্ধতি, যদিও সংরক্ষিত অবস্থা তার ইনপুট হতে পারে।

কুকি: সীমার নিয়মসহ সার্ভারমুখী অবস্থা

HTTP নিজে বেশিরভাগ সময় কোনো অবস্থা ধরে রাখে না। কুকির মাধ্যমে সার্ভার ব্রাউজারকে নাম-মানের জোড়া দেয় এবং পরের মিলে যাওয়া অনুরোধে তা ফিরে পায়। RFC 6265 Set-Cookie উত্তর-হেডার, Cookie অনুরোধ-হেডার ও ব্রাউজারের সংরক্ষণ মডেল সংজ্ঞায়িত করে।

কুকি হতে পারে:

• সেশন-সীমাবদ্ধ, ব্রাউজার-নির্ধারিত সেশন শেষ হওয়া পর্যন্ত রাখা হয়;
• স্থায়ী, মেয়াদ শেষ বা সর্বোচ্চ বয়স নির্ধারিত থাকে;
• শুধু-হোস্ট, যে হোস্ট সেট করেছে সেখানেই ফেরত যায়;
• ডোমেইন-সীমাবদ্ধ, নির্দিষ্ট ডোমেইন ও মিলে যাওয়া সাবডোমেইনের জন্য প্রযোজ্য;
• Secure, ব্রাউজার নির্ধারিত সুরক্ষিত চ্যানেলেই ফেরত যায়; এবং
• HttpOnly, স্ক্রিপ্টের কুকি API থেকে লুকানো, কিন্তু HTTP অনুরোধে পাওয়া যায়।

এই বৈশিষ্ট্যগুলো কুকি কীভাবে পাঠানো হবে ও স্ক্রিপ্টে কীভাবে দেখা যাবে তা প্রভাবিত করে। কুকির মান নিজে কোনো স্বাধীন নিরাপত্তা-সীমা তৈরি করে না। RFC 6265 বলে নিরাপত্তার জন্য Path বৈশিষ্ট্যের ওপর নির্ভর করা উচিত নয় এবং সংবেদনশীল কুকির বিষয়বস্তুর জন্য সুরক্ষিত পরিবহন ও অতিরিক্ত সুরক্ষা সুপারিশ করে।

কুকি মুছলে অ্যাকাউন্ট থেকে বেরিয়ে যেতে হয় কেন

অনেক সেবা কুকিতে এলোমেলো সেশন শনাক্তকারী রাখে এবং সার্ভারে অ্যাকাউন্ট ও সেশনের বিবরণ রাখে। কুকি মুছলে ব্রাউজারে থাকা শনাক্তকারীর কপিটি সরে যায়, তাই পরের অনুরোধ একই সেশন হিসেবে দেখা যায় না। সার্ভারে থাকা অ্যাকাউন্ট ও অন্য সেশন তবু থাকতে পারে।

এই কারণেই প্রমাণীকরণের কুকির কপি সংবেদনশীল। কার্যকর সেশন শনাক্তকারী প্রবেশের তথ্যের মতো কাজ করতে পারে। কাঁচা কুকি টিকিট, লগ, অটোমেশনের আউটপুট বা দলের চ্যাটে পেস্ট করবেন না।

লোকাল স্টোরেজ: একটি উৎসের স্ক্রিপ্ট-নিয়ন্ত্রিত অবস্থা

HTML Standard localStorage-কে উৎসের লোকাল স্টোরেজ এলাকায় অ্যাক্সেস হিসেবে সংজ্ঞায়িত করে। এটি উইন্ডো জুড়ে থাকা ও বর্তমান সেশনের পরেও টিকে থাকার জন্য ব্যবহৃত হয়। স্টোরেজে স্ট্রিং কী-মানের জোড়া থাকে এবং সেই উৎসের অধিকার নিয়ে চলা স্ক্রিপ্ট তা ব্যবহার করতে পারে।

একটি উৎস সাধারণত স্কিম, হোস্ট ও পোর্ট মিলিয়ে গঠিত হয়। তাই এই সীমাগুলো আলাদা:

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

URL-এর পথ উৎসের অংশ নয়। একই উৎসের /billing/ ও /support/ পেজ একই লোকাল স্টোরেজ ব্যবহার করতে পারে, যদি অ্যাপ্লিকেশন নিজস্ব যৌক্তিক আলাদা ব্যবস্থা না করে।

কুকির মতো localStorage HTTP অনুরোধে স্বয়ংক্রিয়ভাবে যুক্ত হয় না। সাইটের স্ক্রিপ্ট এটি পড়ে কী করবে তা ঠিক করে। তাই ইন্টারফেসের পছন্দ, খসড়ার অবস্থা ও অ্যাপ্লিকেশন ডেটায় এটি উপযোগী, কিন্তু উৎসের অধিকার নিয়ে চলা স্ক্রিপ্ট তা পড়তে পারে। সংবেদনশীল সেশন নকশায় স্ক্রিপ্টের দখল হয়ে যেতে পারে ধরে নিন; “লোকাল” মানেই গোপন নয়।

এখানে স্থায়িত্ব বলতে বোঝায় ডেটা ব্রাউজিং সেশন পার হয়ে টিকে থাকতে পারে। এর অর্থ চিরস্থায়ী সংরক্ষণ নয়। ব্যবহারকারী ডেটা মুছতে পারেন, ব্রাউজারের নীতি তা সীমিত করতে পারে এবং ব্রাউজার স্টোরেজ সরিয়ে ফেলার নিয়ম প্রয়োগ করতে পারে।

sessionStorage-এর আলাদা মেয়াদ

sessionStorage উৎস ও শীর্ষ-স্তরের ব্রাউজিং সেশনের সঙ্গে যুক্ত। ট্যাব বা উইন্ডোতে কাজ চলা পর্যন্ত অবস্থা রেখে সেশন শেষে শেষ করার জন্য এটি উপযোগী। কপি বা পুনরুদ্ধার করা ট্যাবে ব্রাউজারভেদে জীবনচক্রের বিবরণ বদলাতে পারে; তাই গুরুত্বপূর্ণ কাজের একমাত্র রেকর্ড হিসেবে এটি ব্যবহার করবেন না।

লোকাল স্টোরেজই একমাত্র সাইট-ডেটা ব্যবস্থা নয়

আধুনিক ওয়েব অ্যাপ্লিকেশন IndexedDB, Cache Storage, সার্ভিস-ওয়ার্কার রেজিস্ট্রেশন, Origin Private File System, অনুমতি ও ব্রাউজার-পরিচালিত অন্য স্টোরেও ডেটা রাখতে পারে। ডেভেলপার টুলে শুধু localStorage পরিষ্কার করলে অন্য অবস্থা থেকে যেতে পারে।

HTML Standard-এর গোপনীয়তা-সংক্রান্ত নির্দেশনা বলে ব্রাউজারকে স্থায়ী সংরক্ষণের ব্যবস্থাগুলো একসঙ্গে পরিষ্কার করার সুযোগ দেওয়া উচিত, নইলে সাইট একটি স্টোরে থাকা তথ্য দিয়ে অন্য স্টোর থেকে মুছে ফেলা শনাক্তকারী আবার তৈরি করতে পারে।

ক্যাশ: একই শব্দে কয়েকটি আলাদা ব্যবস্থা

HTTP ক্যাশ

RFC 9111 HTTP ক্যাশকে উত্তর বার্তার ভাণ্ডার এবং সংরক্ষণ, খোঁজা ও মুছে ফেলা নিয়ন্ত্রণকারী ব্যবস্থা হিসেবে সংজ্ঞায়িত করে। ব্রাউজারের ক্যাশ নতুন উত্তর পুনর্ব্যবহার করতে বা পুরোনো উত্তর আবার যাচাই করতে পারে, ফলে বিলম্ব ও নেটওয়ার্কে ডেটা পাঠানো কমে।

ক্যাশ কীতে অন্তত অনুরোধের পদ্ধতি ও লক্ষ্য URI থাকে এবং উত্তর-হেডার পুনর্ব্যবহার হবে কি না ও কতক্ষণ হবে তা প্রভাবিত করে। HTTP ক্যাশ মূলত গতি বাড়ানোর একটি স্তর। ক্যাশে থাকা ছবি বা স্ক্রিপ্ট মানেই কেউ অ্যাকাউন্টে প্রবেশ করেছেন—সাধারণত তা নয়।

ক্যাশের অবস্থা গোপনীয়তায় প্রভাব ফেলতে পারে। কিছু হুমকির মডেলে সময়ের পার্থক্য বা কোনো সম্পদ আগে থেকেই আছে কি না তা তথ্য ফাঁস করতে পারে। W3C-এর ফিঙ্গারপ্রিন্টিং নির্দেশনায় ক্যাশে থাকা সম্পদ পর্যবেক্ষণকে ব্রাউজার বা ব্যবহারকারীর বিন্যাস অনুমানের একটি উপায় বলা হয়েছে।

Cache Storage ও সার্ভিস ওয়ার্কার

Cache Storage API সাইটকে স্পষ্টভাবে নিয়ন্ত্রিত Cache অবজেক্ট দেয়, যা প্রায়ই অফলাইন ওয়েব অ্যাপ্লিকেশনে ব্যবহৃত হয়। Service Workers-এর নির্দিষ্টকরণ বলে এগুলো ব্রাউজারের HTTP ক্যাশ থেকে আলাদা, উৎসভিত্তিক বিচ্ছিন্ন এবং সাধারণ HTTP সতেজতার নিয়মে নয়—অ্যাপ্লিকেশনের যুক্তি অনুযায়ী আপডেট বা মুছে ফেলা হয়।

ডিবাগ করার সময় পার্থক্যটি গুরুত্বপূর্ণ:

• “ক্যাশে থাকা ছবি ও ফাইল” পরিষ্কার করলে ব্রাউজারের সাধারণ ক্যাশ লক্ষ্য করা হয়;
• সাইটের ডেটা পরিষ্কার করলে Cache Storage ও সার্ভিস-ওয়ার্কারের অবস্থাও সরিয়ে দিতে পারে; এবং
• HTTP ক্যাশ এড়িয়ে আবার লোড করলেও সক্রিয় সার্ভিস ওয়ার্কার অনুরোধ নিয়ন্ত্রণ করতে পারে।

পরীক্ষা বা পরিষ্কার করার আগে আপনি কোন ক্যাশ বোঝাচ্ছেন তা স্পষ্ট করে নাম দিন।

স্টোরেজ পার্টিশনিং আরেকটি কী যোগ করে

আগে একই উৎসের ভেতরে বসানো তৃতীয় পক্ষের উপাদান অনেক শীর্ষ-স্তরের সাইটে একই স্টোরেজ পড়তে পারত। আধুনিক ব্রাউজার স্টোরেজের কীতে শীর্ষ-স্তরের সাইট বা সম্পর্কিত প্রেক্ষাপটও যোগ করছে।

Chrome-এর storage partitioning নথি দেখায়, a.com-এ বসানো example.com ফ্রেম এবং b.com-এ একই ফ্রেমের Local Storage, IndexedDB, Cache Storage, সার্ভিস ওয়ার্কার ও কিছু যোগাযোগের ব্যবস্থা স্বয়ংক্রিয়ভাবে এক হয় না। Chrome বলেছে Chrome 115 থেকে এটি সব ব্যবহারকারীর জন্য চালু ছিল, যদিও কিছু API-তে পরে পরিবর্তন এসেছে।

পার্টিশনিং একটি অদ্ভুত ফল ব্যাখ্যা করে: চারপাশের সাইট অনুযায়ী একই বসানো উৎস আলাদা স্টোরেজ দেখতে পারে। এর অর্থ সব স্টোরেজের জন্য একই দুই-কী মডেল আছে—এমন নয়। ব্রাউজারের সংস্করণ, শীর্ষ-স্তরের ও বসানো প্রেক্ষাপট, স্টোরেজ-অ্যাক্সেসের অনুমতি, প্রতিষ্ঠানের নীতি, এক্সটেনশন ও API-ভিত্তিক নিয়ম ফল বদলাতে পারে।

শুধু ডোমেইনের নাম দেখে অনুমান না করে সঠিক প্রেক্ষাপটটি পরীক্ষা করুন।

ব্রাউজার ফিঙ্গারপ্রিন্ট: কোনো ফোল্ডার নয়, দৃশ্যমান সংকেত

W3C ব্রাউজার ফিঙ্গারপ্রিন্টিংকে বিন্যাসের সেটিং বা দেখা যায় এমন বৈশিষ্ট্য দিয়ে ব্যবহারকারী, ইউজার এজেন্ট বা ডিভাইসকে শনাক্ত বা আবার শনাক্ত করার ক্ষমতা বলে। তার 2025 সালের নির্দেশিকা কয়েকটি ধরন আলাদা করে:

• নিষ্ক্রিয় ফিঙ্গারপ্রিন্টিং অনুরোধ বা নেটওয়ার্কে আগে থেকেই দেখা তথ্য, যেমন অনুরোধের হেডার ও IP ঠিকানা, ব্যবহার করে।
• সক্রিয় ফিঙ্গারপ্রিন্টিং কোড চালিয়ে উইন্ডোর আকার, ফন্ট, সংযুক্ত ডিভাইস, কর্মক্ষমতা, সেন্সর বা গ্রাফিক্স রেন্ডারিং দেখে।
• অস্থায়ী ঘটনার মিল প্রায় একই সময়ে ডিভাইস বা পরিবেশে হওয়া পরিবর্তন দিয়ে প্রেক্ষাপট যুক্ত করে।
• কুকির মতো পদ্ধতি এমন ব্যবস্থায় অবস্থা রাখে ও পড়ে, যা সাধারণ কুকির পরে টিকে থাকতে বা কুকি আবার তৈরি করতে পারে।

ফিঙ্গারপ্রিন্ট সাধারণত ব্রাউজারে রাখা একটি অপরিবর্তনীয় মান নয়। পর্যবেক্ষক বিভিন্ন সংকেত বেছে নিয়ে মেলায় এবং আগের ভিজিটের সঙ্গে কতটা মেলে তা বিচার করে। ব্রাউজার আপডেট, উইন্ডোর পরিবর্তন, নতুন ফন্ট, সংযুক্ত ডিভাইস বা নেটওয়ার্কের পথ বদলালে ফল বদলাতে পারে। কুকি পরিষ্কার করার পরও অনেক মৌলিক সংকেত একই থাকায় ফল একই রকম হতে পারে।

ফিঙ্গারপ্রিন্টিং পরিচয়ের প্রমাণ নয়

সংকেতের সমষ্টি অনেক মানুষের মধ্যে একই হতে পারে বা একজনের ক্ষেত্রে সময়ের সঙ্গে বদলাতে পারে। সাইট ফিঙ্গারপ্রিন্টের সঙ্গে প্রবেশের তথ্য, সার্ভারে থাকা অ্যাকাউন্টের ইতিহাস, নেটওয়ার্কের সুনাম বা সংরক্ষিত শনাক্তকারীও মিলিয়ে দেখতে পারে। ডেটা পরিষ্কার করার পরও চিনে ফেললে তার একমাত্র কারণ ফিঙ্গারপ্রিন্টিং—এমন প্রমাণ হয় না।

একই কারণে একটি দৃশ্যমান সেটিং বদলালেই নতুন পরিচয় নিশ্চিত হয় না। সামঞ্জস্যপূর্ণ ও সাধারণ বিন্যাস কিছুটা স্বাতন্ত্র্য কমাতে পারে, আবার অনেক অস্বাভাবিক আলাদা পরিবর্তন আরও বিরল সমন্বয় তৈরি করতে পারে। এই সংকেতগুলো অদৃশ্য থাকা বা তৃতীয় পক্ষের সেবা গ্রহণ করবে—এমন নিশ্চয়তা দেয় না।

সাধারণ পরিষ্কার করার কাজ আসলে কী বদলায়

কাজ	সম্ভাব্য প্রভাব	গুরুত্বপূর্ণ যা থেকে যায়
কোনো সাইটের কুকি মুছুন	মিল থাকা ব্রাউজারে রাখা কুকির অবস্থা সরায় ও প্রায়ই সেই প্রোফাইল থেকে অ্যাকাউন্টে প্রবেশ বন্ধ করে	সার্ভারে থাকা অ্যাকাউন্টের ডেটা, অন্য ডিভাইস ও কুকি-বহির্ভূত স্টোর থাকতে পারে
কুকি ও অন্য সাইট-ডেটা মুছুন	ব্রাউজারের ইন্টারফেস ও সীমা অনুযায়ী কুকি, Web Storage, IndexedDB, সার্ভিস ওয়ার্কার ও সংশ্লিষ্ট সাইট-অবস্থা সরাতে পারে	পাসওয়ার্ড ম্যানেজার, ডাউনলোড, অ্যাকাউন্টের ডেটা ও দেখা যায় এমন ডিভাইস-সংকেত আলাদা থাকে
ক্যাশে থাকা ছবি ও ফাইল মুছুন	সাধারণ ক্যাশে থাকা উত্তর-বিষয়বস্তু সরায়	কুকি, লোকাল স্টোরেজ ও Cache Storage আলাদাভাবে বেছে নিতে হতে পারে
ইতিহাস পরিষ্কার করুন	নির্বাচিত সীমার ভিজিট করা URL ও সংশ্লিষ্ট পরামর্শ সরায়	ডাউনলোড করা ফাইল ও সাইটে থাকা রেকর্ড থেকে যায়
ব্রাউজার প্রোফাইল সরান	ডিভাইস থেকে লোকাল বুকমার্ক, ইতিহাস, পাসওয়ার্ড ও অন্যান্য সেটিং সরায়	সিঙ্ক করা অ্যাকাউন্টের ডেটা, ডাউনলোড বা এক্সপোর্ট করা ফাইল, ব্যাকআপ ও সার্ভারে থাকা ডেটা থেকে যেতে পারে
নতুন প্রোফাইল শুরু করুন	আলাদা প্রোফাইলের অবস্থা নিয়ে শুরু হয়	ডিভাইস, OS, ব্রাউজার বিল্ড ও নেটওয়ার্ককে তবু সম্পর্কিত হিসেবে দেখা যেতে পারে

Chrome-এর ব্রাউজিং ডেটা নির্দেশিকা ইতিহাস, কুকি ও সাইটের ডেটা, ক্যাশে থাকা ছবি ও ফাইল, ডাউনলোডের ইতিহাস, অটোফিল, সাইটের সেটিং ও হোস্ট করা অ্যাপের ডেটাকে আলাদা শ্রেণি হিসেবে দেখে। এতে আরও বলা আছে, ডাউনলোডের ইতিহাস মুছলেও ডাউনলোড করা ফাইল কম্পিউটারে থাকে এবং অ্যাকাউন্টে প্রবেশ করা ডেটা মুছলে Google Account ও অন্য সিঙ্ক করা ডিভাইস প্রভাবিত হতে পারে।

নির্বাচিত সময়সীমা, প্রোফাইল, অ্যাকাউন্টের অবস্থা, ব্রাউজারের সংস্করণ ও প্রতিষ্ঠানের নীতির ওপর প্রকৃত ফল নির্ভর করে। সহজে ফিরিয়ে আনা যায় না এমন ডেটা মুছার আগে নিশ্চিতকরণ লেখা পড়ুন।

আলাদা ব্রাউজার প্রোফাইল প্রতিটি ব্যবস্থায় কী প্রভাব ফেলে

সঠিকভাবে আলাদা স্থায়ী প্রোফাইলের নিজস্ব কুকি ভাণ্ডার, ওয়েব স্টোরেজ এলাকা, সাইটের ডেটাবেস, Cache Storage, HTTP ক্যাশের মালিকানা, ইতিহাস, সাইটের অনুমতি ও এক্সটেনশনের অবস্থা থাকা উচিত। এতে প্রোফাইল B সরাসরি প্রোফাইল A-এর সংরক্ষিত সেশন উত্তরাধিকারসূত্রে পায় না।

কিছু সংকেত একই থাকতে পারে:

• ব্রাউজার ইঞ্জিন ও সংস্করণ;
• অপারেটিং সিস্টেম ও হার্ডওয়্যার;
• ইনস্টল করা সিস্টেম ফন্ট ও পর্দার বৈশিষ্ট্য;
• হোস্ট থেকে পাওয়া ভাষা, সময় অঞ্চল বা অ্যাক্সেসিবিলিটি সেটিং;
• আলাদা পথ ঠিক না করলে IP ঠিকানা ও নেটওয়ার্কের পথ; এবং
• অপারেটরের আচরণ বা অ্যাপ্লিকেশন স্তরের প্রবেশের তথ্য, যা কাজগুলোকে যুক্ত করতে পারে।

এক্সটেনশন, অনুমতি, উইন্ডোর আকার, ভাষার সেটিং বা প্রক্সির পথের কারণে আলাদা প্রোফাইল আলাদা সংকেতও দেখাতে পারে। ফল বাস্তবায়ন ও প্রেক্ষাপটের ওপর নির্ভর করে। প্রোফাইল আলাদা রাখাকে অবস্থা আলাদা রাখার ব্যবস্থা হিসেবে মূল্যায়ন করুন, ফিঙ্গারপ্রিন্টের নিশ্চয়তা হিসেবে নয়।

সব পরিষ্কার করার আগে লক্ষণটি বুঝুন

“আমি অ্যাকাউন্ট থেকে বেরিয়ে গেছি”

আগে কুকি দেখুন। সেশনের কুকির মেয়াদ শেষ, মুছে যাওয়া, ব্রাউজারের নীতিতে প্রত্যাখ্যাত হওয়া অথবা সার্ভারে বাতিল হয়ে যাওয়া সম্ভব। লোকাল স্টোরেজ ইন্টারফেসকে সহায়তা করতে পারে, কিন্তু HTTP অনুরোধ প্রমাণীকরণে স্বয়ংক্রিয়ভাবে পাঠানো কুকি সাধারণত এটি নয়।

“সাইট আমার খসড়া বা অফলাইন ডেটা ভুলে গেছে”

লোকাল স্টোরেজ, IndexedDB, Cache Storage ও সার্ভিস-ওয়ার্কারের অবস্থা দেখুন। উৎসটি শীর্ষ-স্তরের পেজ, নাকি অন্য সাইটে বসানো—তা নিশ্চিত করুন, কারণ পার্টিশনিং স্টোরেজ বদলাতে পারে।

“প্রথমবার আবার লোড হতে সময় লাগে”

খালি বা পুরোনো HTTP ক্যাশ একটি কারণ হতে পারে। নেটওয়ার্ক, সার্ভার ও সার্ভিস-ওয়ার্কারের আচরণ একই লক্ষণ তৈরি করতে পারে; সিদ্ধান্তে আসার আগে অনুরোধের সময় ও ক্যাশের অবস্থা লিখে রাখুন।

“ডেটা পরিষ্কার করার পরও সাইট পরিবেশ চিনছে”

এর কয়েকটি ব্যাখ্যা থাকতে পারে: অন্য কোথাও অ্যাকাউন্টে প্রবেশ করা আছে, সার্ভার অ্যাকাউন্ট বা নেটওয়ার্কের ডেটা দিয়ে ভিজিট মিলিয়েছে, অন্য কোনো ব্রাউজার স্টোর থেকে গেছে অথবা দেখা যায় এমন বৈশিষ্ট্য সেশনগুলোকে যুক্ত করেছে। ফিঙ্গারপ্রিন্টিংকে একটি সম্ভাব্য কারণ হিসেবে ভাবুন, স্বয়ংক্রিয় উত্তর হিসেবে নয়।

সিদ্ধান্ত নেওয়ার দিক

প্রশ্ন অনুযায়ী ব্যবস্থা বেছে নিন:

• সার্ভারের সেশন নিয়ে প্রশ্ন হলে কুকি পরীক্ষা বা পরিষ্কার করুন;
• ওয়েব অ্যাপ্লিকেশন স্থানীয় অবস্থা রাখলে উৎস-সীমাবদ্ধ সাইটের স্টোর দেখুন;
• পুরোনো বা অফলাইন বিষয়বস্তু খুঁজতে HTTP ক্যাশ ও Cache Storage আলাদা করে দেখুন;
• সংরক্ষিত কাজের অবস্থা আলাদা রাখতে আলাদা স্থায়ী প্রোফাইল ব্যবহার করুন; এবং
• ফিঙ্গারপ্রিন্টিংকে দেখা যায় এমন সংকেতের মিল হিসেবে নিন; ডেটা পরিষ্কার বা একটি সেটিং বদলালেই তার সীমা মুছে যায় না।

এই মডেল দুটি ব্যয়বহুল ভুল এড়ায়: প্রয়োজনের চেয়ে বেশি অবস্থা মুছে ফেলা এবং খালি কুকি-স্টোরকে নতুন ডিভাইসের পরিচয় ভাবা।

সীমাবদ্ধতা

ব্রাউজারের সংস্করণ বদলালে ওয়েব স্টোরেজ ও গোপনীয়তার আচরণও বদলায়। তৃতীয় পক্ষের কুকির নিয়ম, স্টোরেজ পার্টিশনিং, ডেটা সরিয়ে ফেলা, সিঙ্ক, প্রতিষ্ঠানের নীতি, এক্সটেনশন ও ব্যক্তিগত-ব্রাউজিং মোড এখানে বর্ণিত আচরণ বদলাতে পারে। প্রবেশের তারিখে প্রচলিত মান ও বর্তমান Chrome নথির ভিত্তিতে এই নির্দেশিকা লেখা; প্রতিটি ব্রাউজার বা ওয়েবসাইটের বাস্তবায়ন এটি বর্ণনা করে না।