🌐 Website Issue | Jami is missing a warning about metadata #1357
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#1357
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?
I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added.
I cannot find a direct quote, just two parts that need someone wiser to take a look:
https://www.techrepublic.com/article/privacy-focused-skype-alternative-ring-shows-promise/
https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol#contacting-another-account
I guess it's implied that your Jami usage is announced wide and this leads to the concluion that someone monitoring the network can see where a connection comes from and where it's going to.
See also:
From this link you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed:
SHA1("callto"+deviceID)
. So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID.wouldn't it be possible for the observer of the openDHT to calculate the same hash valua and correlate it?
Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?):
Since we establish peer-to-peer connexions between contacts, network operators could see the p2p TCP channel and infer who you're talking to. I guess this is true for most IP communication systems (even centralized) as network operators could infer source/destination IPs from the traffic flow, unless a specific strategy is deployed to hide the source/destination IP (like Tor). Currently the media channel is UDP-only which doesn't work over Tor but that might change (however the real-time communication experience might not be great by going over Tor).
Device and account public keys are published on the DHT. This is used for the user lookup and multi-device feature. Knowing the device ID or public key doesn't allow to know who's calling who, however a network observer could infer some meta-data.
Thank you very much @aberaud for taking the time to clarify this issue!
PR #2293 addresses this issue for all P2P networks, they all share the same issue of non anonymity of senders and receivers.
(PS: Given the discussion above, it doesn't appear that Jami leaks any more metadata than any other secure P2P network, it's normal that the nodes IDs are propagated through the network via a DHT for a distributed P2P system.)