Exactly. There’s no justification for them storing the private key online for “convenience”. And key generation happens in the browser with JS. Which means it is possible to send backdoored JS to easily copy the private key.
Comment on Proton is transitioning towards a non-profit structure | Proton
endofline@lemmy.ca 4 weeks agoIt’s still insecure. They decryption process is still in the proton company hands and they could add some client specific code to log the password on the fly. Proton is obliged to follow the swiss law and I can imagine situation that police asks proton (+ gag order ) to log certain data for specific clients like passwords and ips. Still private keys are better to be stored separately. You can sync them easily if you with with either rsync or rclone
Asudox@lemmy.world 4 weeks ago
sudneo@lemm.ee 4 weeks ago
There is a reason: simplicity. Either you do all the key management yourself, which in practice means 98% of the people won’t do it at all, or you implement a solution like they did and increase the risk of a small % (see my other comment) but you cover every customer.
Asudox@lemmy.world 4 weeks ago
That simplicity introduces lots of security and privacy issues.
sudneo@lemm.ee 4 weeks ago
Introduces some risks in terms of security. Privacy concerns are extremely minimal, because in any case you don’t control the setup of your other interlocutor(s).
Considering that the realistic alternative is not using anything at all and the fact that you have both options with Proton, it’s a win-win scenario.
endofline@lemmy.ca 4 weeks ago
endof
Especially with the fact that: 1) deminificafion of the javascript code is not simple 2) you cannot “freeze” the code version you use. Still your computer does allow it ( minus the windows which follows the Microsoft thinking way, kidding about windows updates )
sudneo@lemm.ee 4 weeks ago
It’s not “insecure”, it’s simply a supply chain risk. You have the same exact problem with any client software that you might use. There are still jurisdictions, there are still supply chain attacks. The posture is different simply by a small tradeoff: business incentive and size for proton as pluses vs quicker updates (via JS code) and slower updates vs worse security and dependency on a handful of individuals in case of other tools.
Any software that makes the crypto operations can do stuff with the keys if compromised or coerced by law enforcement to do so.
In any case, if this tradeoff doesn’t suit you, the bridge allows you to use your preferred tool, so this is kinda of a moot point.
The main argument for me is that if you rely on mail and gpg not to get caught by those who can coerce proton, you are already failing.
endofline@lemmy.ca 4 weeks ago
I used bridge for many years. It was totally unusable - 1) you cannot delete emails with it ( deleted emails were coming back ), 2) synchronization issues so it made me move to another “plain and simple” email provider offering pop3 and imap and also gpg integration ( but without that e2e hype talk )
sudneo@lemm.ee 4 weeks ago
I can’t comment on this, since I don’t use the bridge for a while. But it’s just an IMAP/SMTP server, so not sure why certain features wouldn’t work. What service did you end up using which has gpg integration?
endofline@lemmy.ca 4 weeks ago
I used protonmail for 3 years - bridge issues have been being ignored by protonmail support in my opinion. “Clean cache and try again”. I stopped using protonmail and switched to mailbox.org. So far so good.