प्राइवेट स्टेट टोकन के लिए डेवलपर गाइड

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

Private State Tokens की मदद से, वेब पर जानकारी शेयर की जा सकती है. हालांकि, ऐसा निजता बनाए रखते हुए किया जाता है. इसके लिए, यह कंट्रोल किया जाता है कि कितना डेटा शेयर किया जा सकता है.

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

इस दस्तावेज़ में, Private State Tokens (PST) को लागू करने के बारे में तकनीकी जानकारी दी गई है. ज़्यादा जानकारी के लिए, पीएसटी की खास जानकारी देखें.

प्राइवेट स्टेट टोकन कैसे काम करते हैं?

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

• जारी करने वाली इकाइयां - इन इकाइयों के पास किसी उपयोगकर्ता के बारे में कुछ सिग्नल होता है. उदाहरण के लिए, वह उपयोगकर्ता बॉट है या नहीं. ये इकाइयां उस सिग्नल को ऐसे टोकन में एम्बेड करती हैं जो उपयोगकर्ता के डिवाइस पर सेव होता है. अगले सेक्शन में इस बारे में ज़्यादा जानकारी दी गई है.
• रिडीमर - इन इकाइयों के पास किसी उपयोगकर्ता के बारे में कोई सिग्नल नहीं हो सकता है, लेकिन उन्हें उसके बारे में कुछ जानकारी चाहिए होती है. उदाहरण के लिए, वह उपयोगकर्ता बॉट है या नहीं. साथ ही, वे उपयोगकर्ता की विश्वसनीयता को समझने के लिए, टोकन जारी करने वाले व्यक्ति या कंपनी से टोकन रिडीम करने के लिए कहते हैं.

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

क्या प्राइवेट स्टेट टोकन मेरे लिए सही हैं?

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

टोकन जारी करना और उन्हें रिडीम करना

पीएसटी को लागू करने की प्रोसेस तीन चरणों में होती है:

1. टोकन जारी करना
2. टोकन रिडीम करना
3. रिडेंप्शन रिकॉर्ड फ़ॉरवर्ड करना

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

टोकन की रणनीति तय करना

टोकन की रणनीति तय करने के लिए, आपको पीएसटी के मुख्य कॉन्सेप्ट (टोकन और रिडेंप्शन रिकॉर्ड), वैरिएबल, व्यवहार, और सीमाओं को समझना होगा. इससे आपको अपने इस्तेमाल के उदाहरण के लिए, इनके संभावित इस्तेमाल के बारे में सोचने में मदद मिलेगी.

टोकन और रिडेंप्शन रिकॉर्ड: इन दोनों के बीच क्या संबंध है?

हर डिवाइस, टॉप-लेवल की वेबसाइट और जारी करने वाले के हिसाब से ज़्यादा से ज़्यादा 500 टोकन सेव कर सकता है. साथ ही, हर टोकन में मेटाडेटा होता है. इससे पता चलता है कि टोकन जारी करने वाले ने इसे जारी करने के लिए किस कुंजी का इस्तेमाल किया है. इस जानकारी का इस्तेमाल, टोकन रिडीम करने की प्रोसेस के दौरान यह तय करने के लिए किया जा सकता है कि टोकन रिडीम करना है या नहीं. PST डेटा को ब्राउज़र, उपयोगकर्ता के डिवाइस पर सेव करता है. इसे सिर्फ़ PST API से ऐक्सेस किया जा सकता है.

जब कोई टोकन रिडीम किया जाता है, तो रिडेंप्शन रिकॉर्ड (आरआर) को डिवाइस पर सेव किया जाता है. यह स्टोरेज, आने वाले समय में रिडीम किए जाने वाले ऑफ़र के लिए कैश मेमोरी के तौर पर काम करता है. हर डिवाइस, पेज, और जारी करने वाले के लिए, हर 48 घंटे में दो टोकन रिडीम करने की सीमा होती है. नए रिडेंप्शन कॉल में, जहां भी हो सकेगा वहां कैश मेमोरी में सेव किए गए आरआर का इस्तेमाल किया जाएगा. इसके लिए, जारी करने वाले व्यक्ति या कंपनी को अनुरोध नहीं भेजा जाएगा.

1. नए टोकन जारी किए जाते हैं. हर जारी करने वाले, साइट, और डिवाइस के लिए ज़्यादा से ज़्यादा 500 टोकन जारी किए जाते हैं.
2. सभी टोकन, डिवाइस पर मौजूद टोकन स्टोर में सेव किए जाते हैं. यह कुकी स्टोर की तरह ही होता है.
3. अगर कोई चालू आरआर नहीं मिलता है, तो नए आरआर जारी किए जा सकते हैं. हालांकि, हर 48 घंटे में ज़्यादा से ज़्यादा दो आरआर जारी किए जा सकते हैं.
4. आरआर को तब तक ऐक्टिव माना जाता है, जब तक उनकी समयसीमा खत्म नहीं हो जाती. साथ ही, इनका इस्तेमाल लोकल कैश मेमोरी के तौर पर किया जाएगा.
5. रिडेंप्शन के नए कॉल, लोकल कैश मेमोरी को हिट करेंगे. हालांकि, कोई नया आरआर जनरेट नहीं होगा.

इस्तेमाल के उदाहरण के बारे में बताने के बाद, आपको अपने आरआर की लाइफ़स्पैन के बारे में ध्यान से बताना होगा. ऐसा इसलिए, क्योंकि इससे यह तय होगा कि अपने मामले में इनका इस्तेमाल कितनी बार किया जा सकेगा.

अपनी रणनीति तय करने से पहले, पक्का करें कि आपको यहां दिए गए अहम व्यवहार और वैरिएबल के बारे में पता हो:

उदाहरण के तौर पर दिए गए मामले

पहला उदाहरण: आरआर का लाइफ़स्पैन 24 घंटे से कम (t=t) है और 48 घंटे की अवधि के दौरान, इसे कई बार रिडीम किया गया है.

दूसरा उदाहरण: आरआर का लाइफ़स्पैन 24 घंटे है और 48 घंटे की विंडो के दौरान, इसे कई बार रिडीम किया जाता है.

तीसरा उदाहरण: आरआर का लाइफ़स्पैन 48 घंटे है और 48 घंटे की अवधि के दौरान, इसे कई बार रिडीम किया जाता है.

डेमो चलाएं

हमारा सुझाव है कि पीएसटी को अपनाने से पहले, डेमो का इस्तेमाल करें.

इस डेमो को चलाने पर, आपका ब्राउज़र टोकन देने और इस्तेमाल करने के लिए, डेमो जारी करने वाले और रिडीम करने वाले सर्वर का इस्तेमाल करता है.

इन तकनीकी बातों पर ध्यान दें

अगर आपको डेमो का सबसे अच्छा अनुभव चाहिए, तो यह तरीका अपनाएं:

• फ़्लैग के साथ Chrome चलाने से पहले, पक्का करें कि आपने Chrome के सभी इंस्टेंस बंद कर दिए हों.
• अगर Windows मशीन का इस्तेमाल किया जा रहा है, तो Chrome की एक्ज़िक्यूट की जा सकने वाली बाइनरी फ़ाइल में पैरामीटर पास करने का तरीका जानने के लिए, यह गाइड पढ़ें.
• डेमो ऐप्लिकेशन का इस्तेमाल करते समय, ऐप्लिकेशन > स्टोरेज > निजता की स्थिति वाले टोकन में जाकर Chrome DevTools खोलें. इससे, डेमो जारी करने वाली कंपनी के जारी किए गए या रिडीम किए गए टोकन देखे जा सकते हैं.

अपनाने के लिए सेट अप करना

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

सेवा देने वाली इकाई बनना

पीएसटी में, कार्ड जारी करने वाली कंपनियों की अहम भूमिका होती है. ये टोकन को वैल्यू असाइन करते हैं, ताकि यह पता लगाया जा सके कि कोई उपयोगकर्ता बॉट है या नहीं. अगर आपको पीएसटी को जारी करने वाले व्यक्ति के तौर पर इस्तेमाल करना है, तो आपको जारी करने वाले व्यक्ति के तौर पर रजिस्ट्रेशन की प्रोसेस पूरी करके रजिस्टर करना होगा.

कार्ड जारी करने वाली कंपनी बनने के लिए, कंपनी की वेबसाइट के ऑपरेटर को GitHub रिपॉज़िटरी पर "नया पीएसटी जारी करने वाला" टेंप्लेट इस्तेमाल करके, नया इश्यू खोलना होगा. समस्या की जानकारी देने के लिए, रिपॉज़िटरी में दिए गए निर्देशों का पालन करें. किसी एंडपॉइंट की पुष्टि हो जाने के बाद, उसे इस रिपॉज़िटरी में मर्ज कर दिया जाएगा. इसके बाद, Chrome का सर्वर-साइड इन्फ़्रास्ट्रक्चर उन कुंजियों को फ़ेच करना शुरू कर देगा.

जारी करने वाले सर्वर

पीएसटी के लिए, जारी करने वाले और रिडीम करने वाले मुख्य किरदार होते हैं. साथ ही, सर्वर और टोकन मुख्य टूल होते हैं. हमने टोकन और GitHub पर उपलब्ध दस्तावेज़ में पहले ही कुछ जानकारी दे दी है. हालांकि, हम पीएसटी सर्वर के बारे में ज़्यादा जानकारी देना चाहते हैं. पीएसटी जारी करने वाली कंपनी के तौर पर सेट अप करने के लिए, आपको सबसे पहले पीएसटी जारी करने वाला सर्वर सेट अप करना होगा.

अपना एनवायरमेंट डिप्लॉय करना: क्रेडिट कार्ड जारी करने वाले बैंक के सर्वर

टोकन जारी करने वाले सर्वर को लागू करने के लिए, आपको एचटीटीपी एंडपॉइंट दिखाने वाला अपना सर्वर साइड ऐप्लिकेशन बनाना होगा.

कार्ड जारी करने वाली कंपनी के कॉम्पोनेंट में दो मुख्य मॉड्यूल होते हैं: (1) कार्ड जारी करने वाली कंपनी का सर्वर और (2) टोकन जारी करने वाली कंपनी.

वेब से जुड़े सभी ऐप्लिकेशन की तरह, हम आपको सुझाव देते हैं कि आप अपने जारी करने वाले सर्वर के लिए सुरक्षा की एक और लेयर जोड़ें.

1. जारी करने वाला सर्वर: हमारे उदाहरण में, जारी करने वाला सर्वर एक Node.js सर्वर है. यह Issuer HTTP एंडपॉइंट को होस्ट करने के लिए, Express फ़्रेमवर्क का इस्तेमाल करता है. GitHub पर सैंपल कोड देखा जा सकता है.

2. टोकन जारी करने वाला: टोकन जारी करने वाले क्रिप्टोग्राफ़िक कॉम्पोनेंट के लिए किसी खास भाषा की ज़रूरत नहीं होती. हालांकि, इस कॉम्पोनेंट की परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों की वजह से, हम C को उदाहरण के तौर पर उपलब्ध करा रहे हैं. यह टोकन मैनेज करने के लिए, BoringSSL लाइब्रेरी का इस्तेमाल करता है. आपको GitHub पर, जारी करने वाले के कोड का उदाहरण और इंस्टॉलेशन के बारे में ज़्यादा जानकारी मिल सकती है

3. कुंजियां: टोकन जारी करने वाला कॉम्पोनेंट, टोकन को एन्क्रिप्ट (सुरक्षित) करने के लिए, कस्टम ईसी कुंजियों का इस्तेमाल करता है. इन कुंजियों को सुरक्षित रखना और सुरक्षित स्टोरेज में सेव करना ज़रूरी है.

कार्ड जारी करने वाली कंपनी के सर्वर के लिए तकनीकी शर्तें

प्रोटोकॉल के मुताबिक, आपको अपने जारी करने वाले के सर्वर में कम से कम दो एचटीटीपी एंडपॉइंट लागू करने होंगे:

• कुंजी की पुष्टि (उदाहरण के लिए, /.well-known/private-state-token/key-commitment): इस एंडपॉइंट पर, एन्क्रिप्शन के लिए इस्तेमाल की गई सार्वजनिक कुंजी की जानकारी ब्राउज़र के लिए उपलब्ध होगी. इससे यह पुष्टि की जा सकेगी कि आपका सर्वर असली है.
  • GitHub पर कोड का सैंपल
  • डेमो देखें
• टोकन जारी करना (उदाहरण के लिए, /.well-known/private-state-token/issuance): टोकन जारी करने वाला एंडपॉइंट, जहां टोकन के सभी अनुरोधों को मैनेज किया जाएगा. यह एंडपॉइंट, टोकन जारी करने वाले कॉम्पोनेंट के लिए इंटिग्रेशन पॉइंट होगा.
  • GitHub पर कोड का सैंपल
  • डेमो देखें

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

जारी करने वाले के सर्वर को कॉल भेजें

नए टोकन जारी करने के लिए, जारी करने वाले के स्टैक में वेबसाइट फ़ेच कॉल लागू करें.

 // issuer request
    await fetch("/.well-known/private-state-token/issuance", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-request"
      }
    });

कोड का उदाहरण देखें.

रिडीमर सर्वर

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

आपके पास, इश्यू करने वाले और रिडीम करने वाले को एक ही सर्वर (या सर्वर के ग्रुप) में चलाने का विकल्प होता है.

रिडीमर सर्वर के लिए तकनीकी ज़रूरी शर्तें

प्रोटोकॉल के मुताबिक, आपको रिडीमर सर्वर के लिए कम से कम दो एचटीटीपी एंडपॉइंट लागू करने होंगे:

• /.well-known/private-state-token/redemption: ऐसा एंडपॉइंट जहां टोकन रिडीम करने की सभी कार्रवाइयां मैनेज की जाएंगी. यह एंडपॉइंट वह जगह होगी जहां टोकन रिडीमर कॉम्पोनेंट को इंटिग्रेट किया जाएगा
  • GitHub पर उदाहरण के लिए कोड
  • डेमो

रिडीमर सर्वर को कॉल भेजना

टोकन रिडीम करने के लिए, आपको रिडीम करने वाले स्टैक में वेबसाइट फ़ेच कॉल लागू करना होगा, ताकि पहले जारी किए गए टोकन रिडीम किए जा सकें.

    // redemption request
    await fetch("/.well-known/private-state-token/redemption", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-redemption",
        refreshPolicy: "none"
      }
    });

कोड का सैंपल देखें.

टोकन रिडीम करने के बाद, रिडेंप्शन रिकॉर्ड (आरआर) भेजा जा सकता है. इसके लिए, फ़ेच करने का एक और कॉल करें:

    // attach redemption records from the issuers to the request
    await fetch("<DESTINATION_RESOURCE>", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "send-redemption-record",
        issuers: [<ISSUER_DOMAIN>]
      }
    });

कोड का सैंपल देखें.

लागू किए गए बदलावों को डिप्लॉय करना

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

असल दुनिया में डिप्लॉयमेंट

हमारा सुझाव है कि आप ऐसी टारगेट वेबसाइटें चुनें जो आपके खास इस्तेमाल के उदाहरण का हिस्सा हों:

• हर महीने कम विज़िट (~ 10 लाख से कम विज़िट/महीना): आपको सबसे पहले, एपीआई को कम ऑडियंस के लिए डिप्लॉय करना चाहिए
• इसका मालिकाना हक और कंट्रोल आपके पास होता है: अगर ज़रूरी हो, तो बिना किसी जटिल मंज़ूरी के, इसे तुरंत बंद किया जा सकता है
• टोकन जारी करने वाली कंपनी एक से ज़्यादा नहीं होनी चाहिए: इससे टोकन की संख्या सीमित रहती है, ताकि टेस्टिंग को आसान बनाया जा सके.
• दो से ज़्यादा लोगों को रिडीम करने की अनुमति न दें: ऐसा इसलिए, ताकि समस्या होने पर उसे आसानी से ठीक किया जा सके.

अनुमतियों की नीति

सही तरीके से काम करने के लिए, PST API टॉप-लेवल पेज और एपीआई का इस्तेमाल करने वाले सभी सब-संसाधनों के लिए उपलब्ध होना चाहिए.

टोकन के लिए अनुरोध करने की कार्रवाई को private-state-token-issuance डायरेक्टिव से कंट्रोल किया जाता है. token-redemption और send-redemption-record कार्रवाइयों को private-state-token-redemption डायरेक्टिव से कंट्रोल किया जाता है. Chrome 132 और इसके बाद के वर्शन में, इन डायरेक्टिव के लिए अनुमति वाली सूची को डिफ़ॉल्ट रूप से * (सभी ऑरिजिन) पर सेट किया जाता है. इसका मतलब है कि यह सुविधा, टॉप-लेवल पेज, एक ही ऑरिजिन वाले iframe, और साफ़ तौर पर डेलिगेशन के बिना क्रॉस-ऑरिजिन iframe के लिए उपलब्ध है.

अपनी साइट के कुछ पेजों के लिए, पीएसटी टोकन जारी करने या रिडीम करने की सुविधा से ऑप्ट आउट किया जा सकता है. इसके लिए, हर पेज के Permissions-Policy हेडर में private-state-token-issuance=() और private-state-token-redemption=() शामिल करें.

Permissions-Policy हेडर का इस्तेमाल करके, तीसरे पक्ष को पीएसटी का ऐक्सेस देने पर भी कंट्रोल किया जा सकता है. हेडर ऑरिजिन सूची के पैरामीटर के तौर पर, self और उन सभी ऑरिजिन का इस्तेमाल करें जिन्हें आपको एपीआई का ऐक्सेस देना है. उदाहरण के लिए, अपने ऑरिजिन और https://example.com को छोड़कर, सभी ब्राउज़िंग कॉन्टेक्स्ट में पीएसटी के इस्तेमाल को पूरी तरह से बंद करने के लिए, यहां दिए गए एचटीटीपी रिस्पॉन्स हेडर सेट करें:

Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")

सभी क्रॉस-ऑरिजिन संसाधनों के लिए एपीआई चालू करने के लिए, ऑरिजिन की सूची को * पर सेट करें.

अनुमतियों से जुड़ी नीति की मदद से, Privacy Sandbox की सुविधाओं को कंट्रोल करने का तरीका जानें. इसके अलावा, अनुमतियों से जुड़ी नीति के बारे में ज़्यादा जानें.

समस्या का हल

Chrome DevTools के नेटवर्क और ऐप्लिकेशन टैब से, पीएसटी की जांच की जा सकती है.

नेटवर्क टैब पर:

ऐप्लिकेशन टैब पर:

DevTools इंटिग्रेशन के बारे में ज़्यादा जानें.

क्लाइंट के लिए सबसे सही तरीके

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

हर टॉप-लेवल के लिए, दो से ज़्यादा आईएसएसर नहीं हो सकते. साथ ही, तीसरे पक्ष की स्क्रिप्ट भी hasPrivateToken(issuer) को कॉल करने की कोशिश कर सकती हैं, ताकि वे अपने पसंदीदा आईएसएसर को प्राथमिकता दे सकें. इसलिए, ज़रूरी क्रेडिट कार्ड जारी करने वाली कंपनियों को पहले से सुरक्षित करें, ताकि यह पक्का किया जा सके कि आपकी साइट उम्मीद के मुताबिक काम कर रही है.

  // Prioritize your critical token issuer.
  document.hasPrivateToken('https://critical-issuer.example')
    .then(hasToken => {
      if (hasToken) {
        // Use the token or perform actions based on its availability.
      } else {
        // Handle the case where the token is not available.
      }
    });

  // Load third-party scripts or secure another token issuer (up to two in total).

सर्वर के लिए सबसे सही तरीके और समस्या हल करना

हमारा सुझाव है कि आप यहां दिए गए सबसे सही तरीके अपनाएं, ताकि आपका जारी करने वाला और रिडीम करने वाला सर्वर बेहतर तरीके से काम कर सके. इससे यह पक्का किया जा सकेगा कि आपको पीएसटी के लिए, ऐक्सेस, सुरक्षा, लॉगिंग या ट्रैफ़िक से जुड़ी कोई समस्या न हो.

• आपके एंडपॉइंट पर, टीएलएस 1.3 या 1.2 का इस्तेमाल करके, मज़बूत क्रिप्टोग्राफ़ी लागू होनी चाहिए.
• आपका इंफ़्रास्ट्रक्चर, ट्रैफ़िक के अलग-अलग वॉल्यूम को मैनेज करने के लिए तैयार होना चाहिए. इसमें ट्रैफ़िक में अचानक होने वाली बढ़ोतरी भी शामिल है.
• पक्का करें कि आपकी कुंजियां सुरक्षित हों और आपकी ऐक्सेस कंट्रोल नीति, कुंजी मैनेजमेंट की रणनीति, और कारोबार को जारी रखने की योजनाओं के मुताबिक हों.
• अपने स्टैक में ऑब्ज़र्वेबिलिटी मेट्रिक जोड़ें. इससे यह पक्का किया जा सकेगा कि प्रोडक्शन में जाने के बाद, आपको इस्तेमाल, परफ़ॉर्मेंस से जुड़ी समस्याओं, और बॉटलनेक के बारे में जानकारी मिल पाए.

ज़्यादा जानकारी

1. डेवलपर के लिए उपलब्ध दस्तावेज़ देखें:
   1. पीएसटी और इसकी क्षमताओं के बारे में जानने के लिए, खास जानकारी पढ़ें.
   2. पीएसटी के बारे में जानकारी देने वाला वीडियो देखें.
   3. पीएसटी का डेमो आज़माएं.
   4. इसके बारे में ज़्यादा जानकारी पाने के लिए, एपीआई के बारे में जानकारी देने वाला लेख भी पढ़ें.
   5. एपीआई के मौजूदा स्पेसिफ़िकेशन के बारे में ज़्यादा जानें.
2. GitHub की समस्याओं या W3C की कॉल का इस्तेमाल करके, बातचीत में हिस्सा लें.
3. किसी भी शब्दावली को बेहतर तरीके से समझने के लिए, Privacy Sandbox की शब्दावली देखें.
4. 'ऑरिजिन ट्रायल' या 'Chrome फ़्लैग' जैसे Chrome के कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, goo.gle/cc पर उपलब्ध छोटे वीडियो और लेख देखें.