4 ms·
>GET parameter Yes, it's convenient. But to tout that as what a well designed encryption scheme should look like? Nah.
by emilfihlman 7y ago
>GET parameter
Yes, it's convenient.
But to tout that as what a well designed encryption scheme should look like? Nah.
- bflesch 7y agoWhat is your alternative suggestion? In a browser-based video chat scenario you are ultimately assuming some level of browser security and that the clients are trusted. What they propose is an E2E encryption, e.g. Zoom / MS Teams are unable to decrypt your conversations. Obviously, if you choose a weak key, they can just store the stream and crack it later.
- giancarlostoro 7y agoIt was a hash mark, only the client got that value (specifically JavaScript). Note how his page did not reload when he hit enter. Had it been a GET request, it would of refreshed.
- CrazyStat 7y agoFrom the link: > In order to enable quick demos of the feature we allowed for e2ee keys to be passed to Jitsi Meet via a URL parameter. > IMPORTANT NOTE: This is a demo of an e2e encrypted call and the feature is NOT YET intended for general availability, so play with it all you want, but, for now, in matters where security is paramount we still recommend deploying your own Jitsi Meet instance. > As we already pointed out, passing keys as URL parameters is a demo thing only. Aside from being impractical it also carries risks given that URL params are stored in browser history. > Our next step is therefore to work out exactly how key management and exchange would work. We expect we will be using The Double Ratchet Algorithm through libolm but the details are still to be ironed out. They're not touting passing the keys in a URL parameter as a "well designed encryption scheme." They're presenting it as a proof of concept, and planning for the future work that they acknowledge is necessary. Your comment is ill-informed and misleading.