Google открыл пробную версию Chrome для API проверки электронной почты, предложения WICG, которое позволяет браузеру подтверждать, что посетитель владеет введенным адресом электронной почты, не отправляя ни одного сообщения. Испытание началось с Chrome 150 для настольных компьютеров, при этом Gmail принял участие в качестве первого участвующего провайдера.
Идея заменяет привычный одноразовый код или волшебную ссылку. Сегодня пользователь вводит электронное письмо, уходит в свой почтовый ящик, копирует код и возвращается — переключение контекста, которое часто его теряет. В предложении используется трехсторонняя модель, в которой браузер находится между сайтом («верификатор») и поставщиком почтовых ящиков («эмитент»). Если пользователь уже вошел в систему своего провайдера, браузер незаметно извлекает подписанный токен и помещает его в форму, а сервер проверяет этот токен при отправке. Google отмечает, что эмитент никогда не узнает, какой сайт сделал запрос.
Для разработчиков реализация внешнего интерфейса довольно проста. Поле электронной почты требует подсказки для автозаполнения, а также скрытого ввода, содержащего одноразовый номер, привязанный к сеансу:
Более тяжелая работа выполняется на стороне сервера, где подпись токена сверяется с ключами провайдера. Фил Нэш из Resend, написавший пошаговое описание процесса, опубликовал пакет npm и пример Next.js для выполнения этого синтаксического анализа и проверки.
На Hacker News разработчик заявил, что «буквально нет худшего переключения контекста», чем переход к папке «Входящие» во время регистрации, и что проверка электронной почты стоила им «десятков, а может быть, сотен» регистраций, которые они так и не завершили. Другой отметил, что письма с подтверждением часто блокируются или фильтруются как спам, без видимой разницы между задержанными и потерянными сообщениями, поэтому их удаление — настоящая победа.
Один из комментаторов заявил, что требования о конфиденциальности неубедительны:
Усложняйте все, что работает.
Нет никакого преимущества.
«Конфиденциальность пользователя повышается, поскольку эмитент не узнает, какое веб-приложение отправляет запрос, поскольку запрос передается через браузер». В настоящее время каждое веб-приложение отправляет вам приветственное напоминание после проверки. (Без улучшения конфиденциальности пользователя)
Итак, мы получаем новый процесс, который ничего не решает, но все усложняет. (И сложное в долгосрочной перспективе помогает большому и вредит маленькому)
Не проверено, но похоже на черновик Google, который закрывает сеть.
Другой назвал слепоту эмитента к запрашивающему сайту «функциональной обязанностью», а не особенностью. Разработчики, которые полагаются на адреса каждого получателя, такие как name+site@example.comотметил, что поток по-прежнему вызывает откат, когда поставщик не может подтвердить эти псевдонимы. Другие сравнили его с FedCM, встраивающим примитивы идентификации в браузер, как это когда-то делали менеджеры паролей.
За пределами Chrome с зарегистрированной учетной записью Gmail сайты возвращаются к классическому электронному письму с подтверждением, а установленные службы проверки синтаксиса, MX и SMTP по-прежнему охватывают адреса, которые этот API не может.
Команды, уже тестирующие, должны отслеживать критические изменения. В октябрьском обновлении Chrome добавлены пробные версии Android и сторонних производителей в Chrome 154, переименованные в Sec-Fetch-Dest эмиссионная стоимость до email-verificationа из Chrome 156 возвращает электронное письмо точно так, как оно было отправлено. Руководства верификатора и эмитента отслеживают текущий контракт.
API проверки электронной почты остается экспериментальным предложением, которое сегодня лучше всего использовать в качестве постепенного улучшения, пока WICG собирает отзывы от сайтов, поставщиков и пользователей.
