Open ara4n opened 2 years ago
This is quite subtle given trusting the website hoster to embed a non-malicious chatterbox means that even with verification, there's a risk of a malicious chatterbox being inserted into the mix if the host website wants to MITM its users. Suggestions welcome on how best to solve this one, as verification is useless if you can't trust the endpoint...
So the threat model could potentially be that the user doesn't necessarily trust the embedding website, but they do trust element to host a non-backdoored chatterbox?
OTOH, the agent and bot they will be talking to (and receive the keys) will most likely be part of the same org that is embedding chatterbox in the first place.
Build should be reproducible, so I wonder if there is a way users could verify that a release of the source code on the GH repo is indeed what they are using.
Is your feature request related to a problem? Please describe.
E2EE is of very limited use if you can’t prove whether you’re talking to the right person or a MITM.
Describe the solution you'd like
Ability to view the olm public keys of the user you’re talking to, and be warned if they change, and have the option to verify them via device verification (and/or via some other out-of-band verification channel, e.g. an ID server)
This is quite subtle given trusting the website hoster to embed a non-malicious chatterbox means that even with verification, there's a risk of a malicious chatterbox being inserted into the mix if the host website wants to MITM its users. Suggestions welcome on how best to solve this one, as verification is useless if you can't trust the endpoint...
Additional context https://news.ycombinator.com/item?id=32020476 https://twitter.com/MTRNord/status/1545089701698306050