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 <[email protected]> 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 -- Liberationtech is public & archives are searchable from any major commercial search engine. Violations of list guidelines will get you moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe, change to digest mode, or change password by emailing [email protected].
