तीसरे पक्ष की कुकी को बंद होने से बचाने के लिए, हम Chrome की सुविधा वाले टेस्टिंग मोड उपलब्ध कराएंगे. इनकी मदद से, साइटें इस बात की झलक देख पाएंगी कि तीसरे पक्ष की कुकी के बिना, साइट कैसे काम करती है और कैसे काम करती है. इस गाइड में उन टेस्टिंग मोड की खास जानकारी दी गई है जिन्हें Chrome उपलब्ध कराना है. साथ ही, प्रयोग ग्रुप के लेबल को ऐक्सेस करने के तरीके की जानकारी भी दी गई है.
यहां Chrome ब्राउज़र का मतलब Chrome क्लाइंट है: किसी डिवाइस पर Chrome इंस्टॉलेशन. हर उपयोगकर्ता की डेटा डायरेक्ट्री का एक अलग क्लाइंट होता है.
एक्सपेरिमेंट ग्रुप: Chrome ब्राउज़र का एक सेट, जिसके लिए कुछ सुविधाएं चालू, बंद या कॉन्फ़िगर की जाती हैं. Chrome की सुविधा वाले टेस्टिंग के संदर्भ में, ब्राउज़र का एक सेट, जिसके लिए लेबल सेट किए जाते हैं.
लेबल: इस संदर्भ में, अनुरोध के हेडर की वैल्यू, जो एक्सपेरिमेंट ग्रुप से जुड़े ब्राउज़र के लिए सेट की जाती है. Chrome की सुविधा वाली टेस्टिंग के दौरान, किसी एक्सपेरिमेंट ग्रुप में मौजूद हर ब्राउज़र, उस ग्रुप में बना रहेगा. इससे, यह पक्का किया जाता है कि जांच करने वाले सभी लोगों के लिए, ब्राउज़र का लेबल एक जैसा बना रहे.
हमने दो अलग-अलग मोड ऑफ़र किए हैं:
- मोड A: नवंबर 2023 से, PS R&M API का इस्तेमाल करने वाले संगठनों को Chrome ब्राउज़र के सबसेट पर एक जैसे लेबल पाने के लिए ऑप्ट-इन करने की सुविधा मिली है. इससे, अलग-अलग टेस्टर के साथ मिलकर टेस्ट किया जा सकेगा.
- मोड B: 4 जनवरी, 2024 से, Chrome ने दुनिया भर में कुछ Chrome ब्राउज़र के लिए तीसरे पक्ष की कुकी बंद कर दी हैं.
दोनों मोड, साल 2024 की दूसरी तिमाही तक जारी रहेंगे. मोड B में तीसरे पक्ष की कुकी जिन पर बंद होती हैं, वे तीसरे पक्ष की कुकी के पूरे चरण तक बंद रहेंगी.
हमने सीएमए के साथ मिलकर काम किया है, ताकि यह पक्का किया जा सके कि ये टेस्टिंग मोड, तीसरे पक्षों के टेस्टिंग फ़्रेमवर्क (और टाइमलाइन) के हिसाब से हों. इंडस्ट्री की टेस्टिंग से जुड़े दिशा-निर्देशों में यह जानकारी दी गई है. इसलिए, सीएमए का अनुमान है कि इन मोड में की गई टेस्टिंग के नतीजों का इस्तेमाल, प्राइवसी सैंडबॉक्स के आकलन में किया जा सकता है. CMA ने संकेत दिया है कि वे एक्सपेरिमेंटल डिज़ाइन 2 के नतीजों पर ज़्यादा ज़ोर दे सकते हैं, जिसमें मोड बी लेबल और मोड A कंट्रोल 1 लेबल का इस्तेमाल किया जाता है. एक्सपेरिमेंटल डिज़ाइन 2 के बारे में ज़्यादा जानकारी के लिए, 26 अक्टूबर के लिए सीएमए के दिशा-निर्देश देखें.
हम इस प्रस्ताव को सामान्य ब्लिंक डेवलपमेंट प्रोसेस से भी भेजेंगे, जिसमें तकनीकी डिज़ाइन और Chrome रिलीज़ के माइलस्टोन को अंतिम रूप दिया जाएगा. हालांकि, हम इसे लागू करना चाहते हैं, लेकिन अतिरिक्त चर्चा और मंज़ूरी का मतलब है कि इन जानकारी में अब भी बदलाव हो सकता है. जैसे-जैसे प्लान आगे बढ़ेगा, हम इस पेज को अपडेट करते रहेंगे. साथ ही, आप चाहें, तो सुझाव या राय दें या सवाल पूछें.
मोड A: लेबल किए गए ब्राउज़र ग्रुप
टेस्टिंग में हिस्सा लेने वाले संगठन, Chrome ब्राउज़र के सबसेट के लिए लेबल का लगातार सेट पाने के लिए ऑप्ट-इन कर सकेंगे. इससे वे ब्राउज़र के एक ही सेट पर, अलग-अलग विज्ञापन टेक्नोलॉजी के लिए एक साथ प्रयोग कर पाएंगे.
उदाहरण के लिए, अगर कोई ब्राउज़र, label_only_3
एक्सपेरिमेंट ग्रुप (जैसा कि नीचे दी गई टेबल में दिखाया गया है) में आता है, तो इस टेबल में शामिल सभी विज्ञापन टेक्नोलॉजी, label_only_3
लेबल को देख पाएंगी और उसके हिसाब से निर्देश दे पाएंगी: PS R&M एपीआई का इस्तेमाल करें, लेकिन तीसरे पक्ष की कुकी का इस्तेमाल नहीं करें. हम उम्मीद करते हैं कि पेज पर
हिस्सा लेने वाले लोग, यह पक्का करेंगे कि लेबल दूसरे लोगों को भेजे जा रहे हैं, ताकि विज्ञापन चुनने और उनकी परफ़ॉर्मेंस को मापने
की पूरी प्रोसेस में एक जैसा प्रयोग किया जा सके.
उदाहरण के लिए, इससे एक से ज़्यादा लोग, ब्राउज़र के एक जैसे ग्रुप में तीसरे पक्ष की कुकी के बिना, Protected Audience की नीलामियां कर सकते हैं. नीलामी में हिस्सा लेने वाले लोग, निगरानी में रखे गए लेबल को खरीदारों को भेजेंगे, ताकि वे सोच-समझकर जांच कर सकें.
ये लेबल, Chrome के उन इंस्टेंस में किसी भी सुविधा को प्रभावित नहीं करते हैं. इनमें तीसरे पक्ष की कुकी की उपलब्धता भी शामिल है. लेबल, स्वतंत्र और कोऑर्डिनेटेड प्रयोगों के लिए ग्रुपिंग उपलब्ध कराते हैं, लेकिन यह प्रयोग में हिस्सा लेने वाले पक्षों पर निर्भर करता है कि वे प्रयोग के लिए ज़रूरी पैरामीटर लागू करें. अगर तीसरे पक्ष की कुकी को हटाने के असर की जांच की जा रही है, तो मीटिंग में हिस्सा लेने वाले हर व्यक्ति को उस लेबल वाले ब्राउज़र के लिए तीसरे पक्ष की कुकी के डेटा को बाहर रखना होगा.
इसका मकसद ऐसे ग्रुप बनाना है जो Chrome के सामान्य ट्रैफ़िक को दिखाते हों. इसका मतलब है कि तीसरे पक्ष की कुकी और PS R&M API, दोनों उपलब्ध होने चाहिए. हालांकि, हो सकता है कि कुछ उपयोगकर्ताओं ने सेटिंग या एक्सटेंशन की मदद से, सुविधाओं में बदलाव किया हो या उन्हें बंद कर दिया हो.
लेबल आम तौर पर Chrome में पूरे ब्राउज़िंग सेशन और सभी सेशन में एक जैसे रहते हैं. हालांकि, इसकी कोई गारंटी नहीं है. ऐसा बहुत कम होता है, क्योंकि ब्राउज़र को पूरी तरह से रीसेट करने पर भी मौजूदा लेबल रीसेट हो सकता है.
हम मोड A में 8.5% Chrome स्टेबल ब्राउज़र को शामिल करने की योजना बना रहे हैं. हमारे शुरुआती प्रस्ताव में इन सभी लोगों को नौ ग्रुप में बांटा गया है. छोटे सबग्रुप का मक़सद यह है कि लेबल को एक साथ इस्तेमाल करने के लिए, विज्ञापन टेक्नोलॉजी को इसमें बदलाव किया जा सके, ताकि वे अलग-अलग साइज़ के खुद के प्रयोग बना सकें. ग्रुप ओवरलैप नहीं होते हैं.
ध्यान दें कि control_1.*
लेबल को "कंट्रोल 1" के तौर पर इस्तेमाल किया जाना चाहिए, जैसा कि सीएमए के इंडस्ट्री से जुड़े टेस्ट के दिशा-निर्देशों में बताया गया है. इसलिए, टेस्टिंग में हिस्सा लेने वाले लोगों को इस ट्रैफ़िक के लिए, Topics API का इस्तेमाल या नीलामी में हिस्सा नहीं लेना चाहिए. लेबल से, फ़ंक्शन पर कोई असर नहीं पड़ता. इसलिए, control_1.*
ग्रुप लेबल का पता चलने के बाद, हिस्सा लेने वाले लोगों को निगरानी वाले विषयों को पास नहीं करना चाहिए या प्रोटेक्टेड ऑडियंस नीलामियों नहीं करनी चाहिए.
हम इस बारे में सुझाव का स्वागत करते हैं कि चुने गए ग्रुप, हिस्सा लेने वाले संगठनों की ज़रूरतों को पूरा करते हैं या नहीं.
लेबल | स्टेबल ट्रैफ़िक का प्रतिशत |
---|---|
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 एपीआई को बंद कर दिया गया है. अन्य एपीआई, जैसे कि मिलती-जुलती वेबसाइट के सेट, सीएचआईपीएस, और FedCM को बंद नहीं किया जाएगा. हमारा अनुमान है कि यह कॉम्बिनेशन, तीसरे पक्ष की कुकी और PS R&M एपीआई के बिना, ब्राउज़र की परफ़ॉर्मेंस की बेसलाइन तय करने में मदद करेगा.
मोड B के हिस्से के तौर पर, हम उन ब्राउज़र के लिए भी लेबल देंगे जिन पर असर हुआ है. लेबल तब ही उपलब्ध होंगे, जब एपीआई बंद किए गए होंगे. हमारा सुझाव है कि
लोगों को तीन treatment_1.*
ग्रुप में बांटा जाए, जिनमें तीसरे पक्ष की कुकी बंद हों, लेकिन PS R&M एपीआई उपलब्ध हों. वहीं, एक control_2
ग्रुप में, तीसरे पक्ष की कुकी और PS R&M एपीआई बंद दोनों बंद हों.
Attribution Reporting API और Private एग्रीगेशन एपीआई इंटिग्रेशन को डीबग करने में मदद करने और ग़ैर-ज़रूरी आवाज़ों को समझने में मीटिंग में हिस्सा लेने वाले लोगों की मदद करने के लिए, ARA डीबग रिपोर्ट और प्राइवेट एग्रीगेशन डीबग रिपोर्ट, अब भी मोड B में ब्राउज़र के लिए उपलब्ध रहेंगी. ऐसा तब तक होगा, जब तक उपयोगकर्ता ने तीसरे पक्ष की कुकी को साफ़ तौर पर ब्लॉक न किया हो. डीबग रिपोर्ट,
control_2
में उपलब्ध नहीं होगी. ऐसा इसलिए, क्योंकि उस स्लाइस में PS R&M एपीआई उपलब्ध नहीं हैं. तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने के साथ-साथ, डीबग रिपोर्ट को भी बंद किया जाएगा.
- Attribution Reporting API के लिए, तीसरे पक्ष की कुकी बंद होने की वजह से, रिपोर्टिंग ऑरिजिन
ar_debug
कुकी को सेट नहीं कर पाएगा और डीबग करने की रिपोर्ट पाने के लिए ऑप्ट-इन या आउट करने के लिए,debug_key
फ़ील्ड (एट्रिब्यूशन-सक्सेस रिपोर्ट के लिए) औरdebug_reporting
फ़ील्ड (वर्बोस रिपोर्ट के लिए) को सेट करना होगा. - Private एग्रीगेशन एपीआई के लिए, डीबग करने की रिपोर्ट पाने के ऑप्ट-इन को कंट्रोल करने के लिए, रिपोर्टिंग ऑरिजिन को
enableDebugMode()
को कॉल करने पर निर्भर करना चाहिए. कंपनियों को यह तय करना चाहिए कि एट्रिब्यूशन की सुविधा के एपीआई और Private एग्रीगेशन एपीआई के इस्तेमाल पर, कानूनी जवाबदेही किस तरह लागू हो सकती है. इनमें डीबग रिपोर्ट भी शामिल हैं.
मोड 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-Depre मामलों में एचटीटीपी हेडर को ऐक्सेस करें
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
कुकी सेट की जा सकती हैं.
कुकी डेप्रेशनलेबल JavaScript API को ऐक्सेस करना
Cookie-Deprecation
वैल्यू को
navigator.cookieDeprecationLabel.getValue()
JavaScript API के ज़रिए भी ऐक्सेस किया जा सकता है. इससे एक ऐसा प्रॉमिस मिलेगा जो लागू ग्रुप लेबल वाली स्ट्रिंग तक ले जाता है. उदाहरण के लिए, अगर ब्राउज़र 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 के ज़रिए, आप यह देख सकते हैं कि लेबल किस तरह काम करते हैं.
प्राइवसी सैंडबॉक्स से जुड़ी गड़बड़ियों और मेज़रमेंट एपीआई के लिए रजिस्ट्रेशन लागू किया गया है. इसलिए, आपको chrome://flags/#privacy-sandbox-enrollment-overrides
का इस्तेमाल करके और डेमो ऑरिजिन की जानकारी देकर, लोकल टेस्टिंग के लिए नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को बदलना पड़ सकता है. इसके अलावा, अगर Chrome को किसी टर्मिनल से चलाया जा रहा है, तो यहां दिया गया कमांड लाइन फ़्लैग शामिल करें:
--args --disable-features=EnforcePrivacySandboxAttestations
फ़्लैग ड्रॉप-डाउन में एक से ज़्यादा विकल्प होते हैं. टेस्टर को मुख्य रूप से "ज़बरदस्ती" के तौर पर मार्क की गई एंट्री में दिलचस्पी होगी. इससे यह पक्का होता है कि दूसरे डिवाइस कॉन्फ़िगरेशन के बावजूद, प्रयोग की सुविधा चालू हो.
सिर्फ़ एक्सपेरिमेंट ग्रुप लेबल की जांच करने के लिए, "फ़ोर्स कंट्रोल 1 चालू किया गया" या "फ़ोर्स लेबल सिर्फ़ चालू किया गया" चुनें. इनकी वजह से, ब्राउज़र "fake_control_1.1" या "fake_label_only_1.1" लेबल भेजेगा.
Chrome के M120 या उसके बाद के वर्शन में, नीचे दी गई एंट्री का भी इस्तेमाल किया जा सकता है.
तीसरे पक्ष की कुकी ब्लॉक करने की सुविधा की जांच करने के लिए, "फ़ोर्स ट्रीटमेंट चालू है" को चुनें. इससे "fake_practice_1.1" प्रयोग ग्रुप लेबल भेजा जाएगा, लेकिन तीसरे पक्ष की कुकी को ब्लॉक करने के लिए, कुकी सेटिंग पेज और मौजूदा कुकी सेटिंग में भी बदलाव किया जाएगा.
निजी विज्ञापन एपीआई के बिना, तीसरे पक्ष की कुकी को ब्लॉक करने की सुविधा की जांच करने के लिए, "फ़ोर्स कंट्रोल 2" चुनें. इससे "fake_control_2" का प्रयोग ग्रुप लेबल भेजा जाएगा, कुकी सेटिंग पेज को अपडेट किया जाएगा, तीसरे पक्ष की कुकी ब्लॉक की जाएंगी, और नए निजी विज्ञापन एपीआई को भी बंद कर दिया जाएगा.
ध्यान दें, फ़िलहाल एक समस्या है जहां ब्राउज़र में, कुकी की नई सेटिंग वाला पेज बना रहेगा. साथ ही, इस सेटिंग की वजह से तीसरे पक्ष की कुकी ब्लॉक हो जाएंगी, भले ही आपने फ़्लैग को बंद कर दिया हो. हम इस समस्या को ठीक करने के लिए काम कर रहे हैं, लेकिन इस बीच आप एक अलग Chrome डेटा डायरेक्ट्री में इन फ़्लैग वैल्यू की जांच कर सकते हैं. ऐसा करने के लिए, आपको --user-data-dir=<new dir>
कमांड लाइन फ़्लैग के साथ Chrome को लॉन्च करना होगा.
सुझाव/राय दें या शिकायत करें
हम सवालों को मैनेज करने के लिए, GitHub पर डेवलपर सहायता रेपो में "chrome-testing" लेबल का इस्तेमाल करते हैं. हम आपके सुझाव, शिकायत या राय और शुरुआती सवालों पर चर्चा का स्वागत करते हैं:
- क्या आपको मोड A, मोड B या दोनों में से किसी का इस्तेमाल करके टेस्ट करना है?
- Chrome की सुविधा वाली टेस्टिंग के लिए लेबल का साइज़ चुनना
- Chrome की मदद से जांच करने के लिए, क्लाइंट हिंट का इस्तेमाल करना
"Chrome की सुविधा वाले टेस्टिंग" टेंप्लेट का इस्तेमाल करके, रेपो में नए सवाल या चर्चाएं बढ़ाई जा सकती हैं.