Isoline गाइड

कुकी, लोकल स्टोरेज, कैश और ब्राउज़र फ़िंगरप्रिंट का अंतर

ब्राउज़र की सहेजी स्थिति और दिखने वाले पहचान संकेत अलग तंत्र हैं। यह गाइड उनके दायरे, जीवनकाल, मिटाने के असर और सामान्य समस्याओं की जाँच समझाती है।

ये शब्द अक्सर गोपनीयता सेटिंग, डिबगिंग निर्देश और ब्राउज़र प्रोफ़ाइल उत्पादों में साथ आते हैं। उनका व्यवहार इतना अलग है कि ‘ब्राउज़र साफ़ करो’ अधूरा निर्देश है।

काम में आने वाला ढाँचा

तंत्र कौन बनाता या नियंत्रित करता है सामान्य दायरा आम उपयोग अनुरोध के साथ अपने आप जाता है?
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 मानक 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 मानक का गोपनीयता मार्गदर्शन ब्राउज़र को स्थायी स्टोरेज तंत्र साथ मिटाने देने की सलाह देता है, वरना साइट एक स्टोर से दूसरे से हटाया पहचानकर्ता फिर बना सकती है।

कैश: कई तंत्रों के लिए एक शब्द

HTTP कैश

RFC 9111 HTTP कैश को उत्तर संदेशों के स्टोर और उन्हें रखने, लेने व मिटाने की प्रणाली के रूप में परिभाषित करता है। ब्राउज़र ताज़ा उत्तर दोबारा इस्तेमाल या पुराने उत्तर का पुनः सत्यापन करके देरी और नेटवर्क ट्रांसफ़र घटा सकता है।

कैश कुंजी में कम से कम अनुरोध विधि और लक्ष्य URI होते हैं। उत्तर हेडर तय करते हैं कि उत्तर दोबारा इस्तेमाल हो सकता है या नहीं और कितनी देर। HTTP कैश अनुकूलन की परत है। कैश में चित्र या स्क्रिप्ट होने का सामान्यतः मतलब व्यक्ति का साइन इन होना नहीं।

कैश स्थिति गोपनीयता को फिर भी प्रभावित कर सकती है। कुछ खतरे के मॉडल में समय या संसाधन पहले से उपलब्ध होना जानकारी दिखा सकता है। W3C फ़िंगरप्रिंटिंग मार्गदर्शन कैश संसाधन अवलोकन को ब्राउज़र या उपयोगकर्ता कॉन्फ़िगरेशन समझने का एक तरीका बताता है।

Cache Storage और सर्विस वर्कर

Cache Storage API साइट को स्पष्ट स्क्रिप्ट नियंत्रित Cache ऑब्जेक्ट देती है, अक्सर ऑफ़लाइन वेब ऐप के लिए। Service Workers विनिर्देश बताता है कि ये ब्राउज़र HTTP कैश से अलग, ओरिजिन के अनुसार पृथक और सामान्य HTTP ताज़गी नियमों के बजाय ऐप लॉजिक से अपडेट या मिटते हैं।

डिबगिंग में यह अंतर महत्वपूर्ण है:

  • ‘कैश की गई तस्वीरें और फ़ाइलें’ मिटाना सामान्य ब्राउज़र कैश पर लागू होता है;
  • साइट डेटा मिटाने से Cache Storage और सर्विस वर्कर स्थिति भी हट सकती है; और
  • HTTP कैश छोड़कर रीलोड करने पर भी सक्रिय सर्विस वर्कर अनुरोध नियंत्रित कर सकता है।

जाँच या मिटाने का तरीका चुनने से पहले बताइए कि कौन-सा कैश है।

स्टोरेज पार्टिशनिंग एक और कुंजी जोड़ती है

पहले ओरिजिन दायरा एम्बेड की गई तीसरी साइट को कई मुख्य साइटों में वही स्टोरेज पढ़ने देता था। आधुनिक ब्राउज़र बढ़ते तौर पर शीर्ष स्तर की साइट या संबंधित संदर्भ स्टोरेज कुंजी में जोड़ते हैं।

Chrome बताता है कि उसकी स्टोरेज पार्टिशनिंग a.com में लगे example.com फ़्रेम को b.com में उसी फ़्रेम से Local Storage, IndexedDB, Cache Storage, सर्विस वर्कर और कुछ संचार तंत्र अपने आप साझा करने से रोकती है। Chrome के अनुसार यह Chrome 115 से सभी उपयोगकर्ताओं के लिए सक्षम है; कुछ अतिरिक्त API में बाद में बदलाव हुए।

इससे एक अन्यथा चौंकाने वाला परिणाम समझ आता है: वही एम्बेड ओरिजिन आसपास की साइट के अनुसार अलग स्टोरेज देख सकता है। इसका अर्थ नहीं कि हर स्टोरेज के लिए एक सार्वभौमिक दो-कुंजी मॉडल है। संस्करण, मुख्य व एम्बेड संदर्भ, स्टोरेज पहुँच अधिकार, एंटरप्राइज़ नीति, एक्सटेंशन और API नियम परिणाम बदल सकते हैं।

केवल डोमेन नाम से अनुमान लगाने के बजाय सटीक संदर्भ जाँचें।

ब्राउज़र फ़िंगरप्रिंट: दिखने वाले संकेत, कोई फ़ोल्डर नहीं

W3C ब्राउज़र फ़िंगरप्रिंटिंग को कॉन्फ़िगरेशन या दूसरी दिखने वाली विशेषताओं से उपयोगकर्ता, ब्राउज़र या डिवाइस की पहचान अथवा फिर पहचान की क्षमता कहता है। उसका 2025 का मार्गदर्शन कई रूप अलग करता है:

  • निष्क्रिय फ़िंगरप्रिंटिंग: अनुरोध या नेटवर्क में पहले से दिखती जानकारी, जैसे हेडर और IP।
  • सक्रिय फ़िंगरप्रिंटिंग: विंडो आकार, फ़ॉन्ट, जुड़े डिवाइस, प्रदर्शन, सेंसर या ग्राफ़िक्स देखने वाला कोड।
  • क्षणिक घटनाओं का संबंध: लगभग एक साथ हुए डिवाइस या वातावरण बदलाव से संदर्भ जोड़ना।
  • कुकी जैसे तरीके: ऐसे तंत्र से स्थिति रखना और पाना जो सामान्य कुकी से अधिक टिके या उसे फिर बनाए।

फ़िंगरप्रिंट शायद ही ब्राउज़र में रखा एक अपरिवर्तनीय मान हो। पर्यवेक्षक संकेत चुनता, जोड़ता और पिछली विज़िट से मेल की मज़बूती तय करता है। अपडेट, विंडो बदलाव, फ़ॉन्ट जुड़ना, डिवाइस कनेक्ट होना या नेटवर्क रास्ता बदलना परिणाम बदल सकते हैं। कुकी मिटाने के बाद भी मूल संकेत समान होने से परिणाम मिलता-जुलता रह सकता है।

फ़िंगरप्रिंट पहचान का प्रमाण नहीं है

कई लोगों के संकेत समान हो सकते हैं या एक व्यक्ति के समय के साथ बदल सकते हैं। साइट फ़िंगरप्रिंट को लॉगिन, सर्वर खाता इतिहास, नेटवर्क प्रतिष्ठा या सेव पहचानकर्ता से भी जोड़ सकती है। इसलिए डेटा मिटाने के बाद पहचान होना यह सिद्ध नहीं करता कि कारण केवल फ़िंगरप्रिंटिंग था।

इसी तरह एक सेटिंग बदलना नई पहचान की गारंटी नहीं। संगत और आम कॉन्फ़िगरेशन कुछ विशिष्टता घटा सकती है, जबकि कई असामान्य स्वतंत्र बदलाव दुर्लभ संयोजन बना सकते हैं। ये संकेत अदृश्यता या तीसरे पक्ष की स्वीकृति की गारंटी का आधार नहीं हैं।

सामान्य सफ़ाई कार्रवाइयाँ क्या बदलती हैं

कार्रवाई संभावित असर महत्वपूर्ण बची चीज़ें
साइट की कुकी मिटाना संबंधित ब्राउज़र कुकी हटती हैं; अक्सर उस प्रोफ़ाइल से साइन आउट होता है सर्वर खाता डेटा, दूसरे डिवाइस और गैर-कुकी स्टोर बच सकते हैं
कुकी और अन्य साइट डेटा मिटाना UI व दायरे के अनुसार कुकी, Web Storage, IndexedDB, सर्विस वर्कर और संबंधित स्थिति हट सकती है पासवर्ड मैनेजर, डाउनलोड, खाता डेटा और डिवाइस संकेत अलग हैं
कैश चित्र व फ़ाइलें मिटाना सामान्य कैश उत्तर हटते हैं कुकी, लोकल स्टोरेज और Cache Storage को अलग चयन चाहिए हो सकता है
इतिहास मिटाना चुने दायरे के विज़िट URL और संबंधित सुझाव हटते हैं डाउनलोड फ़ाइलें और साइट के रिकॉर्ड बचते हैं
प्रोफ़ाइल हटाना डिवाइस से स्थानीय बुकमार्क, इतिहास, पासवर्ड और सेटिंग हटती हैं सिंक खाता डेटा, डाउनलोड या निर्यात, बैकअप और सर्वर डेटा बच सकते हैं
नई प्रोफ़ाइल शुरू करना अलग प्रोफ़ाइल स्थिति से शुरुआत डिवाइस, OS, ब्राउज़र बिल्ड और नेटवर्क संबंधित दिख सकते हैं

Chrome की ब्राउज़िंग डेटा गाइड इतिहास, कुकी व साइट डेटा, कैश चित्र व फ़ाइलें, डाउनलोड इतिहास, ऑटोफ़िल, साइट सेटिंग और होस्ट ऐप डेटा अलग श्रेणियाँ मानती है। वह बताती है कि डाउनलोड इतिहास मिटाने से फ़ाइलें कंप्यूटर पर रहती हैं और साइन इन डेटा मिटाने से Google खाता व दूसरे सिंक डिवाइस प्रभावित हो सकते हैं।

सटीक असर चुनी समय अवधि, प्रोफ़ाइल, खाता स्थिति, संस्करण और एंटरप्राइज़ नीति पर निर्भर है। कठिनाई से लौटने वाले डेटा को मिटाने से पहले पुष्टि का पाठ पढ़ें।

अलग प्रोफ़ाइल हर तंत्र को कैसे प्रभावित करती है

सही अलग की गई स्थायी प्रोफ़ाइल का अपना कुकी संग्रह, वेब स्टोरेज, साइट डेटाबेस, Cache Storage, HTTP कैश स्वामित्व, इतिहास, अनुमतियाँ और एक्सटेंशन स्थिति होनी चाहिए। इससे B को A का सेव सत्र अपने आप नहीं मिलता।

कुछ संकेत साझा रह सकते हैं:

  • ब्राउज़र इंजन और संस्करण;
  • OS और हार्डवेयर;
  • सिस्टम फ़ॉन्ट और डिस्प्ले;
  • होस्ट से मिली भाषा, समय क्षेत्र या सुलभता सेटिंग;
  • अलग रास्ता न हो तो IP और नेटवर्क पथ; और
  • ऐप स्तर पर गतिविधि जोड़ने वाला ऑपरेटर व्यवहार या लॉगिन।

एक्सटेंशन, अनुमतियाँ, विंडो आकार, भाषा या प्रॉक्सी से अलग प्रोफ़ाइल अलग संकेत भी दिखा सकती हैं। कुल असर लागूकरण और संदर्भ पर निर्भर है। प्रोफ़ाइल अलगाव को स्थिति के अलगाव के रूप में आँकें, फ़िंगरप्रिंट की गारंटी के रूप में नहीं।

सब मिटाने से पहले लक्षण समझें

‘मैं साइन आउट हो गया’

पहले कुकी जाँचें। सत्र कुकी समाप्त, मिटी, नीति से अस्वीकृत या सर्वर से अमान्य हुई हो सकती है। लोकल स्टोरेज इंटरफ़ेस का साथ दे सकता है, लेकिन वह सामान्यतः HTTP प्रमाणीकरण के लिए अपने आप भेजी कुकी नहीं है।

‘साइट मेरा ड्राफ़्ट या ऑफ़लाइन डेटा भूल गई’

लोकल स्टोरेज, IndexedDB, Cache Storage और सर्विस वर्कर जाँचें। ओरिजिन और पेज मुख्य है या दूसरी साइट में लगा है, इसकी पुष्टि करें; पार्टिशनिंग उपलब्ध स्टोरेज बदल सकती है।

‘पहली बार फिर लोड करना धीमा है’

खाली या पुराना HTTP कैश संभावित कारण है। नेटवर्क, सर्वर और सर्विस वर्कर वही लक्षण दे सकते हैं, इसलिए निष्कर्ष से पहले अनुरोध समय और कैश स्थिति दर्ज करें।

‘डेटा मिटाने पर भी साइट वातावरण पहचानती है’

कई कारण संभव हैं: खाता दूसरी जगह साइन इन है, सर्वर ने खाता या नेटवर्क डेटा से विज़िट जोड़ी, कोई दूसरा स्टोर बचा या दिखने वाली विशेषताओं ने सत्र जोड़े। फ़िंगरप्रिंटिंग को एक संभावना मानें, अपने आप अंतिम उत्तर नहीं।

तंत्र के अनुसार समाधान चुनें

  • सर्वर सत्र का सवाल हो तो कुकी देखें या मिटाएँ;
  • ऐप स्थानीय स्थिति रखता हो तो ओरिजिन आधारित स्टोर जाँचें;
  • पुरानी या ऑफ़लाइन सामग्री में HTTP कैश और Cache Storage अलग पहचानें;
  • काम की सेव स्थिति स्वतंत्र चाहिए तो अलग स्थायी प्रोफ़ाइल लें; और
  • फ़िंगरप्रिंटिंग को दिखने वाले संकेतों का संबंध मानें, जिसकी सीमाएँ डेटा मिटाने या एक सेटिंग बदलने से खत्म नहीं होतीं।

यह ढाँचा दो महँगी गलतियाँ रोकता है: ज़रूरत से अधिक स्थिति मिटाना और खाली कुकी संग्रह को नई डिवाइस पहचान समझना।

सीमाएँ

वेब स्टोरेज और गोपनीयता व्यवहार ब्राउज़र व रिलीज़ के साथ बदलते हैं। तीसरे पक्ष की कुकी नीति, पार्टिशनिंग, डेटा हटना, सिंक, एंटरप्राइज़ नीति, एक्सटेंशन और निजी मोड यहाँ का व्यवहार बदल सकते हैं। यह गाइड स्रोत देखने की तारीख पर मानक और Chrome दस्तावेज़ समझाती है; हर ब्राउज़र या वेबसाइट का पूरा वर्णन नहीं।

इस गाइड के बारे में

AI सहायता
इस लेख का अंग्रेज़ी स्रोत से AI की सहायता से अनुवाद किया गया है। प्रकाशित सामग्री की ज़िम्मेदारी Isoline की है। हिंदी में दक्ष व्यक्ति की समीक्षा अभी दर्ज नहीं हुई है।

स्रोत

स्रोत नीचे दिए विषयों का समर्थन करते हैं। देखने की तारीखें बताती हैं कि उद्धृत सामग्री कब जाँची गई थी।

  1. विषय
    कुकी स्टोरेज, भेजना, विशेषताओं का अर्थ, सुरक्षा सीमाएँ और स्वतः लागू सत्र अधिकार।
    देखने की तारीख
  2. विषय
    ओरिजिन तक सीमित localStorage और sessionStorage का व्यवहार, स्थायित्व और गोपनीयता मार्गदर्शन।
    देखने की तारीख
  3. IETF RFC 9111: HTTP कैशिंग Internet Engineering Task Force
    विषय
    HTTP कैश स्टोरेज, कुंजियाँ, ताज़गी, पुनः सत्यापन और उत्तर दोबारा इस्तेमाल करने के नियम।
    देखने की तारीख
  4. विषय
    ओरिजिन से बँधा स्क्रिप्ट नियंत्रित Cache Storage और ब्राउज़र HTTP कैश से उसका अंतर।
    देखने की तारीख
  5. विषय
    शीर्ष स्तर के संदर्भ से Chrome स्टोरेज अलग करना, उसका लागू होना और API अनुसार सीमाएँ।
    देखने की तारीख
  6. विषय
    मिटाने की अलग श्रेणियाँ, सिंक पर असर और इतिहास मिटाने के बाद बचा डेटा।
    देखने की तारीख
  7. विषय
    Cache Storage, सर्विस वर्कर और साइट स्टोरेज सहित ब्राउज़र डेटा प्रकार के नियंत्रण।
    देखने की तारीख
  8. विषय
    स्थानीय Chrome प्रोफ़ाइल अलगाव और प्रोफ़ाइल मिटाने के असर व सीमाएँ।
    देखने की तारीख
  9. विषय
    निष्क्रिय, सक्रिय और सहेजी स्थिति आधारित फ़िंगरप्रिंट संकेत तथा उन्हें जोड़ने की सीमाएँ।
    देखने की तारीख
सुधार सुझाएँ