3 ms·

I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the

I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the keys of who's actually in the room, rather than just trusting a static key which will inevitably leak. They're presumably also planning to re-key via a ratchet to avoid a single leaked key compromising the whole conference recording.

sigwinch28 7y ago
Yes, my comment w.r.t. the hash is that it's inherently a bad final implementation because it's visible to the server via malicious Javascript. I really hope that it can be as simple as "share a password with someone"/"send an invite link to someone" because as the parent effectively said, this would be a complete UX nightmare.
- cheald 7y ago
  I'm having trouble envisioning how you could possibly put together a solution where the encryption key wouldn't be visible to Javascript, malicious or otherwise. How would that work?
  - sigwinch28 7y ago
    Assuming that the client is essentially a web app then yes, the javascript must be able to read the encryption key. However, it's not a hard requirement that the server delivers the javascript to us: it could be hosted locally, e.g. a trusted Electron wrapper around a set of HTML/CSS/JS stored on my computer, for some definition of trusted. This is how a lot of other e2e-encrypted messaging app can be used, e.g. Signal, WhatsApp, Riot.im: a "trusted" set of client code over which the untrusted server has no control.