AliasVault: Open-Source E2EE Password & (Email) Alias Manager

Thank you for taking the time to write this out. Also thank you for the kind words and compliments! Happy to answer your questions and address the questions and points you raise below.

To get to the core of your point: email, as it exists today, is fundamentally a weak link: it’s largely plaintext, server-handled, and outside the user’s control. Aside from niche PGP setups (which remain fragmented to an extent), there’s simply no way to send or receive email without it transiting through a server in readable form at some point (where you don’t know whether they keep backups or not). That part of the threat model can’t be eliminated, only constrained. What AliasVault aims to do is try to reduce exposure as close to the user’s end as possible: emails received by the AliasVault server are only ever stored on disk in encrypted form. Only the recipient can actually access the contents, even if they haven’t synced their mailbox yet.

However you’re absolutely right about the core E2EE principle: ideally, trust should not need to be placed in any backend at all. That’s exactly why AliasVault is fully open-source (therefore auditable) but also offers class-A support for self-hosting. If you don’t want to trust the cloud or any AliasVault provided email domain, you don’t have to, including for email handling.

A few clarifications that may help:

1. Email contents are encrypted in memory immediately upon receipt, before any storage. This flow is intentionally simple and auditable in the codebase. This can be assessed and verified relatively simply in any (security) audit. Relevant lines are here: aliasvault/apps/server/Services/AliasVault.SmtpService/Handlers/DatabaseMessageStore.cs at 5d7af1d1232b3a278e0a20551bf58a8d8cb2c376 · aliasvault/aliasvault · GitHub
2. Email aliases are optional. AliasVault can be used purely as a password manager vault, alongside your own existing email addresses. You can choose if and when to use an alias: e.g. only for obvious throwaway accounts, or not at all.
3. When self-hosting, you can use your own email domain, with no dependency on aliasvault.net infrastructure.
4. For the hosted version, we’re working toward allowing custom email domains as well, so users can connect their own domain names to use for aliases, which also allows them to take their domains with them if they want to no longer use AliasVault anymore.

So rather than asking users to fully trust us, the goal is to provide real choices:

1. Full convenience: Use the fully managed AliasVault cloud, with end-to-end encryption that can be audited and verified. Aliases are optional.
2. Convenience and control: Use the AliasVault cloud but connect your own email domain: (support for this is coming in one of the next releases)
3. Full control: self-host AliasVault and maintain your own hardware, software and email domain(s).

LongPenne:

Anyway, I hope I’m just being paranoid/stupid, and your solution can be greenlighted by real security professionals, and liked by many users.

I don’t think you’re being paranoid at all :). A healthy sense of skepticism is really a strength in the privacy/security world. AliasVault is designed to be open-source and community-driven, so we actively try to learn from feedback and address any questions people might have. Questions, suggestions and improvements to the core security model are also always appreciated.

If you have any follow up questions, feel free to let me know!