पब्लिश होने की तारीख: 5 अक्टूबर, 2026
ईमेल पते की पुष्टि करने की सुविधा के लिए, ओरिजिन ट्रायल जारी है. हमने आपके सुझाव, शिकायत या राय के आधार पर, कुछ और अपडेट किए हैं. हमें उम्मीद है कि आगे कोई और बड़ा बदलाव नहीं होगा. हम इस सुविधा को लॉन्च करने की तैयारी कर रहे हैं. हमने ईमेल की पुष्टि करने के लिए, एक नया दस्तावेज़ सेक्शन भी लॉन्च किया है. इसमें पुष्टि करने वालों और जारी करने वालों के लिए अलग-अलग सेक्शन हैं.
ईमेल की पुष्टि करने वाले ऑरिजिन ट्रायल को डेस्कटॉप पर Chrome 150 में शुरू किया गया था. डेवलपर के सुझाव, शिकायत या राय और पूरे इकोसिस्टम में टेस्टिंग के बाद, हम इस सुविधा को लागू करने के तरीके को बेहतर बनाते रहेंगे. इस पोस्ट में, Chrome 154 से जुड़े अपडेट के बारे में बताया गया है. इनमें Android के लिए सहायता, तीसरे पक्ष के ओरिजिन ट्रायल, टोकन की पुष्टि के दौरान मुख्य डिस्कवरी को हैंडल करना, और ईमेल सेवा देने वाली कंपनियों के लिए हेडर अपडेट शामिल है.
उपयोगकर्ताओं के लिए उपलब्ध अपडेट
यूज़र इंटरफ़ेस या उपयोगकर्ता के सामने दिखने वाले व्यवहार में बदलाव.
Android पर Chrome के लिए सहायता
Chrome 154 और इसके बाद के वर्शन में, Android के लिए Chrome पर ईमेल पते की पुष्टि करने की सुविधा काम करती है. पुष्टि करने वालों या सेवा देने वालों को कोई बदलाव करने की ज़रूरत नहीं है, क्योंकि एपीआई या प्रोटोकॉल पहले जैसा ही है. इसके लिए भी वही ज़रूरी शर्तें लागू होती हैं. इनमें यह शर्त भी शामिल है कि उपयोगकर्ता ने ब्राउज़र में, ईमेल की सेवा देने वाली कंपनी के खाते में साइन इन किया हो.
उपयोगकर्ता, सेटिंग > पते और अन्य जानकारी > पुष्टि किया गया ईमेल में जाकर अपनी सेटिंग ऐक्सेस कर सकते हैं.
पुष्टि करने वाले के लिए अपडेट
ईमेल पते इकट्ठा करने और उनकी पुष्टि करने वाली साइटों के लिए बदलाव.
तीसरे पक्ष की ऑरिजिन ट्रायल
Chrome 154 से, ईमेल की पुष्टि करने के लिए तीसरे पक्ष के ऑरिजिन के ट्रायल इस्तेमाल किए जा सकते हैं. इसके बारे में ज़्यादा जानने के लिए, समस्या 534377131 देखें. अगर आपने एम्बेड की गई स्क्रिप्ट या Identity SDK टूल दिया है, तो अब तीसरे पक्ष के ट्रायल टोकन के लिए रजिस्टर किया जा सकता है. साथ ही, इसे स्क्रिप्ट होस्ट करने वाले पेजों में डाला जा सकता है. आपकी स्क्रिप्ट को एम्बेड करने वाली वेबसाइटों को, ऑरिजिन ट्रायल के लिए अलग से टोकन रजिस्टर करने की ज़रूरत नहीं होती.
हालांकि, इसके लिए एक ज़रूरी शर्त है: ओरिजिन ट्रायल के लिए रजिस्टर करने वाला और कुकी जारी करने वाला, दोनों एक ही साइट के होने चाहिए. खास तौर पर, मुफ़्त में आज़माने की सुविधा के लिए रजिस्टर किया गया ऑरिजिन, जारी करने वाले डोमेन से मेल खाना चाहिए.
इस्तेमाल किया जा सकने वाला कॉन्फ़िगरेशन:
- जारी करने वाला डोमेन:
issuer.example - OT registrant:
https://issuer.example - JavaScript ऑरिजिन:
https://issuer.example(याhttps://app.issuer.example, जिसमें सबडोमेन मैचिंग की सुविधा होती है)
इस्तेमाल न किए जा सकने वाले कॉन्फ़िगरेशन:
- सबडोमेन रजिस्ट्रेंट: जारी करने वाला डोमेन
issuer.exampleहै, लेकिन ओटी रजिस्ट्रेंटhttps://app.issuer.exampleहै. - क्रॉस-साइट रजिस्ट्रेंट: जारी करने वाला डोमेन
issuer.exampleहै, लेकिन ओटी रजिस्ट्रेंटhttps://different.exampleहै.
ईवीटी में हैंडल kid की जानकारी देना ज़रूरी नहीं है
ईमेल की पुष्टि करने वाले टोकन (ईवीटी) की पुष्टि करते समय, आपका सर्वर
प्रोवाइडर के JSON वेब की सेट (जेडब्ल्यूकेएस) को फ़ेच करता है, ताकि जारी करने वाले के क्रिप्टोग्राफ़िक
हस्ताक्षर की पुष्टि की जा सके. कुंजियों में, kid कुंजी आइडेंटिफ़ायर शामिल होता है. यह JWT में भी शामिल होता है. इससे पता चलता है कि टोकन पर हस्ताक्षर करने के लिए किस कुंजी का इस्तेमाल किया गया था.
अगर टोकन में kid दावा शामिल नहीं है (उदाहरण के लिए, Gmail के साथ), तो सही कुंजी ढूंढने के लिए कुंजियों को दोहराएं. दस्तावेज़ और डेमो में, ऐसा करने के लिए कोड दिखाया गया है.
email दावे को ठीक उसी तरह वापस लाना जैसा उसे सबमिट किया गया था
Chrome के वर्शन 156 से, टोकन में मौजूद ईमेल पते को ठीक उसी तरह दिखाया जाएगा जिस तरह उसे फ़ॉर्म सबमिट करते समय दिया गया था. इसके बारे में ज़्यादा जानने के लिए, समस्या 549217427 देखें. पहले, जारी करने वाले लोग या कंपनियां, खाते का कैननिकल ईमेल पता दिखा सकती थीं. उदाहरण के लिए, फ़ॉर्म सबमिट करने के दौरान first.last@example.com मौजूद होने पर First.Last@example.com दिखाना. ध्यान दें कि रिटर्न किए गए ईमेल की तुलना करते समय, केस-इनसेंसिटिव (अक्षर छोटा या बड़ा होने से कोई फ़र्क़ न पड़ना) का इस्तेमाल करना हमेशा एक अच्छा तरीका होता है. इसलिए, इसमें कोई बड़ा बदलाव नहीं होना चाहिए.
सेवा देने वाली कंपनियों के अपडेट
ईमेल की सेवा देने वाली कंपनियों के लिए बदलाव.
email दावे को ठीक उसी तरह वापस लाना जैसा उसे सबमिट किया गया था
ईमेल की सेवा देने वाली कंपनी के लिए, यह ज़रूरी शर्त ज़्यादा सख्त है: अगर कंपनी, ईमेल को ठीक उसी तरह से वापस नहीं भेजती है जैसा कि उसे भेजा गया था, तो Chrome टोकन को अस्वीकार कर देगा. इससे, पुष्टि करने वाले ईमेल से पता चलने वाले डेटा के मुकाबले ज़्यादा डेटा का खुलासा नहीं होता. आने वाले ईमेल की पुष्टि करें. इसके लिए, साइन इन किए हुए उपयोगकर्ता के ईमेल पते से ईमेल पते को मैच करें. ऐसा उसी तरह करें जिस तरह ईमेल डिलीवर करने के लिए किया जाता है.
Sec-Fetch-Dest का नाम बदलकर email-verification किया जा रहा है
Chrome 154 से, टोकन जारी करने के अनुरोधों पर भेजे गए Sec-Fetch-Dest हेडर को अपडेट किया गया है. अब इसमें हाइफ़न का इस्तेमाल किया जाता है:
- Chrome 154 या इसके बाद के वर्शन:
Sec-Fetch-Dest: email-verification - Chrome 153:
Sec-Fetch-Dest: emailverification
इस बदलाव से, फ़ेच डेस्टिनेशन आइडेंटिफ़ायर को वेब प्लैटफ़ॉर्म के नाम रखने के नियमों के मुताबिक बनाया गया है. इसके बारे में जानने के लिए, समस्या 546618576 देखें.
अगर आपका इश्यू करने वाला एंडपॉइंट, Sec-Fetch-Dest हेडर की पुष्टि करता है (सीएसआरएफ़ और अनचाहे अनुरोधों से बचने के लिए ऐसा करना ज़रूरी है), तो email-verification को स्वीकार करने के लिए, अपनी जांच को अपडेट करें. ब्राउज़र रोल आउट के दौरान रुकावट से बचने के लिए, ट्रांज़िशन के दौरान दोनों वैल्यू स्वीकार करें.
रिसॉर्स और सुझाव
- दस्तावेज़: ईमेल पते की पुष्टि करने के बारे में खास जानकारी, पुष्टि करने वाले व्यक्ति के लिए गाइड, जारी करने वाले व्यक्ति के लिए गाइड
- लाइव डेमो: सत्यापन करने वाले का डेमो और जारी करने वाले का डेमो
- ऑरिजिन ट्रायल: ट्रायल के लिए रजिस्टर करें
- शिकायत करें: WICG रिपॉज़िटरी में फ़ाइल से जुड़ी समस्याएं या Blink>Identity>EVP कॉम्पोनेंट में Chromium की गड़बड़ियों की शिकायत करें.