So… this was the plan of the Standard Notes guys all along? Now it makes sense why they never made open-source and self-hosting a true priority.
Let’s see what Proton does with this, but I personally believe they’ll just integrate it in Proton and further close things even more. The current subscription-based model, docker container and whatnot might disappear as well. Proton is a greedy company that doesn’t like interoperability and likes to add features designed in a way to keep people locked their Web UI and applications.
Standard Notes for self-hosting was already mostly dead due to the obnoxious subscription price, but it is a well designed App with good cross-platform support and I just wish the Joplin guy would take a clue on how to design UIs from them instead of whatever they’re doing now that is ugly and barely usable.
Yes the clients are open source but the server part is closed and it’s a big missing part
Now, better to be 50% oss than 0%, but it’s not a community effort. Most commits are done behind the scenes and then published when app is released. This causes most pull releases to be rejected as the problem was already fixed internally months before. It’s more like “source available”
There’s no vendor lock in until you realize your emails are essentially hostage of their apps and a bridge that may be shutdown at any point. If you can’t simply setup a regular email client then there’s vendor lock in, not even Microsoft does that.
They say the reason for needing their bridge is the encryption at rest, but I feel like the better way to handle wanting to push email privacy forward would be to publish (or better yet coordinate with other groups on drafting) a public standard that both clients and competing email servers could adopt for an email syncing protocol for that sort of zero-access encryption that requires users give their client a key file. A bridge would be easier to swallow as a fallback option until there’s wider client support rather than as the only way.
A similar standard for server-to-server communication, like for automatic pgp key negotiation, would be nice too.
Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR. It’s manual enough to not be an effective way to keep up-to-date backups in case you ever abruptly lose access but it’s good enough to handle wanting to migrate to another provider.
I agree 100% with your ideia. The best path for this would’ve been for them to actually design that system you describe and THEN implement it on Dovecot and Postfix in their own fork or a Dovecot extension / Postfix add-on so others would start using them. Eventually after some times and other providers also optionally supporting the thing an RFC could be written. This is the usual course we see with protocols/extensions and is what should’ve happened here.
I want to share another thing, before Snowden there was Lavabit, they also did “encryption at rest” and the user password involved for some parts of the information and it was proven to be effective. It wasn’t a perfect model but it was certainly better than the havoc Proton did to e-mail by opening the precedent that is okay not to run on standard protocols.
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. People in this community seem to be okay with this just because they sell the “privacy” cool-aid.
server-to-server communication, like for automatic pgp key negotiation, would be nice too.
I’m not sure if this is required. Any decent e-mail server uses TLS to communicate these days, so everything in transit is already encrypted.
Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR.
Yes, they have it because GDPR does require it. It works, but it’s not a real time sync alternative to anything and it is some kind of vendor lock-in.
As I said in other comments, not using standard protocols only makes thing worse. I used iOS as an example, for Android you can get a bridge but that’s just going to be one more thing going for your battery.
Now, consider this, there’s a TON of situation where having a standard SMTP-capable provider is interesting. Maybe you’re running in iOS, maybe you want to have an ESP32 to send a few emails, or some custom software in your computer. All those use cases are impossible or require more coding and more non-standard solutions just because Proton decided to be the first provider ever not to use standard protocols.
So… this was the plan of the Standard Notes guys all along? Now it makes sense why they never made open-source and self-hosting a true priority.
Let’s see what Proton does with this, but I personally believe they’ll just integrate it in Proton and further close things even more. The current subscription-based model, docker container and whatnot might disappear as well. Proton is a greedy company that doesn’t like interoperability and likes to add features designed in a way to keep people locked their Web UI and applications.
Standard Notes for self-hosting was already mostly dead due to the obnoxious subscription price, but it is a well designed App with good cross-platform support and I just wish the Joplin guy would take a clue on how to design UIs from them instead of whatever they’re doing now that is ugly and barely usable.
Doesn’t proton open source everything they do? Iirc, proton mail, calendar, vpn, drive, and simplelogin are open source under GPL v3 on github.
Yes the clients are open source but the server part is closed and it’s a big missing part
Now, better to be 50% oss than 0%, but it’s not a community effort. Most commits are done behind the scenes and then published when app is released. This causes most pull releases to be rejected as the problem was already fixed internally months before. It’s more like “source available”
There’s no vendor lock in until you realize your emails are essentially hostage of their apps and a bridge that may be shutdown at any point. If you can’t simply setup a regular email client then there’s vendor lock in, not even Microsoft does that.
They say the reason for needing their bridge is the encryption at rest, but I feel like the better way to handle wanting to push email privacy forward would be to publish (or better yet coordinate with other groups on drafting) a public standard that both clients and competing email servers could adopt for an email syncing protocol for that sort of zero-access encryption that requires users give their client a key file. A bridge would be easier to swallow as a fallback option until there’s wider client support rather than as the only way.
A similar standard for server-to-server communication, like for automatic pgp key negotiation, would be nice too.
Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR. It’s manual enough to not be an effective way to keep up-to-date backups in case you ever abruptly lose access but it’s good enough to handle wanting to migrate to another provider.
I agree 100% with your ideia. The best path for this would’ve been for them to actually design that system you describe and THEN implement it on Dovecot and Postfix in their own fork or a Dovecot extension / Postfix add-on so others would start using them. Eventually after some times and other providers also optionally supporting the thing an RFC could be written. This is the usual course we see with protocols/extensions and is what should’ve happened here.
I want to share another thing, before Snowden there was Lavabit, they also did “encryption at rest” and the user password involved for some parts of the information and it was proven to be effective. It wasn’t a perfect model but it was certainly better than the havoc Proton did to e-mail by opening the precedent that is okay not to run on standard protocols.
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. People in this community seem to be okay with this just because they sell the “privacy” cool-aid.
I’m not sure if this is required. Any decent e-mail server uses TLS to communicate these days, so everything in transit is already encrypted.
Yes, they have it because GDPR does require it. It works, but it’s not a real time sync alternative to anything and it is some kind of vendor lock-in.
As I said in other comments, not using standard protocols only makes thing worse. I used iOS as an example, for Android you can get a bridge but that’s just going to be one more thing going for your battery.
Now, consider this, there’s a TON of situation where having a standard SMTP-capable provider is interesting. Maybe you’re running in iOS, maybe you want to have an ESP32 to send a few emails, or some custom software in your computer. All those use cases are impossible or require more coding and more non-standard solutions just because Proton decided to be the first provider ever not to use standard protocols.
Do you have a privacy oriented email provider alternative to proton?
I have my domain name, but I don’t want to manage an email server on my server.
Maybe one listed at https://www.privacytools.io/privacy-email or https://european-alternatives.eu/category/email-providers ?
Please don’t use privacytools.io anymore. Use privacyguides.org instead
What’s wrong with Privacy Tools?
Huh? This is not true. Proton have an app that exports all your emails for reimport into the platform of your choice.