עדכונים באימות כתובות אימייל, אוקטובר 2026

Rowan Merewood

פורסם: 5 באוקטובר 2026

אנחנו ממשיכים את גרסת המקור לניסיון של אימות כתובות אימייל, וביצענו עדכונים נוספים על סמך המשוב שלכם. אנחנו לא צופים שינויים נוספים שעלולים לשבור את התאימות לאחור, ואנחנו מתכוננים להשיק את התכונה. השקנו גם קטע חדש של תיעוד לאימות כתובות אימייל, עם קטעים ייעודיים למאמתים ולמנפיקים.

גרסת המקור לניסיון של אימות כתובת האימייל התחילה ב-Chrome 150 במחשב. בעקבות משוב ממפתחים ובדיקות שערכנו במערכת האקולוגית, אנחנו ממשיכים לשפר את ההטמעה. בפוסט הזה נסביר על העדכונים מ-Chrome 154, כולל תמיכה ב-Android, תקופות ניסיון של מקורות צד שלישי, טיפול בגילוי מפתחות במהלך אימות טוקנים ועדכון של כותרת לספקי אימייל.

עדכונים שגלויים למשתמשים

שינויים בממשק המשתמש או בהתנהגות שגלויים למשתמשים.

תמיכה ב-Chrome ב-Android

החל מגרסה 154 של Chrome, ‏Chrome ל-Android תומך באימות כתובת אימייל. מאמתים או ספקים לא צריכים לבצע שינויים כי ה-API או הפרוטוקול נשארים זהים. אותם תנאים מוקדמים חלים גם כאן, כולל הדרישה שהמשתמש צריך להיות מחובר לספק האימייל שלו בדפדפן.

המשתמשים יכולים לגשת להגדרות שלהם בקטע הגדרות > כתובות ועוד > אימייל מאומת.

עדכונים לגבי הגורם המאמת

שינויים באתרים שבהם נאספות ומאומתות כתובות אימייל.

תקופות ניסיון של תכונות ממקורות צד שלישי

החל מ-Chrome 154, יש תמיכה בניסויים של מקורות צד שלישי לאימות כתובות אימייל (ראו בעיה 534377131). אם אתם מספקים סקריפט מוטמע או SDK של זהות, עכשיו אתם יכולים להירשם לקבלת אסימון ניסיון של צד שלישי ולהחדיר אותו לדפים שמארחים את הסקריפט שלכם. אתרים שבהם מוטמע הסקריפט שלכם לא צריכים לרשום טוקנים נפרדים לגרסת מקור לניסיון.

חשוב לדעת: הנרשם לניסיון המקור והמנפיק צריכים להיות באותו האתר. באופן ספציפי, המקור שרשום לניסיון חייב להיות זהה לדומיין של המנפיק.

הגדרה נתמכת:

  • דומיין המנפיק: issuer.example
  • OT registrant: https://issuer.example
  • מקור JavaScript: https://issuer.example (או https://app.issuer.example עם התאמה לתת-דומיין)

הגדרות שלא נתמכות:

  • רושם של תחום משנה: דומיין המנפיק הוא issuer.example, אבל רושם ה-OT הוא https://app.issuer.example.
  • רושם באתרים שונים: דומיין המנפיק הוא issuer.example, אבל הרושם של ה-OT הוא https://different.example.

כינוי אופציונלי kid ב-EVT

כשמאמתים את אסימון אימות האימייל (EVT), השרת מאחזר את קבוצת מפתחות האינטרנט מסוג JSON‏ (JWKS) של הספק כדי לאמת את החתימה הקריפטוגרפית של המנפיק. המפתחות יכולים לכלול מזהה מפתח kid, שגם הוא יכול להיכלל ב-JWT כדי לציין באיזה מפתח נעשה שימוש לחתימה על האסימון. אם האסימון לא כולל את טענת kid (לדוגמה, ב-Gmail), צריך לחפש את המפתח הנכון בין המפתחות. במסמכים ובהדגמה מופיע הקוד לביצוע הפעולה.

החזרת התלונה email בדיוק כפי שסופקה

החל מגרסה 156 של Chrome, כתובת האימייל באסימון תוחזר בדיוק כמו שהיא סופקה בהגשת הטופס (ראו בעיה 549217427). בעבר, יכול להיות שהנפיקים החזירו את כתובת האימייל הקנונית של החשבון (לדוגמה, החזרה של First.Last@example.com כששליחת הטופס כללה את first.last@example.com). חשוב לציין שתמיד מומלץ להשתמש בהשוואה לא תלוית-רישיות באימייל המוחזר, כך שזה לא אמור להיות שינוי שובר.

עדכונים מספקים

שינויים לספקי אימייל.

החזרת התלונה email בדיוק כפי שסופקה

מצד הספק, הדרישה הזו מחמירה יותר: אם הספק לא מחזיר את האימייל בדיוק כפי שהוא סופק, Chrome ידחה את האסימון. כך לא נחשפים יותר נתונים מאלה שנחשפים בשליחת אימייל אישור. צריך לאמת את האימייל הנכנס מול המשתמש שמחובר לחשבון כדי למצוא התאמה, באותו אופן שבו מטפלים במסירת אימייל.

שינוי השם של Sec-Fetch-Dest לemail-verification

החל מגרסה 154 של Chrome, הכותרת Sec-Fetch-Dest שנשלחת בבקשות להנפקת טוקנים עודכנה כך שנעשה בה שימוש במקף:

  • ‫Chrome 154 ואילך: Sec-Fetch-Dest: email-verification
  • ‫Chrome 153: Sec-Fetch-Dest: emailverification

השינוי הזה יוצר סטנדרטיזציה של מזהה יעד השליפה בהתאם למוסכמות השמות של פלטפורמת האינטרנט (ראו בעיה 546618576).

אם נקודת הקצה של הנפקת הכרטיס מאמתת את הכותרת Sec-Fetch-Dest (מומלץ כדי להגן מפני CSRF והקשרים לא מכוונים של בקשות), צריך לעדכן את הבדיקה כך שתקבל email-verification. כדי למנוע שיבושים במהלך השקת הדפדפן, כדאי לאשר את שני הערכים במהלך המעבר.

מקורות מידע ומשוב