Görsel: Gezdiren için özgün editoryal çalışma.
Bir üyelik formuna e-posta yazınca çoğu kişi aynı küçük kopuşu yaşıyor: sayfadan ayrıl, posta kutusunu aç, kodu bul, geri dön. Chrome'un deneme aşamasındaki Email Verification özelliği bu kopuşu kısaltmayı amaçlıyor. Tarayıcı, kullanıcının oturum açtığı e-posta sağlayıcısından doğrulama alıyor; siteye imzalı bir doğrulama belirteci veriliyor. Böylece kayıt, giriş, hesap kurtarma ya da ödeme sırasında gelen kutusuna sıçrama gerekmeyebiliyor.
Bu, e-posta adresinin siteye verilmediği bir düzen anlamına gelmiyor. Adres formda yine yazılıyor. Değişen nokta, sitenin bu adresin denetlendiğini kanıtlamak için kendi gönderdiği bağlantıya veya tek kullanımlık koda daha az ihtiyaç duyması. Chrome'un açıklamasına göre özellik Chrome 150'den beri deneme programında; Chrome 154'le Android'e de geldi. Kullanıcı, tarayıcıda ilgili e-posta sağlayıcısında oturum açmış olmalı. Bu sınır, ilk bakışta pürüz gibi görünebilir. Aslında hangi hesabın bu doğrulamada devreye girdiğini saklamıyor.
Teknik ayrıntı burada güven meselesine dönüşüyor. Site, tarayıcıdan aldığı tokenı e-posta sağlayıcısının anahtarlarıyla doğruluyor. Sağlayıcı da formdaki adresi aynen döndürmek zorunda; aksi halde Chrome tokenı kabul etmiyor. Bu kural, kullanıcının yazdığı adres ile sağlayıcının hesap içindeki başka bir yazımını birbirine karıştırmamak için var. E-posta karşılaştırmasının sunucuda büyük-küçük harfe duyarsız yapılması gerektiği uyarısı da aynı nedenle önemli. Kimlik akışında küçük bir normalleştirme tercihi, destek ekibinin önüne "adresim kabul edildi ama hesabım neden açılmadı" sorusunu bırakabilir.
Yeni düzen, e-posta sağlayıcısına da daha belirgin bir rol veriyor. Sağlayıcının doğrulama uçlarını DNS ve `.well-known` üzerinden tanıtması gerekiyor. Bu yüzden formdaki tek bir alan, sitenin arka ucu, tarayıcı ve sağlayıcının yapılandırması arasında çalışan bir zincire bağlanıyor. Bir kimlik kütüphanesi kullanan siteler için üçüncü taraf deneme tokenı desteği işi kolaylaştırabilir; yine de tokenı kaydeden alan ile doğrulama yapan sağlayıcının aynı site sınırında kalması isteniyor. Kütüphane, başka bir alan adına ait sağlayıcı adına token kaydedemiyor.
Burada geliştiricinin önündeki görev, "doğrulandı" işaretini eklemekten daha geniş. Form, tarayıcının doğrulamayı başlatıp bitirmesini anlaşılır biçimde göstermeli. Sağlayıcı desteklemiyorsa, kullanıcı oturum açmamışsa veya token sunucuda doğrulanamazsa eski e-posta bağlantısı ya da kod adımı çalışmalı. Bu yollar yoksa, desteklenmeyen tarayıcıdaki kullanıcı kayıt ve hesap kurtarma işlemini tamamlayamaz.
E-posta doğrulamasının kıymeti, posta kutusuna daha az bakmakta. Fakat kullanıcı için iyi deneyim, arka plandaki imzanın tek başına doğru olmasıyla oluşmuyor. Hangi hesabın devrede olduğu, adresin nasıl eşleştiği ve tarayıcı zinciri kuramadığında ne yapılacağı ekranda ve sunucuda birlikte düşünülmeli. Form, doğrulama beklerken durumu göstermeli; başarısızlıkta da kullanıcıyı e-posta bağlantısı veya kod seçeneğine yönlendirmeli.