स्टोरेज ऐक्सेस एपीआई

Chrome, क्रॉस-साइट ट्रैकिंग को कम करने के लिए, तीसरे पक्ष की कुकी के साथ काम करने की सुविधा बंद कर रहा है. यह उन साइटों और सेवाओं के लिए एक चुनौती हो सकती है जो उपयोगकर्ता की गतिविधियों, जैसे कि पुष्टि करने के लिए, एम्बेड किए गए कॉन्टेक्स्ट में कुकी का इस्तेमाल करती हैं. Storage Access API (SAA), क्रॉस-साइट ट्रैकिंग को ज़्यादा से ज़्यादा सीमित करते हुए, इस्तेमाल के इन उदाहरणों की मदद से काम करता रहता है.

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

ब्राउज़र सहायता

  • 119
  • 85
  • 65
  • 11.1

सोर्स

Storage Access API सभी मुख्य ब्राउज़र पर उपलब्ध है. हालांकि, दोनों ब्राउज़र पर लागू करने में थोड़ा अंतर होता है. इन अंतरों को इस पोस्ट के संबंधित सेक्शन में हाइलाइट किया गया है.

एपीआई के स्टैंडर्ड तय करने से पहले, ब्लॉक करने से जुड़ी बाकी सभी समस्याओं को ठीक करने के लिए काम जारी है.

Storage Access API क्या है?

Storage Access API ऐसा JavaScript एपीआई है जो iframe को स्टोरेज के ऐक्सेस की अनुमतियों का अनुरोध करने की अनुमति तब देता है, जब ब्राउज़र सेटिंग इसकी अनुमति नहीं देती है. इस्तेमाल के उदाहरणों के साथ जोड़े गए ऐसे एम्बेड जो क्रॉस-साइट रिसॉर्स लोड होने पर निर्भर करते हैं, वे ज़रूरत के हिसाब से उपयोगकर्ता से ऐक्सेस की अनुमति का अनुरोध करने के लिए एपीआई का इस्तेमाल कर सकते हैं.

अगर स्टोरेज के लिए अनुरोध स्वीकार कर लिया जाता है, तो iframe को अपनी क्रॉस-साइट कुकी का ऐक्सेस मिलेगा. ये कुकी तब भी उपलब्ध होती हैं, जब उपयोगकर्ता किसी टॉप लेवल साइट के तौर पर उस पर जाते हैं.

Storage Access API, क्रॉस-साइट कुकी के ऐक्सेस की सुविधा देता है, ताकि असली उपयोगकर्ता पर उसका ज़्यादा से ज़्यादा दबाव न पड़े. साथ ही, सामान्य क्रॉस-साइट कुकी के ऐक्सेस को रोका जा सके, जैसा कि अक्सर उपयोगकर्ता ट्रैकिंग के लिए इस्तेमाल किया जाता है.

इस्तेमाल के उदाहरण

तीसरे पक्ष के कुछ एम्बेड को क्रॉस-साइट कुकी के ऐक्सेस की ज़रूरत होती है, ताकि उपयोगकर्ता को बेहतर अनुभव दिया जा सके. कुछ ऐसा जो तीसरे पक्ष की कुकी के बंद होने के बाद उपलब्ध नहीं होगा.

इस्तेमाल के उदाहरणों में ये शामिल हैं:

  • एम्बेड किए गए टिप्पणी करने वाले विजेट, जिनके लिए लॉगिन सेशन की जानकारी ज़रूरी है.
  • सोशल मीडिया के "पसंद करें" बटन, जिनके लिए लॉगिन सेशन की जानकारी देना ज़रूरी होता है.
  • एम्बेड किए गए ऐसे दस्तावेज़ जिनके लिए लॉगिन सेशन की जानकारी देना ज़रूरी है.
  • एम्बेड किए गए वीडियो को बेहतरीन अनुभव देने के लिए, जैसे कि लॉग इन किए हुए उपयोगकर्ताओं को विज्ञापन न दिखाना, सबटाइटल के लिए उपयोगकर्ता की पसंद जानना या कुछ खास तरह के वीडियो पर पाबंदी लगाना.
  • एम्बेड किए गए पेमेंट सिस्टम.

इनमें से ज़्यादातर मामलों में, एम्बेड किए गए iframe में लॉगिन ऐक्सेस बनाए रखना शामिल है.

अन्य एपीआई के बजाय, Storage Access API का इस्तेमाल कब करना चाहिए

तीसरे पक्ष की कुकी के बजाय, Storage Access API एक अच्छा विकल्प है. इसलिए, यह समझना ज़रूरी है कि इस एपीआई का इस्तेमाल दूसरे एपीआई की तुलना में कब किया जाना चाहिए. यह ऐसे इस्तेमाल के मामलों के लिए है जहां नीचे दी गई दोनों शर्तें सही हैं:

  • उपयोगकर्ता एम्बेड किए गए कॉन्टेंट के साथ इंटरैक्ट करेगा. इसका मतलब है कि यह कोई पैसिव iframe या छिपा हुआ iframe नहीं है.
  • उपयोगकर्ता ने टॉप लेवल कॉन्टेक्स्ट में एम्बेड किए गए ऑरिजिन को ऐक्सेस किया हो. इसका मतलब है कि उस ऑरिजिन को किसी दूसरी साइट में एम्बेड नहीं किया गया है.

अलग-अलग तरह के इस्तेमाल के लिए, अन्य एपीआई भी मौजूद हैं:

  • कुकी हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट (सीएचआईपीएस) की मदद से डेवलपर, "पार्टिशन्ड" स्टोरेज के लिए कुकी के लिए ऑप्ट-इन कर सकते हैं. इसमें हर टॉप-लेवल साइट के लिए एक अलग कुकी जार होता है. उदाहरण के लिए, सेशन की जानकारी सेव करने के लिए, तीसरे पक्ष का वेब चैट विजेट कोई कुकी सेट कर सकता है. सेशन की जानकारी हर साइट के हिसाब से सेव की जाती है. इसलिए, विजेट से सेट की गई कुकी को ऐसी दूसरी वेबसाइटों पर ऐक्सेस करने की ज़रूरत नहीं है जहां इसे एम्बेड किया गया है. Storage Access API तब काम आता है, जब एम्बेड किया गया तीसरे पक्ष का कोई विजेट, अलग-अलग ऑरिजिन पर एक ही जानकारी शेयर करने पर निर्भर होता है. उदाहरण के लिए, लॉग इन किए गए सेशन की जानकारी या प्राथमिकताओं के लिए.
  • मिलती-जुलती वेबसाइटों के सेट (RWS), किसी संगठन के लिए साइटों के बीच संबंध बताने का एक तरीका है, ताकि ब्राउज़र खास मकसद के लिए, तीसरे पक्ष की सीमित कुकी ऐक्सेस की अनुमति दे सकें. साइटों को अब भी Storage Access API की मदद से ऐक्सेस का अनुरोध करना होगा. हालांकि, सेट की गई साइटों के लिए, उपयोगकर्ता के प्रॉम्प्ट के बिना ही, उन्हें ऐक्सेस दिया जा सकता है.
  • फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (FedCM), फ़ेडरेटेड आइडेंटिटी सेवाओं के लिए निजता बनाए रखने का एक तरीका है. Storage Access API, लॉगिन के बाद कुकी को ऐक्सेस करने की सुविधा देता है. इस्तेमाल के कुछ मामलों में, FedCM, Storage Access API के लिए वैकल्पिक समाधान देता है. साथ ही, हो सकता है कि इस सुविधा को प्राथमिकता दी जाए, क्योंकि इसमें लॉगिन को ध्यान में रखकर बनाए गए ब्राउज़र का प्रॉम्प्ट ज़्यादा होता है. हालांकि, आम तौर पर FedCM का इस्तेमाल करने के लिए, आपको अपने कोड में कुछ और बदलाव करने होते हैं. जैसे, इसके एचटीटीपी एंडपॉइंट के साथ काम करने के लिए.
  • धोखाधड़ी वाले कॉन्टेंट, विज्ञापन से जुड़े, और मेज़रमेंट वाले एपीआई भी मौजूद हैं. हालांकि, Storage Access API का इस्तेमाल इन समस्याओं को हल करने के लिए नहीं किया जा सकता.

Storage Access API का इस्तेमाल करना

Storage Access API में दो तरीके हैं, जिनके बारे में बताया गया है:

यह Permissions API के साथ भी इंटिग्रेट होती है. इससे आपको तीसरे पक्ष के लिए, स्टोरेज के ऐक्सेस की अनुमति के स्टेटस की जांच करने की सुविधा मिलती है. इससे, यह पता चलता है कि document.requestStorageAccess() को किया गया कॉल, अपने-आप स्वीकार हो जाएगा या नहीं:

hasStorageAccess() तरीके का इस्तेमाल करना

जब कोई साइट पहली बार लोड होती है, तो वह hasStorageAccess() तरीके का इस्तेमाल करके, यह पता लगा सकती है कि तीसरे पक्ष की कुकी का ऐक्सेस पहले से दिया गया है या नहीं.

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted via the Storage Access API.
    // Note on page load this will always be false initially so we could be
    // skipped in this example, but including for completeness for when this
    // is not so obvious.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

किसी iframe दस्तावेज़ को स्टोरेज का ऐक्सेस तब ही दिया जाता है, जब requestStorageAccess(), को कॉल किया जाता है. इसलिए, शुरुआत में hasStorageAccess() हमेशा गलत दिखाएगा. हालांकि, ऐसा तब होगा, जब उसी iframe में मौजूद, ऑरिजिन वाले किसी अन्य दस्तावेज़ को पहले ही ऐक्सेस दिया गया हो. इस अनुमति को iframe में, एक ही ऑरिजिन वाले नेविगेशन के लिए सुरक्षित रखा जाता है. ऐसा खास तौर पर, उन पेजों को ऐक्सेस देने के बाद फिर से लोड करने की अनुमति देने के लिए किया जाता है जिनके लिए एचटीएमएल दस्तावेज़ के शुरुआती अनुरोध में कुकी का मौजूद होना ज़रूरी होता है.

requestStorageAccess() तरीके का इस्तेमाल करना

अगर iframe के पास ऐक्सेस नहीं है, तो उसे requestStorageAccess() तरीके का इस्तेमाल करके ऐक्सेस का अनुरोध करना पड़ सकता है:

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

पहली बार इसका अनुरोध करने पर, हो सकता है कि उपयोगकर्ता को ब्राउज़र की सूचना की मदद से इस ऐक्सेस को मंज़ूरी देनी पड़े. इसके बाद, प्रॉमिस का समाधान हो जाएगा या इसे अस्वीकार कर दिया जाएगा. अगर await का इस्तेमाल किया जाता है, तो अपवाद माना जाएगा.

किसी उपयोगकर्ता के इंटरैक्शन के बाद ही, ब्राउज़र पर यह प्रॉम्प्ट दिखेगा, ताकि इसका गलत इस्तेमाल न किया जा सके. इसलिए, जब iframe लोड होता है, तो शुरुआत में requestStorageAccess() को उपयोगकर्ता के चालू किए गए इवेंट हैंडलर से कॉल करना ज़रूरी होता है, न कि तुरंत:

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if above did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

अनुमति के प्रॉम्प्ट

जब उपयोगकर्ता पहली बार बटन पर क्लिक करता है, तो ब्राउज़र का प्रॉम्प्ट अपने-आप दिखने लगेगा. आम तौर पर, यह पता बार में दिखता है. नीचे Chrome के संकेत का एक उदाहरण दिया गया है, लेकिन दूसरे ब्राउज़र का यूज़र इंटरफ़ेस (यूआई) इससे मिलता-जुलता है:

Chrome Storage Access API की अनुमति के अनुरोध का स्क्रीनशॉट
Chrome के Storage Access API की अनुमति का अनुरोध

कुछ मामलों में, ब्राउज़र इस प्रॉम्प्ट को स्किप कर सकता है और अपने-आप अनुमति दे सकता है:

  • अगर प्रॉम्प्ट स्वीकार करने के बाद पिछले 30 दिनों में पेज और iframe का इस्तेमाल किया गया हो.
  • अगर एम्बेड किया गया iframe किसी मिलती-जुलती वेबसाइट के सेट का हिस्सा है.
  • Firefox में, प्रॉम्प्ट को ऐसी वेबसाइटों (जिनसे आपने टॉप लेवल पर इंटरैक्ट किया है) के लिए भी शुरुआती पांच कोशिशों के दौरान स्किप कर दिया जाता है.

इसके अलावा, कुछ खास मामलों में प्रॉम्प्ट दिखाए बिना, इस तरीके को अपने-आप अस्वीकार किया जा सकता है:

  • अगर उपयोगकर्ता ने पहले कभी विज़िट नहीं किया है और iframe का मालिकाना हक रखने वाली साइट से इंटरैक्ट किया है, तो यह किसी iframe में नहीं होता. इसका मतलब है कि Storage Access API सिर्फ़ एम्बेड की गई उन साइटों के लिए काम करता है जिन पर उपयोगकर्ता, पहले पक्ष के तौर पर पहले जा चुके हैं.
  • अगर इंटरैक्शन के बाद, प्रॉम्प्ट की अनुमति के बिना, requestStorageAccess() तरीके को उपयोगकर्ता के इंटरैक्शन वाले इवेंट के बाहर कॉल किया जाता है.

हालांकि, उपयोगकर्ता को शुरुआत में इस्तेमाल करने के लिए कहा जाएगा, लेकिन बाद में विज़िट करने पर requestStorageAccess() का समाधान किया जा सकता है. इसके लिए, Chrome और Firefox का इस्तेमाल करने की ज़रूरत नहीं पड़ती. ध्यान दें कि Safari में हमेशा उपयोगकर्ता इंटरैक्शन की ज़रूरत होती है.

कुकी का ऐक्सेस, किसी प्रॉम्प्ट या उपयोगकर्ता इंटरैक्शन के बिना दिया जा सकता है. इसलिए, (Chrome और Firefox) के साथ काम करने वाले ब्राउज़र पर, उपयोगकर्ता इंटरैक्शन से पहले, requestStorageAccess() को पेज लोड पर कॉल करके, तीसरे पक्ष की कुकी का ऐक्सेस पा सकता है. इससे, आपको तीसरे पक्ष की क्रॉस-साइट कुकी को तुरंत ऐक्सेस करने और उपयोगकर्ता के iframe के साथ इंटरैक्ट करने से पहले भी पूरा अनुभव देने की सुविधा मिल सकती है. यह कुछ स्थितियों में उपयोगकर्ता इंटरैक्शन की इंतज़ार करने की तुलना में एक बेहतर उपयोगकर्ता अनुभव हो सकता है.

storage-access की अनुमति से जुड़ी क्वेरी का इस्तेमाल करना

उपयोगकर्ता के इंटरैक्शन के बिना ऐक्सेस दिया जा सकता है या नहीं, यह देखने के लिए storage-access अनुमति की स्थिति देखें. साथ ही, requestStoreAccess() को पहले ही कॉल करें, ताकि उपयोगकर्ता की कार्रवाई की ज़रूरत न हो. कॉल करने के बजाय, अगर इंटरैक्शन ज़रूरी हो, तो उसे फ़ेल कर दें.

इसकी मदद से, अलग-अलग कॉन्टेंट दिखाया जा सकता है. जैसे, लॉगिन बटन का इस्तेमाल करके, पहले ही किसी प्रॉम्प्ट की ज़रूरत को पूरा करना.

यह कोड, storage-access की अनुमति की जांच को पिछले उदाहरण में जोड़ता है:

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and older versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Currently not used. See:
      // https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by one of above.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

सैंडबॉक्स किए गए iframe

सैंडबॉक्स किए गए iframe में Storage Access API का इस्तेमाल करते समय, सैंडबॉक्स की ये अनुमतियां ज़रूरी हैं:

  • स्टोरेज ऐक्सेस एपीआई को ऐक्सेस करने की अनुमति देने के लिए, allow-storage-access-by-user-activation ज़रूरी है.
  • JavaScript के इस्तेमाल को एपीआई को कॉल करने की अनुमति देने के लिए, allow-scripts ज़रूरी है.
  • एक ही ऑरिजिन वाली कुकी और अन्य स्टोरेज का ऐक्सेस देने के लिए, allow-same-origin ज़रूरी है.

उदाहरण के लिए:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Chrome में Storage Access API से ऐक्सेस किए जाने के लिए, क्रॉस-साइट कुकी को इन दो एट्रिब्यूट के साथ सेट करना ज़रूरी है:

  • SameSite=None - इसकी मदद से, कुकी को क्रॉस-साइट के तौर पर मार्क किया जाता है
  • Secure - इससे यह पक्का होता है कि सिर्फ़ एचटीटीपीएस साइटों ने जो कुकी सेट की हैं उन्हें ही ऐक्सेस किया जा सकता है.

Firefox और Safari में, कुकी की डिफ़ॉल्ट वैल्यू SameSite=None होती है और वे SSA को Secure कुकी तक सीमित नहीं करती हैं. इसलिए, इन एट्रिब्यूट की ज़रूरत नहीं होती. हमारा सुझाव है कि SameSite एट्रिब्यूट के बारे में साफ़ तौर पर जानकारी दें और हमेशा Secure कुकी का इस्तेमाल करें.

टॉप लेवल पेज ऐक्सेस

Storage Access API का मकसद है कि एम्बेड किए गए iframe में, तीसरे पक्ष की कुकी का ऐक्सेस चालू किया जा सके.

जब टॉप लेवल पेज को तीसरे पक्ष की कुकी के ऐक्सेस की ज़रूरत होती है, तब भी अन्य मामलों में भी इसका इस्तेमाल किया जा सकता है. उदाहरण के लिए, कुकी की वजह से सीमित इमेज या स्क्रिप्ट. साइट के मालिक, इन्हें iframe के बजाय सीधे टॉप लेवल के दस्तावेज़ में शामिल करना पसंद कर सकते हैं. इस्तेमाल के इस उदाहरण को हल करने के लिए, Chrome ने स्टोरेज ऐक्सेस एपीआई के लिए एक्सटेंशन का सुझाव दिया है. इसमेंrequestStorageAccessFor() तरीका जोड़ा गया है.

requestStorageAccessFor() तरीका

ब्राउज़र सहायता

  • 119
  • 119
  • x
  • x

सोर्स

requestStorageAccessFor() वाला तरीका, requestStorageAccess() की तरह ही काम करता है. हालांकि, यह तरीका टॉप लेवल के संसाधनों के लिए काम करता है. इसका इस्तेमाल सिर्फ़ मिलती-जुलती वेबसाइट के सेट में मौजूद साइटों के लिए किया जा सकता है, ताकि तीसरे पक्ष की कुकी को सामान्य ऐक्सेस न दिया जा सके.

requestStorageAccessFor() का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, मिलती-जुलती वेबसाइट के सेट: डेवलपर गाइड पढ़ें.

top-level-storage-access की अनुमति से जुड़ी क्वेरी

ब्राउज़र सहायता

  • 119
  • 119
  • x
  • x

storage-access अनुमति की तरह ही, यह देखने के लिए top-level-storage-access की अनुमति है कि requestStorageAccessFor() को ऐक्सेस दिया जा सकता है या नहीं.

RWS के साथ इस्तेमाल किए जाने पर Storage Access API अलग कैसे होता है?

जब मिलती-जुलती वेबसाइट के सेट को Storage Access API के साथ इस्तेमाल किया जाता है, तब कुछ और सुविधाएं उपलब्ध होती हैं. इनके बारे में यहां टेबल में बताया गया है:

RWS के बिना आरडब्ल्यूएस के साथ
स्टोरेज के ऐक्सेस का अनुरोध करने के लिए, उपयोगकर्ता के जेस्चर की ज़रूरत होती है
ऐक्सेस देने से पहले, उपयोगकर्ता को टॉप लेवल कॉन्टेक्स्ट में, अनुरोध किए गए स्टोरेज के ऑरिजिन पर जाने की ज़रूरत होती है
पहली बार उपयोगकर्ता के प्रॉम्प्ट को स्किप किया जा सकता है
अगर पहले से ऐक्सेस दिया गया है, तो requestStorageAccess को कॉल करने की ज़रूरत नहीं है
यह सुविधा, मिलती-जुलती वेबसाइट की साइट में अन्य डोमेन से अपने-आप ऐक्सेस देती है
टॉप लेवल पेज ऐक्सेस के लिए requestStorageAccessFor का इस्तेमाल करता है
मिलती-जुलती वेबसाइट के सेट के बिना और उसके साथ Storage Access API का इस्तेमाल करने के बीच अंतर

डेमो: कुकी को सेट और ऐक्सेस करना

इस डेमो में दिखाया गया है कि डेमो की पहली स्क्रीन में खुद से सेट की गई कुकी को, डेमो की दूसरी साइट में एम्बेड किए गए फ़्रेम में कैसे ऐक्सेस किया जा सकता है:

storage-access-api-demo.glitch.me

डेमो के लिए ऐसा ब्राउज़र होना ज़रूरी है जिस पर तीसरे पक्ष की कुकी बंद हों:

  • Chrome 118 या उसके बाद के वर्शन वाला डिवाइस, जिसमें chrome://flags/#test-third-party-cookie-phaseout फ़्लैग सेट है और ब्राउज़र रीस्टार्ट हुआ है.
  • Firefox
  • Safari

रिसॉर्स