Thanks for writing and your thoughts here. To clear up some confusion – it’s only accessible via SQLite in-memory (the database isn’t necessarily decrypted, but there’s an open in-memory connection to it). That being said, we hope to build trust as mentioned through routine audits and by hopefully implementing diskless server infrastructure and use System Transparency as Mullvad has (see above) in the near future. Additionally, any user can encrypt their data stored in the SQLite mailbox with their PGP key – therefore even if a rogue employee attack occurred, it would be impossible to read your emails since they’re not only encrypted with your IMAP password using ChaCha20-Poly1305 on the SQLite file itself, but also the content in the database (accessible via in-memory connection) is also encrypted.
I am the owner commenting here and the main contributor. We are a Delaware, USA LLC with some amazing advisors in the open-source community. Eventually we may come out of stealth mode – we’re running a privacy-focused company and have been focused intensely on product, not marketing. It’s not easy to do this all ramen-profitable style – we’ve poured a ton of passion and time into this, more than anyone could imagine. It’s probably why we’re the only 100% open-source provider right now.
Hey, I appreciate you responding even though my question was flagged for some reason.
I don’t doubt the effort you have made both in development and in communication, and I was even close to subscribing for both of those reasons (and in fact I made this account to try clearing up some doubts), but I still find it hard to put my trust in your company. Checking the filing for your llc, it was registered in June of 2023, so it’s rather recent, and on your website the link one would expect should lead to contact information is only an e-mail address. As I do not have much legal know-how I cannot comment further on either of these but I wanted to bring it up.
To clairify: our stance on back end code not really mattering stems from the fact that its hard to know whether the code you publish is the same that you run on your servers. Audits help, but those are just a snapshot in time, and those can be changed at any moment.
This is one of the reasons why Proton has been criticized in the past for claiming end to end encryption. This was because they provide a web login, and the code that your browser downloads can be changed at any moment in time to make a convienient copy of your encryption key for “safe keeping”. Its why its generally recommended to stick to apps for end to end encrypted things, as these are harder to backdoor without leaving evidence behind.
In any case, as the server in general is seen as an untrusted party with email, it should be designed to not trust it via client side encryption.
Sure, one can argue that you will be able to copy incoming mails, but you can atleast make sure past mails were properly encrypted and no longer accessible to you. This is sadly a limitation of email as a medium(in the case one does not use pgp).
P.s. on the side, apple is doing interesting things in this area with private cloud compute, where the server basically has a remote attestation with the client to prove its running that code on the server, really cool.
This is awesome & very similar to Mullvad’s System Transparency:
Boot chain measurements may then be used by the TPM to provide remote attestation.
https://www.system-transparency.org/#:~:text=Attestation%20of%20present,provide%20remote%20attestation. → https://git.glasklar.is/system-transparency/core/system-transparency/-/blob/main/doc/guide.md#L135-177
Determining how to make this publicly auditable (at anytime) is something we’ll need to look into. We have to do more mental cycles on all this and experimentation, but we hope to have something in the future at some point with either our own apps or a simple way to verify.
Edit: Here’s a video on System Transparency: https://www.osfc.io/2019/talks/introducing-system-transparency/
The drawback of your method here isn’t just about securely accessing it, in case of a compromised server or court order the entire email history becomes readable if the user logs in. When the client decrypts everything using a private key, the only way to gain ahold of old emails is by targeting the user with a compromised client instead of just reading from the server side.
New emails are (almost) always interceptable so those are less important for the argument in my opinion.
As mentioned, you can encrypt the data stored in the encrypted IMAP mailbox using your OpenPGP Public Key. This ensures that even if an attacker had access to the servers, modified code to get in-memory password and database access to stdout, it would be impossible to read the messages. We do this ourselves to protect mailboxes with sensitive customer information, e.g. support@forwardemail.net and abuse@forwardemail.net.
Thanks for repeating it, hard to follow a thread with 220 posts. Good to see that at least for technical users there is a way to protect against compromise down the line, would be good to see this as a default for all users, but maybe that would be difficult to implement for your style of providing emails.
For further clarification, what information is encrypted using the pgp key? Is it only contents or do you include metadata?
Previously in this thread you also talked about “encrypting passwords” which you then store on the server. Does this not mean you don’t even need to be logged in for your database to be accessible? Found the information previously in the thread.
The email message/body is encrypted using OpenPGP (standard).
We must emphasize that as far as i understand from you this is not a default.
In your other encryption model with the database in RAM I could think of many things that could go wrong here. Also like mentioned by @mountainofmeat the data will be fully unlocked on user login and not be necessarily only accessible by them. Can you comment on that more?
I do really wish to see an audit on your methods from subject experts here. Personally this is a huge factor for me in putting any trust in the way you handle this.
The approach will be to have IMAP, SMTP, POP3, CalDAV, and other servers that do not require disks to be diskless/memory only. The server with mounted block storage of encrypted SQLite files running the WebSocket server will most likely not be as it is required for SQLite functionality/operations.
See the answer posted here https://discuss.privacyguides.net/t/forward-email-email-provider/13370/177 for more insight (including link to the source code).
If you have other questions we’re happy to answer them. We take passion in what we do and have put an immense amount of thought into our architecture. There is also the write-up at https://forwardemail.net/blog/docs/best-quantum-safe-encrypted-email-service for more reading.
And we 100% agree – we cannot wait to get more feedback from third parties auditing our service, infrastructure, and design. We do hope that this is not holding us back from PG inclusion, and stress these two points made here.
I guess your reply/feature here Forward Email (email provider) - #215 is similar to what Mailbox.org offers.
I do consider this necessary from what I understand from your design to qualify as E2EE and zero knowledge
Having the (not anymore) encrypted data on RAM on your server does not meet the requirements of PG:
- “Encrypts email account data at rest with zero-access encryption.”
- “Zero access encryption, builds on encryption at rest. The provider does not have the decryption keys to the data they hold. This prevents a rogue employee leaking data they have access to or remote adversary from releasing data they have stolen by gaining unauthorized access to the server.”
Only by doing the step of adding a public PGP key as you describe would make you qualify for it. I understand the technical limitations and the way you made intercompatibility, which is quite cool. We should however at minimum mention that for both Mailbox.org and your offering this is a necessary step. Having the data living memory-only on your side is neither E2EE nor no knowledge by definition. I am not saying you don’t offer it at all but from my reading I understand it is not a default per se.
I just found this on your website here too: Frequently Asked Questions
I think that takes away from of the questions.
Feel free to correct me if I am misunderstanding.
To add on what @ph00lt0 said, cpild you tell me a little about what threatmodel Forwardmail had in mind when they were designing your service and specifically the mailbox encryption.
Also, do you happen to have a security whitepaper.
Something else I just was looking into going over the requirements.
In the minimum to qualify PG states:
“Privacy policy that meets the requirements defined by the GDPR.”
Given Privacy Guides targets individuals I will skip the Data Processing Agreements you offer, while great that it is there those are not relevant for your direct customers.
So that leaves me with the question do you have any legal representation in any member state of the EU? This is a requirement defined in Article 27 of the GDPR. I was not able to find any contact for this on your website.
@ph00lt0 Yes, thank you for pinging us about this!
We’ve updated our GDPR page to include our representative (Osano) and their mailing addresses at https://forwardemail.net/gdpr#gdpr-representative.
Screenshot:
@overdrawn98901 We’ve spent a lot of time meticulously checking our dependencies and license compatibility – which is why some of our code is BSL and some is MPL. We’ve also reached out to the actual authors of source code we use (e.g. WildDuck, which uses EUPL license) to get written permission. We have also donated and sponsored the efforts of several open-source authors and contributors over the years (we know how hard it is to be a maintainer).
For the purposes of staying on topic (we’d love to be included in PG); we aren’t going to dive into a discussion about changing licenses – but here’s a brief overview of our license history:
We originally were entirely MIT licensed, but MIT is not compatible with EUPL (e.g. we can’t do inbound EUPL to outbound MIT), so we opted for MPL in those cases. As we became a business and monetized the service (since it used to just be purely free DNS-based and forwarding only – but now we offer IMAP/POP3/SMTP etc) – we decided to try to protect us from large businesses cloning our service and we introduced the BSL as well. This also opened up the door for enterprise licensing, so we can help public universities and governments now (and actually be a business and stick around for a long time).
In the future we may revisit licensing – but here are some of our bookmarks on AGPL if anyone is curious:
- AGPL is compatible with EUPL (so we could potentially use it)
- Heather Meeker’s article on AGPL (prolific open-source licensing legal expert)
- Drew Devault’s article on AGPL (also has great criteria for a mail service provider; which we think we pass!)
@Niek-de-Wilde Stay tuned – we’re aiming to publish a draft of our white-paper next week and will follow up in this thread once it’s available for download. 
P.S. Today we published a press & media page at https://forwardemail.net/press 
It would be great if you tried to contact Securitum, our (probably) best Polish security group, which has audited Protonmail among other things. The largest Polish/foreign/bank companies choose them because of the amount of things they find and describe in their reports.
I see you repeat this claim, but this doesn’t make sense. Your source is about those who use Proton Mail with the Bridge, and how they can’t attach their own external keys to non-Proton users (not needed between Proton users). While I’m not expert, and therefore can’t exactly evaluate the claim, I do know that for the 99% of users that use the Web or native app, the encryption is perfectly safe. This is because Proton does support OpenPGP in their client. And they also allow sending encrypted emails with a password.
Unrelated, but could you please posting about every small updates to your service when it doesn’t concern the inclusion. This thread is already 233 posts long, and I don’t want it to become longer uselessly.
Who are “we”?
Edited, this was meant as a general statement of fact, but made it clearer.