मिलते-जुलते वेबसाइट सेट: डेवलपर गाइड

bookmark_border संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

मिलती-जुलती वेबसाइट के सेट (RWS), वेब प्लैटफ़ॉर्म का एक तरीका है. इससे ब्राउज़र को डोमेन के कलेक्शन के बीच के संबंधों को समझने में मदद मिलती है. इससे ब्राउज़र, साइट के कुछ फ़ंक्शन चालू करने के लिए अहम फ़ैसले ले पाते हैं. जैसे, क्रॉस-साइट कुकी को ऐक्सेस करने की अनुमति देना या नहीं. साथ ही, यह जानकारी उपयोगकर्ताओं को दिखा पाते हैं.

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

मिलती-जुलती वेबसाइट का सेट क्या है?

हाई लेवल पर, मिलती-जुलती वेबसाइट का सेट, डोमेन का एक कलेक्शन होता है. इसके लिए, एक "सेट प्राइमरी" और संभावित रूप से कई "सेट मेंबर" होते हैं.

नीचे दिए गए उदाहरण में, primary प्राइमरी डोमेन की सूची दिखाता है और associatedSites उन डोमेन की सूची दिखाता है जो संबंधित सबसेट की ज़रूरी शर्तों को पूरा करते हैं.

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

मिलती-जुलती वेबसाइटों के सेट, GitHub पर होस्ट की गई सार्वजनिक JSON फ़ाइल में मौजूद होते हैं. यह अनुमति पा चुके सभी सेट का मुख्य सोर्स होता है. ब्राउज़र इस फ़ाइल का इस्तेमाल यह तय करने के लिए करते हैं कि साइटें एक ही Related Website Set से जुड़ी हैं या नहीं.

सिर्फ़ वे लोग ही किसी डोमेन के साथ सेट बना सकते हैं जिनके पास उस डोमेन का एडमिन कंट्रोल है. सबमिट करने वाले लोगों को हर "सेट मेंबर" और उसके "सेट प्राइमरी" के बीच के संबंध के बारे में बताना होगा. सेट के सदस्यों में अलग-अलग तरह के डोमेन शामिल हो सकते हैं. साथ ही, उन्हें इस्तेमाल के उदाहरण के आधार पर सबसेट का हिस्सा होना चाहिए.

अगर आपका ऐप्लिकेशन, एक ही मिलती-जुलती वेबसाइट के सेट में मौजूद सभी साइटों पर क्रॉस-साइट कुकी (जिन्हें तीसरे पक्ष की कुकी भी कहा जाता है) के ऐक्सेस पर निर्भर करता है, तो उन कुकी के ऐक्सेस का अनुरोध करने के लिए, Storage Access API (SAA) और requestStorageAccessFor API का इस्तेमाल किया जा सकता है. हर साइट जिस सबसेट का हिस्सा है उसके आधार पर, ब्राउज़र अनुरोध को अलग तरीके से मैनेज कर सकता है.

सेट सबमिट करने की प्रोसेस और ज़रूरी शर्तों के बारे में ज़्यादा जानने के लिए, सबमिट करने के लिए बने दिशा-निर्देश देखें. सबमिट किए गए सेट की पुष्टि करने के लिए, उन पर कई तकनीकी जांच की जाएगी.

मिलती-जुलती वेबसाइट के सेट के इस्तेमाल के उदाहरण

मिलती-जुलती वेबसाइट के सेट, उन मामलों के लिए एक अच्छा विकल्प हैं जब किसी संगठन को अलग-अलग टॉप लेवल साइटों पर, एक जैसी पहचान दिखानी हो.

मिलती-जुलती वेबसाइट के सेट के इस्तेमाल के कुछ उदाहरण यहां दिए गए हैं:

• देश के हिसाब से कस्टमाइज़ेशन. शेयर किए गए इन्फ़्रास्ट्रक्चर का इस्तेमाल करते हुए, स्थानीय साइटों का फ़ायदा लेना. उदाहरण के लिए, example.co.uk, example.ca की होस्ट की गई सेवा का इस्तेमाल कर सकता है.
• सेवा का डोमेन इंटिग्रेशन. ऐसे सेवा डोमेन का इस्तेमाल करना जिनसे उपयोगकर्ता कभी सीधे तौर पर इंटरैक्ट नहीं करते, लेकिन जो एक ही संगठन की सभी साइटों (example-cdn.com) पर सेवाएं देते हैं.
• उपयोगकर्ता के कॉन्टेंट को अलग करना. अलग-अलग डोमेन पर डेटा ऐक्सेस करना, जो सुरक्षा के लिहाज़ से, उपयोगकर्ता के अपलोड किए गए कॉन्टेंट को साइट के अन्य कॉन्टेंट से अलग करता है. साथ ही, सैंडबॉक्स किए गए डोमेन को पुष्टि करने वाली (और अन्य) कुकी का ऐक्सेस देता है. अगर उपयोगकर्ताओं का अपलोड किया गया ऐसा कॉन्टेंट दिखाया जा रहा है जिसे अब इस्तेमाल नहीं किया जा रहा है, तो सबसे सही तरीकों का पालन करके, उसे उसी डोमेन पर सुरक्षित तरीके से होस्ट किया जा सकता है.
  • पुष्टि किया गया एम्बेड किया गया कॉन्टेंट. अफ़िलिएट की सभी प्रॉपर्टी से एम्बेड किए गए कॉन्टेंट के साथ काम करता है. जैसे, वीडियो, दस्तावेज़ या ऐसे संसाधन जिन पर सिर्फ़ टॉप-लेवल साइट पर साइन इन करने वाले उपयोगकर्ताओं को ऐक्सेस मिलता है.
• साइन इन करें. अफ़िलिएट की सभी प्रॉपर्टी में साइन इन करने की सुविधा. FedCM API का इस्तेमाल, कुछ मामलों में भी किया जा सकता है.
• Analytics. सेवाओं की क्वालिटी को बेहतर बनाने के लिए, सहयोगी प्रॉपर्टी पर उपयोगकर्ता के सफ़र का विश्लेषण और मेज़रमेंट करना.

मिलती-जुलती वेबसाइट के सेट के इंटिग्रेशन की जानकारी

Storage Access API

Storage Access API (SAA), एम्बेड किए गए क्रॉस-ऑरिजिन कॉन्टेंट को स्टोरेज ऐक्सेस करने का एक तरीका उपलब्ध कराता है. आम तौर पर, क्रॉस-ऑरिजिन कॉन्टेंट के पास सिर्फ़ फ़र्स्ट पार्टी कॉन्टेक्स्ट में स्टोरेज ऐक्सेस करने का विकल्प होता है.

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

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

स्टोरेज के ऐक्सेस की जानकारी देखना और उसका अनुरोध करना

एम्बेड की गई साइटें, Document.hasStorageAccess() तरीका इस्तेमाल करके यह देख सकती हैं कि उनके पास फ़िलहाल स्टोरेज का ऐक्सेस है या नहीं.

यह तरीका एक प्रॉमिस दिखाता है, जो बूलियन वैल्यू के साथ हल होता है. इससे यह पता चलता है कि दस्तावेज़ के पास पहले से ही अपनी कुकी का ऐक्सेस है या नहीं. अगर iframe, टॉप फ़्रेम के सोर्स से मेल खाता है, तो यह प्रॉमिस भी सही वैल्यू दिखाता है.

क्रॉस-साइट कॉन्टेक्स्ट में कुकी का ऐक्सेस पाने के लिए, एम्बेड की गई साइटें Document.requestStorageAccess() (rSA) का इस्तेमाल कर सकती हैं.

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

requestStorageAccess() एक प्रॉमिस दिखाता है. अगर स्टोरेज का ऐक्सेस दिया गया है, तो यह प्रॉमिस रिज़ॉल्व हो जाता है. अगर किसी वजह से ऐक्सेस अस्वीकार किया गया है, तो इसकी वजह बताकर वादा अस्वीकार कर दिया जाता है.

Chrome में requestStorageAccessFor

Storage Access API, एम्बेड की गई साइटों को सिर्फ़ उन <iframe> एलिमेंट से स्टोरेज का ऐक्सेस पाने का अनुरोध करने की अनुमति देता है जिन पर उपयोगकर्ता का इंटरैक्शन हुआ है.

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

इस समस्या को हल करने के लिए, Chrome ने टॉप-लेवल साइटों के लिए एक तरीका लागू किया है. इससे वे Document.requestStorageAccessFor() (rSAFor) का इस्तेमाल करके, कुछ खास ऑरिजिन के लिए स्टोरेज ऐक्सेस का अनुरोध कर सकती हैं.

 document.requestStorageAccessFor('https://target.site')

requestStorageAccessFor() एपीआई को टॉप-लेवल दस्तावेज़ से कॉल किया जाना चाहिए. साथ ही, उस दस्तावेज़ पर उपयोगकर्ता का हाल ही में इंटरैक्शन भी हुआ हो. हालांकि, requestStorageAccess() के उलट, Chrome पिछले 30 दिनों में टॉप-लेवल दस्तावेज़ में इंटरैक्शन की जांच नहीं करता, क्योंकि उपयोगकर्ता पहले से ही पेज पर मौजूद होता है.

स्टोरेज ऐक्सेस करने की अनुमतियां देखना

कैमरा या जगह की जानकारी जैसी ब्राउज़र की कुछ सुविधाओं का ऐक्सेस, उपयोगकर्ता की दी गई अनुमतियों पर निर्भर करता है. Permissions API की मदद से, किसी एपीआई को ऐक्सेस करने के लिए अनुमति की स्थिति देखी जा सकती है. इससे यह पता चलता है कि अनुमति दी गई है या नहीं या फिर उसे ऐक्सेस करने के लिए, उपयोगकर्ता को किसी तरह का इंटरैक्शन करना होगा. जैसे, किसी प्रॉम्प्ट पर क्लिक करना या पेज के साथ इंटरैक्ट करना.

navigator.permissions.query() का इस्तेमाल करके, अनुमति की स्थिति के बारे में क्वेरी की जा सकती है.

मौजूदा कॉन्टेक्स्ट के लिए, स्टोरेज ऐक्सेस करने की अनुमति देखने के लिए, आपको 'storage-access' स्ट्रिंग को पास करना होगा:

navigator.permissions.query({name: 'storage-access'})

किसी खास ऑरिजिन के लिए स्टोरेज ऐक्सेस करने की अनुमति देखने के लिए, आपको 'top-level-storage-access' स्ट्रिंग को पास करना होगा:

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

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

यह इस बात पर निर्भर करता है कि अनुमति अपने-आप दी जा सकती है या इसके लिए उपयोगकर्ता के कोई कार्रवाई करने की ज़रूरत है. इसके आधार पर, यह prompt या granted दिखाएगा.

हर फ़्रेम के लिए मॉडल

rSA अनुदान, हर फ़्रेम पर लागू होते हैं. rSA और rSAFor अनुदान को अलग-अलग अनुमतियों के तौर पर माना जाता है.

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

iframe को रीफ़्रेश करने, फिर से लोड करने या फिर से बनाने के लिए, ऐक्सेस का फिर से अनुरोध करना होगा.

कुकी से जुड़ी ज़रूरी शर्तें

कुकी में SameSite=None और Secure, दोनों एट्रिब्यूट की वैल्यू होनी चाहिए, क्योंकि rSA सिर्फ़ उन कुकी का ऐक्सेस देता है जिन्हें पहले से ही दूसरी साइट के कॉन्टेक्स्ट में इस्तेमाल करने के लिए मार्क किया गया है.

SameSite=Lax, SameSite=Strict या SameSite एट्रिब्यूट वाली कुकी सिर्फ़ पहले पक्ष के इस्तेमाल के लिए होती हैं. साथ ही, इन्हें किसी भी आरएसए के बावजूद, क्रॉस-साइट कॉन्टेक्स्ट में कभी शेयर नहीं किया जाएगा.

सुरक्षा

rSAFor के लिए, सब-रिसॉर्स के अनुरोधों में क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) हेडर या रिसॉर्स पर crossorigin एट्रिब्यूट की ज़रूरत होती है. इससे साफ़ तौर पर ऑप्ट-इन करने की पुष्टि होती है.

लागू करने के उदाहरण

एम्बेड किए गए क्रॉस-ऑरिजिन iframe से स्टोरेज का ऐक्सेस पाने का अनुरोध करना

देखें कि आपके पास स्टोरेज का ऐक्सेस है या नहीं

यह देखने के लिए कि आपके पास पहले से स्टोरेज का ऐक्सेस है या नहीं, document.hasStorageAccess() का इस्तेमाल करें.

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

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

स्टोरेज के ऐक्सेस का अनुरोध करना

अगर आपको स्टोरेज के ऐक्सेस का अनुरोध करना है, तो पहले स्टोरेज के ऐक्सेस की अनुमति navigator.permissions.query({name: 'storage-access'}) देखें. इससे यह पता चलेगा कि इसके लिए उपयोगकर्ता के जेस्चर की ज़रूरत है या यह अपने-आप मिल सकती है.

अगर अनुमति granted है, तो document.requestStorageAccess() को कॉल किया जा सकता है और यह उपयोगकर्ता के जेस्चर के बिना पूरा हो जाना चाहिए.

अगर अनुमति की स्थिति prompt है, तो आपको उपयोगकर्ता के किसी जेस्चर के बाद document.requestStorageAccess() कॉल शुरू करना होगा. जैसे, बटन पर क्लिक करना.

उदाहरण:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

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

क्रॉस-ऑरिजिन साइटों की ओर से कुकी ऐक्सेस का अनुरोध करने वाली टॉप-लेवल साइटें

टॉप-लेवल साइटें, खास ऑरिजिन के लिए स्टोरेज ऐक्सेस का अनुरोध करने के लिए requestStorageAccessFor() का इस्तेमाल कर सकती हैं.

hasStorageAccess() सिर्फ़ यह जांच करता है कि इसे कॉल करने वाली साइट के पास स्टोरेज का ऐक्सेस है या नहीं, ताकि कोई टॉप लेवल साइट किसी दूसरे ऑरिजिन की अनुमतियां देख सके.

यह जानने के लिए कि उपयोगकर्ता को प्रॉम्प्ट मिलेगा या नहीं या किसी खास ऑरिजिन को स्टोरेज का ऐक्सेस पहले ही दिया जा चुका है या नहीं, navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) को कॉल करें.

अगर अनुमति granted है, तो document.requestStorageAccessFor('https://target.site') को कॉल किया जा सकता है. यह उपयोगकर्ता के जेस्चर के बिना काम करना चाहिए.

अगर अनुमति prompt है, तो आपको उपयोगकर्ता के जेस्चर के पीछे document.requestStorageAccessFor('https://target.site') कॉल को हुक करना होगा. जैसे, बटन पर क्लिक करना.

उदाहरण:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

requestStorageAccessFor() कॉल पूरा होने के बाद, किसी दूसरी साइट से किए गए अनुरोधों में कुकी शामिल होंगी. ऐसा तब होगा, जब उनमें सीओआरएस या crossorigin एट्रिब्यूट शामिल होगा. इसलिए, हो सकता है कि साइटें अनुरोध को ट्रिगर करने से पहले इंतज़ार करना चाहें.

अनुरोधों में credentials: 'include' विकल्प का इस्तेमाल करना ज़रूरी है. साथ ही, रिसॉर्स में crossorigin="use-credentials" एट्रिब्यूट शामिल होना चाहिए.

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

स्थानीय तौर पर जांच करने का तरीका

ज़रूरी शर्तें

मिलती-जुलती वेबसाइटों के सेट को स्थानीय तौर पर टेस्ट करने के लिए, कमांड लाइन से लॉन्च किए गए Chrome 119 या इसके बाद के वर्शन का इस्तेमाल करें. साथ ही, test-third-party-cookie-phaseout Chrome फ़्लैग को चालू करें.

Chrome फ़्लैग चालू करना

ज़रूरी Chrome फ़्लैग चालू करने के लिए, पता बार से chrome://flags#test-third-party-cookie-phaseout पर जाएं और फ़्लैग को Enabled पर बदलें. फ़्लैग बदलने के बाद, ब्राउज़र को रीस्टार्ट करना न भूलें.

मिलती-जुलती वेबसाइट के स्थानीय सेट की मदद से Chrome को लॉन्च करना

स्थानीय तौर पर तय किए गए मिलती-जुलती वेबसाइट के सेट के साथ Chrome को लॉन्च करने के लिए, एक JSON ऑब्जेक्ट बनाएं. इसमें ऐसे यूआरएल शामिल करें जो किसी सेट के सदस्य हैं. इसके बाद, इसे --use-related-website-set को पास करें.

फ़्लैग के साथ Chromium चलाने के तरीके के बारे में ज़्यादा जानें.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

उदाहरण

मिलती-जुलती वेबसाइट के सेट को स्थानीय तौर पर चालू करने के लिए, आपको chrome://flags में test-third-party-cookie-phaseout को चालू करना होगा. साथ ही, --use-related-website-set फ़्लैग के साथ कमांड-लाइन से Chrome को लॉन्च करना होगा. इसमें, ऐसे यूआरएल वाले JSON ऑब्जेक्ट का इस्तेमाल करना होगा जो किसी सेट के सदस्य हैं.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

पुष्टि करें कि आपके पास क्रॉस-साइट कुकी का ऐक्सेस है

जिन साइटों की जांच की जा रही है उनसे एपीआई (rSA या rSAFor) को कॉल करें और क्रॉस-साइट कुकी के ऐक्सेस की पुष्टि करें.

मिलती-जुलती वेबसाइट के सेट सबमिट करने की प्रोसेस

डोमेन के बीच के संबंध की जानकारी देने और यह बताने के लिए कि वे किस सबसेट के हिस्से हैं, यह तरीका अपनाएं.

1. अपने RWS की पहचान करना

काम के डोमेन की पहचान करें. इनमें सेट प्राइमरी और सेट मेंबर शामिल हैं, जो मिलती-जुलती वेबसाइट के सेट का हिस्सा होंगे. यह भी पता लगाएं कि हर सेट के सदस्य किस सबसेट टाइप से जुड़े हैं.

2. आरडब्ल्यूएस सबमिशन बनाना

GitHub रिपॉज़िटरी की लोकल कॉपी (क्लोन या फ़ोर्क) बनाएं. अपने सेट को दिखाने के लिए, नई शाखा में related_website_sets.JSON फ़ाइल में बदलाव करें. यह पक्का करने के लिए कि आपके सेट में JSON का सही फ़ॉर्मैट और स्ट्रक्चर है, JSON जनरेटर टूल का इस्तेमाल किया जा सकता है.

3. पक्का करें कि आपका आरडब्ल्यूएस, तकनीकी ज़रूरी शर्तों को पूरा करता हो

पक्का करें कि सेट बनाने की ज़रूरी शर्तें और सेट की पुष्टि करने की ज़रूरी शर्तें पूरी की गई हों.

4. अपने आरडब्ल्यूएस को स्थानीय तौर पर टेस्ट करना

अपना सेट सबमिट करने के लिए, पुल अनुरोध (पीआर) बनाने से पहले, अपने सबमिशन की स्थानीय तौर पर जांच करें, ताकि यह पक्का किया जा सके कि वह सभी ज़रूरी जांचों में पास हो.

5. अपना आरडब्ल्यूएस सबमिट करना

मिलती-जुलती वेबसाइट के सेट को सबमिट करने के लिए, related_website_sets.JSON फ़ाइल में पुल रिक्वेस्ट (पीआर) बनाएं. इस फ़ाइल में, Chrome मिलती-जुलती वेबसाइट के सेट की कैननिकल सूची होस्ट करता है. (पीआर बनाने के लिए, GitHub खाता ज़रूरी है. साथ ही, सूची में योगदान देने से पहले, आपको योगदान देने वाले के लाइसेंस के लिए कानूनी समझौते (सीएलए) पर हस्ताक्षर करना होगा.)

पीआर बनाने के बाद, कई तरह की जांच की जाती हैं. इससे यह पक्का किया जाता है कि तीसरे चरण की ज़रूरी शर्तें पूरी की गई हैं. जैसे, आपने सीएलए पर हस्ताक्षर किए हैं और .well-known फ़ाइल मान्य है.

अगर यह प्रोसेस पूरी हो जाती है, तो पीआर में यह जानकारी दिखेगी कि जांच पूरी हो गई है. अनुमति पा चुके पीआर को, हर हफ़्ते एक बार (ईएसटी के हिसाब से मंगलवार को दोपहर 12 बजे) मैन्युअल तरीके से, मिलती-जुलती वेबसाइट के सेट की कैननिकल सूची में, एक साथ मर्ज कर दिया जाएगा. अगर कोई भी जांच पूरी नहीं होती है, तो सबमिट करने वाले को GitHub पर, पीआर की प्रक्रिया पूरी न होने की सूचना दी जाएगी. सबमिट करने वाला व्यक्ति, गड़बड़ियों को ठीक करके पीआर को अपडेट कर सकता है. साथ ही, इन बातों का ध्यान रखें:

• अगर पीआर सबमिट नहीं हो पाता है, तो गड़बड़ी के मैसेज में इस बारे में ज़्यादा जानकारी दी जाएगी कि सबमिट न हो पाने की वजह क्या हो सकती है. (example).
• सेट सबमिशन को कंट्रोल करने वाली सभी तकनीकी जांच, GitHub पर की जाती हैं. इसलिए, तकनीकी जांच की वजह से सबमिशन में हुई सभी गड़बड़ियां, GitHub पर देखी जा सकती हैं.

एंटरप्राइज़ नीतियां

एंटरप्राइज़ उपयोगकर्ताओं की ज़रूरतों को पूरा करने के लिए, Chrome में दो नीतियां लागू हैं:

• ऐसे सिस्टम जो 'मिलती-जुलती वेबसाइट के सेट' के साथ इंटिग्रेट नहीं हो सकते, वे RelatedWebsiteSetsEnabled नीति की मदद से, Chrome के सभी एंटरप्राइज़ इंस्टेंस में 'मिलती-जुलती वेबसाइट के सेट' सुविधा को बंद कर सकते हैं.
  • कुछ एंटरप्राइज़ सिस्टम में, सिर्फ़ इंटरनल साइटें (जैसे, कोई इंट्रानेट) होती हैं. इन साइटों के डोमेन, रजिस्टर किए जा सकने वाले ऐसे डोमेन होते हैं जो मिलती-जुलती वेबसाइट के सेट में मौजूद डोमेन से अलग होते हैं. अगर उन्हें इन साइटों को सार्वजनिक तौर पर ज़ाहिर किए बिना, मिलती-जुलती वेबसाइट के सेट के हिस्से के तौर पर इस्तेमाल करना है (क्योंकि डोमेन गोपनीय हो सकते हैं), तो वे RelatedWebsiteSetsOverrides नीति का इस्तेमाल करके, मिलती-जुलती वेबसाइट के सेट की सार्वजनिक सूची में साइटों को जोड़ सकते हैं या उन्हें बदल सकते हैं.

Chrome, सार्वजनिक और एंटरप्राइज़ सेट के इंटरसेक्शन को दो में से किसी एक तरीके से हल करता है. यह इस बात पर निर्भर करता है कि replacements या additions में से किसका इस्तेमाल किया गया है.

उदाहरण के लिए, सार्वजनिक सेट {primary: A, associated: [B, C]} के लिए:

मिलती-जुलती वेबसाइट के सेट से जुड़ी समस्या हल करना

"उपयोगकर्ता प्रॉम्प्ट" और "उपयोगकर्ता जेस्चर"

"उपयोगकर्ता प्रॉम्प्ट" और "उपयोगकर्ता जेस्चर" अलग-अलग चीज़ें हैं. Chrome, एक ही मिलती-जुलती वेबसाइट के सेट में शामिल साइटों के लिए, उपयोगकर्ताओं को अनुमति का अनुरोध नहीं दिखाएगा. हालांकि, Chrome के लिए अब भी यह ज़रूरी है कि उपयोगकर्ता ने पेज के साथ इंटरैक्ट किया हो. अनुमति देने से पहले, Chrome को उपयोगकर्ता के जेस्चर की ज़रूरत होती है. इसे "उपयोगकर्ता इंटरैक्शन" या "उपयोगकर्ता ऐक्टिवेशन" भी कहा जाता है. ऐसा इसलिए है, क्योंकि वेब प्लैटफ़ॉर्म के डिज़ाइन के सिद्धांतों के मुताबिक, मिलती-जुलती वेबसाइट के सेट (जैसे कि requestStorageAccess()) के कॉन्टेक्स्ट के बाहर, Storage Access API का इस्तेमाल करने के लिए भी उपयोगकर्ता जेस्चर की ज़रूरत होती है.

अन्य साइटों की कुकी या स्टोरेज को ऐक्सेस करना

मिलती-जुलती वेबसाइटों के सेट, अलग-अलग साइटों के स्टोरेज को मर्ज नहीं करते: इससे सिर्फ़ आसान (प्रॉम्प्ट-फ़्री) requestStorageAccess() कॉल की सुविधा मिलती है. मिलती-जुलती वेबसाइट के सेट, सिर्फ़ Storage Access API का इस्तेमाल करने में उपयोगकर्ता को आने वाली समस्याओं को कम करते हैं. हालांकि, ऐक्सेस वापस मिलने के बाद क्या करना है, यह तय नहीं करते. अगर A और B एक ही मिलती-जुलती वेबसाइट के सेट में शामिल अलग-अलग साइटें हैं और A ने B को एम्बेड किया है, तो B, requestStorageAccess() को कॉल कर सकता है और उपयोगकर्ता से अनुमति लिए बिना, पहले पक्ष के स्टोरेज का ऐक्सेस पा सकता है. मिलती-जुलती वेबसाइट के सेट, किसी भी साइट के बीच कोई कम्यूनिकेशन नहीं करते. उदाहरण के लिए, मिलती-जुलती वेबसाइट के सेट को सेट अप करने से, B की कुकी, A को भेजी नहीं जाएंगी. अगर आपको वह डेटा शेयर करना है, तो आपको उसे खुद शेयर करना होगा. उदाहरण के लिए, B iframe से A फ़्रेम में window.postMessage भेजकर.

डिफ़ॉल्ट रूप से, बिना बंटे हुए कुकी ऐक्सेस

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

सुझाव, शिकायत या राय दें

GitHub पर सेट सबमिट करने और Storage Access API और requestStorageAccessFor API के साथ काम करने से, आपको प्रोसेस के बारे में अपने अनुभव और उससे जुड़ी समस्याओं के बारे में बताने का मौका मिलता है.

मिलती-जुलती वेबसाइट के सेट के बारे में चर्चाओं में शामिल होने के लिए:

• मिलती-जुलती वेबसाइट के सेट की सार्वजनिक मेलिंग सूची में शामिल हों.
  • समस्याएं बताएं और मिलती-जुलती वेबसाइट के सेट के GitHub रिपॉज़िटरी पर चर्चा में हिस्सा लें.