What Proton is doing to e-mail is about the same that WhatsApp, Messenger and others did to messaging - instead of just using an open protocol like XMPP they opted for their closed thing in order to lock people into their apps.
PGP is not closed. What proton has done is make a really cool JS library for PGP as part of their Web UI (openpgpjs.org) which other projects, even those unrelated to Proton have used, like Mailvelope. They’re also pushing the PGP standard itself to support stuff like post-quantum encryption. So this is really odd to hear as Proton is, without a doubt, the most open and interoperable of all the properly encrypted providers.
Lavabit
With Lavabit, you were simply trusting them mostly blindly on their claims. Yeah it worked out that one time but could have gone very wrong.
Yes, they have it because GDPR does require it.
They’ve had it since far before GDPR took affect. They’ve also had bridge which has always allowed external backups and is in fact real time. They now also support forwarding mails, which should also suffice for your use case.
Open sourcing the server software is desired ofc, but would it really mean a lot for security? Not really. All the relevant bits are already open source. And none of it is really non-standard. But i do still wish for that for the sake of transparency. And yeah i wish they would move away from this almost source-available model.
Regarding SMTP, yeah i agree. But they do provide that through bridge and also for business users based on a per-request basis.
There are definitely a few artificial limitations and stuff that really pisses me off, like the limit on aliases in custom domains and SMTP for normal paid users, but a lot of the talk I’m hearing on lemmy about proton is just FUD.
PGP is not closed. What proton has done is make a really cool JS library for PGP as part of their Web UI (openpgpjs.org) which other projects, even those unrelated to Proton have used, like Mailvelope.
I never said PGP was closed, what I was saying is that their implementation of the access to their service is closed (not using standard IMAP/SMTP) and subsequently “their” PGP might be questionable / opaque.
If they actually do everything with open standards and PGP by the book as they say, why can’t they provide IMAP/SMTP access to everyone who wants it BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… they could even configure their submission to refuse any email that isn’t PGP encrypted to improve things further. The fact that they don’t do this leads me to believe that they either a) aren’t actually doing everything as “by the book PGP” and there might be security issues or b) they’re “privacy” as a catch all excuse in order to push a bit of vendor lock-in.
Their market niche is privacy conscientious people and those same people tend be to computer savvy and I bet half of them would mind setting up PGP on Thunderbird and use Proton without a bridge. Everyone else could still use their apps, web or the bridge.
They can’t do traditional IMAP/SMTP simply because they always do client-side auth rather than tradition server-side auth, which inherently makes them more trustworthy than every other provider that does offer IMAP/SMTP-based provider to whom you always send your passwords in plaintext. This has the added benefit of having at least your own mailbox always be zero access encrypted.
they always do client-side auth rather than tradition server-side auth
They must have some server-side auth as well, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted email from their servers. Even though it would be mostly useless it would still be a big vulnerability issue.
IMAP/SMTP-based provider to whom you always send your passwords in plaintext
Why do you say that? What led you to believe it?
Most providers are running IMAPS (IMAP over SSL) or IMAP with StartTLS (upgrade to TLS) and the same for submission to make sure there are no passwords in plain-text. Furthermore mail clients and servers also support password hashing and some, like Google, even go further and push people into IMAP/SMTP authentication with XOAUTH2 (OAuth token unique for each e-mail client).
Non-plaintext mechanisms have been designed to be safe to use even without SSL encryption. Because of how they have been designed, they require access to (…) their own special hashed version of it. https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/#non-plaintext-authentication
Going back to Proton, if they do use PGP in a generic way it means all your e-mail are encrypted and whenever you want to open the website or use the bridge they’ve to decrypt them. As you described before, they do this client side and that’s okay.
Now the next question is: how do they decrypt your mailbox? Their servers hold your private PGP key encrypted with your login password, once a client wants to decrypt your mailbox it has to pull that private key from the server and then use your password to locally decrypt it. Said now plain text key can then be used to decrypt the e-mails. This is a common security practice to make PGP and other asymmetric encryption schemes work securely without forcing the user to store and mange its own private key - that’s okay as well.
For e-mail coming from external providers (and people who don’t use PGP) Proton receives the unencrypted message (over TLS) and then encrypts it with your public PGP key. After this point you are the only person who can decrypt the message because while they also hold your private key it is encrypted thus they can’t use it to decrypt the message. This is reasonable and okay.
Now the thing is, all this can be accomplished via IMAP/SMTP, with the same level of security, if you employ a few rules:
- Tell customers who want to use IMAP/SMTP that they’re required to configure PGP manually on their clients otherwise their mailbox will be encrypted / useless and they won’t be able to send e-mail;
- Submission (sending e-mail via SMPT) servers configured to refuse any e-mail that isn’t PGP encrypted;
- Only provide IMAP/SMTP authentication with SSL/TLS;
- Restrict the IMAP/SMTP authentication to a non-plaintext mechanism;
- If they don’t go for XOAUTH2, then force people into creating a specific app password for each e-mail client - like Google also allows for legacy stuff that doesn’t support XOAUTH2.
Note that their current apps/bridge also needs to authenticate itself with some hashed version of your password, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted messages from their servers. Actually using XOAUTH2 tokens or unique app passwords would be even be safer than what they’re doing.
Considering their PGP implementation is standard then doing those tweaks isn’t impossible and they would provide the same level of security their apps provide but also be flexible enough for more advanced users.