Chrome ने एक नए अनुभव का प्रस्ताव दिया है. इसमें उपयोगकर्ता यह चुन पाएंगे कि ब्राउज़ करते समय तीसरे पक्ष की कुकी को कैसे मैनेज किया जाए. साइटों और सेवाओं को यह पता लगाना पड़ सकता है कि किसी खास संदर्भ में तीसरे पक्ष की कुकी उपलब्ध हैं या नहीं. Chrome में, एम्बेड किए गए कॉन्टेंट के लिए तीसरे पक्ष की कुकी के ऐक्सेस का पता लगाने के दो मुख्य तरीके हैं: hasStorageAccess JavaScript तरीके का इस्तेमाल करना और Sec-Fetch-Storage-Access हेडर को देखना.
Privacy Sandbox में ऐसे एपीआई शामिल किए गए हैं जो कुछ शर्तें पूरी होने पर, चुनिंदा फ़्रेम को तीसरे पक्ष की कुकी का ऐक्सेस दे सकते हैं. इसलिए, यह ज़रूरी है कि हर एम्बेड के हिसाब से, बिना बंटवारे वाली कुकी के ऐक्सेस का पता लगाया जा सके.
iframes में तीसरे पक्ष की कुकी के ऐक्सेस का पता लगाना
जब किसी iframe का कॉन्टेंट, उपयोगकर्ता के पता बार में दिखने वाली साइट से अलग साइट पर होस्ट किया जाता है, तो इसे क्रॉस-साइट माना जाता है. साथ ही, हो सकता है कि तीसरे पक्ष की कुकी पर पाबंदी लगाई गई हो. iframe, await document.hasStorageAccess()
को कॉल करके पता लगा सकता है कि उसके पास फ़िलहाल तीसरे पक्ष की कुकी का ऐक्सेस है या नहीं. यह तरीका true
या false
दिखाता है. यह इस बात पर निर्भर करता है कि फ़्रेम के पास, बिना बंटवारे वाली कुकी का ऐक्सेस है या नहीं.
अगर आपका iFrame, बिना बंटे हुए क्रॉस-साइट कुकी का ऐक्सेस पाने के लिए, Storage Access API (SAA) का इस्तेमाल करता है (SAA का इस्तेमाल करके या मिलती-जुलती वेबसाइट के सेट के साथ), तो storage-access
अनुमति देखें. इससे यह पता चलेगा कि फ़्रेम, बिना बंटे हुए कुकी को ऐक्सेस करने के लिए ऑप्ट-इन कर सकता है या नहीं.
एचटीटीपी अनुरोधों में तीसरे पक्ष की कुकी के ऐक्सेस का पता लगाना
Chrome 133 से, हेडर Sec-Fetch-Storage-Access
को क्रेडेंशियल वाले अनुरोधों के साथ भेजा जाता है, ताकि सर्वर को यह पता चल सके कि उसके कॉलिंग कॉन्टेक्स्ट के पास, बिना बंटवारे वाली कुकी का ऐक्सेस है या नहीं. इस हेडर में इनमें से कोई एक वैल्यू होती है:
none
: एम्बेड किए गए कॉन्टेंट के पास, बिना बंटवारे वाली कुकी का ऐक्सेस नहीं होताinactive
: एम्बेड को बिना बंटवारे वाली कुकी ऐक्सेस करने की अनुमति है, लेकिन उसने इसे चालू नहीं किया हैactive
: एम्बेड किए गए कॉन्टेंट के पास, बिना बंटवारे वाली कुकी का ऐक्सेस होता है
ऐसी शर्तें जिनमें एम्बेड को बिना बंटवारे वाली कुकी का ऐक्सेस दिया जाता है
जिन मामलों में तीसरे पक्ष की कुकी ज़रूरी फ़ंक्शन देती हैं वहां, बिना बंटे हुए तीसरे पक्ष की कुकी का ऐक्सेस कई तरीकों से दिया जा सकता है. इन तरीकों से, बिना बंटे हुए कुकी ऐक्सेस को अनुमति मिलती है. कई मामलों में, ऐक्सेस देने से पहले requestStorageAccess()
या requestStorageAccessFor()
को कॉल करना ज़रूरी होता है.
तरीका | उदाहरण | क्या requestStorageAccess को कॉल करना ज़रूरी है? |
---|---|---|
Storage Access API प्रॉम्प्ट | उपयोगकर्ता को स्टोरेज का ऐक्सेस देने के लिए कहा जाता है और वह "अनुमति दें" को चुनता है. | हां |
फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट | उपयोगकर्ता, फ़ेडरेटेड आइडेंटिटी प्रोवाइडर (आईडीपी) से लॉग इन करता है; आईडीपी का फ़्रेम, स्टोरेज ऐक्सेस का अनुरोध करता है. | हां |
मिलती-जुलती वेबसाइट के सेट | एम्बेड और एम्बेड करने वाला व्यक्ति, दोनों एक ही RWS से जुड़े हों. | हां |
उपयोगकर्ता सेटिंग में 3PC चालू हैं | उपयोगकर्ता, अपनी सभी ब्राउज़िंग या सिर्फ़ किसी खास ऑरिजिन के लिए, 3PC को अनुमति देता है. | नहीं |
ह्यूरिस्टिक (तय नियमों) के आधार पर लागू होने वाले अपवाद | Chrome, हेयुरिस्टिक्स पैटर्न का पता लगाता है और बिना सेगमेंट वाली कुकी का ऐक्सेस अपने-आप दे देता है. requestStorageAccess() को कॉल करने की ज़रूरत नहीं है. |
नहीं |
कुछ समय के लिए अपवाद (उदाहरण के लिए, ग्रेस पीरियड) | साइट या सेवा को Chrome के लिए, कुछ समय के लिए अपवाद के तौर पर शामिल किया गया है. ऐसा इसलिए किया गया है, क्योंकि साइट या सेवा को बेहतर तरीके से काम करने वाले समाधान पर ट्रांज़िशन किया जा रहा है. | नहीं |
एंटरप्राइज़ से जुड़ी नीतियां | कंपनी के Chrome Enterprise एडमिन ने कुछ या सभी ट्रैफ़िक पर 3PC को अनुमति दी है. | नहीं |