Brave ships email aliases: stop keying customers on email

Brave shipped built-in email aliases in desktop version 1.94 on August 27. Click an email field on any signup form, pick "New Email Alias," and the site gets a throwaway forwarding address instead of the customer's real inbox. Five aliases free, no extension, no separate service to sign up for. If you run a store, a booking system, or anything with a customer list, the useful question is not whether this is good privacy. It is what breaks when the email address stops being a stable identifier.

What actually happened

Per Brave's own privacy update, Email Aliases is wired into the browser's autofill layer — the same place that already fills your name and card. Generate an alias from the email field or the right-click menu, manage the list under Autofill & Passwords, and switch off any single address the moment it starts pulling spam. Brave forwards the mail, runs standard spam filtering, and says it does not read message contents, deleting them from its servers within seconds of forwarding.

The feature rides on a new Brave Accounts system built on OPAQUE, a password-authenticated key exchange in which the password never leaves the device. Brave says a Premium tier is planned and mobile support is in progress. Everyone gets five aliases at launch.

TechCrunch framed it as Brave one-upping Chrome, and that framing is the part that matters to you. Apple has had Hide My Email since 2021, Firefox has Relay, DuckDuckGo has Duck Addresses. Those were opt-in products people had to go find. This is a default surface in a mainstream browser, at the exact moment of signup.

Why aliased email breaks your customer data

Most small-business stacks treat email as the primary key. Shopify customer records, your CRM dedupe rule, your abandoned-cart trigger, your loyalty lookup, your "have we seen this person before" check — all of it usually resolves on the email string. Aliases quietly turn that key into a per-site random value that the customer can revoke without telling you.

Three concrete failure modes:

Dedupe stops working. The same human buys twice, once in Safari with Hide My Email and once in Brave with an alias, and you now have two customers, two lifetime-value numbers, and two segments. Any repeat-purchase metric you report is understated.

Bounce rates climb. A revoked alias is not a soft bounce that recovers. It is a dead address that keeps getting mailed by every automation you built. Enough of those and your sending domain's reputation degrades for everyone on the list, including the customers who gave you real addresses.

Identity-gated features get weird. Anything that says "we found an existing order for this email" — order lookup, warranty registration, returns portals — fails for the customer who used an alias last time and a different one today.

What to do about it: stop using email as your join key. Issue an internal customer ID at first touch and hold it in a first-party cookie or account record. Add a second matching signal you actually control — phone, order number, shipping address hash. Prune hard bounces aggressively rather than letting automations retry dead aliases for months. And when you gate something behind email verification, remember that a verified alias proves the person controls a forwarder, not that you can reach them next quarter.

None of this is a reason to fight the feature. Customers giving you a working forwarding address instead of a fake one is an improvement. Your data model just has to stop pretending the string is the person.

Sources: Brave Privacy Updates, TechCrunch.