[liberationtech] Zoom admitted, then denied, then admitted again that it censored an activist

[Seth David Schoen]

Hi Adam!

Adam Fisk writes:

> Not to get too sidetracked here, but all major browsers have supported
> WebRTC for a long time now. I'm not exactly sure what Jitsi is taking
> advantage of in newer Chrome versions, but it's certainly not the basic
> WebRTC core components, which exist in all browsers.

Maybe Aaron could explain what the functionality gap between browsers is
currently?

> All that said, I would agree the key distribution problem for E2EE, not to
> mention the challenge of how to make E2EE as performant as the alternative,
> are not trivial issues AFAICT. One general rule of thumb that Zoom has made
> abundantly clear yet again is that performance is absolutely essential for
> the vast majority of users. Definitely not saying people should use Zoom
> but rather that competing with it with a secure product is challenging.

It seems like a pity in this regard that Zoom has just bought Keybase,
because Keybase has a pretty nice model for this.  Possibly the furthest
developed model for linking identities to generic end-to-end encrypted
operations.

There are a lot of potentially promising things out there, though.  You
could try to extend Magic Wormhole -- Brian Warner has said that the
ultimate vision for this tool is introducing devices to one another in
order to perform arbitrary kinds of secured communications between them
in the future (which is also something that Keybase has tried to do).

Presumably we would need a browser extension to bridge the gap between
"your computer knows a shared secret that can be used to derive a key for
this person" (or "your computer knows a public key for this person")
and "this Jitsi call is claiming that it's appropriate to use this key
for this person" (or "the browser is wondering what key to use to
encrypt this particular WebRTC session").  This is a potential UI
advantage for Zoom since they have a standalone application, where they
can do key management and UI stuff that directly impacts the
cryptographic behavior of the application.

I agree that these things are tricky, especially if you have people
joining and leaving an already-established call... and I again think
that Keybase has a sophisticated set of models for group membership
and distribution of secrets (e.g., also a way to kick someone out of
the group by giving everyone else a fresh secret).  It's a lot easier
to deal with key management if you never have to revoke keys or secrets.

And another question is whether you want to have shareable links that
contain all of the information needed to join the chat (as Jitsi Meet
and Zoom both currently offer), and whether you still want that with
an encrypted chat.  With a browser extension, you could potentially
put a secret key into the link fragment (after the #) so that it's
not sent to the server, like

https://future.meet.jit.si/HypotheticalThingsActHypothetically#5ce97a638c863ad6e8a8456749b3814d

Then the authority to actually participate in the call would be connoted
by possession of the link, but the web server performing the coordination
wouldn't receive that authority.

-- 
Seth Schoen  <schoen at eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107