निजता सैंडबॉक्स के कई एपीआई, 2024 में तीसरे पक्ष की कुकी के बंद होने की तैयारी के लिए, Chrome Stable में सामान्य उपलब्धता (GA) को लॉन्च कर रहे हैं. इनमें से कुछ एपीआई, क्रॉस-साइट कुकी के इस्तेमाल के ज़रूरी उदाहरणों को सुरक्षित रखने में मदद करेंगे. जैसे, सीएचआईपीएस और एपीआई को फ़िलहाल पहले पक्ष के सेट (एफ़पीएस) के नाम से जाना जाता है. इस पोस्ट में, हमने मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) की जानकारी दी है. यह एफ़पीएस के लिए हमारा नया नाम है, जो इसके मकसद को बेहतर तरीके से बताता है. साथ ही, ऐप्लिकेशन के इस्तेमाल के खास उदाहरणों के बारे में जानकारी देता है. साथ ही, इससे जुड़े सबसेट डोमेन की सीमा के बारे में अपडेट देता है.
उपयोगकर्ता की गतिविधियों को अहम बनाए रखना
जब Chrome डिफ़ॉल्ट रूप से तीसरे पक्ष की कुकी के ऐक्सेस को सीमित करना शुरू कर देता है, तब लोगों के लिए उपलब्ध खास सुविधाओं में आने वाली रुकावटों को कम करने के लिए, RWS को डिज़ाइन किया गया है. हमारा मकसद है कि उपयोगकर्ता, प्राइवसी सैंडबॉक्स के निजता से जुड़े लक्ष्यों को पूरा करते हुए, कम से कम रुकावट के साथ वेब ब्राउज़ कर सकें. ऐसा करने के लिए, आरडब्ल्यूएस वेबसाइट के फ़ंक्शन के इस्तेमाल के कुछ खास मामलों को टारगेट करता है:
- ccTLD के इस्तेमाल के उदाहरण से, हमारे सार्वजनिक ट्रैकर में दर्ज किए गए लॉगिन उदाहरण जैसे ब्रेकेज के बारे में पता चलता है. इस तरह के मामलों को अक्सर अनुमान पर आधारित अपवादों की मदद से नेटवर्क में हल किया जाता है (रेफ़रंस 1 देखें).
- सेवा डोमेन के इस्तेमाल का उदाहरण, उपयोगकर्ता के इस्तेमाल वाले डोमेन से संवेदनशील फ़ंक्शन (जैसे पुष्टि करने की प्रोसेस के साथ काम करना) को अलग करने के लिए, एक सामान्य डेवलपर तरीके का इस्तेमाल करता है. इस तरह के मामलों को नेटवर्क में, टारगेट किए गए अपवादों के ज़रिए हल किया जा सकता है (रेफ़रंस 2 देखें).
- असोसिएट किए गए डोमेन के इस्तेमाल के उदाहरण में, ऐसे डोमेन को ज़्यादा आसानी से इस्तेमाल करने की सुविधा मिलती है जिन्हें उपयोगकर्ता की अहम गतिविधियों के लिए, तीसरे पक्ष की कुकी के ऐक्सेस की ज़रूरत हो सकती है (रेफ़रंस 3 देखें). गलत इस्तेमाल को कम करने के लिए, ccTLD और सेवा डोमेन के इस्तेमाल के उदाहरण में, डोमेन की विशेषताओं के आधार पर सख्त तकनीकी जांच की जाती है. हालांकि, इससे जुड़े डोमेन में संख्या वाली सीमा का इस्तेमाल किया जाता है. अगले सेक्शन में, इस बारे में ज़्यादा पढ़ें.
इससे जुड़े डोमेन की सीमा बढ़ाकर पांच डोमेन कर दी गई है
Chrome ने पहले ही असोसिएट किए गए सबसेट (एक प्राइमरी डोमेन के साथ) के लिए, तीन डोमेन की संख्या की सीमा का सुझाव दिया था. ऐसा बड़े पैमाने पर ट्रैकिंग के गलत इस्तेमाल को रोकने के हमारे मकसद को ध्यान में रखकर किया गया था. हमें वेब मानकों में हिस्सा लेने वालों से सुझाव मिले हैं कि अलग-अलग तरह के इस्तेमाल के उदाहरणों के लिए यह सीमा बहुत कम थी.
हमने इससे जुड़े डोमेन की सीमा को पांच डोमेन तक बढ़ाने का फ़ैसला किया है. इसमें एक प्राइमरी डोमेन शामिल है, जो किसी दूसरे मुख्य ब्राउज़र की तुलना में बेहतर तरीके से लागू किया जा सकता है (रेफ़रंस 4 देखें). यह बदलाव, Chrome 117 और उसके बाद के वर्शन से लागू होगा.
RWS को विज्ञापनों की सुविधा के तौर पर नहीं बनाया गया है. इसलिए, हम विज्ञापनों के इस्तेमाल के उदाहरणों को बेहतर तरीके से दिखाने के लिए, RWS को बेहतर बनाने के तरीके पर विचार नहीं कर रहे हैं. विज्ञापनों के इस्तेमाल के उदाहरणों के लिए, डेवलपर को Topics, Protected Audience, और Attribution Reporting API का इस्तेमाल करना चाहिए. साथ ही, उन्हें इस हिसाब से सुझाव देने चाहिए.
उपयोगकर्ताओं के पास पांच से ज़्यादा डोमेन के अलावा, कई और मामलों में इस्तेमाल करने का विकल्प होता है
Chrome उन उपयोगकर्ताओं पर असर डालने वाले अनुभवों के लिए है जो इस सीमा के साथ काम नहीं करते हैं. इसके लिए, Chrome उपयोगकर्ता को प्रॉम्प्ट भेजने के फ़्लो पर काम कर रहा है. यह स्टोरेज ऐक्सेस एपीआई (एसएए) का भी इस्तेमाल करता है. यह एक स्टैंडर्ड है जिसे अन्य ब्राउज़र में अपनाया जाता है. इस्तेमाल के ऐसे मामलों के लिए, जिनमें पांच से ज़्यादा डोमेन जुड़े होने की ज़रूरत होती है, हम डेवलपर को यह आकलन करने के लिए बढ़ावा देते हैं कि SAA के साथ गैर-RWS के कॉन्टेक्स्ट में कैसे काम किया जा सकता है. हम इस सुविधा के लिए, Blink के लॉन्च की प्रोसेस को अलग से फ़ॉलो कर रहे हैं. इसे Chrome डेस्कटॉप पर, Chrome 117 की शुरुआत में लॉन्च किया जाएगा.
अगले चरण
नेटवर्क से जुड़े सुझावों के लिए हम शुक्रगुज़ार हैं. इन सुझावों से अब तक एपीआई को बेहतर बनाने में मदद मिली है. हमने RWS में एक ऐसा तरीके के तौर पर निवेश किया है जिसकी मदद से, डेवलपर अपनी बनाई गई वेबसाइटों के असली उपयोगकर्ता अनुभव को बनाए रखने के लिए, अनुमान लगाने के साथ-साथ कंट्रोल और एजेंसी भी इस्तेमाल कर सकते हैं. हम यह देखने के लिए उत्साहित हैं कि डेवलपर किस तरह से RWS को अपनाते हैं और उसका इस्तेमाल कैसे करते हैं. फ़िलहाल, सबमिशन की प्रोसेस लाइव है. सबमिशन में मदद पाने के लिए, RWS JSON जनरेटर टूल का इस्तेमाल करना बेहतर है.
प्रोग्रेस को ट्रैक करने के लिए, थ्रेड को शिप करने के इंटेंट का पालन करें. साथ ही, इसे लागू करने के बारे में दिशा-निर्देश देखने के लिए, इन मटीरियल को देखें.
References
- सभी ब्राउज़र पर एक आम सहमति है कि क्रॉस-साइट कुकी के इस्तेमाल के ये उदाहरण ज़रूरी हैं. हालांकि, इन्हें चालू करने के लिए उन्होंने अलग-अलग तरीके अपनाए हैं. Firefox (कोड) और Safari (कोड) दोनों में पॉप-अप ह्यूरिस्टिक लागू किया गया है, जो देखे गए ब्रेक के बारे में बताता है. उदाहरण के लिए, Nintendo के लॉगिन फ़्लो.
- इसके अलावा, ऐसे कई उदाहरण भी हैं जिनमें ब्राउज़र के हार्ड कोड अपवाद के तौर पर इस्तेमाल किए जाते हैं, ताकि उपयोगकर्ताओं को कम से कम परेशानी हो. Firefox Microsoft Teams और लॉगिन.microsoftonline.us के बीच रीडायरेक्ट फ़्लो पर स्टोरेज ऐक्सेस देता है.
- जब कोई उपयोगकर्ता instagram.com पर लॉग इन करता है, तो Firefox "शिम" उपलब्ध कराता है, जो facebook.com की ओर से requestStorageAccessForOrigin को कॉल करेगा. एक से ज़्यादा डोमेन के लिए स्टोरेज ऐक्सेस के अनुरोधों को ग्रुप करने के लिए, साइट ग्रुपिंग का एक उदाहरण Safari के हार्ड कोड किए गए अपवादों में भी देखा जा सकता है.
- Firefox किसी तीसरे पक्ष की साइट से किए गए पहले पांच requestStorageAccess कॉल (कोड) के लिए अपने-आप अनुमति देता है, जिन्हें उपयोगकर्ता पहले देख चुका है. Chrome में, एक ही सेट के प्राइमरी डोमेन के साथ-साथ, जुड़े हुए सबसेट में शामिल पहले पांच डोमेन को RWS के ज़रिए तीसरे पक्ष की कुकी का अपने-आप ऐक्सेस मिलेगा.