तीसरे पक्ष की कुकी का इस्तेमाल बंद करने के लिए, हम Chrome के साथ काम करने वाले टेस्टिंग मोड उपलब्ध करा रहे हैं. इनसे साइटें तीसरे पक्ष की कुकी के बिना, साइट के काम करने के तरीके और सुविधाओं की झलक देख सकती हैं. इस गाइड में, Chrome के टेस्टिंग मोड की खास जानकारी दी गई है. साथ ही, यह बताया गया है कि एक्सपेरिमेंट के ग्रुप के लेबल को ऐक्सेस करने का तरीका क्या है.
इस संदर्भ में Chrome ब्राउज़र का मतलब Chrome क्लाइंट से है: डिवाइस पर Chrome इंस्टॉलेशन. हर उपयोगकर्ता की डेटा डायरेक्ट्री का एक अलग क्लाइंट होता है.
एक्सपेरिमेंट ग्रुप: Chrome ब्राउज़र का एक सेट, जिसके लिए कुछ सुविधाएं चालू, बंद या कॉन्फ़िगर की गई हैं. Chrome की टेस्टिंग के लिए, ब्राउज़र का एक सेट जिसके लिए लेबल सेट किए जाते हैं.
लेबल: इस संदर्भ में, अनुरोध के हेडर की वैल्यू, जो किसी एक्सपेरिमेंट ग्रुप से जुड़े ब्राउज़र के लिए सेट की जाती है. Chrome की मदद से की जाने वाली टेस्टिंग की पूरी अवधि के दौरान, प्रयोग वाले ग्रुप का हर ब्राउज़र उसी ग्रुप में बना रहेगा. इससे यह पक्का किया जाता है कि जांच करने वाले सभी लोगों के लिए, ब्राउज़र का लेबल एक जैसा बना रहे.
हमने दो अलग-अलग मोड ऑफ़र किए हैं:
- मोड A: नवंबर 2023 से, PS R&M API की जांच करने वाले संगठन, Chrome ब्राउज़र के सबसेट पर एक जैसे लेबल पाने के लिए ऑप्ट-इन कर चुके हैं. इससे अलग-अलग टेस्टर के लिए, कोडिंग की जांच की जा सकेगी.
- मोड B: 4 जनवरी, 2024 से, Chrome ने दुनिया भर में कुछ Chrome ब्राउज़र के लिए तीसरे पक्ष की कुकी को बंद कर दिया है.
अगर तीसरे पक्ष की कुकी को मोड B में बंद किया जाता है, तो वे तीसरे पक्ष की कुकी के पूरे चरण तक बंद रहेंगी.
हमने सीएमए के साथ काम किया है, ताकि यह पक्का किया जा सके कि ये टेस्टिंग मोड, तीसरे पक्षों के लिए टेस्टिंग फ़्रेमवर्क (और टाइमलाइन) के मुताबिक हों. इनके बारे में, इंडस्ट्री टेस्टिंग के लिए दिए गए दिशा-निर्देश में बताया गया है. इस वजह से, सीएमए को अनुमान लगता है कि इन मोड में की गई टेस्टिंग के नतीजे, प्राइवसी सैंडबॉक्स की जांच में इस्तेमाल किए जा सकते हैं. सीएमए ने बताया है कि उसे एक्सपेरिमेंटल डिज़ाइन 2 से मिलने वाले नतीजों को ज़्यादा अहमियत देनी है. इसमें मोड बी लेबल और मोड ए कंट्रोल 1 लेबल का इस्तेमाल किया जाता है. एक्सपेरिमेंटल डिज़ाइन 2 के बारे में ज़्यादा जानकारी के लिए, सीएमए के 26 अक्टूबर को जारी किया गया दिशा-निर्देश देखें.
लेबल को, एचटीटीपी हेडर या JavaScript API में मौजूद अस्थायी Cookie-Deprecation वैल्यू का इस्तेमाल करके ऐक्सेस किया जा सकता है. लागू करने की जानकारी के लिए, बाद में दिया गया सेक्शन कुकी के बंद होने की वैल्यू का इस्तेमाल करके लेबल ऐक्सेस करना देखें.
हम इस प्रस्ताव को ब्लिंक डेवलपमेंट प्रोसेस की सामान्य प्रोसेस के ज़रिए भी भेजेंगे. इसमें तकनीकी डिज़ाइन और Chrome रिलीज़ के माइलस्टोन को तय किया जाएगा. हम इस तरीके को लागू करना चाहते हैं. हालांकि, इस बारे में ज़्यादा चर्चा और अनुमति होने का मतलब है कि जानकारी में अब भी बदलाव किया जा सकता है. जैसे-जैसे प्लान आगे बढ़ता जाएगा, हम इस पेज को अपडेट करते रहेंगे. साथ ही, सुझाव/राय देना या शिकायत करना जारी रख सकते हैं.
मोड A: लेबल किए गए ब्राउज़र ग्रुप
टेस्टिंग में हिस्सा लेने वाले संगठन, Chrome ब्राउज़र के किसी सबसेट के लिए लगातार लेबल पाने का विकल्प चुन सकेंगे. इससे, ब्राउज़र के एक ही सेट पर, अलग-अलग विज्ञापन टेक्नोलॉजी के लिए प्रयोग किए जा सकेंगे.
उदाहरण के लिए, अगर कोई ब्राउज़र label_only_3 एक्सपेरिमेंट ग्रुप में शामिल है (जैसा कि इस टेबल में दिखाया गया है), तो इस सुविधा का इस्तेमाल करने वाली सभी विज्ञापन टेक्नोलॉजी, label_only_3 लेबल देख पाएंगी और उसी के मुताबिक काम कर पाएंगी: PS R&M API का इस्तेमाल करें, लेकिन तीसरे पक्ष की कुकी का इस्तेमाल न करें. पेज पर मौजूद लोगों से हमें उम्मीद है कि वे यह पक्का करें कि लेबल, मीटिंग में शामिल अन्य लोगों को भेजे जा रहे हों. इससे विज्ञापन चुनने और उनकी परफ़ॉर्मेंस को मेज़र करने की पूरी प्रोसेस को लगातार टेस्ट किया जा सकेगा.
उदाहरण के लिए, इससे लोगों को एक जैसे ब्राउज़र पर Protected Audience की नीलामी करने की अनुमति मिलती है. इसके लिए, तीसरे पक्ष की कुकी का इस्तेमाल नहीं किया जाता. नीलामी में हिस्सा लेने वाले सेलर, मॉनिटर किए गए लेबल को खरीदारों को भेजेंगे. इससे उन्हें कोऑर्डिनेटेड टेस्टिंग की सुविधा मिलेगी.
Chrome के इन इंस्टेंस में होने वाले किसी भी व्यवहार पर लेबल का असर नहीं पड़ता. इनमें तीसरे पक्ष की कुकी का उपलब्ध होना भी शामिल है. लेबल, स्वतंत्र और कोऑर्डिनेटेड प्रयोगों के लिए ग्रुप बनाते हैं. हालांकि, एक्सपेरिमेंट के लिए काम के पैरामीटर लागू करने की ज़िम्मेदारी उपयोगकर्ताओं की होती है. अगर तीसरे पक्ष की कुकी को हटाने के असर की जांच की जा रही है, तो हर पार्टनर की ज़िम्मेदारी होगी कि वह इस लेबल वाले ब्राउज़र के लिए, तीसरे पक्ष का कुकी डेटा शामिल न करे.
इसका मकसद ऐसे ग्रुप बनाना है जो Chrome के सामान्य ट्रैफ़िक को दिखाते हैं. इसका मतलब है कि तीसरे पक्ष की कुकी और PS R&M API, दोनों उपलब्ध होने चाहिए. हालांकि, हो सकता है कि कुछ उपयोगकर्ताओं ने सुविधाओं को बदलने या बंद करने के लिए, सेटिंग या एक्सटेंशन का इस्तेमाल किया हो.
लेबल आम तौर पर Chrome में पूरे ब्राउज़िंग सेशन और सभी सेशन के दौरान स्थायी रहेंगे. हालांकि, इसकी गारंटी नहीं है, क्योंकि बहुत कम मामलों में ब्राउज़र को पूरी तरह से रीसेट करने से भी मौजूदा लेबल रीसेट हो सकता है.
हम मोड ए के लिए 8.5% Chrome स्टेबल ब्राउज़र को शामिल करने की योजना बना रहे हैं और हमारा शुरुआती प्रस्ताव इस जनसंख्या को नौ ग्रुप में बांट देगा. छोटे-छोटे सबग्रुप का मकसद विज्ञापन टेक्नोलॉजी को लेबल को एक साथ जोड़ने की सुविधा देना है, ताकि वे अलग-अलग साइज़ के अपने एक्सपेरिमेंट बना सकें. ग्रुप ओवरलैप नहीं होते.
ध्यान दें कि control_1.* लेबल का इस्तेमाल "कंट्रोल 1" के तौर पर किया जाना चाहिए, जैसा कि सीएमए के
इंडस्ट्री टेस्टिंग के लिए दिशा-निर्देश में बताया गया है.
इसलिए, टेस्टिंग में हिस्सा लेने वाले लोग इस ट्रैफ़िक के लिए, Topics API का इस्तेमाल नहीं करना चाहिए या Protected Audience
नीलामी नहीं करनी चाहिए. लेबल से ब्राउज़र के काम करने के तरीके पर कोई असर नहीं पड़ता. इसलिए, control_1.* ग्रुप लेबल का पता चलने पर, मीटिंग में शामिल लोगों को निगरानी वाले विषयों को पास नहीं करना चाहिए. इसके अलावा, उन्हें Protected Audience से जुड़ी नीलामियां भी नहीं करनी चाहिए.
हम इस बात के लिए सुझाव चाहते हैं कि क्या ग्रुप को चुनने से, इस कार्यक्रम में हिस्सा लेने वाले संगठनों की ज़रूरतों को पूरा किया जा सकता है.
| लेबल | स्टेबल ट्रैफ़िक का% |
|---|---|
control_1.1 |
0.25 |
control_1.2 |
0.25 |
control_1.3 |
0.25 |
control_1.4 |
0.25 |
label_only_1 |
1.5 |
label_only_2 |
1.5 |
label_only_3 |
1.5 |
label_only_4 |
1.5 |
label_only_5 |
1.5 |
मोड A label_only_ ब्राउज़र ग्रुप, नवंबर 2023 से उपलब्ध हैं.
मोड A control_1_* ग्रुप 4 जनवरी, 2024 से उपलब्ध कराए गए थे.
मोड B: तीसरे पक्ष की 1% कुकी बंद करें
Chrome ने 4 जनवरी, 2024 से करीब 1% Chrome स्टेबल ब्राउज़र के लिए, तीसरे पक्ष की कुकी को बंद कर दिया है. साथ ही, साल 2023 की चौथी तिमाही के दौरान डेवलपर, कैनरी, और बीटा ब्राउज़र के लिए भी यह सुविधा बंद कर दी गई है. PS R&M API का टेस्ट करने वाले संगठनों को इस मोड के लिए ऑप्ट-इन करने की ज़रूरत नहीं है. ऐसा इसलिए है, क्योंकि यह पूरे ब्राउज़र पर एक ही तरह से लागू होगा. अगर साइट ने अब तक सीएचआईपीएस या मिलती-जुलती वेबसाइट के सेट जैसे किसी दूसरे समाधान का इस्तेमाल नहीं किया है, तो हो सकता है कि साइट की कुछ सुविधाओं पर असर पड़े.
इसके अलावा, हमारी योजना मोड B में ट्रैफ़िक का एक छोटा सा हिस्सा उपलब्ध कराने की है, जिसमें PS R&M API बंद हैं. अन्य एपीआई, जैसे कि मिलती-जुलती वेबसाइट के सेट, सीएचआईपीएस, और FedCM को बंद नहीं किया जाएगा. हमारा अनुमान है कि यह कॉम्बिनेशन, तीसरे पक्ष की कुकी और PS R&M एपीआई के बिना ब्राउज़र के लिए, परफ़ॉर्मेंस की बेसलाइन तय करने में मददगार होगा.
मोड B के हिस्से के तौर पर, हम उन ब्राउज़र के लिए भी लेबल उपलब्ध कराते हैं जिन पर इस बदलाव का असर हुआ है. लेबल उसी समय उपलब्ध होते हैं जब एपीआई बंद होते हैं. हमारा
सुझाव है कि लोगों को तीन treatment_1.* ग्रुप में बांटा जाए, जिनमें तीसरे पक्ष की कुकी बंद हों, लेकिन PS R&M एपीआई उपलब्ध हों. साथ ही, एक control_2 ग्रुप हो, जिसमें तीसरे पक्ष की कुकी और PS R&M API दोनों बंद हों.
Attribution Reporting API और Private एग्रीगेशन एपीआई इंटिग्रेशन को डीबग करने में मदद करने और शोर के असर को समझने में टेस्टिंग में शामिल लोगों की मदद करने के लिए, ARA डीबग रिपोर्ट और प्राइवेट एग्रीगेशन डीबग रिपोर्ट मोड B में मौजूद ब्राउज़र के लिए उपलब्ध रहेंगी. ऐसा तब तक होगा, जब तक उपयोगकर्ता ने तीसरे पक्ष की कुकी को साफ़ तौर पर ब्लॉक नहीं किया हो. डीबग रिपोर्ट
control_2 में उपलब्ध नहीं होंगी, क्योंकि इस स्लाइस में PS R&M एपीआई उपलब्ध नहीं हैं. डीबग रिपोर्ट को अब भी बंद कर दिया जाएगा. साथ ही, तीसरे पक्ष की कुकी के इस्तेमाल को धीरे-धीरे बंद कर दिया जाएगा.
- Attribution Reporting API के लिए, तीसरे पक्ष की कुकी बंद होने की वजह से
रिपोर्टिंग ऑरिजिन,
ar_debugकुकी को सेट नहीं कर पाएगा. साथ ही, उसे डीबग की रिपोर्ट पाने के लिए ऑप्ट-इन या ऑप्ट-आउट करने के लिए,debug_keyफ़ील्ड (एट्रिब्यूशन की सफलता की रिपोर्ट के लिए) औरdebug_reportingफ़ील्ड (वर्बज़ रिपोर्ट के लिए) पर निर्भर रहना होगा. - Private एग्रीगेशन API के लिए, रिपोर्टिंग ऑरिजिन को
enableDebugMode()को कॉल करने की सुविधा का इस्तेमाल करना चाहिए, ताकि डीबग की रिपोर्ट पाने के ऑप्ट-इन को कंट्रोल किया जा सके. कंपनियों को इस बात पर ध्यान रखना चाहिए कि डीबग रिपोर्ट के साथ-साथ Attribution Reporting API और Private एग्रीगेशन API के इस्तेमाल पर, कानूनी जवाबदेही किस तरह लागू हो सकती है.
मोड A चलता रहेगा और ये ग्रुप, मोड A ग्रुप से अलग होंगे. इसकी वजह यह है कि
उपयोगकर्ता या तो मोड A, मोड B या दोनों में से कोई भी मोड में नहीं होगा. टेस्टिंग में शामिल लोगों को
control_1.* ट्रैफ़िक का इस्तेमाल कंट्रोल ग्रुप के तौर पर करना चाहिए. इससे तीसरे पक्ष की कुकी और
मौजूदा स्थिति के बारे में पता चलता है.
| लेबल | स्टेबल ट्रैफ़िक का% |
|---|---|
treatment_1.1 |
0.25 |
treatment_1.2 |
0.25 |
treatment_1.3 |
0.25 |
control_2 |
0.25 |
Chrome ने 20% Chrome कैनरी, डेवलपर, और बीटा क्लाइंट के लिए भी कुकी पर पाबंदी लगा दी है.
| लेबल | प्री-स्टेबल ट्रैफ़िक का% |
|---|---|
prestable_treatment_1 |
10% |
prestable_control_2 |
10% |
इनमें से किसी एक एक्सपेरिमेंट ग्रुप में शामिल होने से, वैसा ही असर पड़ेगा जैसा कि इनके लिए तय किए गए मिलते-जुलते एक्सपेरिमेंट पर होता है.
मोड A की तरह, PS R&M API के उपलब्ध होने की कोई गारंटी नहीं है, क्योंकि उपयोगकर्ता
इन्हें Chrome की निजता और सुरक्षा सेटिंग में जाकर बंद कर सकते हैं. इसी तरह,
तीसरे पक्ष की कुकी को control_2 ग्रुप के हर सदस्य के लिए बंद किए जाने की गारंटी नहीं है. इसकी वजह यह है कि उपयोगकर्ता, किसी साइट पर तीसरे पक्ष की कुकी को अनुमति देने के लिए, ब्राउज़र का यूज़र इंटरफ़ेस (यूआई) ऐक्सेस कर सकते हैं.
एक्सपेरिमेंट को मॉनिटर करना
हर ट्रीटमेंट और कंट्रोल लेबल के ट्रैफ़िक वॉल्यूम को मॉनिटर करना न भूलें. treatment_1.1 में करीब
treatment_1.2 और treatment_1.3 के बराबर ट्रैफ़िक होना चाहिए.
हमारा सुझाव है कि आप Chrome के 120 वर्शन से पहले के वर्शन से आने वाले लेबल से जुड़े ट्रैफ़िक के बारे में सोच-समझकर फ़ैसला लें. आम तौर पर, अमान्य ट्रैफ़िक को मैनेज करने वाली आपकी टीम, ऐसे उपयोगकर्ता एजेंट की पहचान करती है जो अमान्य ट्रैफ़िक की विशेषताएं दिखाते हैं. ऐसे में, जांच के नतीजों को फ़िल्टर करके बाहर रखना सही होगा.
प्री-पीरियड लेबल
जनवरी 2024 तक, हमने कई एक्सपेरिमेंट ग्रुप के लिए प्री-पीरियड चलाई:
वह समयावधि जिससे Chrome को आंकड़ों के हिसाब से ग्रुप का सही साइज़ चुनने और उन्हें सही तरीके से चुनने की अनुमति देने के लिए तय किया गया था. ये प्री-अवधियां, उन सभी ग्रुप के लिए चली जिन्हें जनवरी में शुरू होने के लिए शेड्यूल किया गया था: मोड B और Control_1.* ग्रुप. यहां, डेवलपर या साइट को कोई कार्रवाई करने की ज़रूरत नहीं है. पहले के इन ग्रुप के काम करने के तरीके या एपीआई की उपलब्धता में कोई बदलाव नहीं होगा. हालांकि, आपको पता होना चाहिए कि कुछ मामलों में, आपको preperiod लेबल दिख सकता है. हालांकि, preperiod लेबल पाने वाले ब्राउज़र किसी एक्सपेरिमेंट ग्रुप में जा सकते हैं, लेकिन इसकी कोई गारंटी नहीं है. इसलिए, हमारा सुझाव है कि आप यह न मानें कि इस लेबल वाले ब्राउज़र, एक्सपेरिमेंट में शामिल हो सकते हैं.
एक्सपेरिमेंट ग्रुप, स्टडी में शामिल लोगों का एक सबसेट है: इस मामले में, लेबल किए गए ग्रुप में से एक.
कुकी-डेप्रिकेशन वैल्यू का इस्तेमाल करके लेबल ऐक्सेस करना
मोड A और मोड B की अवधि के लिए, हमने एक अस्थायी Cookie-Deprecation वैल्यू उपलब्ध कराई है, जिसे ऑप्ट-इन एचटीटीपी हेडर और JavaScript API का इस्तेमाल करके ऐक्सेस किया जा सकता है. इससे, अगर ब्राउज़र इनमें से किसी एक में आता है, तो उसे मोड A या B एक्सपेरिमेंट के ग्रुप (जैसा कि ऊपर दिए गए प्रतिशत में तय किया गया है) के लिए लेबल मिलता है.
लेबल को ऐक्सेस करने के लिए, उपयोगकर्ता के डिवाइस में सेव की गई जानकारी को ऐक्सेस करना शामिल होता है. ईयू (यूरोपीय संघ) और यूके जैसे कुछ अधिकार क्षेत्रों में, हम समझते हैं कि इस गतिविधि में कुकी का इस्तेमाल होता है. इसलिए, लेबल ऐक्सेस करने के लिए असली उपयोगकर्ता की सहमति की ज़रूरत हो सकती है. लेबल का अनुरोध करने से पहले, हमारा सुझाव है कि आप इस बारे में कानूनी सलाह लें कि सहमति की यह जवाबदेही आप पर लागू होती है या नहीं.
सेक-कुकी-डेप्रिकेशन एचटीटीपी हेडर को ऐक्सेस करना
Sec-Cookie-Deprecation अनुरोध का हेडर पाने के लिए, साइट को पहले receive-cookie-deprecation कुकी सेट करनी होगी. इस कुकी को Partitioned एट्रिब्यूट का इस्तेमाल करना होगा. इसका मतलब है कि हेडर पाने के लिए, टॉप-लेवल की हर साइट के लिए ऑप्ट-इन करना ज़रूरी है.
उदाहरण के लिए, अगर 3p-example.site को example.com पर एम्बेड किए गए रिसॉर्स पर Sec-Cookie-Deprecation हेडर पाना है, तो 3p-example.site को उसके हिसाब से नीचे दी गई कुकी सेट करनी होगी.
Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned; Max-Age=15552000
Secure, HttpOnly, SameSite, और Partitioned कुकी एट्रिब्यूट का इस्तेमाल करना ज़रूरी है. अन्य एट्रिब्यूट को आपकी ज़रूरत के हिसाब से सबसे सही के तौर पर सेट किया जा सकता है: Domain, Path, Expires, और Max-Age. हालांकि, Path=/ को डिफ़ॉल्ट तौर पर इस्तेमाल किया जा सकता है. यहां दिए गए उदाहरण में, Max-Age=15552000 को सेट किया गया है, ताकि कुकी 180 दिनों के बाद खत्म न हो.
Chrome की सुविधा वाली टेस्टिंग की अवधि शुरू होने से पहले, शायद आप receive-cookie-deprecation=1 कुकी को सेट करना चाहें. इससे यह पक्का किया जा सकेगा कि
किसी एक्सपेरिमेंट ग्रुप के ब्राउज़र में, Sec-Cookie-Deprecation अनुरोध का हेडर उपलब्ध होते ही उसे शामिल किया जाए.
उदाहरण के लिए, मान लें कि ब्राउज़र example_label_1 ग्रुप में है, तो इस कुकी को शामिल करने वाले बाद के अनुरोधों में Sec-Cookie-Deprecation हेडर भी शामिल होगा.
Sec-Cookie-Deprecation: example_label_1
अगर ब्राउज़र किसी ग्रुप का हिस्सा नहीं है, तो कोई हेडर नहीं भेजा जाएगा.
कुकी की मौजूदगी से लेबल जुड़े होते हैं, इसलिए अगर कुकी को मिटा दिया जाता है, पूरी तरह से ब्लॉक कर दिया जाता है या किसी खास साइट के लिए ब्लॉक किया जाता है, तो लेबल नहीं भेजे जाएंगे. तीसरे पक्ष की कुकी के पूरी तरह से बंद होने के बाद, Partitioned एट्रिब्यूट का इस्तेमाल जारी रखा जा सकता है. इसका मतलब है कि तीसरे पक्ष की कुकी ब्लॉक होने पर, Partitioned की कुकी सेट की जा सकती हैं.
कुकी DeprecationLabel JavaScript API को ऐक्सेस करना
navigator.cookieDeprecationLabel.getValue() JavaScript API का इस्तेमाल करके भी Cookie-Deprecation वैल्यू को ऐक्सेस किया जा सकता है. इससे ऐसा प्रॉमिस मिलेगा जो लागू ग्रुप लेबल वाली स्ट्रिंग में बदल जाएगा. उदाहरण के लिए, अगर ब्राउज़र example_label_1 ग्रुप में था, तो:
// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
// Request value and resolve promise
navigator.cookieDeprecationLabel.getValue().then((label) => {
console.log(label);
// Expected output: "example_label_1"
});
}
अगर ब्राउज़र किसी ग्रुप का हिस्सा नहीं है, तो एपीआई उपलब्ध नहीं होगा या वैल्यू एक खाली स्ट्रिंग होगी. इसलिए, पक्का करें कि सुविधा की पहचान की जा रही हो.
receive-cookie-deprecation कुकी मौजूद होने पर भी JavaScript API को कॉल किया जा सकता है. हालांकि, अगर कुकी को पूरी तरह या खास तौर पर साइट के लिए ब्लॉक किया जाता है, तो एपीआई फिर से उपलब्ध नहीं होगा या खाली स्ट्रिंग दिखाएगा.
क्लाइंट से मिली किसी भी वैल्यू की तरह, पक्का करें कि इस्तेमाल करने से पहले, हेडर या JavaScript API से मिली वैल्यू को साफ़ करें और उसकी पुष्टि करें.
डेमो और टेस्टिंग
Chrome 120 और उसके बाद के वर्शन में, लेबल का अनुरोध करने और उन्हें पढ़ने के लिए, लोकल डेवलपर जांच को चालू करने के लिए फ़्लैग उपलब्ध हैं.
chrome://flags/#tpc-phase-out-facilitated-testing फ़्लैग की मदद से, चुने गए टेस्ट लेबल चालू किए जा सकते हैं. इन लेबल की शुरुआत में fake_ लगाया जाता है, ताकि इन्हें असली लेबल से अलग किया जा सके. फ़्लैग को चालू करने से, ब्राउज़र को किसी भी प्रयोग के लिए बनाए गए ग्रुप में शामिल नहीं किया जाता.
आप goo.gle/cft-demo पर जाकर, काम करते हुए लेबल देख सकते हैं.
Privacy Sandbox की प्रासंगिकता और मेज़रमेंट एपीआई के लिए रजिस्ट्रेशन की प्रक्रिया शुरू होने के बाद, आपको स्थानीय टेस्टिंग के लिए नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को बदलना पड़ सकता है. इसके लिए, आपको chrome://flags/#privacy-sandbox-enrollment-overrides का इस्तेमाल करना होगा और डेमो ऑरिजिन उपलब्ध कराना होगा. इसके अलावा, अगर Chrome को किसी टर्मिनल से चलाया जा रहा है, तो यहां दिया गया कमांड लाइन फ़्लैग शामिल करें:--args --disable-features=EnforcePrivacySandboxAttestations
फ़्लैग ड्रॉप-डाउन में कई विकल्प होते हैं. टेस्टर की दिलचस्पी मुख्य रूप से "हर हाल में" के तौर पर मार्क की गई एंट्री में होगी. इससे यह पक्का होता है कि अन्य डिवाइस कॉन्फ़िगरेशन चाहे जो भी हों, एक्सपेरिमेंट चालू रहेगा.
सिर्फ़ एक्सपेरिमेंट ग्रुप के लेबल की जांच करने के लिए, "चालू किए गए फ़ोर्स कंट्रोल 1" या "फ़ोर्स किए गए लेबल को चालू करें" चुनें. इससे ब्राउज़र, "fake_control_1.1" या "fake_label_only_1.1" लेबल भेजेगा.
Chrome M120 या इसके बाद के वर्शन में, इन एंट्री का भी इस्तेमाल किया जा सकता है.
तीसरे पक्ष की कुकी ब्लॉक करने की जांच करने के लिए, "ज़बरदस्ती ट्रीटमेंट चालू किया गया" चुनें. इससे "fake_पॉइंट_1.1", एक्सपेरिमेंट ग्रुप का लेबल भेजा जाएगा. साथ ही, तीसरे पक्ष की कुकी को ब्लॉक करने के लिए, कुकी सेटिंग पेज और मौजूदा कुकी सेटिंग में भी बदलाव किया जाएगा.
निजी विज्ञापन एपीआई के बिना, तीसरे पक्ष की कुकी को ब्लॉक करने की जांच करने के लिए, "ज़बरदस्ती कंट्रोल 2" चुनें. यह "fake_control_2" एक्सपेरिमेंट ग्रुप लेबल भेजेगा, कुकी सेटिंग पेज को अपडेट करेगा, तीसरे पक्ष की कुकी को ब्लॉक करेगा, और नए निजी विज्ञापन एपीआई को भी बंद कर देगा.
ध्यान दें कि एक समस्या यह है कि ब्राउज़र में नई कुकी सेटिंग पेज और सेटिंग बनी रहेगी, जो तीसरे पक्ष की कुकी को ब्लॉक कर देती है, भले ही आप फ़्लैग को बंद कर दें. हम इस समस्या को ठीक करने के लिए काम कर रहे हैं, लेकिन इस बीच आप --user-data-dir=<new dir> कमांड लाइन फ़्लैग के साथ Chrome लॉन्च करके किसी अलग Chrome डेटा डायरेक्ट्री में इन फ़्लैग मानों की जाँच कर सकते हैं.
सुझाव/राय दें या शिकायत करें
हम सवालों को मैनेज करने के लिए, GitHub पर डेवलपर सपोर्ट रिपॉज़िटरी में "chrome-testing" लेबल का इस्तेमाल करते हैं. हम शुरुआती सवालों पर आपके सुझाव, शिकायत या राय का स्वागत करते हैं:
- क्या आपको मोड A, मोड B या दोनों में से किसी एक का इस्तेमाल करके टेस्ट करना है?
- Chrome की मदद से की जाने वाली टेस्टिंग के लिए, लेबल के साइज़ चुनना
- Chrome की मदद से की जाने वाली टेस्टिंग के लिए, क्लाइंट हिंट का इस्तेमाल करना
"Chrome की मदद से जांच करने की सुविधा" वाले टेंप्लेट का इस्तेमाल करके, डेटा स्टोर करने की जगह में नए सवालों या चर्चाओं को बढ़ावा देने की सुविधा भी उपलब्ध है.