3 ms·
>Default End-to-end Encryption So, the first question to ask here is: How can a user be sure they are actually talking to who they think they are talking to?
by upofadown 4y ago
>Default End-to-end Encryption
So, the first question to ask here is:
How can a user be sure they are actually talking to who they think they are talking to? How can they be sure that they are not instead connected to a server somewhere that is simply forwarding the data between users while recording it? Who do you have to trust?
An example of the sort of thing I mean:
Signal Messenger verifies your phone number through the phone system for default identity verification. So you trust:
* The people that run the Signal servers
* Twilio (the ones that provide the SMS verification)
* The phone company
Signal also has the option to do direct verification by comparing key fingerprints (they call them Safety Numbers). Then you are truly end to end and only have to trust your correspondent (and yourself I suppose).
- barathr 4y agoThe good news with this is that we've built our implementation on top of LiveKit, and you can look at the source, so you can see the E2EE in the browser. The encryption key for video/audio is only known to the client, so it's only known to whomever you share it with (the other participants). You can also look at your browser's WebRTC internals to see who it's talking with. Eventually our plan is to support TEE-based attestation of the Multi-Party Relay hops as well.
- HappyTypist 4y agoWhy not implement the tried and true fingerprint verification? Quite easy to do when you're having synchronous, lively video/audio conversations.
- barathr 4y agoThat's what we'll be doing for a well-defined group of users -- that is, with stable, long-term cryptographic identities. It's not as useful for conversations where participants join with a link.