Your Email Address Is a Tracking Cookie You Cannot Clear. Brave Wants to Replace It
Brave has added email aliases to its desktop browser. The feature creates a different forwarding address for each service, reducing the need to expose a primary email address that can be leaked, spammed and reused to correlate activity across sites.
The comparison to a tracking cookie is deliberate but incomplete. An email address is a durable identifier that people often reuse for years. Clearing browser storage does not change it. An alias breaks some of that reuse, but it does not make the user anonymous.
Why email addresses became identity infrastructure
Websites use email addresses for login, password recovery, marketing, fraud controls and customer support. Data brokers and advertisers can also use a normalised or hashed address to connect records collected in different contexts.
That persistence is valuable to legitimate services and attackers. When one company is breached, the address can be tested elsewhere, used for phishing or combined with other leaked data. Changing a primary email address is far more disruptive than deleting a cookie.
How Brave Email Aliases works
Brave 1.94 for desktop can generate an alias when a site asks for an email address. Messages sent to that alias are forwarded to the user’s primary inbox.
A different alias can be used for each service. If one address begins receiving spam or appears in a breach, the user can disable that alias without abandoning the primary inbox or changing accounts elsewhere.
Brave says the feature is integrated into the browser and uses a Brave account. That account requires an email address and password, so the service introduces its own trust relationship rather than eliminating trust.
The privacy gain is compartmentalisation
Unique aliases reduce direct cross-site correlation through a reused address. A retailer, forum and newsletter no longer need to see the same identifier.
They also improve breach scoping. If a message arrives at an alias created for one service, the user has a strong clue about which relationship produced the address or where it was later shared.
This is similar to using unique passwords. The goal is not secrecy from every provider. The goal is to prevent one identifier from becoming a universal key.
What aliases do not hide
The destination service still knows the alias it received. Brave’s forwarding infrastructure processes messages in order to deliver them. The user’s network address, device signals, payment details and account behaviour may still support identification or correlation.
An alias also cannot protect information voluntarily placed in a message or account profile. If the same name, phone number and card are reused, changing the email field addresses only one part of the identity graph.
Security and availability questions
Forwarding becomes part of the account-recovery path. If the alias service is unavailable, messages containing login links or recovery codes may be delayed. Users should understand how aliases are exported, recovered and disabled before relying on them for critical accounts.
Organisations should also consider whether aliases conflict with identity, compliance or fraud processes. Blocking all aliases is a blunt response. It can push users back toward more exposed identifiers without proving the person behind the account is more trustworthy.
Practical use
- Use a unique alias for each service rather than one alias everywhere.
- Keep the primary mailbox protected with a unique password and phishing-resistant multi-factor authentication.
- Record which alias belongs to which service so unexpected mail can be investigated.
- Test recovery flows before using an alias for a critical financial or administrative account.
- Disable an alias when it is abused, but also change the affected service’s password and review its security.
- Do not treat the alias as protection against device fingerprinting, payment correlation or legal identification.
The BlackTree view
Email became a universal identifier because it was convenient, not because it was designed to be a privacy boundary. Every reuse turns a contact address into a correlation point that survives ordinary browser controls.
Brave’s feature applies a security principle that already works elsewhere: give every relationship a separate credential. The benefit is not invisibility. It is containment when one site leaks, sells or misuses the address.
Sources
- Brave Privacy Updates: Email Aliases, published 27 August 2026. The primary page provides a date but no publication time.
- Brave release notes, including desktop version 1.94.117 released 27 August 2026. The release page provides a date but no publication time.
