ProtonMail Web Client VS Synapse

> Is this password-derived key the "account key" which I see in the Proton Mail settings interface?

No, the account key is an OpenPGP key which is encrypted with a key derived from your password. The "key encryption key" is not separately visible. The address keys are in turn encrypted using the account key.

> Please clarify what key derivation function is being used.

We use bcrypt, in addition to the OpenPGP S2K (i.e. the bcrypt output is fed as the "password" to OpenPGP's key encryption).

We are in the process of rolling out OpenPGP.js v6, which supports Argon2 for the OpenPGP S2K step, after which we'll start using that - but we aren't quite yet.

> Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.

Take a look at https://github.com/ProtonMail/WebClients/blob/main/packages/..., for example. Though to be honest, if you want to verify that we aren't sending the password to the server anywhere, in principle you'd have to check the code of the entire web app. It's all open source, but it's a lot of work, of course. But you can also check the latest audit report: https://proton.me/blog/security-audit. They also verified all of this stuff.

> It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. (...) So I was really hoping to be able to use Proton Mail with this identity instead of the key pair that's generated for the account.

Yeah, I understand. Though, the typical advice from a cryptographer's perspective would be, it's better to use separate keys for separate purposes; and the simplest way to do that is to generate separate OpenPGP certificates, so that's what we'd generally recommend. But, if you want to generate separate subkeys and sign them all using a common primary key, that's also reasonable enough. And, we can improve the documentation on that, although it's a bit of a niche use case (not for HN of course, but for the general audience it is).

> Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.

Thanks, glad to hear! :)

The source code is here https://github.com/ProtonMail/WebClients

> Finally, in keeping with our long track record of transparency, Proton Pass is open source so anyone can review and verify our security architecture

They sure do enjoy writing that sentence without including any hyperlinks. This (https://github.com/ProtonMail/WebClients/tree/main/applicati...) appears to be the browser extension and https://github.com/ProtonMail/WebClients/tree/main/packages/... appears to look like the backend referenced in the extension's readme, but that directory's readme is zero bytes so (shrug)

Fork the frontend and make your own lightweight option

PS: I hope that we selfhosters will have a modern, efficient, easy to use mail suite one day with modern features like JMAP, good self-learning spam integration, automated checks and validations for SPF/DMARC/DKIM or whether the IP/host suddenly appears in a blocklist and integrated encryption at rest for emails. Something that isn't 30 services in a container image, with 30 different configuration styles. Maybe even with an API integrated that's compatible to the ProtonMail frontend (like the neutron server once intended to be). Anyway, I'm sorry for dreaming. ;)

And if you want to customize it further you can use Stylus to add custom CSS, Tampermonkey to add JS, or even modify the whole thing yourself from source (if you run it locally it syncs with your actual account).

What are you thinking of here? Synapse has supported purging room history since 2016: https://github.com/matrix-org/synapse/pull/911, and configurable data retention since 2019: https://github.com/matrix-org/synapse/pull/5815.

Meanwhile, Matrix has never needed the full room history to be synchronised - when a server joins a room, it typically only grabs the last 20 messages. (It does needs to grab all the key-value state about the room, although these days that happens gradually in the background).

If you're wondering why Matrix implementations are often greedy on disk space, it's because they typically cache the key-value state aggressively (storing a snapshot of it for the room on a regular basis). However, that's just an implementation quirk; folks could absolutely come up with fancier datastructures to store it more efficiently; it's just not got to the top of anyone's todo list yet - things like performance and UX are considered much more important than disk usage right now.

some context re the Matrix isses, long history apparently: https://github.com/matrix-org/synapse/issues/14481#issuecomm...

Why not Matrix? Here's one reason: it has incredibly hard-to-debug edge cases, and plenty of bugs. One of my favourites is the one where people are kicked out of your room at random, which was reported a year ago[0]. It wasn't fixed, however, because the head of the Matrix foundation (Matthew) presumably didn't like the issue being posted on Twitter.

This is honestly really disappointing behaviour from a platform owner.

[0]: https://github.com/matrix-org/synapse/issues/14481

> That doesn't make this situation any less bad to the rest of the community.

How is the community suffering here? Let's say Element adds a bunch of baller stuff to their versions over the next few months and then closes the source. Can't the community just fork the last AGPL version? You might say, "well then no one can take the AGPL fork and make their own closed-source business", but do you want them to? Even if you do, they still can with the existing Apache-licensed version, just like Element is doing right now.

You're arguing that Element will lose a lot of contributions, but TFA points out that despite being super open, the vast majority of contributions are still made by Element employees (which seems to be true [0]). It's not the case that Element is looking to monetize the (small) contributions of others, it is the case that others are looking to monetize the (huge) contributions of Element.

And besides, aren't the MSCs the core of Matrix? It's already super possible to build your own compliant client and server.

The situation is that Element needs money to keep developing the ecosystem. It would be cool if there were a big network of donors and contributions, but there isn't. You're essentially saying, "that's fine, go out of business then, and the community will keep developing the ecosystem", but that's not happening now, and it can still happen anyway with the Apache-licensed versions, which again people can still contribute to.

[0]: https://github.com/matrix-org/synapse/graphs/contributors