Brave в версии 1.94 встроил в браузер почтовые алиасы Brave: теперь при регистрации на новом сайте можно сгенерировать одноразовый адрес вместо основного ящика. Для пользователя это мелочь на уровне формы входа, а для рынка приватности вполне заметный ход: браузер пытается перекрыть не куки и не отпечатки устройства, а куда более скучный и потому опасный идентификатор — обычный email.
О нововведении сообщает BleepingComputer. Сценарий простой: сайт получает не ваш реальный адрес, а алиас, письма при этом пересылаются в основной ящик. Идея не новая сама по себе, похожие механики давно есть у почтовых сервисов и у Apple через Hide My Email, но здесь важен именно формат доставки: функция приехала прямо в браузер, то есть ближе к моменту, когда пользователь оставляет контакт на форме регистрации, подписки или покупки.
Brave давно строит продукт вокруг изоляции данных между сайтами. Браузер уже разделяет куки, кэш и сетевое состояние так, чтобы один сайт не мог слишком легко узнать пользователя по следам, оставленным на другом. Но email до сих пор выпадал из этой схемы: адрес хранится уже не в браузере, а на стороне сервиса, а дальше спокойно гуляет по CRM, рекламным кабинетам, партнерским интеграциям и, в худшем случае, по базам после утечки. В этом смысле почтовые алиасы Brave закрывают довольно прозаичную, но очень реальную дыру в приватности: даже если фронтенд у вас чистый, трекинг может продолжаться на серверной стороне через сопоставление email-адресов.
Именно этот момент делает релиз интересным не только для обычных пользователей, но и для разработчиков, продактов и маркетинга. Большая часть браузерной войны последних лет крутилась вокруг third-party cookies, fingerprinting и рекламных идентификаторов. Однако adtech давно умеет жить не только ими. Если компания получает email при регистрации, она может связать его с профилями в системах Meta, Google или LinkedIn через server-side matching. То есть браузер заблокировал пиксель, а бизнес все равно восстановил цепочку через адрес почты, который пользователь сам и ввел. Brave фактически говорит: если приватность заканчивается на форме sign-up, то вся предыдущая защита уже не так впечатляет.
У функции есть и вполне земное антисапм-назначение. Brave прямо привязывает запуск алиасов к рискам после взломов: если сервис, где вы регистрировались, утечет, в оборот попадет не основной email, а отдельный адрес, который можно отключить. Это снижает объем спама и затрудняет фишинг, особенно тот, что приходит месяцами после старого инцидента и очень любит играть на узнаваемых брендах. Бесплатно дадут до пяти алиасов, позже компания планирует платную Premium-версию без этого лимита. Тут без сюрпризов: почтовая пересылка стоит денег, а приватность как подписка давно стала отдельной строкой в P&L подобных сервисов.
Чтобы все это заработало, пользователю нужен бесплатный Brave Account и основной email, на который будут пересылаться письма. Это отдельная сущность, не связанная с Brave Premium. Для аутентификации Brave использует OPAQUE — стандартизованный протокол password-authenticated key exchange из RFC 9807. Компания подает это как способ не отправлять на сервер ни сам пароль, ни его хэш. На практике это не серебряная пуля и не отмена слабых паролей или фишинга, но архитектурно решение здравое: меньше чувствительных данных на сервере — меньше последствий, если кто-то полезет смотреть дампы, логи или утекшую базу. Для продукта, который продает приватность не баннером, а инфраструктурой, это уже не маркетинговая косметика, а обязательный минимум.
Brave отдельно подчеркивает, что основной адрес и сами алиасы хранятся в зашифрованном виде, а письма не анализируются за пределами автоматической фильтрации спама и вредоносных вложений. После доставки сообщения удаляются с серверов в течение секунд. Заметки к алиасам остаются локально на устройстве, а при синхронизации через Brave Sync шифруются end-to-end. Но есть и менее глянцевая деталь: компания предупреждает, что на старте часть пересылаемых писем может попадать в спам, пока новый почтовый отправитель набирает репутацию. И вот это уже хороший маркер зрелости релиза: настоящие инфраструктурные функции почти всегда начинаются не с магии, а с настройки доставляемости и борьбы за доверие почтовых систем.
Для российского и в целом русскоязычного IT-рынка здесь важен не только сам релиз, но и направление. Браузеры все чаще лезут туда, что раньше считалось зоной почтовиков, менеджеров паролей и identity-сервисов. Для разработчиков это еще один сигнал: если продукт завязан на email как на универсальный пользовательский идентификатор, качество этих данных будет падать. Для бизнеса это неудобная, но логичная реальность: пользователи и платформы последовательно режут наблюдаемость. А для команд, которые строят онбординг, retention и антифрод, это повод заранее думать, как жить в мире, где адрес почты все хуже подходит на роль «сквозного ключа» между сайтами, устройствами и рекламными кабинетами. Подробности релиза собраны в материале ; главный вопрос теперь не в том, приживутся ли такие инструменты, а в том, сколько еще привычных идентификаторов браузеры попробуют выбить из рук adtech и growth-команд.