Use an account A that has not been connected to the Internet since registration, run it in the LAN, and add B.
When A and B are in the same group chat, although A is not connected to the Internet, B in the same LAN can forward messages.
Therefore, this complex method can achieve a certain degree of anonymity for account A in group chat.
Although B cannot hide its own IP in it.
After trying, I found that this seems feasible, but I want to know if there are any loopholes in this method?
Actually Peer-to-peer (P2P) still might not be anonymous enough:
Other messengers might have more privacy if you really want to hide your identity:
Overview: https://smokeappope.sourceforge.io/
3 Likes
I think this method can increase the cost of tracing to some extent, especially when there are many members in the group
It’s just one-hop proxy + a infeasible assumption that adversaries can’t see traffic between the proxy and users. It’s very weak.
1 Like
If possible, I would like it to only run in the local area network. Given Jami’s characteristics, there is a certain chance that the monitor will not be able to lock users. If possible, perhaps we can increase the number of users who can help redirect to 3-5.
When the number of group members exceeds a certain number, it is also difficult to review
However, there is a problem. Maybe we can see that anonymity is implemented on Jami only after Jami supports tor, but Jami’s anonymity still needs anonymous users. If the user leaves traces on the Internet, then such anonymity is only false
This may mean that we need to register a Jami user who will always run only on the tor,
My point of view is that Jami may be able to use some mechanism to enable the current user to obtain an identity exclusive to the tor
Jami’s user traffic is indeed too low, and even increasing the number of jump nodes would not be difficult for review. This is something I did not consider before