Huge! Well done to the Bitwarden team for this first class support of digital identity compartmentalization, although a bit more improvement to be made to reduce friction on the user side for plugging in alias providers (pop up to login to retrieve an API token behind the scenes vs the API token copy paste dance, with login creds Bitwarden might be storing already).
Edit: Is there a standard or API spec perhaps across email alias services for generating, listing, managing, and invalidating aliases?
(happy paying bitwarden customer, no other affiliation)
It's been like this for years. However, with one of my own domains and a catch all rule in the e-mail server. Why? From time to time, some services require that you send emails with exactly this e-mail address as the sender. And that doesn't just work with most services. Because in such a case, you have to turn exactly this e-mail address into a real account with a mailbox.
For me, the value of using aliases on my own domain isn't anonymity, it's provenance; I can tell where my email was obtained from based on the the prefix used. If I get an email sent to git@<domain>, I know that someone (or something) was looking at git logs to get it, if it's sent to resume@<domain>, I know someone got it from my resume, etc.
Pretty much my exact same reason, plus the separation of concerns concept. If a service got breached and that email leaked, I don’t have to worry about using that email to brute force other services.
I'm not sure if the comment I replied directly to got deleted or if I accidentally replied to the wrong thread or something, but for some reason I thought I had replied about provenance specifically in response to a comment saying that separate prefixes didn't provide anonymity. Using a custom domain is mostly a fun novelty for me, and if separate prefixes didn't provide any value, I'd still just use use a single prefix on my custom domain because I like it.
Spammers who just blast stuff out won't do it, I'm sure.
But as a counterpoint it literally happened to me to me years ago when I used to use name+<service>@exmaple.com. I got cold emails to 'name+paypal' despite never, ever having used that localpart. I've no doubt it was absolutely targetted and not a hit-and-hope spamblast but it was enough of a wake-up call for me to realise it couldn't really be relied on.
I’ve been doing this for years and have never had any problems with it. It is more likely that generic emails will be generated if you have a domain that is also present as a public website on the internet.
Why would they want to spend effort trying to brute-force addresses to show me emails that they already have the ability to sent to me and I didn't generate them any revenue from?
No idea, just pointing out it is such an obvious alg it doesn't really show provenance.
I used similar (well, plus addressing with localpart=name+<service>) a long time ago and once got emails to name+paypal@example.com even though that was a suffix I'd never used. Some enterprising person out there had obviously obtained one or more of my service-specific addresses and was trying to game my attention by changing the identifier to something 'important'. That's when I personally ditched the approach.
"Provenance" might be have been a bit too strong; maybe I should have said "strong signal". It's an additional piece of info that will almost always identify the source, but in the rare exceptions it's not any worse than if I just used a single address for anything.
In principle, someone seeing heido15wkj6@yourraredomain.com, yua16ooaaj2@yourraredomain.com, and kqoq91inhi4@yourraredomain.com in a dump might be able to infer that all of these belong to the same user with a catchall address (especially if they can verify that the domain is unpopular via dns caching or other tricks). Using a common service adds another partial layer of anonymity between the email addresses, making one harder to track.
Especially necessary when your domain is your full name. It's painfully obvious that all addresses under the domain belong to a single person. I've been using Fastmail's masked email service for a while to hide my personal domain. And before that I had a handful of gmail addresses that I set to forward to my main address.
Theoretical yes. But never had that. It is more likely that generic, non existant emails like info@domain.com, admin@domain.com, etc. will be generated if you have a domain with a public website.
AFAIK Fastmail is the only service that allows you to respond from an arbitrary email address (of course, provided that you prove that you own the domain).
You can do it in Office 365 but it's tedious, you have to add the alias and then you can email from it.
Not necessarily. You can for example configure both Thunderbird and mailcow to allow you to reply from any address (of the domains you manage, of course), without having to create the mailbox.
That’s great, but there’s a caveat. When I normally create a random email with my own domain as a username, I am not tied to a specific service. I can always migrate to another one without having to take any action. However, if I used this with Fastmail, for example, the generated emails are with fastmail.com or similar domains that aren’t under my control. If I wanted to migrate in the future, I would have to redo all of these randomly generated emails.
It's an important consideration; email sovereignty is at odds with a domain hosting relay aliases where you can blend in with everyone else. Perhaps the solution is a mechanism where you can migrate aliases between services, creating new aliases and updating at each service, and invalidating old aliases, all programatically. Somewhat similar to token and secret rotation. It's just a string identifier that can be an email target.
Or maybe having an option to generate aliases using my own domain. I don’t mind exposing my domain or even creating a new domain only for this purpose, say @aliasdomain.com. That way, I am still in full control and utilizing the generated aliases.
As mentioned somewhere in this thread, using a custom domain poses other risks, in some cases more significant. All your aliases will be forever tied to your identity (and potentially de-anonymized by a single leak).
> All your aliases will be forever tied to your identity
A separate domain can be used if really needed. But even with using my own domain, I don’t see it as a problem. After all, emails are not anonymous, and a leak with an alias with a custom domain is still meaningless and doesn’t affect other services.
Most domain registrars require providing identity details. Even if these details are private, a single leak or a config mistake on this domain will expose your real identity, tied to all aliases. With an alias service or a shared email provider you don't have this risk as you don't have to provide your real-life identity.
So while it's tempting to use one random alias (h3hj4gjh234@yourdomain.com) for a high-risk service and another alias for a critical service (github@yourdomain.com), these aliases are easily identifiable as belonging to the same person.
Ah, this is nice. It brings the Apple Hide My Email functionality (though not compatibility) to all platforms, which is something I do desire since using Hide My Email makes non-Apple platforms unusable for logins.
Why would using Apple's Hide My Email functionality make non-Apple platforms unusable for logins? If you're storing these credentials in a cross-platform password manager like Bitwarden, you should be able to enter your (fake) email address and password anywhere to sign in.
Oh this is funny to see. I just posted a blog post talking about Email Aliases an hour ago without knowing about the Bitwarden announcement.
I would love to see aliases being promoted more and more by companies. In the end most companies want to get in touch with you via e.g. a newsletter. So why do they need exactly your private email and not just an email alias. In the end they're reaching the same person.
They don't want to send you a newsletter. They want to get you to click a unique, personalized tracking link so they can drop a cookie in your browser and start tracking everything you do and tying it back to a single, named identity in their contacts database that they can then try to extract money from.
Is this really a problem people have? I personally just use some free mail account for all low-priority stuff without push notifications enabled in my client apps.
Also, when it is clear someone is abusing the email you provided, you can nuke it. Perhaps some functionality to be had here between aliases and haveibeenpwned detecting an alias in a breach, queuing for alias cycling or invalidation with a human approval step.
This seems to just generate a random string to go with whatever domain I have set. Personally I prefer my email aliases to be of the form `<business_name>@<my_domain>` or `<website_domain>@<my_domain>`. That way if you do start getting unsolicited email it is crystal clear who is spamming you (or has sold/leaked your data).
In fact, given it seems to just put a random string in front of a domain name you give it I'm a little curious as to why they need your API key at all - is it just to ensure that you are not creating duplicate email aliases?
Needs your API key as it needs to access the email forwarding service which you want to use with it.
It's not just making up a bullshit address, it's generating a random localpart then going to the email forwarding service you've integrated and having that service create an email forward to your real address per whatever settings you have there.
Any email sent to the address it generates (signup confirmations, password resets etc) need to get to you, after all.
This design is completely different to using <business>@example.com. The latter is kind of useful for your use of 'who has sold my address' but has privacy drawbacks this design doesn't. e.g. if a spammer gets bestbuy@exmaple.com they know you prob also have twitter@exmaple.com, facebook@exmaple.com or whatever else and it's all just the same guy with the same inbox.
Truly 'random' addresses at generic forwarding services means that if Ashley Maddison gets breached again then your secret remains safe. sj4h3bd@forwarder.net could be anyone.
> It's not just making up a bullshit address, it's generating a random localpart then going to the email forwarding service you've integrated and having that service create an email forward to your real address per whatever settings you have there.
Fair enough - the one I use automatically creates an alias whenever it receives an email at the relevant domain so there's no need to manually create one, I assumed the other services were the same.
It depends on the alias service you use (this appears to just give you another frontend to your alias service, eg, Addy.io or Firefox Relay). I know with Addy.io, forwarded emails have a special "Reply-To" header which is an address that Addy.io monitors and will forward your response back to the original sender. So replying to email delivered to your alias isn't a problem, though I think initiating an email from an alias would be tricky.
It’s possible to initiate from Addy as well. For example, if your Addy alias is example@mailer.me and you wish to email hn@gmail.com then you would send an email to example+hn=gmail.com@mailer.me from the email address registered to the Addy account.
It's not in the same category. You can use Firefox Relay as an alias generator within Bitwarden. It provides a convenient UI and an integration with the password manager.
Integration. When signing up with a new web service, you can just pop open Bitwarden and will generate both a unique email alias and a unique password, prefill the sign up form, and save the details to the password manager.
Edit: Is there a standard or API spec perhaps across email alias services for generating, listing, managing, and invalidating aliases?
(happy paying bitwarden customer, no other affiliation)