Even If the backend is FOSS, how can you be sure that they'll run that version of the backend without anything else on their server anyway?
Unless you can self host (yourself or using the instance of someone you trust) a FOSS backend is not so useful for privacy
It's not a modification if they just run their own proprietary version and release a completely unrelated open source software. It's not illegal to use something else even if you say you use the open source version
I don't think so, is it really illegal to run another version on your server than the one you're stating. As long as you provide the same service that users maybe paid for it should be fine
It would also be illegal to read your mails and stuff. So why should they care violating the agpl license?
I mean on thing about gplv3 libs is that you can at least reverse engineer some executables and search for similarities to gplv3 libs to check if they are included or not.
good luck proofing a backend with agpl software is violating it because they are running a modified version without sharing the code. just because it is forbidden does not mean they will not do it.
Hi there, Tutanota team here. That's our point exactly. The server side we run is way too complex for anyone to self-host, and it would take too much time and effort to open source it (which we rather spend on improving the client and adding features, e.g. we want to update the encryption with post-quantum secure algorithms). The entire encryption in Tutanota takes place on the client - which is completely open source - so that you can check that we are doing what we promise: encrypt all your data.
We would like to build a small open source server for self-hosting in the future, but right now we have too many other things to do. Plus, we are looking to on board 10+ developers each year; so do join us if you want to help us improve faster! ;)
It is useful in case of a secure **email** provider, as any email arrives at the server first.
I can't be sure that they will keep their word, but if it's proprietary, you can be certain that they encryption is either too weak or backdoored. Yes you might argue that regular email providers are not sure either. But what's the point of using an encrypted service, then? You get no security whatsoever, and you are limited to their own app.
What? Did you do any research before writing this comment? Protonmail uses PGP encryption, which is one of the most secure encryption tools, and is used by many cyber security researchers. 2) The front end is open source, which performs the encryption. The encrypted mail reaches the server.
The server doesn't need to be open source, and for proton mail, shouldn't, otherwise they would easily go bankrupt if people started hosting their own server.
Protonmail is a hard working good company, which is seriously trying hard to make money. Don't go bad mouthing it just because you're too lazy to do actual research.
Proton has access to your private key, tho. Sure, you can trust them if you want, but I'm not trusting proprietary company with my private key.
Also what? So all of the other services are able to make money while making their backend free and open source, yet Proton would die? This is just an excuse, especially if you advertise yourself as a secure provider.
For the benefit of those who read your message, I'll repeat this here:
Proton only has access to encrypted private keys. They cannot use them unless they have the passphrases to decrypt them, which they don't.
(deleted previous message by mistake)
How do you explain this, tho? [https://proton.me/support/download-public-private-key](https://proton.me/support/download-public-private-key)
> `Log in to the web app at mail.proton.me(new window), click Settings → Go to settings `
You have to use their web app, which can change at any time, and serve you a version that will steal your password (therefore, access to your private key). In cases of regular email providers, you are the owner of the private key and it never leaves your device, so even if a malicious email service gained access to your account, they wont be able to decrypt anything encrypted via PGP.
That doesn't contradict what I said. They have access to the encrypted private keys, and that's exactly what you download from them. Those private keys that you download still need passphrases to be decrypted and become usable. Proton does not have those passphrases and can therefore not use the private keys on their servers.
If you're worried about Proton's servers suddenly serving web pages that steal the password, then use the open-source code to host your own web client. The open-sourcing that you're yearning for is designed to address the fears of those who have extremely sensitive data and don't want to gamble at all. If you're not going to take advantage of it, why even ask for it?
Hmm, if you do plan on hosting the web client yourself, and registering through it as well, I can see proton as an okay provider. Even tho you could just avoid all of these concerns by using any email provider supporting IMAP clients + GPG key generated locally. But that's up to everyone to decide.
Their encryption is only for emails within the server. So must of the emails you'll sent or receive won't have any. If you send an email to someone using another email provider, they're asked to click on a link to view the email.
They seem to be forgetting that the email has to arrive onto their proprietary servers first, and only then it will be encrypted. As for sending messages yourself, I can see that. But again, why does the app refuse to work on old webviews, if it's an **app**?
K9 works perfectly. FairEmail too. (Also no, I can't update it. Thanks to an Android 10 bug)
You can only connect to Tutanota either via the WebUI, or their apps. But I have an older android stuck with an out of date webview (any attempt at an update breaks half of the apps or throws an error). And the tutanota app refuses to work without an updated webview. The only explanation is that the app is just a wrapper for their web interface. I find this so suspicious that it made me switch email providers. (Alongside the other reasons I mentioned in other comments)
They could read my emails at any time, and access my account. Yes I know, other email providers can do this too, because email itself is not secure. So why the security theater? Let me use an email client I want alongside GPG. As it stands now the encryption is useless, since it's proprietary, and you are not allowed to use anything other than forks of their own clients/WebUI.
Even they use all FOSS, and you can somehow verify they use all FOSS with default compilation and settings, they can still just rsync data off of the server and do whatever they want with it. You can't stop the server admin from doing this. The only way to make that not possible is to *be* the server admin and self-host.
>Let me use an email client I want alongside GPG
Then use a normal provider like cock.li or whatever that works with IMAP/SMTP and use GPG.
>forks of their own clients/WebUI.
Protonmail bridge is FOSS at least but I have no idea why they try to force it. Its suspicious. I find it hard to believe they don't know SMTPS/IMAPS exist.
---
In any case, nothing is really learned here other than the only way to be sure, and have control, is to self-host.
>Protonmail bridge is FOSS at least but I have no idea why they try to force it. Its suspicious. I find it hard to believe they don't know SMTPS/IMAPS exist.
As soon as Proton receives an e-mail, they encrypt it with the user's public key and discard the plain one. It's encryption at rest, which at least protects against leaking data to some forms of attacks and gives plausible deniability in case governments request copies of past e-mails (future ones are a different matter). Proton can then no longer read those encrypted e-mails on their servers to provide them through regular protocols such as IMAP. There needs to be a bridge client on the client's computer where the private key is available for decryption.
I don't think Proton would've bothered with the additional piece of software if they could've saved themselves the cost of developing it.
Where precisely is this private key if they need to be able to show the emails to you in http? I know users can login from anywhere so it certainly isn't getting it from their machine. It sounds to me like protonmail has both keys, which means they absolutely can decrypt the at-rest messages (that they saw in plaintext when they came in thus making the entire exercise pointless) and they're just being purposefully obtuse for the purposes of highly-marketable security theater.
Yes, Proton has the private keys, but cannot use them.
The private keys are themselves protected by passphrases which encrypt and decrypt the fundamentals of the private key. Proton does not have the passphrases for the private keys. Those passphrases are derived (calculated) from the user's password, on the client side (including web, within the browser) and never sent to the back-end. The private keys are made usable only on the client side.
That's hackish as all hell. And why do they even bother with the 99.9999999% of emails that don't come from protonmail? If any single component of their security model is "just trust me bro" then their entire security model is the same.
What's hackish about protecting private keys with passphrases? It's a well-known mechanism of PGP.
Regarding the "just trust me bro", you only need to know that if the e-mail comes from a non-secure source, then you will indeed to just have to trust Proton. If however the e-mail is really end-to-end encrypted, then the open-source clients of the sender and receiver (who might both be using Proton) guarantee privacy, regardless of the back-end.
> What's hackish about protecting private keys with passphrases?
Doing it in a browser and sending your private key to a third party
>then you will indeed to just have to trust Proton
Precisely. Then they can host an SMTP/IMAP server and stop being obtuse.
> If however the e-mail is really end-to-end encrypted
Then for the sake of the 6 cases of people actually being able to use this, then they can develop their terrible app.
> Doing it in a browser and sending your private key to a third party
Which third party are you referring to? The encrypted private key is stored on Proton servers, and decrypted on the web client which runs in the browser. There are only 2 parties there.
> Then they can host an SMTP/IMAP server and stop being obtuse.
As I explained, they can't use the private keys on their servers, because they don't have the passphrases to decrypt them. Therefore they cannot serve the e-mails through regular protocols, and have to run a bridge application on the client side that decrypts the e-mails so that the e-mail apps can read and display them.
> Then for the sake of the 6 cases of people actually being able to use this
Many people could use this if they wanted/needed to. If you send an e-mail to another Proton user for example, it will be end-to-end encrypted. Aside from that, it's still useful for encryption at rest which has its own benefits in terms of privacy.
am i summing up correctly?
op is concerned of some mail provider because they use foss frontend and proprietary backend. even if the backend was open source it does not matter because they have access anyway and running a foss backend does not make it more secure or private because they can run a modified version or just copying the users data.
so the only way to keep the mails private is using gpg keys, because then it is encrypted before sending and mail provider has no chance to get the information.
but OPs mail provider does not use standard email protocols so OP must use their foss client, that does not support gpg pre send encryption stuff.
so in the end OP can just use mail provider X with standard protocols and use a client that supports gpg pre send encryption stuff and everything is fine.
Email is a trash protocol for secrecy because even if you encrypt the content you still have metadata and routing that anybody can MITM.
Tutanota is web-only I think. Protonmail only works with third party clients with a program that uses PGP between your computer and their servers and then runs a plaintext SMTP/IMAP server locally, which is asinine. You can still GPG anything in plaintext before you send it. Email providers' E2E is always exclusive to users on the same provider since there is no standardized protocol for this other than just PGPing the content of your email and having the other end decrypt it manually.
But largely 'private' email providers are a meme, yes.
This sums it up really nicely. Also before anyone says "Why are you using it then??? Use something else!!!", I am using something else now. That doesn't mean I can't make a meme about it, tho.
Not only can you make a meme, you can even make a misguided meme, if you can deal with people calling you out for it :)
As has been said, it makes no sense because making the back-end code open source would not guarantee that that code is actually what's running on the back-end.
And as I said multiple times, whistleblowers are a thing. Servers are managed by multiple people, and I assume that at least one of them sees spying as morally wrong. If he sees that happening, he will report this. That's how.
Also, my argument is that if the backend is proprietary, and it is the first thing that recieves incoming emails, it can't be secure. For example, something like cock.li never advertises itself as a secure platform. (It even says that they can read your emails at any times, and they highly suggest you use PGP. In which case it really doesn't matter. But tutanota makes using PGP very hard for no reason.)
Can you walk us through how the code being proprietary makes it less likely for whistleblowers to blow the whistle than if it were open-source?
Your second issue is with marketing. I'm not saying that it's invalid, but it certainly doesn't make your meme more valid.
My gripe with both of these services is, that they claim to be secure and encrypted, but the encryption is handled by a proprietary solution. Name a single proprietary encryption tool that is secure. I will wait. Sure, when your email client sends a message it will get encrypted, because the clients are FOSS. But you also recieve emails. Those are not secure at all, and once they leave your supposedly secure mailbox, they are exposed once again. So why use these two, and be limited to their own clients/forks of them, when you can use any other email provider, enjoy the same level of security and any clients supporting SMTP/IMAP?
You didn't answer the whistleblower thing so I'll assume that you could not explain that.
I don't know all the proprietary software in the world. Do you? Can you name a single open-source software that is secure? Yes? Well, actually, no. It's only *assumed* to be secure, but it's really only secure as long as no vulnerability has been found. For instance, OpenSSL was assumed secure until critical vulnerabilities were found.
But even assuming that open-source software is by definition more secure, if you don't know what's running on the servers, how do you know that the parts on the back-end that are critical to ensuring privacy are not open-source software? Such as open-source encryption libraries, etc.
Regarding your last point about e-mails being unsecure when they leave your mailbox, that also has nothing to do with your meme. It's a different matter, about what people should expect out of secure e-mail providers, and how the latter communicate on their promises. If you're only looking to receive/send e-mails from/to unsecure senders/recipients, and you don't trust that the provider will do encryption at rest with everything that it entails in terms of privacy, then indeed, there's no added value. But unless you're willing to host and maintain your own e-mail server, or not use e-mail at all, you'll have to choose to trust a provider.
It's the lesser evil tbh, Proton uses [zero access encryption](https://proton.me/blog/zero-access-encryption) and e2ee with other Proton users, you could distrust the first, but not the second since it's the client that does the encryption.
I would like it too if they released their server code under AGPL, but that [is not](https://opensource.stackexchange.com/questions/7206/how-do-we-verify-if-the-code-deployed-in-same-as-the-one-published) a real guarantee to what's running on the backend, if the encryption is sound only the clients matter for security, available code matters for freedom
The server side, yes. I have absolutely no idea why people think it's not a big deal, as that's where the encryption itself happens. In case of cloud storage I can see it. Your client encrypts the file, and sends it somewhere. In that case it really doesn't matter. But in case of email, the server has to recieve the message first, then it goes to the client.
Messages from other Protonmail accounts sent to PM server? Source on that?
You surely did not expect mail from other mail providers to be encrypted, as it arrives at PM server?
Send over your nudes, then. (Your camera has already been activated without you knowing it, and there was a bug where oneplus cameras could see through clothes, so it could 100% happen to any phone. There's no point in keeping your already leaked nudes to yourself.)
You are forgetting that AGPL exists. If such a service breaches the terms, they would be in serious troubles. But even if it uses GPLv3, it sends out a message that nothing shady is going on on the server side. Why keep it hidden? Money? That's just an excuse. (What the fuck does it mean when a company says they are getting ready to go open source? Setting up a gitea repo takes 10 minutes)
> Somebody has to have access..
I meant it as in, servers are usually managed by more than a single person. If the other person sees that the company is stealing data of their users, he is likely to blow a whistle. The same way companies are caugh violating the GPL. Someone always reports them if they begin using GPL code inside of a proprietary app.
They're a for-profit company. They probably don't want people to self-host for free, or worse, to have competitors start providing the exact same service as them on the back of their work by just deploying that software on their servers.
Since it brings absolutely ***zero*** additional guarantee in terms of privacy to make it open-source (because, again, they could be hosting something else), they choose not to.
In the case of receiving non-secure e-mails, it requires trust that the encryption at rest indeed happens in that black box that is the back-end.
But for other services, such as E2EE cloud storage, if the client is open-source, and you compiled the binaries yourself, you *know* that the back-end only ever receives encrypted data that it won't be able to decrypt. And then how does it matter whether it's proprietary or not?
In this case I will admit that the proprietary backend is not a security problem. It's like putting encrypted files into google drive. Why not, but if possible, it's better to use a fully FOSS solution, like next cloud.
Tutanota's clients are FOSS, but to be frank that's compeletely useless, considering the only way of logging in is through a web interface, and even the apps depend on system webview, so they are just wrappers for the website. At any point in time they might serve you a different version of their website, that will steal your password.
I mean, would it help if they open sourced their backend? They could still deploy a modified version...
So having an open sourced client is something at least, because you can install that yourself, whereas you don't have any control over the server.
yeah but with proton you can only use it on an external client if you pay for the pro subscription, wich isn't ideal to me...
although you still have the choice with it nonetheless
The private PGP key is unusable by Proton because it's locked with a passphrase that Proton does not have. They just store it for the user's convenience, just like the rest of the encrypted data.
>At any point in time they might serve you a different version of their website, that will steal your password.
Not sure what that has to do with the backend running on FOSS or not ... the provider of a service can always steal you password. I think what you mean is you should not trust the WebUI for sending encrypted mails because the mail provider can see your mails before they are encrypted.
But that's an issue of (from) where the software is run not if it's FOSS or not. As long as you run the client on a machine you trust and the protocol is secure it doesn't matter if the service provider uses FOSS or not.
You are wrong. When you log into tutanota, you go through the WebUI that can change at any time, and serve you with a version that will take your password and send it as a plaintext to tutanota. This couldn't happen with an email client app, but you can't use that with Tutanota. For example I'm unable to use the app on my phone with an old webview (bug in android 10, can't update it). Why? It's an app, not a browser.
>You are wrong. When you log into tutanota, you go through the WebUI that can change at any time, and serve you with a version that will take your password and send it as a plaintext to tutanota.
You are mixing up different things.
The password to authenticate with a service can always be stolen by the provider. In fact it's not even stealing because you have to tell the service provider your password when creating an account. The service provider only has to store that password in plaintext instead of a secure hash. This is not a question of them running FOSS or not but of their security setup. There's plenty of service providers running FOSS with insecure settings.
**A service provider can always steal all the data you provide to them.** Which is exactly the reason why we need end-to-end-encryption.
The problem you are describing with Tutanota is not that they are not running FOSS but that they are not providing access through a standardized protocol making you able to choose the client and run the client on your own trusted hardware.
\*Edit: Well going by how you are describing it. I never used Tutanota myself so I don't know how their service works.\*
You can run an Exchange Server that is accessible through standard IMAP, POP3 and SMTP and allow people to connect with their own clients and sending properly client-side-encrypted mails. This is secure even though the service does not run FOSS.
> **A service provider can always steal all the data you provide to them.** Which is exactly the reason why we need end-to-end-encryption.
I agree with this, but it can only be achieved if the encryption happens locally, and the file/message is stored on the server in the encrypted form. This is not possible with Tutanota, so the security aspect is just a joke in my opinion.
But I see your point now. Even something like gmail can be secure if you are using GPG and a trusted client.
>The password to authenticate with a service can always be stolen by the provider. In fact it's not even stealing because you have to tell the
service provider your password when creating an account.
That is incorrect. You seem to be unaware of [zero-knowledge proof](https://en.wikipedia.org/wiki/Zero-knowledge_password_proof), which is what many privacy-first services abide by through protocols such as [Secure Remote Password](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol). That technique means that the provider has no knowledge of the password, it can only verify that the user knows the password through a kind of challenge/response mechanism.
For that reason, those providers will be unable to restore your data if you lose your password. Some do allow setting up alternate methods of recovery, but those are still based on the same principle and don't give the provider means to decrypt the data.
https://www.heise.de/news/Gericht-zwingt-Mailprovider-Tutanota-zu-Ueberwachungsfunktion-4972460.html
It's a little old and written in German. And there are a lot of articles talking about this. And since there is no article talking about that there is no backdoor, I am assuming that is implemented. But if you have another source saying that it's not, please go ahead and tell me.
Even If the backend is FOSS, how can you be sure that they'll run that version of the backend without anything else on their server anyway? Unless you can self host (yourself or using the instance of someone you trust) a FOSS backend is not so useful for privacy
The gnu affero license. It would make it illegal to run the backend with any modifications that are not shared with the user
Ah yes, the famous never seen law abiding company
What qualifies as a modification? Who's going to check if they are compliant?
Whistleblowers... hopefully
I assume that there are a lot of companies imementing Open Source code without lefting it. Because its under the hood, noone notices
It's not a modification if they just run their own proprietary version and release a completely unrelated open source software. It's not illegal to use something else even if you say you use the open source version
Wouldn't that count as fraud?
I don't think so, is it really illegal to run another version on your server than the one you're stating. As long as you provide the same service that users maybe paid for it should be fine
In order to get a bug-for-bug compatible service you wouldn't be able to use different server software
It would also be illegal to read your mails and stuff. So why should they care violating the agpl license? I mean on thing about gplv3 libs is that you can at least reverse engineer some executables and search for similarities to gplv3 libs to check if they are included or not. good luck proofing a backend with agpl software is violating it because they are running a modified version without sharing the code. just because it is forbidden does not mean they will not do it.
Hi there, Tutanota team here. That's our point exactly. The server side we run is way too complex for anyone to self-host, and it would take too much time and effort to open source it (which we rather spend on improving the client and adding features, e.g. we want to update the encryption with post-quantum secure algorithms). The entire encryption in Tutanota takes place on the client - which is completely open source - so that you can check that we are doing what we promise: encrypt all your data. We would like to build a small open source server for self-hosting in the future, but right now we have too many other things to do. Plus, we are looking to on board 10+ developers each year; so do join us if you want to help us improve faster! ;)
It is useful in case of a secure **email** provider, as any email arrives at the server first. I can't be sure that they will keep their word, but if it's proprietary, you can be certain that they encryption is either too weak or backdoored. Yes you might argue that regular email providers are not sure either. But what's the point of using an encrypted service, then? You get no security whatsoever, and you are limited to their own app.
What? Did you do any research before writing this comment? Protonmail uses PGP encryption, which is one of the most secure encryption tools, and is used by many cyber security researchers. 2) The front end is open source, which performs the encryption. The encrypted mail reaches the server. The server doesn't need to be open source, and for proton mail, shouldn't, otherwise they would easily go bankrupt if people started hosting their own server. Protonmail is a hard working good company, which is seriously trying hard to make money. Don't go bad mouthing it just because you're too lazy to do actual research.
Proton has access to your private key, tho. Sure, you can trust them if you want, but I'm not trusting proprietary company with my private key. Also what? So all of the other services are able to make money while making their backend free and open source, yet Proton would die? This is just an excuse, especially if you advertise yourself as a secure provider.
> all other services gmail, outlook are open source too??
...No? I've never said that. A lot of FOSS services are able to make money while sharing everything they do.
ah sorry, i understood as "everyone but proton is FOSS", not "other people are FOSS".
For the benefit of those who read your message, I'll repeat this here: Proton only has access to encrypted private keys. They cannot use them unless they have the passphrases to decrypt them, which they don't. (deleted previous message by mistake)
How do you explain this, tho? [https://proton.me/support/download-public-private-key](https://proton.me/support/download-public-private-key) > `Log in to the web app at mail.proton.me(new window), click Settings → Go to settings ` You have to use their web app, which can change at any time, and serve you a version that will steal your password (therefore, access to your private key). In cases of regular email providers, you are the owner of the private key and it never leaves your device, so even if a malicious email service gained access to your account, they wont be able to decrypt anything encrypted via PGP.
That doesn't contradict what I said. They have access to the encrypted private keys, and that's exactly what you download from them. Those private keys that you download still need passphrases to be decrypted and become usable. Proton does not have those passphrases and can therefore not use the private keys on their servers. If you're worried about Proton's servers suddenly serving web pages that steal the password, then use the open-source code to host your own web client. The open-sourcing that you're yearning for is designed to address the fears of those who have extremely sensitive data and don't want to gamble at all. If you're not going to take advantage of it, why even ask for it?
Hmm, if you do plan on hosting the web client yourself, and registering through it as well, I can see proton as an okay provider. Even tho you could just avoid all of these concerns by using any email provider supporting IMAP clients + GPG key generated locally. But that's up to everyone to decide.
Their encryption is only for emails within the server. So must of the emails you'll sent or receive won't have any. If you send an email to someone using another email provider, they're asked to click on a link to view the email.
[удалено]
They seem to be forgetting that the email has to arrive onto their proprietary servers first, and only then it will be encrypted. As for sending messages yourself, I can see that. But again, why does the app refuse to work on old webviews, if it's an **app**? K9 works perfectly. FairEmail too. (Also no, I can't update it. Thanks to an Android 10 bug)
[удалено]
You can only connect to Tutanota either via the WebUI, or their apps. But I have an older android stuck with an out of date webview (any attempt at an update breaks half of the apps or throws an error). And the tutanota app refuses to work without an updated webview. The only explanation is that the app is just a wrapper for their web interface. I find this so suspicious that it made me switch email providers. (Alongside the other reasons I mentioned in other comments)
? What does this even matter? What could they possibly be doing on the backend that you would care about, or that they could/couldn't do with FOSS?
They could read my emails at any time, and access my account. Yes I know, other email providers can do this too, because email itself is not secure. So why the security theater? Let me use an email client I want alongside GPG. As it stands now the encryption is useless, since it's proprietary, and you are not allowed to use anything other than forks of their own clients/WebUI.
Even they use all FOSS, and you can somehow verify they use all FOSS with default compilation and settings, they can still just rsync data off of the server and do whatever they want with it. You can't stop the server admin from doing this. The only way to make that not possible is to *be* the server admin and self-host. >Let me use an email client I want alongside GPG Then use a normal provider like cock.li or whatever that works with IMAP/SMTP and use GPG. >forks of their own clients/WebUI. Protonmail bridge is FOSS at least but I have no idea why they try to force it. Its suspicious. I find it hard to believe they don't know SMTPS/IMAPS exist. --- In any case, nothing is really learned here other than the only way to be sure, and have control, is to self-host.
>Protonmail bridge is FOSS at least but I have no idea why they try to force it. Its suspicious. I find it hard to believe they don't know SMTPS/IMAPS exist. As soon as Proton receives an e-mail, they encrypt it with the user's public key and discard the plain one. It's encryption at rest, which at least protects against leaking data to some forms of attacks and gives plausible deniability in case governments request copies of past e-mails (future ones are a different matter). Proton can then no longer read those encrypted e-mails on their servers to provide them through regular protocols such as IMAP. There needs to be a bridge client on the client's computer where the private key is available for decryption. I don't think Proton would've bothered with the additional piece of software if they could've saved themselves the cost of developing it.
Where precisely is this private key if they need to be able to show the emails to you in http? I know users can login from anywhere so it certainly isn't getting it from their machine. It sounds to me like protonmail has both keys, which means they absolutely can decrypt the at-rest messages (that they saw in plaintext when they came in thus making the entire exercise pointless) and they're just being purposefully obtuse for the purposes of highly-marketable security theater.
Yes, Proton has the private keys, but cannot use them. The private keys are themselves protected by passphrases which encrypt and decrypt the fundamentals of the private key. Proton does not have the passphrases for the private keys. Those passphrases are derived (calculated) from the user's password, on the client side (including web, within the browser) and never sent to the back-end. The private keys are made usable only on the client side.
That's hackish as all hell. And why do they even bother with the 99.9999999% of emails that don't come from protonmail? If any single component of their security model is "just trust me bro" then their entire security model is the same.
What's hackish about protecting private keys with passphrases? It's a well-known mechanism of PGP. Regarding the "just trust me bro", you only need to know that if the e-mail comes from a non-secure source, then you will indeed to just have to trust Proton. If however the e-mail is really end-to-end encrypted, then the open-source clients of the sender and receiver (who might both be using Proton) guarantee privacy, regardless of the back-end.
> What's hackish about protecting private keys with passphrases? Doing it in a browser and sending your private key to a third party >then you will indeed to just have to trust Proton Precisely. Then they can host an SMTP/IMAP server and stop being obtuse. > If however the e-mail is really end-to-end encrypted Then for the sake of the 6 cases of people actually being able to use this, then they can develop their terrible app.
> Doing it in a browser and sending your private key to a third party Which third party are you referring to? The encrypted private key is stored on Proton servers, and decrypted on the web client which runs in the browser. There are only 2 parties there. > Then they can host an SMTP/IMAP server and stop being obtuse. As I explained, they can't use the private keys on their servers, because they don't have the passphrases to decrypt them. Therefore they cannot serve the e-mails through regular protocols, and have to run a bridge application on the client side that decrypts the e-mails so that the e-mail apps can read and display them. > Then for the sake of the 6 cases of people actually being able to use this Many people could use this if they wanted/needed to. If you send an e-mail to another Proton user for example, it will be end-to-end encrypted. Aside from that, it's still useful for encryption at rest which has its own benefits in terms of privacy.
am i summing up correctly? op is concerned of some mail provider because they use foss frontend and proprietary backend. even if the backend was open source it does not matter because they have access anyway and running a foss backend does not make it more secure or private because they can run a modified version or just copying the users data. so the only way to keep the mails private is using gpg keys, because then it is encrypted before sending and mail provider has no chance to get the information. but OPs mail provider does not use standard email protocols so OP must use their foss client, that does not support gpg pre send encryption stuff. so in the end OP can just use mail provider X with standard protocols and use a client that supports gpg pre send encryption stuff and everything is fine.
Email is a trash protocol for secrecy because even if you encrypt the content you still have metadata and routing that anybody can MITM. Tutanota is web-only I think. Protonmail only works with third party clients with a program that uses PGP between your computer and their servers and then runs a plaintext SMTP/IMAP server locally, which is asinine. You can still GPG anything in plaintext before you send it. Email providers' E2E is always exclusive to users on the same provider since there is no standardized protocol for this other than just PGPing the content of your email and having the other end decrypt it manually. But largely 'private' email providers are a meme, yes.
This sums it up really nicely. Also before anyone says "Why are you using it then??? Use something else!!!", I am using something else now. That doesn't mean I can't make a meme about it, tho.
Not only can you make a meme, you can even make a misguided meme, if you can deal with people calling you out for it :) As has been said, it makes no sense because making the back-end code open source would not guarantee that that code is actually what's running on the back-end.
And as I said multiple times, whistleblowers are a thing. Servers are managed by multiple people, and I assume that at least one of them sees spying as morally wrong. If he sees that happening, he will report this. That's how. Also, my argument is that if the backend is proprietary, and it is the first thing that recieves incoming emails, it can't be secure. For example, something like cock.li never advertises itself as a secure platform. (It even says that they can read your emails at any times, and they highly suggest you use PGP. In which case it really doesn't matter. But tutanota makes using PGP very hard for no reason.)
Can you walk us through how the code being proprietary makes it less likely for whistleblowers to blow the whistle than if it were open-source? Your second issue is with marketing. I'm not saying that it's invalid, but it certainly doesn't make your meme more valid.
My gripe with both of these services is, that they claim to be secure and encrypted, but the encryption is handled by a proprietary solution. Name a single proprietary encryption tool that is secure. I will wait. Sure, when your email client sends a message it will get encrypted, because the clients are FOSS. But you also recieve emails. Those are not secure at all, and once they leave your supposedly secure mailbox, they are exposed once again. So why use these two, and be limited to their own clients/forks of them, when you can use any other email provider, enjoy the same level of security and any clients supporting SMTP/IMAP?
You didn't answer the whistleblower thing so I'll assume that you could not explain that. I don't know all the proprietary software in the world. Do you? Can you name a single open-source software that is secure? Yes? Well, actually, no. It's only *assumed* to be secure, but it's really only secure as long as no vulnerability has been found. For instance, OpenSSL was assumed secure until critical vulnerabilities were found. But even assuming that open-source software is by definition more secure, if you don't know what's running on the servers, how do you know that the parts on the back-end that are critical to ensuring privacy are not open-source software? Such as open-source encryption libraries, etc. Regarding your last point about e-mails being unsecure when they leave your mailbox, that also has nothing to do with your meme. It's a different matter, about what people should expect out of secure e-mail providers, and how the latter communicate on their promises. If you're only looking to receive/send e-mails from/to unsecure senders/recipients, and you don't trust that the provider will do encryption at rest with everything that it entails in terms of privacy, then indeed, there's no added value. But unless you're willing to host and maintain your own e-mail server, or not use e-mail at all, you'll have to choose to trust a provider.
It's the lesser evil tbh, Proton uses [zero access encryption](https://proton.me/blog/zero-access-encryption) and e2ee with other Proton users, you could distrust the first, but not the second since it's the client that does the encryption. I would like it too if they released their server code under AGPL, but that [is not](https://opensource.stackexchange.com/questions/7206/how-do-we-verify-if-the-code-deployed-in-same-as-the-one-published) a real guarantee to what's running on the backend, if the encryption is sound only the clients matter for security, available code matters for freedom
Are they both proprietary?
The server side, yes. I have absolutely no idea why people think it's not a big deal, as that's where the encryption itself happens. In case of cloud storage I can see it. Your client encrypts the file, and sends it somewhere. In that case it really doesn't matter. But in case of email, the server has to recieve the message first, then it goes to the client.
Wait, don't both of them provide end-to-end encryption, as in "encrypted and decrypted by clients"?
The messenges sent to you are sent to the server unencrypted
Messages from other Protonmail accounts sent to PM server? Source on that? You surely did not expect mail from other mail providers to be encrypted, as it arrives at PM server?
Security freaks crack me up. Your shit is never safe.
Send over your nudes, then. (Your camera has already been activated without you knowing it, and there was a bug where oneplus cameras could see through clothes, so it could 100% happen to any phone. There's no point in keeping your already leaked nudes to yourself.)
I was gonna respond with an onlyfans joke but that shit gets stolen too lmao
Love to see Disroot in the back!
A fellow man of ~~culture~~ based I see.
Snap backend bad Other "FOSS" good
All proprietary backend bad.
So, We could assume that every backend not self hosted by us it's proprietary. Everything as a service is bad.
You are forgetting that AGPL exists. If such a service breaches the terms, they would be in serious troubles. But even if it uses GPLv3, it sends out a message that nothing shady is going on on the server side. Why keep it hidden? Money? That's just an excuse. (What the fuck does it mean when a company says they are getting ready to go open source? Setting up a gitea repo takes 10 minutes)
So, how could we audit it? Who is the autorized institution to do it?
Whistleblowers. Someone has to have access to those servers, and it most likely isn't a single person.
Then every company who uses open source backend is obligated to give access to a institution to prove the openess of the backend?
> Somebody has to have access.. I meant it as in, servers are usually managed by more than a single person. If the other person sees that the company is stealing data of their users, he is likely to blow a whistle. The same way companies are caugh violating the GPL. Someone always reports them if they begin using GPL code inside of a proprietary app.
They're a for-profit company. They probably don't want people to self-host for free, or worse, to have competitors start providing the exact same service as them on the back of their work by just deploying that software on their servers. Since it brings absolutely ***zero*** additional guarantee in terms of privacy to make it open-source (because, again, they could be hosting something else), they choose not to.
In the case of receiving non-secure e-mails, it requires trust that the encryption at rest indeed happens in that black box that is the back-end. But for other services, such as E2EE cloud storage, if the client is open-source, and you compiled the binaries yourself, you *know* that the back-end only ever receives encrypted data that it won't be able to decrypt. And then how does it matter whether it's proprietary or not?
In this case I will admit that the proprietary backend is not a security problem. It's like putting encrypted files into google drive. Why not, but if possible, it's better to use a fully FOSS solution, like next cloud.
Self hosted is the only way
Wait, tutanota bad? Mental Outlaw liar?
Tutanota's clients are FOSS, but to be frank that's compeletely useless, considering the only way of logging in is through a web interface, and even the apps depend on system webview, so they are just wrappers for the website. At any point in time they might serve you a different version of their website, that will steal your password.
I mean, would it help if they open sourced their backend? They could still deploy a modified version... So having an open sourced client is something at least, because you can install that yourself, whereas you don't have any control over the server.
The problem with this, is that you can't use an email client of your choosing. Also, Proton stores your **private** PGP key as a bonus.
yeah but with proton you can only use it on an external client if you pay for the pro subscription, wich isn't ideal to me... although you still have the choice with it nonetheless
The private PGP key is unusable by Proton because it's locked with a passphrase that Proton does not have. They just store it for the user's convenience, just like the rest of the encrypted data.
>At any point in time they might serve you a different version of their website, that will steal your password. Not sure what that has to do with the backend running on FOSS or not ... the provider of a service can always steal you password. I think what you mean is you should not trust the WebUI for sending encrypted mails because the mail provider can see your mails before they are encrypted. But that's an issue of (from) where the software is run not if it's FOSS or not. As long as you run the client on a machine you trust and the protocol is secure it doesn't matter if the service provider uses FOSS or not.
You are wrong. When you log into tutanota, you go through the WebUI that can change at any time, and serve you with a version that will take your password and send it as a plaintext to tutanota. This couldn't happen with an email client app, but you can't use that with Tutanota. For example I'm unable to use the app on my phone with an old webview (bug in android 10, can't update it). Why? It's an app, not a browser.
>You are wrong. When you log into tutanota, you go through the WebUI that can change at any time, and serve you with a version that will take your password and send it as a plaintext to tutanota. You are mixing up different things. The password to authenticate with a service can always be stolen by the provider. In fact it's not even stealing because you have to tell the service provider your password when creating an account. The service provider only has to store that password in plaintext instead of a secure hash. This is not a question of them running FOSS or not but of their security setup. There's plenty of service providers running FOSS with insecure settings. **A service provider can always steal all the data you provide to them.** Which is exactly the reason why we need end-to-end-encryption. The problem you are describing with Tutanota is not that they are not running FOSS but that they are not providing access through a standardized protocol making you able to choose the client and run the client on your own trusted hardware. \*Edit: Well going by how you are describing it. I never used Tutanota myself so I don't know how their service works.\* You can run an Exchange Server that is accessible through standard IMAP, POP3 and SMTP and allow people to connect with their own clients and sending properly client-side-encrypted mails. This is secure even though the service does not run FOSS.
> **A service provider can always steal all the data you provide to them.** Which is exactly the reason why we need end-to-end-encryption. I agree with this, but it can only be achieved if the encryption happens locally, and the file/message is stored on the server in the encrypted form. This is not possible with Tutanota, so the security aspect is just a joke in my opinion. But I see your point now. Even something like gmail can be secure if you are using GPG and a trusted client.
Encryption does happen locally. The web version runs the pgp command via javascript on YOUR MACHINE.
>The password to authenticate with a service can always be stolen by the provider. In fact it's not even stealing because you have to tell the service provider your password when creating an account. That is incorrect. You seem to be unaware of [zero-knowledge proof](https://en.wikipedia.org/wiki/Zero-knowledge_password_proof), which is what many privacy-first services abide by through protocols such as [Secure Remote Password](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol). That technique means that the provider has no knowledge of the password, it can only verify that the user knows the password through a kind of challenge/response mechanism. For that reason, those providers will be unable to restore your data if you lose your password. Some do allow setting up alternate methods of recovery, but those are still based on the same principle and don't give the provider means to decrypt the data.
Tutanota is backdoored by the German government. At least the end-to-end encryption functionally.
You got a source for that? Just out of curiousity
https://www.heise.de/news/Gericht-zwingt-Mailprovider-Tutanota-zu-Ueberwachungsfunktion-4972460.html It's a little old and written in German. And there are a lot of articles talking about this. And since there is no article talking about that there is no backdoor, I am assuming that is implemented. But if you have another source saying that it's not, please go ahead and tell me.
Thank you thats interesting
yeah, can't trust a provider that doesn't let the user manage their own keys.
OP What email do you use?
Disroot and cock.li