![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused?
Because most people don’t care about those particular things. Almost all the world uses completely proprietary tools (Gmail) that also violate your privacy.
Not to mention, entirely unnecessary why you should have to use a bridge gateway in the first place with IMAPS & PGP/GPG, CalDav & CardDav. Like I said, Proton is engaged in some questionable practices.
It’s not unnecessary, it’s the result of a technical choice. A winning technical choice actually. PGP has a negligible user-base, while Proton has already 100 million accounts. I would be surprised if there were 10 million people actually using PGP. They sacrificed the flexibility and composability of tools (which results almost always in complexity) and made an opinionated solution that works well enough for the mainstream population, who has no interest in picking their tools and simply expects a Gmail-like experience.
And if you really have stringent requirements, they anyway provided the bridge, so that you can have that flexibility if it’s really important for you.
IMAPS & PGP/GPG, CalDav & CardDav
- IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.
- PGP/GPG is what they use. They just made a tool that is opinionated and just works, rather than one which is more flexible but also more complex. Good choice? Bad choice? It’s a choice.
- *DAV clients expect cleartext data on the server. If you encrypt the data, you need to build all this logic into the clients, and you are not following the standard anymore, which means you will anyway be bound to your client only (and those which implement compatibility). Proton decided that they want to implement e2ee calendar, and they decided to roll their own thing. It’s up to everyone to decide whether e2ee is a more important feature than interoperability with other tools. I don’t care about interoperability, for example, and I’d take e2ee over that.
I feel like I covered this point? They make the client tool you are using, there is 0 need for them to steal your password to decrypt your key. Of course you are trusting them, you are seeing your unencrypted email in their webpage, where they can run arbitrary code. They do have their clients opensourced, but this doesn’t mean much. You are always exposed to a supply-chain risk for your client software.
So…? The point is, if they do, encryption happen without them having to do anything, hence transparently. That was the point of my argument: my mom can make a proton account and send me an email and benefit from PGP without even knowing what PGP is.
And that’s the whole point of the conversation: these users are techies and a super tiny minority. This way, they made a product that allow mainstream users to have encryption.
And this control is worth zilch if they get compromised. This is a control against a MiTM who intercepts your download, it’s not a control if “the maker of Thunderbird” decides to screw you over in the same way that Proton would do by serving malicious JS code. If the threat actor you are considering is a malicious software supplier, you have exactly the same issue. There can be pressures from government agencies, the vendor might decide to go bananas or might get compromised.
Yes, this is true and it’s the real only difference. I consider it a corner case and something that only affects the time needed to compromise your emails, not the feasibility, but it’s true. I am counting on the other hand on a company who has business interests in not letting that happen and a security team to support that work.
Maybe…? If government actors are in your threat model, you shouldn’t use email in the first place. Metadata are unencrypted and cannot be encrypted, and there are better tools. That said, government agencies have the resources to target the supply chain for individuals and simply “encourage” software distributors to distribute patched versions of the software. This is also a much better strategy because it’s likely they can just get access to the whole endpoint and maintain easy persistence (while with JS you are in the browser sandbox and potentially system sandbox), potentially allowing to compromise even other tools (say, Signal). So yeah, the likelihood might be higher with JS-based software, but the impact is smaller. Everyone has their own risk appetite and can decide what they are comfortable with, but again, if you are considering the NSA (or equivalent) as your adversaries, don’t use emails.
Yes.
What I mean is this: a client that implements quite some functionality besides what the server would require to work. In this case, the client handles key management, encryption, decryption, signature verification etc. all functionalities that the server doesn’t even know they exist. This is normal, because the encryption is done on top of regular email protocols, so they require a lot of logic in the client side.
For sure it’s different, I didn’t say it’s the same thing. I am saying that you can migrate away easily if your needs change and you’d rather have interoperability.
Exactly. Which is why in the very comment you quoted I said:
Are you trusting your Nextcloud instance (yours of hosted by someone else) not getting pwned/the server being seized/accessed physically/etc. more than you trust Proton not to get pwnd? Then *Dav tools might be for you.