Jitsi Meet: warn data is decrypted on the server #1728
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#1728
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Jitsi Meet currently does not support end-to-end encryption, because noone found a way to implement multi-party voice/video encryption through WebRTC.
Data is encrypted from the clients to the server, then the server decrypts all data and dispatches back to the clients.
They use Google analytics when connecting to Jitsi Meet to capture user data, such as the room name.
I do not think Jitsi Meet should be delisted, it's a great software, but it's clearly not the most private messaging/videoconferencing tool, I suggest to add a warning.
If I may:
It actually is pretty much the secure video conferencing tool. While indeed it is not e2ee encrypted (and that will soon change), it is the only one that allows complete deployment in ones own server in a very short period of time (under 15 minutes).
Because it encrypts all communication on the wire, owning your own Jitsi Meet server provides similar protection to end-to-end encryption.
You can see Edward Snowden talking about setting up your own Jitsi Meet server as a good practice in his interview with Radio France Inter here:
https://youtu.be/MQmntYFKrX4?t=124
You can see Bruce Schneier recommending Jitsi Meet here (bottom of post):
https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html
FWIW e2ee will be possible in webrtc soon
https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/
And in Jitsi too ... FWIW ;)
Do you have links to Jitsi Meet and Chromium (and Firefox?) tickets on this subject?
@emcho and @murillo128 : That is awesome! I love Jitsi Meet, it's a wonderful project, this issue is not meant to berate the project but simply allow the users to transparently assess whether the privacy provided by the software is sufficient for their needs.
About it being the most secure videoconferencing tool, I don't think that's the case, since if I understood correctly Jami has all communications E2EE, including videoconferencing (but it's not using webrtc, hence why they were not limited in that aspect). That said, Jitsi Meet is highly privacy friendly, it's in the top league for sure, particularly when self-hosted.
I am excited to hear that e2ee will be soon possible in webrtc, I'm really eager to see it :-)
I have just read the link you provided @murillo128 , thanks a lot! That's very very promising! It indeed looks like Secure Frames / SFrames could solve the issue once and for all of multiparty E2EE!
However I fear it may not be soon for Jitsi Meet since this will probably require some major rewrite since media encryption means that all server-side media transcoding and other bandwidth optimization schemes will need to be redesigned to the client-side. So let's wait until that happens, I will follow the progress anyway :-)
If Jitsi can implement multiparty E2EE, that would certainly be a big plus in the field, considering other companies are plainly lying about their E2EE capabilities when in fact they are simply using TLS encryption as does Jitsi currently (but at least Jitsi is transparent about that).
https://protonmail.com/blog/zoom-privacy-issues/