Proton stores your keys

Proton stores an encrypted blob.

All they need now is your decryption password & they can read your messages

“All they need now is your private key”. It’s literally a secret, they use bcrypt and then encrypt it. Also, “they” are not generally in the threat model. “They” can serve you JS that simply exfiltrates your email, because the emails are displayed in their web-app, they have no need to steal your password to decrypt your key and read your email…

It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes.

Probably we misunderstand what “transparent” means in this context. What I mean is that the average user will not do any PGP operation, in general. Encryption happens transparently for them, which is the whole thing about Proton: make encryption easy and default.

Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server.

Again, as I said before, they control the JS, they can get the decrypted data without getting the password…? You always trust your client tooling. There is always a point where I trust someone, be it the “enigmail” maintainers, Thunderbird maintainers (it has access to messages post-decryption!), the CLI tool of choice etc.

How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side?

I mean, their clients are open-source and have also been audited?

If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging?

I don’t know. But here we are talking about a different risk: someone compromising Proton, getting your encrypted private key, and starting bruteforcing bcrypt-hashed-and-salted passwords. I find that risk acceptable.

This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.

See other post.

If you actually understood PGP you’d know you can generate and use local-only keys with IMAPS and have support to use any IMAP client.

Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?

There is no security benefit in their implementation other than to lock you into a walled garden and give you a false sense of security.

Right, because *DAV protocol are so secure. They all support e2ee, right…? There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared. You can export data and migrate when you want easily, so it’s really a matter of preference.

It’s actually fairly simple: if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.

They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream. So they chose building dedicated tools (bridge, web client), rather than letting users use their own tools, because the PGP tooling sucks hard and it’s extremely inaccessible for the general population.

This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee. Instead of using enigmail or other PGP plugins/tools, they built the bridge.

The fact that Lemmy’s core team is taking a fairly laissez faire position on moderation, user safety, and tooling is problematic, and could be a serious blocker for communities currently hosted on Lemmy.

At this point, most of the solutions the ecosystem has relied on have been third-party tools, such as db0’s fantastic Fediseer and Fedi-Safety initiatives. While I’m sure many people are glad these tools exist, the fact that instances have to rely on third-party solutions is downright baffling.

Honestly, what? Why would be baffling to have third party tools in this ecosystem? It would be baffling if that was the case for Facebook. Also the devs did work on some moderation features, but they probably have tons of other stuff to work on, all for an amount of money which is a low salary for one developer.

The whole landscape of health trackers is depressing. I bought a fitbit last year as I could expend it at work, and I ended up leaving it in a drawer exactly for the uneasy feeling of sharing very sensitive data. Health data is probably the most impactful on personal lives (insurances, banks, etc.), and it’s astonishing to me how it’s too much to ask to a company that makes watches to have watches as their mine business model.

I understand sharing data for further analysis etc., but I should be able to use my health tracker locally, only talking to my phone app and nothing else, similar to how gadgetbridge works. I was eyeing banglejs specifically to be able to do this, even though it’s not really a health tracker.