sudneo

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.

There are certain things that are known facts, there is no need to prove them every time.

The simple fact that:

• There is not a standard tool that is common
• The amount of people who use PGP is ridiculously low, including within tech circles. Just to make one example, even a famous cryptographer such as Filippo Sottile mentions to receive maybe a couple of PGP encrypted emails a year. I work in security and I have never received one, nobody among my colleagues has a public key to use, and I have never seen anybody who was not a tech professional use PGP.

You can also see:

• https://www.latacora.com/blog/2019/07/16/the-pgp-problem/:

We can’t say this any better than Ted Unangst: "There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again." If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. You probably don’t suddenly smell burning toast. Now try doing that with PGP.

• https://fosdem.org/2024/schedule/event/fosdem-2024-3297-sequoia-pgp-rethinking-openpgp-tooling/

A recent talk, I will quote the preamble:

Although OpenPGP is widely considered hard to use, overcomplicated, and the stuff of nerds, our prior experience working on another OpenPGP implementation suggested that the OpenPGP standard is actually pretty good, but the tooling needs improvement.

And you can find as many opinion pieces as you want, by just searching (for example: https://nullprogram.com/blog/2017/03/12/).

However, if you really believe I am wrong, and you disagree that PGP tooling is widely considered bad, complex and almost a meme in the security community, you are welcome to show where I am wrong. Show me a simple PGP setup that non-technical people use.

P.s.

I also found https://arxiv.org/pdf/1510.08555.pdf, an interesting paper which is a followup of another paper 10 years older about usability of PGP tools.

They generally require to have data visible on the server and/or handle independently encryption/decryption with related tools and key management (including key discovery).

For some, it might be worth, for 99% of the population who wouldn't be able to do this but also doesn't want their content availablento the provider, it's not.

GPG is a huge pain in the ass to manage. Everyone knows this, because it's the case. The web of trust also doesn't scale and has many problems, handling key securely is hard, making GPG work on all devices is something which is completely impossible for people without solid technical skills.

If you think otherwise, you are just in a bubble.

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.

Companies have to comply with law enforcement. If anything, the little amount of data they were able to give after being forced is a good proof of their overall claim. If there is someone to blame here are courts using antiterrorism laws to catch environmental activists.

Thanks (grazie?)! I was looking for something similar and kanidm looks great feature wise and simple to deploy!

I guess Poland? I know from my colleagues that internet infrastructure jumped from old slow stuff to fiber there and it's fairly cheap.

I struggled with this for a long time, and then I just decided to use synology photos.

It has albums, tagging, geolocation, sharing. It has phone picture backup, it is inherently a backup as it's on my NAS and I back that data up again.

I want to keep the thing that I really care about the most friction free and also not too dependent on myself so that I can still experiment.

I didn't try PiGallery2 though, maybe I will have a look!

Super cool project, thanks for sharing! I think I will try to integrate it with my static sites.

Did it sound cold? Because I didn't mean that, I just meant to actually answer the question from my PoV. Just for the record, I also did not down vote you.

So yeah, use whatever footgun you prefer, I don't judge :)

Or rustic! It is compatible with restic but has some nice additions, for example the fact that supports a config files. It makes operations a bit easier IMHO (I am currently using both).