| That was my thought exactly, but I read the zoom whitepaper (https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom...), and it looks like the scheme addresses many of those issues. Some things that looked like good steps: > we will allow the
SSO IDP (Identity Provider) to sign a binding of a Zoom public key to an SSO identity,
and to plumb this identity through to the UI. > Second, we allow users to track contacts’ keys across meetings.
This way, the UI can surface warnings if a user joins a meeting with a new public key. > we will implement a mechanism that forces Zoom servers (and SSO
providers) to sign and immutably store any keys that Zoom claims belong to a specific
user, forcing Zoom to provide a consistent reply to all clients about these claims. Each
client will periodically audit the keys that are being advertised for their own account and
surface new additions to the user. > In Phase IV, we look to the future where Bob should sign new devices
with existing devices, use an SSO IDP to reinforce device additions, or delegate to his local
IT manager. All of this of course relies on a zoom client actually doing everything described in the whitepaper, but it certainly looks like a good faith effort to implement real, functional e2ee |