30 comments

[ 2.9 ms ] story [ 61.8 ms ] thread
Short answer: like Zoom, multiparty Jitsi meetings are encrypted point-to-point, not end-to-end, and Jitsi can monitor and record your multiparty meetings.
Let's all get out our pitchforks!
Guess the difference is that Jitsi never says/says that the meetings are end-to-end encrypted. One of the questions on their page is "Are my meetings encrypted? Is encryption end-to-end?" but they never give a give a clear yes/no answer to the last question, instead they describe what they are doing (which is clearly not E2E encryption) and how it works.

But for a layperson who reads this without really knowing what E2E encryption is, won't get their answer by reading the answer, they'll finish reading with their own understanding if Jitsi supports E2E encryption or not.

But unlike Zoom they never claimed anything different. Which is a huge difference if you ask me.
But you can host your own and audit the source code. That has to count for something, right?
I have done so on the smallest cheapest gcloud instance and it worked alright. Under a cent an hour for privacy seems worth it.
Don't forget to include bandwidth costs, which turn out to be much higher than you'd expect. 1.5 hours of with 6 participants using simulcast corresponds to about 20GB of outbound (inbound is free on AWS). Which corresponds to a little under $2 (at $0.09 per GB).
I thought jitsi sent video from user to user, not via server? Or is that a configuration matter?
It only does p2p if there's exactly two participants, otherwise it goes through the server.
... unless you self-host the server. What you can do with jitsi, but not with zoom.
Then its still not end-to-end encrypted. The difference is that the only point where its no encrypted is under your control as well. So you're right that your meetings cannot be recorded if you host your own instance.

Unlike Zoom, Jitsi never claimed that their system was e2e encrypted which is a huge difference if you ask me. Apparently its a technical limitation of WebRTC, so I'd assume no webbrowser based solution can be e2e encrypted as of now. Which is ashame since the browser compatability makes meetings with people outside your company (or with less tech savy family members) so much easier.

edit: misunderstoot your point

Thanks for the clarification!

As your edit already states, not the point I was trying to make, but still, good to clear this up.

There was interesting discussion yesterday by the devs of mediasoup, why it is not in webRTC yet: https://news.ycombinator.com/item?id=22761816

Do you know whether Zoom can monitor meetings taking place in Zoom On-Premise Deployments?
Zoom has signed HIPAA BAAs. I doubt they're jumping in on meetings when there's a risk of patient health history being discussed
Are there any cryptographic and/or network designs which allow end-to-end encryption of a group video chat without full meshing?
Facetime claims to be end-to-end encrypted and apple claims to not be able to decrypt it.
And since Facetime is closed source, a claim is all we'll get.

Jami is peer-to-peer and supports end-to-end encryption. Not sure if that counts or if that means it uses full meshing.

The point is not the crypto, but what WebRTC supports. As of now it does not. See https://webrtchacks.com/you-dont-have-end-to-end-encryption-... for reference
Of course WebRTC is only a requirement if you want to be browser-based. And even then, some solutions use WebRTC data channels for video instead (e.g. Zoom's web version). They could do it, although you'd of course still be trusting the server to serve you the right thing.
> Take the case of 10 people having a discussion in a room. You wouldn’t expect one person to have exclusive "kick" and "mute" privileges in an in-person meeting and yet, those meetings usually go fine.

> In the vast majority of cases, moderation controls in online meetings serve a different purpose: they help address tech related issues, such as people not realizing their microphones are introducing noise, or people forgetting to leave. Moderation controls help you solve those, so that people can continue their conversation. And now, with that in mind, why wouldn’t you want to enable anyone in the meeting to help solve these kinds of issues?

This is one of the stupidest things I've ever read about online meeting moderation, and this has been an all-time boner fest of a month for stupid things written about online meeting moderation.

You say it's stupid but don't say why. Honestly dorm my experience this is a useful feature I'm not a tech expert but in most team meetings I'm the most technologically able person in the room. I end up quietly muting people that forget to tune themselves out while typing. Not sure thats useful for a classroom of 10 year olds though.
Ok, but if posting to HN, please don't just rant about how stupid other people are. If you know more than others, share some of what you know, so the rest of us can learn something. And please omit name-calling.

"A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

Basically same situation technically as Zoom, without the PR fiasco
Except with Jitsi, the server that can potentially see the traffic is under your own control.
If you are using webrtc in the browser e2e is not possible. Which is why it’s critical you have the ability to self host such solutions.
What are you talking about? Webrtc has mandatory encryption. The only issue is using a simulcast middleware server. If you’re doing mesh p2p then it’s e2e.
Obviously - I was referring to when you have a SFU, such as Jitsi and comparable to zoom.

The concept of e2e encryption doesn’t even make sense in p2p, the fact that direct communication between two peers is “end to end encrypted” is self evident. It’s only when there is a central server that talking about e2e as a concept is relevant.

No? TURN servers relay webrtc traffic and it’s still e2e encrypted
Wouldn't IP multicast (if it were routed by ISPs) be a perfect fit for a scalable p2p video conference solution? Crypto wise, I guess, a room key could be negotiated.