In a threat model that includes malicious servers, your only defence is smart clients that know how to check the server and inform the user when the server is not behaving - hence the focus on usability and build auditing. In such a world your app (and your phone OS) is your <i>only</i> friend, and everyone else might be malicious. That's really, really tough.<div><br></div><div>I've been having fun with this in my Lighthouse project, which is not e2e communication so I know it's a bit off topic, but some of the issues are related. Lighthouse relies on a peer to peer network. So, some servers may be malicious.</div><div><br></div><div>In some cases, you can tie stuff back to a proof of work and substitute malicious servers for malicious miners, in other cases you can cross check answers. But in all cases you face a hard UI problem - how do you communicate to the user that something is screwy, in a way that they'll understand and react appropriately to? And how do you do it without accidentally crying wolf due to normal events like network instability? It's tough and the best research we have on this is around browser UI, which mostly concludes that it sucks and nobody gets it right :)</div>