<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><br class=""></div><div>I admit this part isn’t my focus, but my understanding is that the technology is called “Insertable Streams”. The basic idea is a hook within the WebRTC engine that allows media to be transformed after capture, but still delivers certain identifiers such as which packet contains a keyframe, or what volume levels to expect, while keep the media itself from being parseable by the server, only the end clients who have the key.</div><div><br class=""></div><div>Here’s a link on WebRTCHacks: </div><div><br class=""></div><div><a href="https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/" class="">https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/</a></div><div class=""><br class=""></div><div class="">Here’s also a cheesy link from the jitsi team which shows our Proof of Concept:</div><div class=""><br class=""></div><div class=""><a href="https://www.youtube.com/watch?v=QNKemVNrCbI" class="">https://www.youtube.com/watch?v=QNKemVNrCbI</a></div><div class=""><br class=""></div><div class="">W.r.t. key negotiation, currently we allow a simple shared key to be entered into the browser via the UI, or via the URL. However, future iterations would definitely use something more sophisticated around confirming identity and possibly using algorithms similar to Signal for generating the keys. That part is definitely outside the scope of my knowledge currently, so I’d encourage anybody who is interested to stop by our community call to ask our team members who know much more about it than I do: <a href="https://jitsi.org/thecall/" class="">https://jitsi.org/thecall/</a> </div><div><br class=""></div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>-Aaron</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 13, 2020, at 3:40 PM, Seth David Schoen <<a href="mailto:schoen@eff.org" class="">schoen@eff.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Adam!<br class=""><br class="">Adam Fisk writes:<br class=""><br class=""><blockquote type="cite" class="">Not to get too sidetracked here, but all major browsers have supported<br class="">WebRTC for a long time now. I'm not exactly sure what Jitsi is taking<br class="">advantage of in newer Chrome versions, but it's certainly not the basic<br class="">WebRTC core components, which exist in all browsers.<br class=""></blockquote><br class="">Maybe Aaron could explain what the functionality gap between browsers is<br class="">currently?<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">All that said, I would agree the key distribution problem for E2EE, not to<br class="">mention the challenge of how to make E2EE as performant as the alternative,<br class="">are not trivial issues AFAICT. One general rule of thumb that Zoom has made<br class="">abundantly clear yet again is that performance is absolutely essential for<br class="">the vast majority of users. Definitely not saying people should use Zoom<br class="">but rather that competing with it with a secure product is challenging.<br class=""></blockquote><br class="">It seems like a pity in this regard that Zoom has just bought Keybase,<br class="">because Keybase has a pretty nice model for this. Possibly the furthest<br class="">developed model for linking identities to generic end-to-end encrypted<br class="">operations.<br class=""><br class="">There are a lot of potentially promising things out there, though. You<br class="">could try to extend Magic Wormhole -- Brian Warner has said that the<br class="">ultimate vision for this tool is introducing devices to one another in<br class="">order to perform arbitrary kinds of secured communications between them<br class="">in the future (which is also something that Keybase has tried to do).<br class=""><br class="">Presumably we would need a browser extension to bridge the gap between<br class="">"your computer knows a shared secret that can be used to derive a key for<br class="">this person" (or "your computer knows a public key for this person")<br class="">and "this Jitsi call is claiming that it's appropriate to use this key<br class="">for this person" (or "the browser is wondering what key to use to<br class="">encrypt this particular WebRTC session"). This is a potential UI<br class="">advantage for Zoom since they have a standalone application, where they<br class="">can do key management and UI stuff that directly impacts the<br class="">cryptographic behavior of the application.<br class=""><br class="">I agree that these things are tricky, especially if you have people<br class="">joining and leaving an already-established call... and I again think<br class="">that Keybase has a sophisticated set of models for group membership<br class="">and distribution of secrets (e.g., also a way to kick someone out of<br class="">the group by giving everyone else a fresh secret). It's a lot easier<br class="">to deal with key management if you never have to revoke keys or secrets.<br class=""><br class="">And another question is whether you want to have shareable links that<br class="">contain all of the information needed to join the chat (as Jitsi Meet<br class="">and Zoom both currently offer), and whether you still want that with<br class="">an encrypted chat. With a browser extension, you could potentially<br class="">put a secret key into the link fragment (after the #) so that it's<br class="">not sent to the server, like<br class=""><br class=""><a href="https://future.meet.jit.si/HypotheticalThingsActHypothetically#5ce97a638c863ad6e8a8456749b3814d" class="">https://future.meet.jit.si/HypotheticalThingsActHypothetically#5ce97a638c863ad6e8a8456749b3814d</a><br class=""><br class="">Then the authority to actually participate in the call would be connoted<br class="">by possession of the link, but the web server performing the coordination<br class="">wouldn't receive that authority.<br class=""><br class="">-- <br class="">Seth Schoen <schoen@eff.org><br class="">Senior Staff Technologist https://www.eff.org/<br class="">Electronic Frontier Foundation https://www.eff.org/join<br class="">815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107<br class=""><br class="">-- <br class="">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 lt-owner@lists.liberationtech.org.</div></div></blockquote></div><br class=""></body></html>