Nice, the more stand alone non corporate email providers the better. You have it on a good host. I've never tried to email from their CIDR blocks, curious how it works out.
I'd like to know more about the operator, besides them being from USA. Having the data in Iceland sounds great, but we should be wary of any new service designed specifically to attract confidential conversations.
I know it's in it's infancy here, but if it's a solo passion project I'd consider open-sourcing it so the E2EE can be verified.
If you plan on launching this as a monetized project of some sort, I, as a potential customer, would suffice for audits but I'm sure they can get pricey.
Another company tried the Iceland root, and after growing steadily and without reporting issues (at least I never saw anything reported) just shut down one day.
You defeated https://www.emailprivacytester.com straight off. Which is more than most new email services. You seem to be relying on CSP entirely for this, but it works.
I’m never hosting or dealing with any companies in Iceland. I had a run in with a hosting company there who was DoS attacking us from compromised nodes. I emailed them and they told me to get a letter from a local lawyer telling them to stop and they’ll look at it. In the end we contacted our DC provider and they dumped all traffic from their entire blocks.
A year later same attitude from a different one hosting a web site for Covid misinformation which was against their own AUP.
I’m trying to create an account to test this service. I get this error message, what does it mean? Why is the error message so short to the point where I (the user) don’t know what to do next? Why can’t software developers learn how to communicate better with their non-tech users? And this is coming from someone with a 30+ years career in software engineering.
edit: after hitting the button “I’ve saved my recovery phrase - continue” multiple times and getting the same repeated error message, it finally worked but then the API returned “error: Registration failed”. And at this point I give up. This is why many projects, even at Big Tech companies, fail: too much friction for new users, or too many features, or too many options to choose from.
for a moment i thought it was rootshell.be - many many years ago they were giving away shell accounts, and teenager me used to have one for learning purposes (and also for the cool domain)
I find it very hard to trust any email service that claims to be E2EE without an audit by a reputable firm like Cure53 or Trail of Bits.
I signed up to give it a brief test and immediately noticed that emails are returned from the server in plain text. This means that the emails are decrypted on the server, which defeats the entire purpose of E2EE. The encrypted email contents and metadata should be returned to the user and decrypted on the client.
It's also painfully obvious that the entire thing is vibe-coded. While that in itself isn't an issue, it raises scrutiny. If the author doesn't have a full understanding of the code their LLM generates, some nasty bugs could be lurking.
I guess we need to coin a new term, something like VibeE2EE. As in "we asked to make something E2EE but we have no idea what it has made, nor we asked anyone to audit it (because it wouldn't pass a code review, let alone security audit)"
The E2EE claim is BS, unless qualified by saying that the platform supports GPG-encrypted emails only. Proton makes the same claim and it’s just completely false. E2EE is not possible with existing email protocols.
The main point they try to make is that once emails land, the platform itself can't read them because they immediately encrypt it with your key, of course, this process is impossible to know for sure. And of course, using PGP or whatever is already a secure medium on all email providers, nothing to really solve here.
Even as some says, even if Cure53 or whatever respectable company does an audit, it still guarantees nothing. Only real way today is with Enclave with proper implementation of attestation and more, anything running server-side can't be checked.
It's quite disappointing that we find many good developers today that still trust ToS of a service as if it was any form of real security, it worth nothing outside of the legal aspect, ToS has nothing to do with code.
I do not understand why anyone would want their email provider to be "E2EE". If I want end-to-end encryption then I will exchange public keys with the recipient.
There is no such thing as E2EE email. You can encrypt your storage or some of the hops, but the plain-text email contents goes through between every layer, unless you're talking about PGP, or some similar scheme you built on top of the email protocol (where obviously both the sender and the recipient must participate).
27 comments
[ 5.6 ms ] story [ 41.0 ms ] threadIf you plan on launching this as a monetized project of some sort, I, as a potential customer, would suffice for audits but I'm sure they can get pricey.
I'll give it a shot either way, just my two cents
A year later same attitude from a different one hosting a web site for Covid misinformation which was against their own AUP.
I’m trying to create an account to test this service. I get this error message, what does it mean? Why is the error message so short to the point where I (the user) don’t know what to do next? Why can’t software developers learn how to communicate better with their non-tech users? And this is coming from someone with a 30+ years career in software engineering.
edit: after hitting the button “I’ve saved my recovery phrase - continue” multiple times and getting the same repeated error message, it finally worked but then the API returned “error: Registration failed”. And at this point I give up. This is why many projects, even at Big Tech companies, fail: too much friction for new users, or too many features, or too many options to choose from.
> encryption key is derived from the password > One can use the passphrase in case password is lost
What does this really means? is the password encrypted with these pass phrases instead of being hashed?
I signed up to give it a brief test and immediately noticed that emails are returned from the server in plain text. This means that the emails are decrypted on the server, which defeats the entire purpose of E2EE. The encrypted email contents and metadata should be returned to the user and decrypted on the client.
It's also painfully obvious that the entire thing is vibe-coded. While that in itself isn't an issue, it raises scrutiny. If the author doesn't have a full understanding of the code their LLM generates, some nasty bugs could be lurking.
Not very promising.
Even as some says, even if Cure53 or whatever respectable company does an audit, it still guarantees nothing. Only real way today is with Enclave with proper implementation of attestation and more, anything running server-side can't be checked.
It's quite disappointing that we find many good developers today that still trust ToS of a service as if it was any form of real security, it worth nothing outside of the legal aspect, ToS has nothing to do with code.