Privacy preserving messenger application

After doing complete analysis, it's clear that there's no privacy oriented messenger out there at all. It seems that even the most "private" apps do not implement core privacy measures.

As example lacking unlimited identities which can't be correlated is first major fail. I should be able to impersonate different identity to every group and user. The other side should not be possible to tell if I'm the same person behind these identities without extensive timing / context analysis. Platform shouldn't provide a way of connecting these identities in technical terms. If I'm user A talking with B and C when I create a group and invite those users to the group, then we should get D E F identities. Its total failure if B and C happens to know each other and when I invite them to the group, they'll see that oh darn, that's the contact I've been talking with.

Some people claim that this would lead to spamming problems? No. if the group / contact is known by someone whom you don't like, the address is already burned. Then just create a new group and invite everyone you like to that. Of course with new identities. Creating a new identity / switching it should be just a button to press and it's done. Then the application locally which maintains the private keys for the identity should allow the user to "name" the identity ID: 62e7d860290b1c1b4429c572f5a4f9d / "Security discussion" + the application should provide automatic way to link the identity with group or recipient address. When ever I'm posting to user B my identity should be D. But if you'll create a new "unlinked / contact introduction" addresses to be given out, in that case you should be able to name the identity so you'll know where you've given it.

Also whenever someone contacts that "contact" identity, when you accept the contact, new identity should be assigned, so that the further potential conversion isn't linked to the "introduction" identity anymore. Fort his kind of application some level of onion where traffic is bounced around + DHT should work for storage, where the users of the network would store the encrypted data distributed around, but the initial source of the data would be completely obscured. Another option to do this would be using super / service / server nodes, where the last layer "Onion kind" of routing and storage in DHT is split on servers, instead of full P2P devices, making the application more mobile friendly. Metadata leaks minimized, as example the identifier hash would be the only thing known to the server. They don't know if it's channel, group, members or sender. All they know is the pseudonym recipient identifier of the message which basically can't be linked to anything. Also it would be trivial to make these identifiers to be re-assigned at specified interval, like 6 hours to 7 days or so. Then there's basically nothing permanent to track. Just the pseudorandom identifiers and strongly encrypted data.

I did shortly check with Session team and they said, they've got no plans to allow multiple identities per user (or at least more than two or so). Of course that can be circumvented using methods like having multiple devices, or multiple profiles / installations per device or running virtual devices etc. But still, the app won't provide out of box "unlimited" identities feature.

If abuse limitation is required, there could be on some layer anonymous tokens which are used just to verify that the random "blob" has been "paid" for. Whatever the payment means, it could be cryptocurrency, hash, anything, which just technically rate-limits flooding and maybe pays for the server nodes. But most important part is that we don't know who paid for it, nor we don't know whom the senders or recipients using the paid capacity are and what the messages contain, but if the payment identifier is good then let the traffic pass. This might be required, even if the users aren't bothered with the spam, there could be a possibility to bring the network down by spamming, which is practically just resource consumption attack.

Just makes me wonder how stuff like chatcontrol would work with platforms like this.

Any thoughts about this? I'm curious to receive feedback. Could DC network be used in this concept somehow, maybe maybe not, maybe it should be optional. Just random thoughts.

Also see: Anonymous, Private and Traffic Pattern Analysis resistant messaging platform

kw: privacy, concepts, pseudonymity, anonymity, architecture, design, principles.

2021-07-11

Update later related to this topic:
These project pretty much follows the concepts I were thinking about, including designs of Loopix and Panoramix. And not forgetting the latest development of Nym Project / Nym Network (@ nymtech.net ), which seems quite interesting.