Proton wants to be a privacy-friendly service alternative to google for everyone.
People forget passwords and are not as tech-savvy as us.
Sure might be good to educate the user what the implications of doing this. But I do understand that they push people towards doing this. The number of times I read comments of angry people who lost access to their proton account because proton can’t recover it for you…
Also, the people who need OPSEC should get real proper advise or gain knowledge on this, as mentioned by others.
They should be transparent about the data they could give to governments.
It is like all messaging apps (except Threema), none of them were transparent about the usage of push notifications until we have seen recently with Teleguard where the gave it to the FBI.
Should proton be clearer about the recovery email not being encrypted? Yes. But should they get so much hate for it? Absolutely not. They provide one of the best privacy friendly services, in many cases they are in unexplored waters and I’d say they are entitled to making mistakes (and they don’t make many). Believe me, no one in proton is designing “dark patterns” on how to get peoples data sneakily so that they can provide them to anyone. I think they are learning as they go… and so are we.
To conclude, I am not saying we should trust blindly, but we should also not be paranoid…
What “hate”? People are offering fair criticism. Unfortunately while Proton claims to be “private by default” that is not always the case and they often require a heavy hand of user feedback to get it right. See your comment:
I think they are learning as they go
I wouldn’t classify this thread as paranoid. Simply offering fair criticism that they could stand to make it more clear when data is encrypted and when it is not. I recall for some time it was not always clear what information in a contact record was encrypted. Now indicators are baked into the web app.
Proton will ship the MVP. Terrific product when it works, but you have to be on your toes to make sure your using it “correctly”.
yeah most of the discussion is fine, I came from other discussions and some people are just irrational. Funny thing is that they do not then care that it is Apple who actually provided the name tied to the email. Apple that markets itself also heavily with privacy. Double standards…
Now indicators are baked into the web app.
hence the statement that I think they are learning as they go. Show me a company that does everything right on first try without honest mistakes.
to make sure your using it “correctly”
this is also an overexageration. It is privacy 101 if you want to stay private do not link your other email address, phone number, whatever with the service. Moreover for many people (and I would even dare to say most people) it is correct to add the recovery email, because they would benefit from having this backup option while their threat model is not hurt. If you wanna stay private you need to know what you want and you need to know how to do it or what to avoid.
I wouldn’t even call this a mistake (though I welcome the clarification and more explicit disclaimer). I see it as Proton just overestimating the limited technical competence and very basic awareness of opsec of a portion of its userbase, and misjudging how much hand holding is necessary to protect users from their own choices.
If I specifically order a hot coffee and then I get upset that it burns my mouth, did the cafe make a mistake by not explicitly warning me that the hot coffee I ordered would be hot and might burn my tongue? If after I complain, they add a warning label, is that proof they made a mistake? In my eyes, the cafe did no wrong, despite taking action to prevent people like me from burning our tongues in the future.
Maybe this is analogy is a bit exaggerated but I think the premise is the same, It is unreasonable to assume that Proton can fully protect users from their own voluntary decisions or that any service or tool can take the place of mildly thoughtful opsec. If you don’t want Proton to be able to link your Proton account to your other accounts, don’t provide Proton a recovery address, or just provide a burner. This is extremely basic opsec.
Part of the issue here is the common conflation of anonymity and privacy. Proton is private by default (the contents of your emails are encrypted) but takes specific efforts to be anonymous like the use of VPN/TOR and not putting any identifying information outside the bodies of emails.
Apple services can be quite private, but they almost never can be anonymous. With advanced data protection enabled by both users my iMessages are private. However, due to meta data that remains unencrypted the conversations are not anonymous.
Keep in mind that even with perfect OpSec, providers like Proton or Tuta can be required by a court to secretly log the not-yet-encrypted emails that arrive at or depart from the mail server for any correspondences with a non-encrypted email provider (Gmail, Outlook, Yahoo… basically 99% of providers and users). I think Tuta was forced by the German authorities to do this in a child porn investigation.
hi @jerm
are you assuming that the open source code (client app, javascript, and server) are all clean, but that someone has compromised a server in the farm to deliver adulterated code?
it seems that an attack could just as well ship you malicious application code. unless you are auditing source and verifying checksum yourself?
in general, a browser gets less system access and acts as a sandbox. and by using noscript or similar tools, you can further tighten restrictions. this is one reason that web-gmail and web-google search on mobile endlessly prompts you to “get the app”; they want those permissions
how would a recovery email work, if Proton themselves were unable to encrypt it?
user loses password
a reset password link must be sent somewhere the user can access.
proton (or any provider) must be able to send email to user@example.com
hopefully, proton encrypts the recovery email at rest and in transit. however, to affect recovery, they need to be able to decrypt it.
what can be done?
one can refuse to enter the recovery email.
then, take their chances that their password backups and such would prevent the need. else, provide a recovery email that is equally resistant to connection back to the user.
near impossible to verify a dynamically-loading, obfuscated, chunked JS Web app
thinking aloud … i suppose to do so would involve an elaborate automated system, like the end-user equivalent of a CI build-time validator. The software provider would need a third party (build system, repo, etc) to publish hashes and a verification API to a server that is not their own?
in effect,
author publishes chunked code and a hash
user gets web app from malicious server
browser tool compares code & source maps to expected hash
dynamic web apps can be limited at load time or runtime, and specific privileges blocked.
native apps are verifiable, and have more privileges on your system
let’s say a flaw or malicious item missed in code review passes verification and gets installed.
the FOSS community cries out and the issue is fixed the next day.
meanwhile, some information from the machine is leaked during that window of time.
I wonder, and sorry in advance for the unpopular wording I will now choose, but if a user do not plan to commit a crime, what would be the main disadvantage of providing backup email that can be unencrypted by proton? Lets set aside the possibility my government goes rogue for a moment.
The only thing that comes to my mind is that in some way, if proton gets hacked and the email leaks, then if someone would target me, specifically, they would now know what email to hack in order to get to my other mail right, but then again would that work if I have e.g. 2FA? Is there any other possible scenario why I wouldn’t want to provide recovery email?
I don’t think the lesson here is necessarily a blanket dissuasion towards ProtonMail or any particular service.
It is instead to be aware of how much information and metadata even “privacy” services can retain and through either a security breach or legal disclosure can potentially reveal about the user of the account. Does Proton get off scot free? Not entirely. If anything I think a prudent step would be for them to be more explicit what unencrypted information ProtonMail does store so users can make their own choices.
It is also a question on how much a court could compel Proton to obtain information they do not already have. If you remember the arrest of the French activist that was because the police were already aware of a suspect and their e-mail address through real-life sleuthing and got a court-order to compel ProtonMail to log the IP address used to access the account. In those circumstances I think the suspect was already in a difficult position legally speaking.
One thing Proton could do is only store a hash of the recovery email. Then on the account recovery page they’d have to make you enter your recovery email address. They’d check if what you entered matched the hash, and if it does match then they’d send the email.
The problem with this is that people would be forced to remember what their recovery email is, which might not be good for the type of person who’s going to forget their password in the first place.
I don’t think they should do this though, I just think they should make it obvious that the recovery email is cleartext metadata being stored alongside your account.
When creating a Proton mailbox it takes your verification email and pre-populates the recovery email with this value. It’s entirely possible to provide your identity email for the verification (a pseudo required step), which is documented as “anonymous” and not understand the implications of accepting the default value as the recovery email.
Agree. I was creating a Proton mail for Ente 2FA Mail. I refused the recovery mail, (the verification mail was mandatory) and entered my account. I couldn’t receive my ente verification codes. Seconds later, I receive an e-mail from Proton saying it isn’t designed for receiving verification codes and that my account was essentially locked.
then, you’d really have a business model