पहले पक्ष के सेट की जांच करने से जुड़े निर्देश

Chrome 108 के डेवलपर फ़ीचर-फ़्लैग टेस्टिंग के लिए, पहले पक्ष के सेट का नया वर्शन तैयार है. हम शिपिंग की दिशा में आगे बढ़ने के मकसद से, पहले पक्ष के सेट पर लगातार काम कर रहे हैं. इसलिए, हम डेवलपर टेस्टिंग के इस चरण से जुड़े सुझाव, शिकायत या राय पर विचार करेंगे. ऐसा मार्च की शुरुआत (7 मार्च, 2023) में Chrome 111 के रिलीज़ होने तक किया जाएगा.

नेटवर्क फ़ीडबैक में अलग-अलग साइटों के इस्तेमाल के ऐसे उदाहरण हाइलाइट किए गए हैं जिन पर तीसरे पक्ष की कुकी के काम न करने पर असर पड़ेगा. पहले पक्ष के सेट प्रपोज़ल, अलग-अलग साइट के इस्तेमाल के ऐसे क्लास की जांच करता है और उन्हें हल करता है जिनमें इंटरडिपेंडेंट साइटों के बीच एक-दूसरे से संबंध होता है. इसकी जानकारी ब्राउज़र को इस तरह दी जा सकती है कि ब्राउज़र, उपयोगकर्ता की ओर से ज़रूरी कार्रवाई कर सके और/या उस जानकारी को उपयोगकर्ता के सामने असरदार तरीके से पेश कर सके.

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

पहले पक्ष के सेट की खास जानकारी

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

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

हमारा सुझाव है कि एफ़पीएस (फ़्रेम प्रति सेकंड) में कुकी का ऐक्सेस चालू करने के लिए, हम Storage Access API (SAA) और requestStorageAccessForOrigin का इस्तेमाल करें, ताकि ब्राउज़र हर सबसेट की निजता से जुड़ी सेटिंग के हिसाब से, हर सबसेट को आसानी से मैनेज कर सके.

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

फ़िलहाल, SAA में यह ज़रूरी है कि एपीआई के तरीकों को कॉल करने से पहले, दस्तावेज़ को उपयोगकर्ता के ऐक्टिवेशन की जानकारी मिले.

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

सबमिशन सेट करें

कैननिकल एफ़पीएस सूची, JSON फ़ाइल फ़ॉर्मैट में सार्वजनिक तौर पर देखी जा सकने वाली सूची होगी. इसे एफ़पीएस GitHub रिपॉज़िटरी में रखा जाएगा. यह सभी सेट के लिए, सच्चाई के स्रोत के तौर पर काम करेगी. Chrome इस फ़ाइल का इस्तेमाल, अपने काम करने के तरीके पर लागू करने के लिए करेगा.

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

सेट सबमिशन की प्रोसेस पर अब भी काम चल रहा है. इसलिए, लोकल टेस्टिंग के लिए, सेट सिर्फ़ कमांड लाइन पर बनाए जा सकते हैं और उन्हें सीधे ब्राउज़र में भेजा जा सकता है. लोकल टेस्टिंग के लिए, फ़ीचर फ़्लैग के साथ टेस्ट करने के लिए, GitHub रेपो में कोई सेट सबमिट करने की ज़रूरत नहीं है.

स्थानीय तौर पर टेस्ट करने का तरीका

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

स्थानीय तौर पर एफ़पीएस (फ़्रेम प्रति सेकंड) की जांच करने के लिए, कमांड लाइन से लॉन्च किए गए Chrome 108 या उसके बाद के वर्शन का इस्तेमाल करें.

Chrome की नई सुविधाएं रिलीज़ होने से पहले ही उनकी झलक देखने के लिए, Chrome का बीटा या कैनरी वर्शन डाउनलोड करें.

उदाहरण

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

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

चरण

स्थानीय तौर पर एफ़पीएस (फ़्रेम प्रति सेकंड) की सुविधा चालू करने के लिए, आपको Chrome के --enable-features विकल्प का इस्तेमाल करना होगा. साथ ही, इस सेक्शन में बताए गए फ़्लैग की एक सूची को कॉमा लगाकर अलग करना होगा. साथ ही, --use-first-party-set को पास करने के लिए, मिलती-जुलती साइटों के सेट को JSON ऑब्जेक्ट के तौर पर बताना होगा.

एफ़पीएस (फ़्रेम प्रति सेकंड) चालू करें

FirstPartySets से, Chrome में एफ़पीएस (फ़्रेम प्रति सेकंड) चालू हो जाता है.

FirstPartySets

Storage Access API को चालू करें

StorageAccessAPI

Chrome में Storage Access API (SAA) को चालू करता है. यह एम्बेड किए गए iframe को, अलग-अलग साइट पर कुकी का ऐक्सेस मांगने के लिए requestStorageAccess() का इस्तेमाल करने की अनुमति देता है. ऐसा तब भी होता है, जब ब्राउज़र ने तीसरे पक्ष की कुकी को ब्लॉक किया हो.

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

StorageAccessAPIForOriginExtension

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

किसी सेट के बारे में स्थानीय तौर पर एलान करना

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

ऐसा JSON ऑब्जेक्ट बनाएं जिसमें किसी सेट के यूआरएल शामिल हों और उसे --use-first-party-set को पास करें.

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

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

उदाहरण:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

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

एफ़पीएस यूज़र इंटरफ़ेस (यूआई) चालू करें

PageInfoCookiesSubpage

यूआरएल बार से ऐक्सेस किए जा सकने वाले PageInfo सेक्शन में FPS (फ़्रेम प्रति सेकंड) दिखाना चालू करता है.

PrivacySandboxFirstPartySetsUI

FPS (फ़्रेम प्रति सेकंड) यूज़र इंटरफ़ेस (यूआई) चालू करता है "मिलती-जुलती साइटों को ग्रुप में अपनी गतिविधि देखने की अनुमति दें" विकल्प का इस्तेमाल करें.

पुष्टि करना कि तीसरे पक्ष की कुकी ब्लॉक हैं

  1. Chrome की सेटिंग में, निजता और सुरक्षा → कुकी और साइट का अन्य डेटा या chrome://settings/cookies पर जाएं.
  2. सामान्य सेटिंग में, पक्का करें कि "तीसरे पक्ष की कुकी ब्लॉक करें" चालू है.
  3. देखें कि "मिलती-जुलती साइटों को ग्रुप में आपकी गतिविधि से जुड़ी जानकारी देखने की अनुमति दें" सब-विकल्प यह भी चालू होता है.

सुरक्षा से जुड़ी बातें

Storage Access API कुछ चुनिंदा मामलों में, वेबसाइटों को तीसरे पक्ष की कुकी का ऐक्सेस वापस पाने की अनुमति देता है. इसलिए, इससे वेब ऐप्लिकेशन पर क्रॉस-साइट हमले होने और जानकारी लीक होने का खतरा ज़्यादा हो सकता है. ऐसी साइटों को सीएसआरएफ और अन्य हमलों के खतरों की जानकारी होनी चाहिए जो अलग-अलग साइटों के कॉन्टेक्स्ट में कुकी का इस्तेमाल करती हैं.

योजनाबद्ध सुधार

इसे बेहतर बनाने के लिए, आने वाले समय में Chrome की रिलीज़ के लिए अतिरिक्त सुरक्षा कंट्रोल की ज़रूरत होगी. ऐसा करने का मकसद यह पक्का करना है कि साफ़ तौर पर एम्बेड की गई फ़ाइल के लिए ऑप्ट-इन किया जा सके. सुझाए गए सुधारों के तहत: सिर्फ़ हर फ़्रेम के आधार पर ऐक्सेस दिया जाएगा. साथ ही, क्रेडेंशियल वाले अनुरोधों पर सीओआरएस की ज़रूरत होगी और सिर्फ़ ऑरिजिन के लिए ऐक्सेस का दायरा रखा जाएगा. ज़्यादा जानकारी के लिए, सुरक्षा से जुड़ा हाल ही का विश्लेषण पढ़ें.

Chrome पर SAA को लागू करने से जुड़े प्लान के मुताबिक किए गए सुधारों की सूची देखें.

ध्यान दें कि Chrome सिर्फ़ क्रॉस-साइट एम्बेड किए गए कॉन्टेक्स्ट में, SameSite=None के तौर पर मार्क की गई कुकी भेजता है. यहां पर Storage Access API काम का होता है. जब तक सभी ब्राउज़र उन कुकी के लिए डिफ़ॉल्ट ऐक्सेस को रोक नहीं देते, तब तक यह अनुमान नहीं लगाया जा सकता कि कुकी का इस्तेमाल कहां किया जा सकता है. यह मान लेना सुरक्षित नहीं है कि ऐक्सेस सिर्फ़ एफ़पीएस (फ़्रेम प्रति सेकंड) के अंदर ही मिलेगा. साथ ही, साइटों को सुरक्षा के लिए तय किए गए सबसे सही तरीकों का इस्तेमाल करना जारी रखना चाहिए.

दिलचस्पी बढ़ाएं और सुझाव दें

लोकल टेस्टिंग, एफ़पीएस को चालू करने के लिए, Storage Access API वाले तरीके को आज़माने का एक मौका है. साथ ही, आपके पास कोई सुझाव या राय है या फिर आपको कोई समस्या आती है. इसके अलावा, GitHub पर सेट सबमिट करने की प्रोसेस की जांच करके, इस प्रोसेस और पुष्टि करने के चरणों के बारे में अपना अनुभव शेयर किया जा सकता है. अपडेट किए गए प्रस्ताव में लोगों की दिलचस्पी बढ़ाने और उनके बारे में सुझाव/राय देने या शिकायत करने के लिए: