Magicall: end-to-end encrypted videoconferencing in the browser, now in alpha
15 points by nadim
15 points by nadim
No friction
but requires creating an account
https://call.element.io provides e2ee videoconferencing in the browser, and you only need to specify your "name" and a name for the conference
Jitsi Meet is a similar web service that is free, open source, and end-to-end encrypted. It has existed since 2013, and I used it successfully for dozens of one-on-one calls in 2020.
The service used to allow anonymous usage, but it started requiring an account two years ago. I found another deployment of the Jitsi Meet software that allows anonymous usage: Brave Talk. It worked both of the times I tried it.
One feature I missed, though, is that Jitsi Meet’s chat is text-only. You can’t use it to send files.
https://galene.org is another videoconference server for self-hosting. We used it in our team before switching everything to MS Teams. If I'd have the choice I'd probably still use it.
I find https://magicall.online/cryptography well written! (Not too marketing and not too technical at the same time)
"Free forever", but it has a free tier like all "enshittified" software and it is still in alpha..
Yeah, without source code and the ability to self host I don't see how this is fundamentally different from other commercial conferencing services.
Pretty cool! But as they clearly state, you still have to trust their servers not to serve any malicious JS. Would be great if one could self-host this, and if the code could be inspected.
EDIT: I suppose if you're self-hosting you wouldn't need end-to-end encryption, because you trust your own server. One could just use something like Jitsi in such a case...
EDIT: I suppose if you're self-hosting you wouldn't need end-to-end encryption, because you trust your own server.
I think that isn't entirely true. E2E would still provide a form of defence in depth. It removes the a successful compromise of conversations when "only" the server gets hacked.
That said trusting server JS is counteracting this, unless you could eg store hashes or similar and have some form of "offline first" application that deals with such things. Of course adding such complexity might itself increase attack surface, if not done properly.
Currently, you can only deal with server trust by using something like the Signed Pages extension. Unfortunately you can't do that with just Service Workers even though TOFU should've been doable there..
Similar art here is Meta's Code Verify (https://engineering.fb.com/2022/03/10/security/code-verify/), which is their hedge against malicious JS being served in an E2EE messaging app.
Basically, each revision of JS has a hash computed and published to a third party (Cloudflare, in this case). The browser extension then checks the JS hashes against the published list.
Thanks pointing to the signed pages extension- I wasn't aware of that. Hopefully some day something allows you to validate that a website matches a published artifact.
(For example, so I can deploy the Bitwarden Web Vault and users can verify that I have not tampered the original vault code.)
(I know Signal not supporting a web version is related to this being much more difficult than what it sounds like, which is already pretty difficult sounding...)