If the owner of the standard notes will now be a proton, doesn’t that contradict this principle? I have a proton email account but I don’t want it linked to my standard notes account. I don’t strongly trust companies that offer packaged services like google or Microsoft. I prefer to have one service from one company. I am afraid that now I will have to change where I save my notes. What do you guys think about this?
Other providers will return garbage to your mail client. The mail client itself must have PGP capability (plenty don’t).
I’ve yet to find any functionality missing from the bridge’s IMAP server that’s missing from any other IMAP server.
There’s not currently a real time way to get that data, but it’s hardly “vendor lockin.”
There’s something ironic to me about chewing Proton out for alleged vendor lock in while using iOS / Apple products.
You got there yourself, that’s one of the problems.
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.
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.
That’s just not true, you’re severely misinformed on this.
Proton took the established practice of PGP encrypted email and put it in a nice package. That’s why you can add public keys and just message somebody that’s using Thunderbird.
There is no “open protocol for end to end encrypted email”, XMPP is not applicable here. There’s no “IMAP for PGP” there’s just IMAP, so they made a bridge so you can use IMAP even if your mail client doesn’t support PGP.
Could they have made an IMAP server that returns the PGP emails and requires your mail client to handle the decryption? Yes. However, that goes against a major selling point of the product which is that it manages all that encryption for you (like a password manager). Nobody in their right mind would use that.
This isn’t some matter of privacy coolaid and fanboyism; they did the open interoperable thing. You can even (as an example use case) if you’re a new customer that was doing PGP email on your own, upload your own existing PGP key, and use that with Proton if you don’t want to change the PGP public key people use to send you email.
Edit: Perhaps you’ve been confused by some falsehoods coming from Tutanota or confused the two https://proton.me/blog/proton-vs-tuta-encryption
I wasn’t even aware of those alleged falsehoods coming from Tutanota…
Essentially my point.
Why not, if they actually do everything with open standards and by the book, why can’t they provide IMAP/SMTP access to everyone who wants BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… but they don’t and that is a red flag. Most of their users are tech savvy people wouldn’t oppose setting that up.
Because you’re paying them so you don’t have to do that. Why would you pay them a premium if you’re just going to do it yourself anyways?
Also that costs money to develop, maintain, and run. Which takes money/resources away from things most customers care about.
There aren’t red flags here, everything is open source, this is all verifiable information. You’re just refusing to accept that.
Because they can provide other assurances with their service even if I’ve to setup the PGP in my e-mail client. Like knowing the entre thing is actually managed with privacy in mind, like not logging more than they should etc.