they have opensource clients that do PGP encryption similar to how your web client would do. Doing encryption on the client is the only way to ensure the server can’t have access to the content of the emails. It just happens that the client is called “proton bridge” or “proton web” instead of OpenPGP.
So tell me, why is it that Proton simply didn’t go for OpenPGP + SMTP + IMAP and simply build a nice web / desktop client for it and kept it compatible with all the other generic solutions out there? What’s the point? Why can’t Proton be just a simple way to get OpenPGP working for anyone who doesn’t have the tech knowledge / time instead of a bunch of proprietary solutions?
The old Lavabit service (before Snowden) was a good example of how you can keep email secure while still providing generic IMAP/SMTP access. It worked, even better than everyone expected. While their model wasn’t perfect they indeed solved the problem.
So your claim that you are vendor locked it’s simply false, deal with it.
It isn’t and I hope I’m never proven right about Proton for your own sake.
They stop giving you the bridge? You move in less than 1h to another provider.
Yes you move if you can. Once you’ve about a TB of e-mail good luck on their export with all the missing metadata. :)
This has anyway nothing to do with being vendor locked, which in fact you completely did not explain. You talked about interoperability at most, which is not related to vendor lock.
It has all to do with vendor lock-in and it is already explained. If a company uses shady stuff that restricts interoperability by definition it is a form of vendor lock-in as you won’t be able to move to another provider as quickly and fast as you might with others.
You also made additional uniformed or false claims: (…) TLS being helpful for e2ee. Is not in the context of email.
And it is, because there’s specific metadata that might get leaked on email headers if not minimized by other techniques that will get protected with TLS between servers. It isn’t perfect but it’s better than having email servers delivering PGP mail over plain text connections. You should be ashamed of yourself for even suggesting that there’s no usefulness whatsoever for this use case.
You failed to understand why using native Cal/Web/CardDAV is incompatible with e2ee.
No. I never said they were, but here’s how decent companies deal with that: they encrypt the data in transit (using TLS) and when stored on their servers by using key store and that is itself encrypted with your login password / hash / derivation or some similar technique. When a device want’s to retrieve the information then the server uses the submitted password to decrypt the key and then it uses it to decrypt the information and sends it to the client.
You clearly have bought into their propaganda but oh well think whatever you want, you’re the one using the service and it’s your data that will be hostage after all.
So tell me, why is it that Proton simply didn’t go for OpenPGP + SMTP + IMAP and simply build a nice web / desktop client for it and kept it compatible with all the other generic solutions out there? What’s the point?
How is this relevant? I don’t know and I don’t care why they picked this technical solution.
It isn’t and I hope I’m never proven right about Proton for your own sake.
It is, and you have been proven wrong. Either that, or you completely misuse or worse misunderstand what vendor lock is.
Yes you move if you can.
It’s not if. You can.
It has all to do with vendor lock-in and it is already explained.
Yes, you explained interoperability that has nothing to do with vendor lock. They are two. different. things.
If a company uses shady stuff that restricts interoperability by definition it is a form of vendor lock-in as you won’t be able to move to another provider as quickly and fast as you might with others.
False. Again.
Interoperability it’s a property that has to do with using the application. Interoperable applications potentially can totally vendor lock. Lemmy interoperates with Mastodon, but vendor locks you because you can not export everything and port all your content away.
You definition is wrong. Just admit you misused the term and move on, there is no need to double down.
And it is, because there’s specific metadata that might get leaked on email headers if not minimized by other techniques that will get protected with TLS between servers.
They use TLS. TLS is useful for transport security. Proton uses TLS.
TLS doesn’t have anything to do with e2ee in the context of emails because TLS is always terminated by the server. Therefore it is by definition not an e2ee protocol in this context.
It is in the context of web, because there the two “ends” are your browser and the web server. It’s not in the context of messaging where the other “end” is another client.
It isn’t perfect
This has nothing to do with perfection, you are simply misunderstanding fundamentally what e2ee is in this context.
it’s better than having email servers delivering PGP mail over plain text connections
And in fact Proton doesn’t do that.
You should be ashamed of yourself for even suggesting that there’s no usefulness whatsoever for this use case.
I am not ashamed because I understand TLS, and I understand that it’s useless in the context of email e2ee. You simply don’t understand the topic but feel brave enough to evangelize on the internet about something you don’t fully understand.
here’s how decent companies deal with that: they encrypt the data in transit (using TLS) and when stored on their servers by using key store and that is itself encrypted with your login password / hash / derivation or some similar technique.
JFC.
Proton uses TLS for transit connections.
E2EE means that the server does not have access to the data. If the server has the key, in whatever form, and can perform a decryption, it’s not e2ee. The only way to have e2ee for these protocols is that the client(s) and only the clients do the encryption/decryption operations. This is exactly what Proton clients do. They use DAV protocols but they extend them with implementing encryption on the client side. Therefore, naturally, by design, they are not compatible with servers which -instead- expect data unencrypted to serve it, unencrypted (only via TLS, which again, it’s a transport protocol, has nothing to do with application data) to other clients.
Ironically, when saying what “decent companies” do, you have described what Proton does: they use your client key to encrypt data on client side. Then they transfer this data via a secure channel (TLS). The server has no keys and sees only encrypted data, and serves such data to other clients (Proton web, android etc.) that do the decryption/encryption operation back. Underlying it’s still CalDAV/WebDAV.
You clearly have bought into their propaganda but oh well think whatever you want, you’re the one using the service and it’s your data that will be hostage after all.
I don’t need to buy propaganda, I am a security professional and do this stuff for a living. I also understand what vendor lock is because all the companies I ever worked with had forms of vendor lock, and I am aware of Proton features instead.
Maybe you should really stop, reflect and evaluate if you really have the competence to make certain claims on the internet. I understand nobody is there keeping score and there are no consequences, but you are honestly embarassing yourself and spreading false information due to the clear lack of understanding about concepts such as e2ee, transport security, vendor locking, etc.
because I understand TLS, and I understand that it’s useless in the context of email e2ee. You simply don’t understand the topic but feel brave enough to evangelize
Your just focusing on strict technical definitions and completely ignoring the context of things. I described before how TLS is useful in the context of some SMTP e2e encrypted solution.
Ironically, when saying what “decent companies” do, you have described what Proton does: they use your client key to encrypt data on client side.
Yet they don’t provide the information in standard protocols…
If the server has the key, in whatever form, and can perform a decryption, it’s not e2ee. The only way to have e2ee for these protocols is that the client(s) and only the clients do the encryption/decryption operations. This is exactly what Proton clients do
I never questioned that. With SMTP you can do true e2ee using PGP and friends, with CalDAV/WebDAV you’ll need to have some kind of middle man doing the encryption and decryption - it’s a fair trade off for a specific problem. The original question here wasn’t about CalDAV/WebDAV but about SMTP where you can have true e2ee. Your previous comment of “SMTP requires server to access the data” is simply wrong.
that do the decryption/encryption operation back. Underlying it’s still CalDAV/WebDAV.
Do you have any proof that they use CalDAV/CardDAV? Most likely they don’t. In the same way they don’t do IMAP/SMTP.
Just admit you misused the term and move on, there is no need to double down. (…) I also understand what vendor lock is because all the companies I ever worked with had forms of vendor lock, and I am aware of Proton features instead.
Get over yourself and your purist approaches, when a company provides a service that is standardized in a specific set of protocols and they decide to go ahead and implement their own stuff it is, at least, a subtle, form of vendor lock-in. End of story.
Your just focusing on strict technical definitions and completely ignoring the context of things. I described before how TLS is useful in the context of some SMTP e2e encrypted solution.
Yes, mentioning things that have not to do with e2ee.
Anything that is encrypted with TLS is not e2ee in the context of emails. You talked about metadata, but the server has access to those because it terminates the connection, therefore, they are not e2ee. It’s a protection against leakage between you and the server (and between server and other server, and between server and the destination of your email), not between you and the destination, hence, irrelevant in the context of e2ee. Metadata such as destination can obviously never be e2ee, otherwise the server wouldn’t know where to send the email, and since it needs access to it, it’s not e2ee, whether you use TLS or not.
TLS in this context doesn’t contribute at all to end to end encryption.
Your definition is wrong, e2ee is a technical definition, is not an abstract thing: e2ee means that only the two ends of a conversation have access to the data encrypted. TLS is by definition between you and your mail server, hence it doesn’t provide any benefit in the context of e2ee. It is useful, but for other reasons that have nothing to do with e2ee.
never questioned that. With SMTP you can do true e2ee using PGP and friends
Exactly, and this is what Proton does. You simply don’t accept that Proton decided to write another client that is tightly coupled with their mail service, which is absolutely nothing malicious or vendor-locky, compared to using an already made client. Proton is simply PGP + SMTP.
with CalDAV/WebDAV you’ll need to have some kind of middle man doing the encryption and decryption - it’s a fair trade off for a specific problem.
Yes, and this middle-man is proton client, which sits on the client’s side. I am glad you understood how the only way to have e2ee with *DAV automatically technically impedes you to use “whatever server”. If anybody else but the client does the encryption/decryption, you lost the end-to-end part. I am not saying e2ee in this context is absolutely necessary, you might not care and value more the possibility to plug other *DAV servers, good. Proton is not for you in that case.
but about SMTP where you can have true e2ee
Yes, you can using a PGP client, like OpenPGP of Proton webmail, or Proton bridge. You need stuff on top of SMTP.
Your previous comment of “SMTP requires server to access the data” is simply wrong.
Nope, you are simply misinterpreting it. In SMTP the server requires access to the data because it’s the one delivering it. PGP is built so that the data it’s a ciphertext and not plaintext, so that the server can’t see the actual content of the mail, but it needs to have the data and ship it, in contrast for example to a p2p protocol. PGP is however on top of SMTP and requires a client doing it for you. OpenPGP or Proton do exactly this. There is no way to support SMTP “natively” and offer e2ee. You would like Proton not to do e2ee and leave the responsibility of the client to do the PGP part, with the freedom of picking whatever client you want? Well, that’s exactly the opposite of their business model, since what they aimed is to make PGP de-facto transparent to the users so that it’s available even to people who are not advanced users.
Do you have any proof that they use CalDAV/CardDAV?
I sent you already a GIthub search of their clients for SMTP, look for yourself in the code. Do you think that makes any sense at all for them to reinvent the wheel and come up with ad-hoc protocols when all they need is a client?
You can also have a look at the job offers they post: https://boards.eu.greenhouse.io/proton/jobs/4294852101
You can see SMTP mentioned and experience with Postfix in production. It’s very likely that they are running that in the background.
Get over yourself and your purist approaches, when a company provides a service that is standardized in a specific set of protocols and they decide to go ahead and implement their own stuff it is, at least, a subtle, form of vendor lock-in. End of story.
No it’s not. Vendor lock means:
In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products, unable to use another vendor without substantial switching costs.
Proton uses open standards, and just builds clients that wrap them. This means, emails are in a format that can easily be imported elsewhere, same for Calendar and Contacts.
You are now watering down the definition of vendor lock to try to make your claim less wrong, but it is wrong. I repeat, and you are welcome to prove me wrong:
There is no substantial cost in any form to migrate from Proton to an equivalent service elsewhere:
You can migrate email simply, by changing domain DNS records and exporting/importing the data.
You can export your Calendar in a standard format
You can export your Contacts in a standard format
This means that I can change vendor easily without significant cost, hence I am not locked-in.
What you actually mean is that while using Proton you can’t interoperate easily with other tools, and this is a by-design compromise to have e2ee done in the way they wanted to make it, which is available to mainstream population. You disagree with their approach? Absolutely legitimate, you prefer to use OpenPGP, handle keys and everything yourself? Then for sure, Proton is not worth for you as you can choose the tools you want if that’s important for you.
But there is no vendor-lock, they simply bundled together the email client with the PGP client, so that you don’t have the full flexibility of separating the two.
You disagree with this definition of vendor lock? Awesome, give me your definition and link some source that use that definition. Because if you keep moving the goalpost and redefine what vendor lock means, there is no point to discuss.
So tell me, why is it that Proton simply didn’t go for OpenPGP + SMTP + IMAP and simply build a nice web / desktop client for it and kept it compatible with all the other generic solutions out there? What’s the point? Why can’t Proton be just a simple way to get OpenPGP working for anyone who doesn’t have the tech knowledge / time instead of a bunch of proprietary solutions?
The old Lavabit service (before Snowden) was a good example of how you can keep email secure while still providing generic IMAP/SMTP access. It worked, even better than everyone expected. While their model wasn’t perfect they indeed solved the problem.
It isn’t and I hope I’m never proven right about Proton for your own sake.
Yes you move if you can. Once you’ve about a TB of e-mail good luck on their export with all the missing metadata. :)
It has all to do with vendor lock-in and it is already explained. If a company uses shady stuff that restricts interoperability by definition it is a form of vendor lock-in as you won’t be able to move to another provider as quickly and fast as you might with others.
And it is, because there’s specific metadata that might get leaked on email headers if not minimized by other techniques that will get protected with TLS between servers. It isn’t perfect but it’s better than having email servers delivering PGP mail over plain text connections. You should be ashamed of yourself for even suggesting that there’s no usefulness whatsoever for this use case.
No. I never said they were, but here’s how decent companies deal with that: they encrypt the data in transit (using TLS) and when stored on their servers by using key store and that is itself encrypted with your login password / hash / derivation or some similar technique. When a device want’s to retrieve the information then the server uses the submitted password to decrypt the key and then it uses it to decrypt the information and sends it to the client.
You clearly have bought into their propaganda but oh well think whatever you want, you’re the one using the service and it’s your data that will be hostage after all.
How is this relevant? I don’t know and I don’t care why they picked this technical solution.
It is, and you have been proven wrong. Either that, or you completely misuse or worse misunderstand what vendor lock is.
It’s not if. You can.
Yes, you explained interoperability that has nothing to do with vendor lock. They are two. different. things.
False. Again. Interoperability it’s a property that has to do with using the application. Interoperable applications potentially can totally vendor lock. Lemmy interoperates with Mastodon, but vendor locks you because you can not export everything and port all your content away. You definition is wrong. Just admit you misused the term and move on, there is no need to double down.
They use TLS. TLS is useful for transport security. Proton uses TLS. TLS doesn’t have anything to do with e2ee in the context of emails because TLS is always terminated by the server. Therefore it is by definition not an e2ee protocol in this context. It is in the context of web, because there the two “ends” are your browser and the web server. It’s not in the context of messaging where the other “end” is another client.
This has nothing to do with perfection, you are simply misunderstanding fundamentally what e2ee is in this context.
And in fact Proton doesn’t do that.
I am not ashamed because I understand TLS, and I understand that it’s useless in the context of email e2ee. You simply don’t understand the topic but feel brave enough to evangelize on the internet about something you don’t fully understand.
JFC. Proton uses TLS for transit connections. E2EE means that the server does not have access to the data. If the server has the key, in whatever form, and can perform a decryption, it’s not e2ee. The only way to have e2ee for these protocols is that the client(s) and only the clients do the encryption/decryption operations. This is exactly what Proton clients do. They use DAV protocols but they extend them with implementing encryption on the client side. Therefore, naturally, by design, they are not compatible with servers which -instead- expect data unencrypted to serve it, unencrypted (only via TLS, which again, it’s a transport protocol, has nothing to do with application data) to other clients.
Ironically, when saying what “decent companies” do, you have described what Proton does: they use your client key to encrypt data on client side. Then they transfer this data via a secure channel (TLS). The server has no keys and sees only encrypted data, and serves such data to other clients (Proton web, android etc.) that do the decryption/encryption operation back. Underlying it’s still CalDAV/WebDAV.
I don’t need to buy propaganda, I am a security professional and do this stuff for a living. I also understand what vendor lock is because all the companies I ever worked with had forms of vendor lock, and I am aware of Proton features instead.
Maybe you should really stop, reflect and evaluate if you really have the competence to make certain claims on the internet. I understand nobody is there keeping score and there are no consequences, but you are honestly embarassing yourself and spreading false information due to the clear lack of understanding about concepts such as e2ee, transport security, vendor locking, etc.
Your just focusing on strict technical definitions and completely ignoring the context of things. I described before how TLS is useful in the context of some SMTP e2e encrypted solution.
Yet they don’t provide the information in standard protocols…
I never questioned that. With SMTP you can do true e2ee using PGP and friends, with CalDAV/WebDAV you’ll need to have some kind of middle man doing the encryption and decryption - it’s a fair trade off for a specific problem. The original question here wasn’t about CalDAV/WebDAV but about SMTP where you can have true e2ee. Your previous comment of “SMTP requires server to access the data” is simply wrong.
Do you have any proof that they use CalDAV/CardDAV? Most likely they don’t. In the same way they don’t do IMAP/SMTP.
Get over yourself and your purist approaches, when a company provides a service that is standardized in a specific set of protocols and they decide to go ahead and implement their own stuff it is, at least, a subtle, form of vendor lock-in. End of story.
Yes, mentioning things that have not to do with e2ee. Anything that is encrypted with TLS is not e2ee in the context of emails. You talked about metadata, but the server has access to those because it terminates the connection, therefore, they are not e2ee. It’s a protection against leakage between you and the server (and between server and other server, and between server and the destination of your email), not between you and the destination, hence, irrelevant in the context of e2ee. Metadata such as destination can obviously never be e2ee, otherwise the server wouldn’t know where to send the email, and since it needs access to it, it’s not e2ee, whether you use TLS or not. TLS in this context doesn’t contribute at all to end to end encryption. Your definition is wrong, e2ee is a technical definition, is not an abstract thing: e2ee means that only the two ends of a conversation have access to the data encrypted. TLS is by definition between you and your mail server, hence it doesn’t provide any benefit in the context of e2ee. It is useful, but for other reasons that have nothing to do with e2ee.
Exactly, and this is what Proton does. You simply don’t accept that Proton decided to write another client that is tightly coupled with their mail service, which is absolutely nothing malicious or vendor-locky, compared to using an already made client. Proton is simply PGP + SMTP.
Yes, and this middle-man is proton client, which sits on the client’s side. I am glad you understood how the only way to have e2ee with *DAV automatically technically impedes you to use “whatever server”. If anybody else but the client does the encryption/decryption, you lost the end-to-end part. I am not saying e2ee in this context is absolutely necessary, you might not care and value more the possibility to plug other *DAV servers, good. Proton is not for you in that case.
Yes, you can using a PGP client, like OpenPGP of Proton webmail, or Proton bridge. You need stuff on top of SMTP.
Nope, you are simply misinterpreting it. In SMTP the server requires access to the data because it’s the one delivering it. PGP is built so that the data it’s a ciphertext and not plaintext, so that the server can’t see the actual content of the mail, but it needs to have the data and ship it, in contrast for example to a p2p protocol. PGP is however on top of SMTP and requires a client doing it for you. OpenPGP or Proton do exactly this. There is no way to support SMTP “natively” and offer e2ee. You would like Proton not to do e2ee and leave the responsibility of the client to do the PGP part, with the freedom of picking whatever client you want? Well, that’s exactly the opposite of their business model, since what they aimed is to make PGP de-facto transparent to the users so that it’s available even to people who are not advanced users.
https://github.com/search?q=org%3AProtonMail+CalDAV&type=code you can dig yourself into the code if you are curious to understand.
I sent you already a GIthub search of their clients for SMTP, look for yourself in the code. Do you think that makes any sense at all for them to reinvent the wheel and come up with ad-hoc protocols when all they need is a client? You can also have a look at the job offers they post: https://boards.eu.greenhouse.io/proton/jobs/4294852101 You can see SMTP mentioned and experience with Postfix in production. It’s very likely that they are running that in the background.
No it’s not. Vendor lock means:
Proton uses open standards, and just builds clients that wrap them. This means, emails are in a format that can easily be imported elsewhere, same for Calendar and Contacts. You are now watering down the definition of vendor lock to try to make your claim less wrong, but it is wrong. I repeat, and you are welcome to prove me wrong:
This means that I can change vendor easily without significant cost, hence I am not locked-in.
What you actually mean is that while using Proton you can’t interoperate easily with other tools, and this is a by-design compromise to have e2ee done in the way they wanted to make it, which is available to mainstream population. You disagree with their approach? Absolutely legitimate, you prefer to use OpenPGP, handle keys and everything yourself? Then for sure, Proton is not worth for you as you can choose the tools you want if that’s important for you. But there is no vendor-lock, they simply bundled together the email client with the PGP client, so that you don’t have the full flexibility of separating the two.
You disagree with this definition of vendor lock? Awesome, give me your definition and link some source that use that definition. Because if you keep moving the goalpost and redefine what vendor lock means, there is no point to discuss.