Shared relational databases (e.g. MongoDB, SQL Server, PostgreSQL, Oracle, MySQL, etc) all require a login (with user/password) to establish the database connection. This means that anyone with this password could query the database for anything. Be it a rogue employee or evil maid attack. This also means that having access to one user’s data means you also have access to everyone else’s. On the other hand, SQLite could be considered a shared database, but how we use it (each mailbox = individual SQLite file) makes it sandboxed.
Since we use sandboxed and individually encrypted SQLite files to hold your data (each with their own password which only you have), this means that none of our employees can ever access your data – it is a core design decision/system architecture difference.
Additionally this also completely eliminates the threat of SQL and NoSQL Injections (e.g. one user can’t do a query injection for your data, as it’s in a completely different database on its own connection). It also eliminates the risk of accidental data deletion, and makes it much easier to maintain backups, restore, and completely delete and purge data if needed on an individual basis.
Given that other providers, namely Proton and Tuta encrypt and decrypt the data at the client. And only store encrypted data on the server. Surely anyone who gained access to their databases could only access encrypted data?
It seems that with your system you just access the encrypted data in a different way? You’ve just added a layer of complexity. Do you not use a databse to manage access to the individual SQLite files?
Another question if I may.
Are users mailboxes decrypted on your server and held in memory so that they can be accessed via IMAP? If so does that mean that an attacker with server access can view the decrypted data? Whereas with other secure providers the decryption only takes place on the client devices?
The reason why we stressed open-source backends so much is that when someone emails you @proton.me, @tuta.com, or @mailbox.org that it is going to first go through their MX servers. This means it could be being stored by them (or in a log). Additionally, even if you email someone from your account on Proton or <other service>, the moment that other person replies, it’s going to hit the MX server again (most likely unencrypted) and can be stored by them. Without seeing any code, and without an audit, the only thing you can rely on is marketing material and what is advertised.
This statement cannot be confirmed without an audit or backend code being shared.
There have been zero publicly shared audits of any currently listed PG email service provider’s backend infrastructures nor open source code snippets shared of how they process inbound email. Nor have they shared anything on their backend infrastructure in public. It is possible that any email service provider could be storing a copy of your messages without your knowledge, and there’s no way to verify they aren’t, or even assume they aren’t, because nobody has seen the code, nor an audit. Not all senders implement PGP/WKD either, e.g. someone that emails you from a Gmail to Proton isn’t going to have the content encrypted on the Gmail side – so once it hits the MX server all of your original outbound messages could be seen.
It is all done in-memory. An attacker would have to gain server access, modify code, and avoid being detected. We also have taken steps to completely disable swap, transparent huge pages, USB devices, and other memory-related security concerns.
I’m not comfortable recommending a product that says that the competition, (Proton, Tuta) is not end-to-end encrypted. And then links to the privacy guides, websites for the definition of end-to-end encryption. They are so implying that privacy guides agrees that the later aren’t E2E.
This is very true. It’s also true for you. There is no guarantee your hosted platform runs the same backend code as the one that’s being published. I feel like I’ve said this before. But open source backend is an ideology advantage, not a security/privacy advantage for a hosted platform. I like what you’re doing, but you really shouldn’t be spouting bad things about the competition that equally apply to you.
This is incorrect as we state the standard for E2EE is to use OpenPGP and WKD, and in the popups for OpenPGP and WKD we link to the Wikipedia pages as well.
Regarding Proton Mail E2EE, we link to an article, which subsequently links to several open GitHub issues filed on the Proton Mail repository.
Additionally, we also link to Tutanota similarly here with another link to a Reddit discussion, and subsequent links which show that they do not support OpenPGP. Tutanota does not support WKD either because of this.
By our definition, these providers do not use E2EE with OpenPGP/WKD (or have a broken implementation, e.g. due to Proton rewriting messages/signatures).
This is exactly why we said “any email service provider”. We’re very passionate about open-source and building trust too. We are following closely Mullvad’s efforts with System Transparency.
Your claims here seem slightly bad faith to me. So, I have decided to waste some of my time refuting them. What follows is an analysis of your comparison page (Link), feel free to refute any and all parts you feel are unfair. I will focus on Proton, as I am most familiar with their infrastructure. Hopefully, Tuta is also similar.
Lets Start
Analysis of their table headers
20 facts in comparison
Only 15 are actually listed. The 5 additional metrics in the header of the table (Hardenize, observatory, etc.) are measures of their website, not their service.
This is a test of their website (not service) security. It uses a very dated idea of HTTP security. Proton fails this due to no CSP policy (Link), which can lead to cross site scripting (XSS) attacks (Link). But, this does not matter on their website since:
Their website actually does not handle any credentials at all. All actual credentials and mails are handled by their webapp or their native clients. Their webapp was found to be vulnerable to XSS attacks in 2022, and was immediately patched. (Link)
Their website passes all other security tests, and uses HSTS and other measures for web security.
What about forwardemail? Well, since they use CSP, they must be invulnerable right?
No. Any and every site is ultimately vulnerable to XSS, due to how web works. Using CSP means they can disable inline JS attacks, but still need to load the JS from their CDN. Who is their CDN? Do they host their entire web infrstructure? Are they invulnerable to transport layer leaks? Are their web implementations bullet-proof? We will never know, since they have no audits of their service, and their website isn’t actually tested regularly by security experts (unlike proton, which actually is tested on the daily by actual malicious actors and experts.)
Proton fails here as they do not resolve IPv6. This is not a bug, its a feature. IPv6 is very new and immature in security, and legacy IPv6 is a privacy risk. Interestingly, forwardemail also failed this test until recently (around 2023). (Link)
Pricing, storage, attachment are all accurate for proton. (as they should be lol, public info)
Open source: Correct claim that Proton backend is not open source. Appreciate forwardemail doing it all open-source, but again, no actual audit of the source. FLOSS is not security.
Sandboxed Encryption: No source for their claim of Proton using what they say proton uses, and no source/audit of what they say they use. Additionally, if e2ee is implemented well, rogue employees or anyone else cannot access that data anyway. Finally a personal opinion: Having individual SQLite mailboxes might add another attack vector where now each mailbox can be easily separated from the larger database by a rouge employee, who can then handover specific data to malicious actor rather than the entire database. No clue if this is true, but that is what I think.
Features: Don’t see the point in debating unlimited domains, aliases, etc. since that is part of pricing models used, and will differ from company to company. Kudos to forwardemail if they provide all this in free plan.
SMTP, IMAP, POP3: Intentional implementation from Proton (Link). Kudos to forwardemail if they support all 3. Interesting thing to note is that both Proton and forwardemail provide SMTP and other protocols only in the paid plan. (Link). I also don’t see any source for their claim of vendor lock-in, since the Proton bridge is open source.
API: Nice feature forwardemail has, but apparantly proton does not. Would be great to see audited reports of API security and its implementation.
E2EE: Insane quote of protonmail “rewriting your email”. Is data corruption and misidentification of protocol used so malicious as to be deemed “rewriting”? The issue is simply Proton intentionally not implementing a feature of being able to use PGP keys not yet registered as a contact on mail service itself. It is a very opinionated choice, and one that people can dispute. But it is NOT, in any sense of the word, rewriting. I would recommend everyone actually read the linked Github issues (Link 1, Link 2). E2EE not being implemented would destroy Proton’s reputation and is a serious allegation. And anyways, we should move away from individually signing PGP keys and focus on automated implementations like Proton does.
OpenPGP and WKD: No issues.
Analysis of their footer
They ask you to review them on Trustpilot. Let’s explore that. (Link)
They have 55 reviews on Trustpilot. Oldest review is from 16th Jan 2023, while the service has been active from 2017 apparently. Most of the 5 star reviews are from people with only 1 review and sound similar in structure. Most of the 1 stars have a comment underneath disputing them and calling the people who reviewed them liars. Seems very interesting.
They seem to have same problems as Proton Mail does on Trustpilot: Reviews by people who were banned. But the difference in proportion of reviews is simply due to the fact that protonmail has a free tier with their own address, while forwardemail does not.
For note, what Tuta does is how you do a comparison in good faith while still showing how your product is better (Link). I do not like how Protonmail does this comparison either, but they at least don’t have intentional misreads of competition’s features. (Link)
Regarding Hardenize/CSP, we have a clear disclaimer that states that all boxes must be green in order to be considered passing (as you mentioned).
We recently obtained access to the Hardenize/Redsift API so that we can programmatically automate these badges/updates. We’re waiting on answers to a few questions before we can automate the badges/results (and could even accurately share then in an automated way which tests are red/green/greyed out, e.g. CSP) so as to better reflect the comparisons.
Yes we’ve had quite a few users post false content on Trust Pilot. For example, there’s one user that claims we don’t list an email address or any way to reach us for help on our site… when in fact there’s clearly links to Help section, FAQ, and our email address (as well as GPG key for our email). Trust Pilot refused to take this down, even though we showed them screenshots. So it’s a constant battle there, but we do our best.
Other providers support end to end encryption though open source and audited client apps. With the encryption taking place within these apps. Not on the server.
What you seem to be referring to is how they handle unencrypted mail. But the same applies to you. With no way of verifying what code is actually running on your servers how can someone know that you can’t read their email either?
I find the lack of disclosure about who owns the service concerning, in the past it seems the owner was a lot more open about it but the info is all gone. It’s a shame because the service itself seems good but hard to trust, so I’d appreciate someone confirming if there really is no owner associated.
First, let me say that I enjoy your service. I noticed that you’ve received a lot of constructive feedback, which is great, but I’d like you to know that people appreciate every company that tries to do things differently - with consideration of people’s privacy.
One thing that worries me and possibly is an obstacle of getting listed on PG is that database is decrypted when accessing Forward Email by IMAP.
This case is very similar to Forward Email. Since the DB is accessible via memory, theoretically you can access user data when account is logged in. If I am wrong, please do not hesitate to correct me.
We like client-side encryption for a reason - even if the data is (somehow) accessed - it will be unreadable without our encryption key. Imagine if password managers such as 1Password or Bitwarden were in decrypted state when log in - it would be frightening, and we would recommend against using such software.
