E2E is something nerds complain about.
You would play it similar to how you attend a Zoom meeting. They could probably reuse most of the client code for this feature. But yes, I agree this is likely not the user experience that most users want.
It’s a hard problem, which gets much easier and delivers a better UX if you can trust the service provider. Also consider why you trust 70 meeting participants more than Zoom/Microsoft/Google/Verizon?
For the very simple reason that "the people that I choose to communicate with are people that I have chosen to communicate with", whereas the communication medium chosen is "the least-bad available". I am able to take whatever other measures I wish via other channels to verify and built-trust-in the participants, but I cannot do so with the communication medium owner.
The middle-man shares a temporary key where his end-point can decrypt the message at any time, generating a new key to deliver the message to its original destiny.
I mean, i've always understood e2e encryption with centralized points of distributions as whatsapp, having the understanding that they, and they only, could still claim e2e while at the same time being able to decrypt the messages themselves.
So i never trust the claim of full secrecy unless i know its e2e over a real p2p channel without a middle-man working as a broker between the parties (where the broken can generate and distribute the keys)
Its looks like snake oil to me. Of course far from the eyes of north korea, who is barely a treat to anyone, but with all we know about things like PRISM, probably being available to all the north-american agencies.
No; this is specifically what end-to-end encryption is designed to prevent. In E2E, the data is encrypted at one end and it is not decrypted until it reaches the other end, because no one in the middle has the decryption key.
Isnt possible that one peer encrypt, pass it to the central server who have the other key, the central server than encrypts again and share it with the real end making it believe the key he is using actually is the same one generated in the first part of the process?
Its like the OR from tor but with 3 parties instead.
How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?
For "good" UX, usually it is based on trust that the peer keys are exchanged with help of the centralised service as middle man but that it does not alter the keys.
For good security, each party should ideally check public key fingerprints with each other party via another mean of communication to ensure that there was no man in the middle. But that's poor UX and might be unpractical for large meetings of participants that do not know each other.
From the article:
> Participants will also see the meeting leader’s security code that they can use to verify the secure connection. The host can read this code out loud, and all participants can check that their clients display the same code.
Obviously the vast majority of people won't do this, so the vast majority of people won't be fully protected against active MITMs. But the potential of meeting participants doing this will discourage attackers in many cases.
This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.
> This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.
Well, before we had to trust simply that people with networking access were non-malicious. Now, we can simply trust that at least one of [crypto, network] people are non-malicious. That seems like an improvement to me.