स्टोरेज के बंटवारे की सुविधा

उपयोगकर्ता की निजता को बेहतर बनाने और साइड चैनल क्रॉस-साइट ट्रैकिंग को रोकने के लिए, Chrome अब स्टोरेज पार्टिशनिंग की प्रोसेस का इस्तेमाल करके, तीसरे पक्ष के संदर्भ में ज़्यादातर स्टोरेज और कम्यूनिकेशन एपीआई को अलग करता है.

लागू करने की स्थिति

यह सुविधा, Chrome 115 और उसके बाद के वर्शन पर सभी उपयोगकर्ताओं के लिए चालू की गई है. स्टोरेज को अलग-अलग हिस्सों में बांटने की सुविधा, Firefox और Safari जैसे दूसरे मुख्य ब्राउज़र में भी उपलब्ध है या उन्हें उपलब्ध कराने की योजना बनाई जा रही है. GitHub पर, स्टोरेज को अलग-अलग हिस्सों में बांटने का प्रस्ताव, आगे की चर्चा के लिए उपलब्ध है.

स्टोरेज का बंटवारा क्या है?

कुछ तरह की साइड चैनल क्रॉस-साइट ट्रैकिंग को रोकने के लिए, Chrome तीसरे पक्ष के संदर्भों में स्टोरेज और कम्यूनिकेशन एपीआई को बांटता है.

स्टोरेज को अलग-अलग हिस्सों में बांटने के बिना, कोई साइट अलग-अलग साइटों के डेटा को जोड़ सकती है, ताकि वह इंटरनेट पर उपयोगकर्ता को ट्रैक कर सके. साथ ही, इससे एम्बेड की गई साइट को टॉप-लेवल साइट में उपयोगकर्ता के बारे में खास जानकारी हासिल करने में मदद मिलती है. इसके लिए, साइड-चैनल तकनीकों का इस्तेमाल किया जाता है. जैसे, टाइमिंग अटैक, XS-Leaks, और COSI.

पहले, स्टोरेज को सिर्फ़ ऑरिजिन के हिसाब से रखा जाता था. इसका मतलब है कि अगर example.com का कोई iframe, a.com और b.com पर एम्बेड किया गया है, तो वह उन दोनों साइटों के लिए आपकी ब्राउज़िंग की आदतों के बारे में जान सकता है. इसके लिए, वह स्टोरेज में आईडी सेव करके और उसे वापस पाकर ऐसा करता है. तीसरे पक्ष के स्टोरेज के पार्टीशन की सुविधा चालू होने पर, example.com के लिए स्टोरेज दो अलग-अलग पार्टीशन में मौजूद होता है. एक a.com के लिए और दूसरा b.com के लिए.

आम तौर पर, पार्टीशन करने का मतलब है कि किसी iframe में, लोकल स्टोरेज और IndexedDB जैसे स्टोरेज एपीआई से लिखे गए डेटा को, एक ही ऑरिजिन शेयर करने वाले सभी कॉन्टेक्स्ट ऐक्सेस नहीं कर सकते. इसके बजाय, अब वह डेटा अलग-अलग होता है और सिर्फ़ उन कॉन्टेक्स्ट के लिए उपलब्ध होता है जो एक ही ऑरिजिन और एक ही टॉप-लेवल साइट को शेयर करते हैं.

पहले

स्टोरेज एपीआई, जिनमें स्टोरेज को अलग-अलग हिस्सों में बांटा नहीं गया है.
स्टोरेज को अलग-अलग हिस्सों में बांटने से पहले, example.com, a.com पर एम्बेड होने पर डेटा लिख सकता है और b.com पर एम्बेड होने पर उसे पढ़ सकता है.

बाद में

पार्टीशन वाले स्टोरेज एपीआई.
स्टोरेज को अलग-अलग हिस्सों में बांटने के बाद, example.com को b.com में जोड़ने पर, वह a.com में जोड़े जाने पर example.com का स्टोरेज ऐक्सेस नहीं कर सकता.

चेन किए गए iframe पर स्टोरेज का बंटवारा

जब iframe नेस्ट किए जाते हैं, तो स्टोरेज को अलग-अलग हिस्सों में बांटने की प्रोसेस काफ़ी मुश्किल हो जाती है. खास तौर पर, जब चेन में एक ही ऑरिजिन कई बार दिखता है.

उदाहरण के लिए, A1 में B के लिए एक iframe है, जिसमें A2 के लिए एक iframe है और A1 और A2, दोनों एक ही साइट पर मौजूद हैं. अगर पार्टिशनिंग में सिर्फ़ टॉप-लेवल साइट और मौजूदा फ़्रेम के ऑरिजिन को शामिल किया जाता है, तो iframe A2 को गलती से 'फ़र्स्ट पार्टी' माना जा सकता है. ऐसा इसलिए, क्योंकि यह टॉप-लेवल (A1) के साथ एक साइट शेयर करता है, भले ही बीच में क्रॉस-साइट iframe B हो. अगर A2 के पास डिफ़ॉल्ट रूप से, बिना बंटे हुए स्टोरेज का ऐक्सेस होता है, तो A2 को क्लिक जैकिंग जैसे सुरक्षा जोखिमों का सामना करना पड़ सकता है.

इस समस्या को हल करने के लिए, Chrome स्टोरेज पार्टीशन की कुंजी में "ऐंसेस्टर बिट" जोड़ता है. यह बिट तब सेट होता है, जब मौजूदा iframe और टॉप-लेवल साइट के बीच कोई दस्तावेज़ किसी दूसरे (क्रॉस-साइट) ऑरिजिन से हो. इस मामले में, साइट B किसी दूसरी साइट से जुड़ी है. इसलिए, बिट A2 के लिए सेट किया जाएगा और उसका स्टोरेज A1 से अलग किया जाएगा.

जब iframe चेन में सिर्फ़ एक ही साइट के कॉन्टेक्स्ट शामिल होते हैं, तो एंसेस्टर बिट अपने स्टोरेज को आगे से अलग-अलग हिस्सों में नहीं बांटेगा. उदाहरण के लिए, साइट A1 में A2 है, जिसमें A3 है. ऐसे मामलों में, उनका स्टोरेज शेयर किया जाता रहता है. यह स्टोरेज, उनके सामान्य ऑरिजिन और टॉप लेवल साइट के हिसाब से शेयर किया जाता है.

जिन साइटों को चेन किए गए iframes में बिना बंटे हुए ऐक्सेस की ज़रूरत है उनके लिए, Chrome इस इस्तेमाल के उदाहरण को चालू करने के लिए, Storage Access API को एक्सटेंड करने के साथ प्रयोग कर रहा है. Storage Access API के लिए, फ़्रेम की गई साइट को एपीआई को साफ़ तौर पर शुरू करना ज़रूरी है. इससे क्लिकजैकिंग का जोखिम कम हो जाता है.

पार्टीशन करने की वजह से एपीआई में हुए बदलाव

जिन एपीआई पर पार्टिशनिंग का असर पड़ा है उन्हें इन ग्रुप में बांटा जा सकता है:

Storage API

  • कोटा सिस्टम
    कोटा सिस्टम का इस्तेमाल यह तय करने के लिए किया जाता है कि स्टोरेज के लिए डिस्क का कितना स्पेस दिया जाए. कोटा सिस्टम, हर सेगमेंट को अलग-अलग बकेट के तौर पर मैनेज करता है. इससे यह तय किया जाता है कि कितना स्टोरेज दिया जाए और कब उसे खाली किया जाए.
    navigator.storage.estimate() तरीका अब स्टोरेज पार्टीशन के बारे में खास जानकारी देता है. सिर्फ़ Chrome के लिए उपलब्ध एपीआई, जैसे कि window.webkitStorageInfo और navigator.webkitTemporaryStorage अब काम नहीं करते.
    IndexedDB और कैश मेमोरी, दोनों में कोटा के बंटे हुए सिस्टम का इस्तेमाल किया जाता है.
  • Web Storage API
    Web Storage API, ब्राउज़र में की-वैल्यू पेयर को सेव करने के तरीके उपलब्ध कराता है. इसके दो तरीके हैं: लोकल स्टोरेज और सेशन स्टोरेज. इन्हें कोटा के हिसाब से मैनेज नहीं किया जाता, लेकिन इन्हें अब भी अलग-अलग हिस्सों में बांटा जाता है.
  • Origin का निजी फ़ाइल सिस्टम
    File System Access API की मदद से, उपयोगकर्ता से ऐक्सेस मिलने के बाद, साइट सीधे डिवाइस पर मौजूद फ़ाइलों और फ़ोल्डर में बदलावों को पढ़ सकती है या सेव कर सकती है. Origin Private File System की मदद से, ओरिजिन सीधे डिस्क पर निजी कॉन्टेंट स्टोर कर सकता है. यह कॉन्टेंट, उपयोगकर्ता के लिए अब भी उपलब्ध है. हालांकि, अब इसे अलग-अलग हिस्सों में बांटा गया है.
  • Storage Bucket API
    Storage Bucket API को स्टोरेज स्टैंडर्ड के लिए डेवलप किया जा रहा है. यह बकेट नाम के नए कॉन्सेप्ट का इस्तेमाल करके, IndexedDB और localStorage जैसे अलग-अलग स्टोरेज एपीआई को एक साथ जोड़ता है. बकेट में सेव किए गए डेटा और बकेट से जुड़े मेटाडेटा को अलग-अलग हिस्सों में बांटा जाता है.
  • Clear-Site-Data हेडर
    रिस्पॉन्स में Clear-Site-Data हेडर शामिल करने से, सर्वर को उपयोगकर्ता के ब्राउज़र में सेव किए गए डेटा को मिटाने का अनुरोध करने की अनुमति मिलती है. कैश मेमोरी, कुकी, और DOM स्टोरेज को मिटाया जा सकता है. हेडर का इस्तेमाल करने पर, सिर्फ़ एक पार्टीशन का स्टोरेज खाली होता है.
  • BLOB यूआरएल स्टोर
    ब्लॉब यूआरएल, ब्लॉब का ऐक्सेस देता है. यह एक ऐसा ऑब्जेक्ट होता है जिसमें रॉ डेटा होता है. स्टोरेज के बंटवारे के बिना, किसी साइट पर तीसरे पक्ष के iframe में जनरेट किए गए ब्लॉब यूआरएल का इस्तेमाल, दूसरी साइट में एम्बेड किए गए एक ही ऑरिजिन वाले iframe में किया जा सकता है. उदाहरण के लिए, अगर example.com iframes, a.com और b.com, दोनों पर एम्बेड किए गए हैं, तो a.com पर एम्बेड किए गए iframe में जनरेट किए गए ब्लॉब यूआरएल को b.com पर एम्बेड किए गए iframe को पास किया जा सकता है. इसके बाद, b.com पर एम्बेड किए गए iframe का इस्तेमाल, बिना किसी पाबंदी के किया जा सकता है. Chrome 137 (27 मई, 2025 को रिलीज़ किया गया) से, ब्लॉब यूआरएल को टॉप-लेवल नेविगेशन के अलावा, सभी इस्तेमाल के लिए अलग-अलग हिस्सों में बांटा गया है. अब जिन मामलों को ब्लॉक किया जाएगा उनमें, क्रॉस-पार्टिशन ब्लॉब यूआरएल का इस्तेमाल fetch() के साथ करने या अलग-अलग एचटीएमएल एलिमेंट के लिए src एट्रिब्यूट की वैल्यू के तौर पर करने के मामले शामिल हैं. अगर BLOB यूआरएल, क्रॉस-पार्टिशन हैं, तो window.open() को कॉल करने या target='_blank' वाले लिंक पर क्लिक करने जैसे टॉप-लेवल नेविगेशन को ब्लॉक नहीं किया जाएगा. हालांकि, अगर BLOB यूआरएल की साइट, नेविगेशन शुरू करने वाले पेज की टॉप-लेवल साइट से क्रॉस-साइट है, तो noopener लागू किया जाएगा. noopener को लागू करने का मतलब है कि नेविगेशन शुरू करने वाले दस्तावेज़ को, खोले गए ब्लॉब यूआरएल दस्तावेज़ के लिए विंडो हैंडल नहीं मिलेगा. पिछले उदाहरण में, पार्टिशन करने से b.com पर मौजूद iframe, ब्लॉब यूआरएल का कॉन्टेंट फ़ेच नहीं कर पाएगा. हालांकि, वह अब भी window.open() कर पाएगा.

Communication APIs

स्टोरेज एपीआई के साथ-साथ, कम्यूनिकेशन एपीआई को भी बांटा जाता है. इन एपीआई की मदद से, एक कॉन्टेक्स्ट को ऑरिजिन की सीमाओं के पार कम्यूनिकेट करने की अनुमति मिलती है. इन बदलावों का मुख्य असर उन एपीआई पर पड़ता है जो ब्रॉडकास्टिंग या एक ही सोर्स के रेंडव्यू का इस्तेमाल करके, दूसरे कॉन्टेक्स्ट को खोजने की अनुमति देते हैं.

पार्टिशन करने की वजह से, ये कम्यूनिकेशन एपीआई तीसरे पक्ष के iframe को, एक ही ऑरिजिन वाले कॉन्टेक्स्ट के साथ डेटा एक्सचेंज करने से रोकते हैं:

  • ब्रॉडकास्ट चैनल
    Broadcast Channel API की मदद से, एक ही ऑरिजिन के ब्राउज़िंग कॉन्टेक्स्ट (विंडो, टैब या iframe) और वर्कर के बीच कम्यूनिकेशन किया जा सकता है.
    क्रॉस-साइट iframe postMessage() के व्यवहार में बदलाव करने का सुझाव नहीं दिया गया है, क्योंकि उन कॉन्टेक्स्ट के बीच का संबंध पहले से ही साफ़ तौर पर बताया गया है.
  • SharedWorker
    SharedWorker API एक ऐसा वर्कर उपलब्ध कराता है जिसे एक ही ऑरिजिन के सभी ब्राउज़िंग कॉन्टेक्स्ट में ऐक्सेस किया जा सकता है.
  • वेब लॉक
    Web Locks API, एक ही ऑरिजिन के एक टैब या वर्कर में चल रहे कोड को, शेयर किए गए संसाधन के लिए लॉक हासिल करने की अनुमति देता है. ऐसा तब किया जाता है, जब कोई काम किया जा रहा हो.

Service Worker API

Service Worker API की मदद से, साइटें बैकग्राउंड में टास्क कर सकती हैं. साइटें, इवेंट के जवाब में नए वर्कर्स कॉन्टेक्स्ट बनाने वाले सेवा वर्कर रजिस्टर करती हैं. आम तौर पर, ये वर्कर्स एक ही ऑरिजिन वाले किसी भी कॉन्टेक्स्ट से कम्यूनिकेट कर सकते थे. हालांकि, सेवा वर्कर नेविगेशन अनुरोधों के समय में बदलाव कर सकते हैं. इसलिए, इनसे इतिहास को चुपके से देखने जैसी क्रॉस-साइट जानकारी लीक होने का खतरा होता है.

इस वजह से, तीसरे पक्ष के संदर्भ से रजिस्टर किए गए सर्विस वर्कर को अब अलग-अलग हिस्सों में बांटा गया है.

एक्सटेंशन एपीआई

एक्सटेंशन ऐसे प्रोग्राम होते हैं जिनकी मदद से, उपयोगकर्ता अपने ब्राउज़िंग अनुभव को पसंद के मुताबिक बना सकते हैं.

एक्सटेंशन पेजों (chrome-extension:// स्कीम वाले पेजों) को वेब पर मौजूद सभी साइटों पर जोड़ा जा सकता है. इस स्थिति में, एक्सटेंशन पेजों के पास अपने टॉप-लेवल के सेगमेंट का ऐक्सेस बना रहता है. एक्सटेंशन, दूसरी साइटों को भी एम्बेड कर सकते हैं. ऐसा करने पर, एम्बेड की गई साइटें अपना टॉप-लेवल पार्टीशन ऐक्सेस करेंगी. हालांकि, इसके लिए ज़रूरी है कि एक्सटेंशन के पास उनके लिए होस्ट की अनुमतियां हों.

ज़्यादा जानकारी के लिए, एक्सटेंशन के दस्तावेज़ देखें.

डेमो: स्टोरेज के पार्टीशन की जांच करना

डेमो साइट: https://storage-partitioning-demo-site-a.glitch.me/

डेमो साइट, जिसमें बाईं ओर हरे रंग के सही का निशान और दाईं ओर लाल रंग के गलत का निशान दिख रहा है.
डेमो का स्क्रीनशॉट, जिसमें बाईं ओर स्टोरेज को अलग-अलग हिस्सों में बांटने वाले ब्राउज़र का आउटपुट और दाईं ओर स्टोरेज को अलग-अलग हिस्सों में न बांटने वाले ब्राउज़र का आउटपुट दिखाया गया है.

डेमो में दो साइटों का इस्तेमाल किया गया है: साइट A और साइट B.

  • जब टॉप-लेवल कॉन्टेक्स्ट में साइट A पर विज़िट किया जाता है, तो यह स्टोरेज के अलग-अलग तरीकों का इस्तेमाल करके डेटा सेट करता है.
  • साइट B, साइट A के किसी पेज को एम्बेड करती है. यह एम्बेड, पहले से सेट किए गए स्टोरेज के विकल्पों को पढ़ने की कोशिश करता है.
  • जब साइट A को साइट B पर एम्बेड किया जाता है, तो स्टोरेज के बंटवारे के बाद, साइट A के पास उस डेटा का ऐक्सेस नहीं होता. इसलिए, डेटा को पढ़ने में समस्या आती है.
  • डेमो में, हर रीड के कामयाब होने या न होने का इस्तेमाल करके यह दिखाया जाता है कि डेटा को पार्टिशन किया गया है या नहीं.

फ़िलहाल, --disable-features=ThirdPartyStoragePartitioning कमांड-लाइन स्विच का इस्तेमाल करके, Chrome में स्टोरेज का बंटवारा करने की सुविधा बंद की जा सकती है. ध्यान दें: यह कमांड-लाइन स्विच, डेवलपमेंट और टेस्टिंग के लिए है. आने वाले समय में, Chrome के वर्शन में इसे हटाया या बदला जा सकता है.

अन्य ब्राउज़र की पार्टीशनिंग की स्थिति देखने के लिए, उसी तरह से उनका भी टेस्ट किया जा सकता है.

दर्शकों से जुड़ना और सुझाव/राय देना या शिकायत करना