ईमेल पते की पुष्टि करने से जुड़े अपडेट, अगस्त 2026

Rowan Merewood

पब्लिश करने की तारीख: 13 अगस्त, 2026, पिछली बार अपडेट करने की तारीख: 5 अक्टूबर, 2026

ईमेल की पुष्टि करने की सुविधा के लिए, ऑरिजिन ट्रायल Chrome 150 में शुरू हुआ. आपके सुझाव/राय के आधार पर, हमने कई समस्याओं को ठीक किया है और कुछ सुधार किए हैं. इस पोस्ट में, बदलावों के बारे में खास जानकारी दी गई है. साथ ही, यह बताया गया है कि आपको अपनी साइट या सेवा पर कौनसी कार्रवाइयां करनी चाहिए.

सबसे पहले, ईमेल पते की पुष्टि करने की सुविधा के बारे में खास जानकारी. ज़्यादा जानकारी के लिए, पहले किया गया एलान देखें. आम तौर पर, साइटों पर उपयोगकर्ता को साइन-अप, साइन-इन, खाता वापस पाने की सुविधा वगैरह के लिए ईमेल पता डालना होता है. इसके बाद, उसे अपने ईमेल पर जाकर मैजिक लिंक पर क्लिक करना होता है या ओटीपी पाना होता है. ईमेल पते की पुष्टि करने की सुविधा, इस तरीके से परतदार वृद्धि के तौर पर काम करती है. यह सीधे तौर पर ब्राउज़र में, ईमेल सेवा देने वाली कंपनी से ईमेल पते की पुष्टि करती है. इसके बाद, साइट को ब्राउज़र से एक टोकन मिलता है. साइट, ईमेल सेवा देने वाली कंपनी से इस टोकन की पुष्टि कर सकती है. इससे, साइट को वह ईमेल भेजने की ज़रूरत नहीं पड़ती.

उपयोगकर्ताओं के लिए उपलब्ध अपडेट

यूज़र इंटरफ़ेस या उपयोगकर्ता के सामने दिखने वाले व्यवहार में बदलाव.

ईमेल पता डालना

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

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

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

अगर इससे कोई समस्या होती है या आपको कोई अनचाहा व्यवहार दिखता है, तो बग की शिकायत करें.

सिर्फ़ डेस्कटॉप

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

पुष्टि करने वाले के लिए अपडेट

ईमेल पते इकट्ठा करने और उनकी पुष्टि करने वाली साइटों के लिए बदलाव.

टोकन की पुष्टि करना

ईमेल पते की पुष्टि करने वाला टोकन, JSON वेब टोकन (एसडी-जेडब्ल्यूटी) के लिए चुनिंदा डिसक्लोज़र फ़ॉर्मैट में दिया जाता है. यह इस तरह दिखता है. इसमें, हस्ताक्षर करने वाले व्यक्ति या कंपनी का JWT होता है. इसके बाद, ज़ाहिर की गई जानकारी होती है. आखिर में, कुंजी बाइंडिंग वाला JWT होता है. हर कॉम्पोनेंट को टिल्ड से अलग किया जाता है:

<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>

ईमेल पते की पुष्टि करने वाला टोकन, मौजूदा फ़ॉर्म में सिर्फ़ जारी करने वाले के हस्ताक्षर वाला JWT और कुंजी बाइंड करने वाला JWT दिखाता है. इसमें कोई भी जानकारी शामिल नहीं होती. ओरिजनल ब्लॉग पोस्ट और डेमो के पहले वर्शन में, टोकन को सिर्फ़ दो हिस्सों में बांटा जा रहा था और दो JWT को पार्स किया जा रहा था. यह कमज़ोर है और अगर आने वाले समय में चुनिंदा खुलासे जोड़े जाते हैं, तो यह काम नहीं करेगा.

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

तीसरे पक्ष की ऑरिजिन ट्रायल

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

केस-इनसेंसिटिव ईमेल की तुलना

ईमेल सेवा देने वाली कंपनियां, कैननिकल ईमेल पते को बड़े अक्षरों में दिखा सकती हैं. उदाहरण के लिए, Demo.User@example.com. भले ही, फ़ॉर्म में demo.user@example.com दिया गया हो. पक्का करें कि आपको मिले ईमेल पते की तुलना करते समय, केस-सेंसिटिविटी का ध्यान न रखा गया हो. हमने सेटिंग पेज में मौजूद एक गड़बड़ी को भी ठीक कर दिया है. इस गड़बड़ी की वजह से, आपको एक ही ईमेल पते के अलग-अलग वर्शन दिख सकते थे.

सेवा देने वाली कंपनियों के अपडेट

ईमेल की सेवा देने वाली कंपनियों के लिए बदलाव.

अनुरोध जारी करने के लिए एचटीटीपी मैसेज सिग्नेचर

हम Chrome 153 में एक बड़ा बदलाव कर रहे हैं. इसके तहत, सर्टिफ़िकेट जारी करने का अनुरोध सिर्फ़ application/json फ़ॉर्मैट में email भेजेगा. साथ ही, इसमें एचटीटीपी मैसेज सिग्नेचर शामिल होंगे.

• Chrome 152 (और इससे पहले के वर्शन): जारी करने वाले एंडपॉइंट को, बॉडी में request_token के साथ application/x-www-form-urlencoded POST अनुरोध मिलता है.
• Chrome 153 (और इसके बाद के वर्शन): कॉन्टेंट टाइप application/json में बदल जाता है. इसमें Signature, Signature-Input, और Signature-Key हेडर होते हैं. साथ ही, इसमें सिर्फ़ email कुंजी वाला मुख्य हिस्सा होता है.

टेस्टिंग के दौरान ट्रैफ़िक के मौजूदा लेवल और लक्ष्यों के आधार पर, इनमें से कोई एक काम किया जा सकता है:

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

डेमो कोड में मौजूद, टोकन जारी करने वाले एंडपॉइंट को अपडेट कर दिया गया है. इससे structured-headers और http-message-sig का इस्तेमाल करके, दोनों फ़्लो को मैनेज किया जा सकेगा.

अनुरोध का पूरा फ़ॉर्मैट:

POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"

{email: "demo@example.com"}

जवाब का फ़ॉर्मैट पहले जैसा ही रहता है: application/json बॉडी में issuance_token.

प्रस्तावित रिपॉज़िटरी के बारे में पढ़ें और ज़्यादा फ़ीडबैक दें: WICG/email-verification और dickhardt/email-verification. अब तक कम्यूनिटी से मिले सुझाव/राय हमारे लिए बहुत मददगार रहे हैं. इसलिए, आपको अपडेट और सुधार मिलते रहेंगे.