4 ms·
> One person who does verify a fingerprint will get a real fingerprint. Or maybe they'll just show you same numbers as to your buddy, because they control both
by hiq 5y ago
> One person who does verify a fingerprint will get a real fingerprint. Or maybe they'll just show you same numbers as to your buddy, because they control both server and client software and users have very very limited resources to control what code is shipped to them via appstores.
The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it. If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.
Nobody claimed E2EE was the be-all and end-all of security; only that it's an improvement over having to trust a 3rd party. This is because everything else being equal, the less components you trust, the better security-wise. So given a network operator, if you can choose between trusting them or not, you'll be better off not trusting them. That's why E2EE is better than no E2EE.
Finally "use your own server" seems like the perfect solution if you're only talking to yourself. To take the email example, just because you trust gmx.de doesn't mean you want to trust mail.ru, but it seems that you're either suggesting that the trust propagates between servers in the same federated network (obviously not the case), or that you can just demand your recipients use the server you chose, ending up with a centralized silo within the federated network, which is itself a contradiction.
- Andrew_nenakhov 5y ago> The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it. Compromised apps can very much silence such warnings. > If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless. Federation absolutely helps. If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced, especially when there are many competing apps. If you run the server yourself, the chance to be compromised becomes infinitely small.
- hiq 5y ago> Compromised apps can very much silence such warnings. Again, this is not a useful take since this equally applies to any other app, federated or not. > If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced No, you just need one of the trusted component to be compromised to lose your security guarantees. You're suggesting to increase your attack surface instead of reducing it.
- Andrew_nenakhov 5y ago> this equally applies to any other app, federated or not. Wrong. If your client software and service come from different vendors, it is by far harder to attack your privacy via compromised apps - especially if there are multiple vendors of client software and reputable open source repositories like f-droid who build apps from sources. > No, you just need one of the trusted component to be compromised to lose your security guarantees While this looks to be true, in real world practice it is completely not so. It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app - especially if the attacker knows which account should be affected. And in a federated environment the attacker might not even know your account name.
- hiq 5y agoWhether the protocol is federated or not (which is the topic of the article) doesn't say anything about the clients and how they're distributed. Even with respect to Signal, which is open-source, can be rebuilt from source and has several clients, including 3rd-party ones. > It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app We'll have to agree to disagree.