Изменения в процессе подтверждения адреса электронной почты (октябрь 2026 г.)

Rowan Merewood

Дата публикации: 5 октября 2026 г.

Мы продолжаем тестировать подтверждение адреса электронной почты и внесли в него изменения на основе ваших отзывов. Мы не ожидаем дальнейших критических изменений и готовимся к выпуску этой функции. Мы также запустили новый раздел документации для подтверждения адреса электронной почты с отдельными разделами для проверяющих и издателей.

Эксперимент с источником для подтверждения адреса электронной почты начался в Chrome 150 на компьютерах. Мы продолжаем совершенствовать реализацию, опираясь на отзывы разработчиков и результаты тестирования в экосистеме. В этой статье рассказывается об изменениях в Chrome 154, в том числе о поддержке Android, пробных версиях для сторонних источников, обработке обнаружения ключей во время проверки токенов и обновлении заголовка для поставщиков услуг электронной почты.

Изменения для пользователей

Изменения пользовательского интерфейса или поведения, видимого пользователям.

Поддержка Chrome на устройствах Android

Начиная с Chrome 154, Chrome для Android поддерживает подтверждение адреса электронной почты. Проверять или предоставлять данные не нужно, поскольку API и протокол не изменились. При этом действуют те же требования, в том числе пользователь должен войти в аккаунт поставщика услуг электронной почты в браузере.

Чтобы посмотреть настройки, нажмите Настройки > Адреса и другое > Подтвержденный адрес электронной почты.

Изменения в работе проверяющих

Изменения для сайтов, которые собирают и проверяют адреса электронной почты.

Эксперименты с источником сторонних разработчиков

В Chrome 154 добавлена поддержка сторонних пробных версий для подтверждения адреса электронной почты (см. проблему 534377131). Если вы используете встроенный скрипт или SDK для идентификации, то можете зарегистрироваться для получения пробного токена стороннего сервиса и внедрить его в страницы, на которых размещен ваш скрипт. Сайтам, встраивающим ваш скрипт, не нужно регистрировать отдельные токены эксперимента с источником.

Важно помнить, что регистрант эксперимента с источником и эмитент должны быть на одном сайте. В частности, источник, зарегистрированный для эксперимента, должен совпадать с доменом издателя.

Поддерживаемая конфигурация

  • Домен издателя: issuer.example
  • Регистратор OT: 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 в том виде, в котором она была предоставлена.

Начиная с 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 (рекомендуется для защиты от CSRF и нежелательных контекстов запросов), измените проверку, чтобы она принимала email-verification. Чтобы избежать перебоев при развертывании браузеров, примите оба значения во время перехода.

Где ещё можно найти информацию по теме и как связаться с нами