|
|
|
|
|
|
by 63stack
11 days ago
|
|
|
This is only true if you are using apps that require no communication with a server.
Otherwise it's constant forced updates, and basing security on the version number of the installed app is a moot point since you can't guarantee the server will send the same replies to 2 different users. I can't parse the part about e2e not making sense for webpages. |
|
|
End-to-end encryption is all about going through an untrusted server. You don't need end-to-end encryption otherwise.
> Otherwise it's constant forced updates
There are apps that allow you to verify that you are running the same signed binary as others. Think key transparency but for apps. It's trivial to do.
> basing security on the version number of the installed app
Obviously you don't base your security on the version number of the installed app?!
> since you can't guarantee the server will send the same replies to 2 different users
With a website, you cannot. When you open protonmail.com in your browser, you don't know if you are running the same code as I am when I do the same.
With a mobile app, you can. You get a signed binary, it's trivial to compare. Also even if you don't check that, if you get the Signal app through the Google Play Store, it means that the app is signed by Signal but distributed by Google. They have to collude in order to have you get a different binary.
> I can't parse the part about e2e not making sense for webpages.
It's what I'm saying above:
- If you audit the Signal sources, compile them and run them, then you don't have to trust the server.
- If you use the Signal app distributed by Google, you can trust that you got the same app as everybody else who downloaded it through the Play Store, unless Signal and Google collude.
- If you open protonmail.com in your browser, you have to blindly trust that the Proton server is sending you the code you expect. But if you have to blindly trust the server, then it's not exactly end-to-end encryption anymore, is it?