Mixed feelings on this, as a user of simplelogin, proton and standard notes as individual services for the last 4+ years I love them all, and trust proton.
However one of the key reasons for choosing those services was they were isolated, and without risk of vendor lock in or single points of failure... Depending how this goes it could be great, I just hope they don't force/push integration with proton too much. Maybe I'm just being a FUD pusher. Certainly equally a chance this is great for both proton and StandardNotes. SN has lacked development on a fair few plugins recently so hopefully this aids that.
I appreciate this perspective and that was also my immediate reaction. Then I realized, as long as I can easily export my data and move elsewhere, I shouldn’t be too concerned.
This is very true, and SN does do that. That said I have hundreds of notes in SN... Its essentially my life at this point so its heavily integrated and would be both a shame and a pain to migrate! Here's hoping its positive for all involved though and this is a needless concern!
Genuinely. Proton expanding is a good thing in my eyes at least in this stage. They offer their services at a pretty hefty, but reasonable price compared to others, and don't have a free offering for certain things they run. Their incentive to operate is continuing what they were built on and getting better.
It will really hard or impossible to reach the level of development that ms and google have in their cloud collaborative products. They don’t have the resources like the mentioned two monsters.
It may require intense passion and a manic episode to do something like that with one coder or a small team, which is hard to arrange bureaucratically.
I don't trust Proton at all, and Obsidian is a nicer experience for this anyway. I had a ton of old notes, and now that a new owner is taking them all, it's time for me to delete my account and move on.
If you trust Proton, you trust that they'll remain e2ee securely. If you don't trust Proton, you don't trust that they'll remain e2ee securely. I don't trust Proton and actively avoid their products.
Can you articulate why you don’t trust Proton? From everything I know, they have a stellar reputation and have been around since 2013 with no end in sight.
I was really dissatisfied that notes are always somehow weirdly shared with a propriatary backend. There is jtx Board which uses your CalDAV calendar (Nextcloud, Radicale, etc.) as a backend which is really cool. The UI is also OK, but there seems to be no (Linux) desktop app for that.
So I started https://github.com/jeena/JNotes because I was curious about developing for GNOME anyway. It's going very slowly - because I am a stay at home dad with a one year old who demands all my attention :D - but it's going forward, but I guess it'll take another year before it's usable ^^.
Actually I was hoping that there would be more notes apps using standard backends like CalDAV or IMAP, but it's almost impossible to find something, everyone seems to want to implement their own backend and then charge for the synchronization.
It's not reasonable to assume that most people are going to self-host, or even how to go about doing that if they wanted to, but people still deserve a right to privacy and products that support that. I think that's what they were trying to say
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.
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.
The issue not that you can’t export in bulk, you’re locked into their apps daily. Every other email provider out there uses standard protocols that allow for any client to be used.
Besides, the export feature is all fun until you actually have to use it. There’s a bunch of metadata that gets lost, contacts, calendars and notes are exported in JSON with propriety structures that other systems can’t deal with. Note that there’s also CardDAV/CalDAV as open and interoperable solutions for those issues and they device not to use them.
And, and what will happen when they decide to discontinue the bridge? What happens when you’re running on iOS and you can’t have the bridge? You’ll be forced into their apps, that’s pretty locked. Besides does the bridge even provide contacts and calendars to Thunderbird? Last time o checked it didn’t. What about notes?
Iirc, all the emails are stored locally so I guess if proton goes down, you can still access the emails on your phone. Same with cakendar, contacts in proton, and hopefully notes
Edit: nevermind, the emails are only stored if you accessed them before.
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.
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.
In transit, yes, but not end-to-end.
One feature that Proton advertises: when you send an email from one Proton mail account to another Proton address, the message is automatically encrypted such that (assuming you trust their client-side code for webmail/bridge) Proton's servers never have access to the message contents for even a moment. When incoming mail hits Proton's SMTP server, Proton technically could (but claims not to) log the unencrypted message contents before encrypting it with the recipient's public key and storing it. That undermines Proton's promise of Proton not having access to your emails. If both parties involved in an email conversation agree to use PGP encryption then they could avoid that risk, and no mail server on either end would have access to anything more than metadata and the initial exchange of public keys, but most humans won't bother doing that key exchange and almost no automated mailers would.
Some standard way of automatically asking a mail server "Does user@proton.me have a PGP public key?" would help on this front as long as the server doesn't reject senders who ignore this feature and send SMTP/TLS as normal without PGP. This still requires trusting that the server doesn't give an incorrect public key but any suspicious behavior on this front would be very noticeable in a way that server-side logging would not be. Users who deem that unacceptable can still use a separate set of PGP keys.
Here's what I think: if they actually do everything with open standards and PGP by the book, 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.
I had assumed their reasoning for not taking that approach might be related to metadata at rest, but it seems they don't use "zero access" encryption for metadata even at rest so I have no idea what technical justification they could have for not supporting IMAP with PGP handled by the email client. The fact that they restrict bridge access to paying subscribers only doesn't help them avoid lock-in impressions either.
Great find, even worse than what I was thinking. Like you I was also under the assumption they applied some kind of encryption to all metadata as well.
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).
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;
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.
The bridge does the decryption using credentials you give it locally. Sorry for mentioning "auth". I should have mentioned encryption instead.
Regarding the rest, it comes down to the zero access mailbox encryption's implementation details. In all described scenarios, you're not really using your master password as the "key" for your mailbox. But in proton's and similar services' case like Tuta, this is true. Any "zero access" service provider offering IMAP access without a bridge is simply lying to you as IMAP (the protocol itself) requires server-side decryption of the content, even if SMTP doesn't. (Btw, SMTP is really an artificial limitation. Just not IMAP. If they give you smtp access, it wouldn't send encrypted mails unless specifically configured to do so but would otherwise be the same.)
What you described is encryption at rest, but not zero access encryption (which is what Purelymail does btw).
Whether all this is needed and all depends on your threat model. I think most tech-savvy folks would be happy with something like Purelymail or Migadu tbh...
The bridge does the decryption using credentials you give it locally.
Are you reading what I'm typing? I just described the full process they do on their apps and what can be done over IMAP to give you the same level of protection that Proton offers.
Besides, Proton doesn't even provide zero access. In Proton there's a bunch of data like e-mail headers that is NOT encrypted at all and they say it:
Any generic IMAP/SMPT provider + Thunderbird with PGP provides the same level of security that Proton provides, assuming they didn't mess their client-side encryption/decryption/key storage in some way. PGP is making sure all your e-mail content is encrypted and that's it, doesn't matter if it's done by Thunderbird and the e-mails are stored in Gmail OR if it's done by the Proton bridge and the e-mails are on their servers, the same PGP tech the only difference is the clients.
One key aspect that you seem to be missing is that Proton encrypts every mail, including those sent by or sent to unencrypted providers using your pgp key before storing them on the server. This isn't a case scenario that can be handled without using a bridge. Thunderbird or any other mail client won't know how to handle that.
What you described only solves the end-to-end encryption portion of the problem Proton is trying to solve. Not zero access.
Yes, mail headers are unencrypted. They never claim otherwise and neither did I. If it were encrypted, it wouldn't be interoperable, which is something you want it to be as well right? I've always been talking about the mail content itself. Unencrypted mail headers don't make it "not zero access".
I feel like you're just not the target audience for Proton. I just use Proton because I'm fine with the web UI and Proton Unlimited is mostly good value for me. I do also pay for Purelymail as i have a few domains and they've been wonderful too.
One key aspect that you seem to be missing is that Proton encrypts every mail, including those sent by or sent to unencrypted providers using your pgp key before storing them on the server. This isn’t a case scenario that can be handled without using a bridge
Yes it can, and I explained how. Maybe you're the one not understanding how Proton actually encrypts emails sent by unencrypted providers/people...
There's guide here explaining this in detail and providing an implementation example with Dovecot. This can be also done when a message is received by the MTA (before it is filed / stored by Dovecot) like discribed in this guide for Exim here. The process should be the same for Postfix.
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"
I pay for the same but may go down to their free tier. After a purge of email and emails with larger attachments I'm down to less than 500mb. The only thing I dislike on the free tier is their automated signature to advertise proton. I hardly ever send emails though so not too much of an issue.
So I don't pay for unlimited I pay for just the email subscription that does include the calendar (which I probably will start using I'm just very ingrained in Google calendar right now and don't feel like going through the hassle of changing it)
But as part of it I can have more than 1 email attached to the same account. So I have 1 for most things and 1 for the really important like bills and stuff
I went with Pro for the custom domains and catch-all inbox. Now I can give out whateveriwant@mydomain.com and it will get back to me. It's nice for easily identifying phishing, plus you can set up filters to trash emails to a particular address automatically, so if one of your addresses gets compromised you can just filter them out. Also, it's nice to see who's selling your info!
I do pay for SimpleLogin and will continue to do so. The only place my actual proton email address is exposed is on SimpleLogin. Every site I use on the internet has its own alias. That's 350+ sites currently.
The only downside to a catchall, as I see it, is someone could just start creating any random email address knowing it will find your legitimate mailbox. Also sending as any of the aliases can be a pain.
Yeah, I have to agree that the 'send as' can be a pain, would be nice if it sent as the recipient email by default. As far as people spamming looking for a legit address, I've fortunately not run into that, but I could see how that could happen.
Yeah. I mean, even if you did get targeted by someone they really don't want to waste their time on someone who is more privacy/security conscious. Thieves want easy targets.
Compared to simplelogin (or proton pass aliases, addy, firefox relay, etc), one other downside of a catchall is in associations across accounts. Registering with a @passmail.net address implies that I use Proton; registering with random-string@mydomain.org implies I have access to that domain. If 10 data breach leaks have exactly one account matching the latter pattern then that's a strong sign the domain isn't shared. If one breached site has my mailing address, my real identity can be tied to all the others.
Not surprising. Proton seems to be exploiting the niche of “privacy” . I haven’t seen anything to the contrary other than turning over metadata due to court order.
In a press release announcing the move, Proton emphasized the pair’s “shared values,” including the use of E2EE; a commitment to open-source technology; and how neither has relied upon venture capital to drive growth.
This includes building on its first acquisition — email alias startup SimpleLogin, which it acquired in 2022 — as well as developing and launching fully fledged password manager app Proton Pass in June.
So the company is evidently not allergic to user acquisition and other consolidation-based growth opportunities where it sees enough philosophical overlap plus the chance to deepen its technical bank.
“The deal is a strategic decision designed to benefit users by bringing to market secure, easy to use, private products that anyone can access,” Proton wrote.
“Standard Notes and Proton engineers will begin working together immediately to ensure their combined skills and experience bear fruit for users as soon as possible.”
Asked about the sustainability of pro-privacy business models that don’t rely on exploitation of user data — when so much of mainstream tech still continues to roll in the opposite, data-mining direction — Yen emphasized the need for long-term thinking by privacy startups.
The original article contains 967 words, the summary contains 190 words. Saved 80%. I'm a bot and I'm open source!
