Addressing the issue of anonymity (or rather lack thereof)

[cyanlemons]

Preface

By and large, Status provides far more anonymity than your average messaging service. However, this issue will specifically be concerned with the following adversaries:

• Any governmental entity with subpoena power
• A malicious/coerced mailserver operator
• A malicious/coerced Infura employee

The threat model is as follows: given a particular chat key, Ethereum address or ENS username†, could one of the aforementioned adversaries determine the legal identity of the respective Status user?

Problem

All network connections will necessarily leak one's IP address. This, in and of itself, is not inherently bad. The issue arises from any data that may have been transferred in said connection.

Relying on common 3rd parties will not affect one's anonymity provided that no unique information is given to said 3rd party. For example, if Status were to simply ping 1.1.1.1, Cloudflare would know that a specific IP address pinged their DNS server, but that is it. In fact, they would not have even known the ping came from a Status user.

However, if any unique identifiers are transferred in a network connection, a link will be created between the IP address and said unique identifiers. Currently, Status will create a link between Status users and their legal identity.

This will happen in two circumstances:

1. It is my understanding that, when using a Waku light node, mailservers will either be able to accurately infer one's chat key, or simply have direct access to one's chat key. This means that a malicious or coerced mailserver operator could associate IP addresses and chat keys. Correction by @cammellos. It appears there is some kind of privacy depreciation when using a Waku light node according to the Waku spec. This could potentially, maybe result in the association of one's IP address and their chat key – given a sufficiently motivated, and perhaps lucky, peer node.

2. The Status Mobile Privacy Policy states that data sent to Infura includes public keys and signed transactions. This means that a malicious or coerced Infura employee could associate IP addresses and Ethereum accounts.

Potential Solutions

1. Solving the Anonymity Trilemma. This is the most ideal yet likely impossible solution. In a world where mobile phones would be exceedingly more performant than they are today, every Status user could simply run both a full Waku node and a full Ethereum node – and that would be the end of it.

2. Improving Waku and finding a reasonably performant yet private alternate to Infura. This would be the second best alternative, yet it would be very difficult to achieve. Lots of research and threat modeling would be required to determine the extent of the anonymity guarantees provided by Waku, and any private alternative to Infura is likely to be resource intensive for mobile devices. This would require lots of time and resources to implement properly. Much of this is currently a work-in-progress for @vacp2p.

3. Providing an option to route all traffic from Status through Tor. This approach makes several concessions: it will not be enabled by default, it slows everything down, and it breaks voice calls††. However, the primary benefits are that this would likely require far less development time, and only the users who opt-in would have a depreciation in performance – which is not necessarily the case for the 2nd potential solution.

4. (credits to @corpetty) Running a full Waku node on desktop and connecting one's light client mobile device to said full node. The primary downside is that the device running the full node must be online when the light client is in use (it must also be online when one wants to receive notifications without exposing one's IP). On the upside, this would would improve decentralization, bring much needed attention to the desktop client, and likely be quicker to implement than the 2nd potential solution.

Opinion

I share the opinion that the 3rd potential solution is the most optimal solution for the time being, and the one that is the most consistent with the 10 principles:

Additionally, we strive to provide the right of total anonymity.

As a bystander who is highly unfamiliar with Status' development process, I'd say a proper implementation of the 2nd solution would take no less than a year. That is a long time to wait for a privacy guarantee that I would deem essential.

Furthermore, even if the 2nd solution is implemented perfectly, this would not address the inevitable de-anonymization through DApp usage. Even if the perfect Infura alternative is created, the second the user logs into a DApp through the provided browser, they would associate their IP address with their Ethereum address. This association would not occur if all traffic was routed through Tor.

It is an unfortunate truth that, at the moment, I am unable to recommend Status to individuals who are actively being persecuted by well-funded adversaries. Instead, I would likely recommend XMPP w/ OTR over Tails.

Notes

†The assumption here is that the ENS username was purchased with cryptocurrency that was cleaned via @tornadocash or a similar service. Of course, if someone purchased their ENS username immediately after withdrawing their ETH from Coinbase, their identity would be compromised. That threat model is beyond the scope of this issue.

††Your typical voice call will be implemented over UDP, which Tor does not support. Even if it did, it would be terribly laggy. However, there could be a system in which one could initiate a request to call over Tor, and if the other party accepts, it would switch over to direct IP communication between the two users. This way, you could conceal your IP address from Status whilst revealing it to individual contacts that you trust.

[cammellos]

Thanks for the detailed post!

In terms of disclosing your public key, I believe you are correct regarding 3rd party services for the most part, one thing I would like to add is that your chat key is not the same as your wallet keys, as we decoupled the two (they are derived from the same root key but use different derivation paths). So I believe at no point we send Infura your chat key, while we certainly do for your wallet (keys).

It is my understanding that, when using a Waku light node, mailservers will either be able to accurately infer one's chat key, or simply have direct access to one's chat key. This means that a malicious or coerced mailserver operator could associate IP addresses and chat keys.

This is not quite accurate, we never disclose your chat key to a mailserver. We disclose the topics you are following (sha3 of the name of the chats and a few more) and your IP address (as it's a direct connection).

To figure out your public key a mailserver (or any node you are connected to, when you are a light node), would have to figure out a public chat your are connected to (that's not trivial, given that there's no way to go from topic -> chat-name), and correlate your posting with the messages sent.

Essentially it needs 2 pieces of information: a message that they can decrypt (so it can see the public key), and the knowledge that this message was sent from your node, and correlate the two (2 they always have access to if you are connected to them)

XMPP w/ OTR

That's interesting, we use a modified version of Signal's Double Ratchet (we don't have a central server, so it needed some adjusting https://github.com/status-im/specs/blob/master/docs/stable/5-secure-transport.md) , which I believe it provides the same level of security/confidentiality as OTR does (which is not anymore recommended by XMPP, replaced by https://en.wikipedia.org/wiki/OMEMO , which is based on Signal's Double Ratchet as well).

But I take the recommendation is strong e2e encryption over tor, which looks like a sound one.

[corpetty]

imo, until we have the ability for light clients (mobile) to be a full participant on the network (as useful as a status node), the easiest way forward is make it incredibly easy for users to run a full node themselves, and attach their light client trust (mobile's dependance) onto it. The full node doesn't broadcast the information it receives from light clients, but it can harvest them. This is mitigated by owning both.

Desktop will make large steps int his, as it gives the user a reason to run a status node, and accompanying infrastructure. the better we get that, the easier it is for users to conduct themselves accordingly.

As for blockchain related stuff, we are working on a myriad of privacy methods for not linking information when a user doesn't want to. You have to remember that the network isn't strictly for people who want to hide. It is meant to serve those individuals, but also serve as a network for those that want to broadcast their digital identity and attestations associated with it.

[cyanlemons]

Thanks for the input @cammellos & @corpetty.

In terms of disclosing your public key, I believe you are correct regarding 3rd party services for the most part, one thing I would like to add is that your chat key is not the same as your wallet keys, as we decoupled the two.

Although I was aware the two are technically decoupled, I do believe that there is an indirect threat here. For instance, an undercover law enforcement agent could request to send me 200 DAI on Status. Even if I don't know the guy, it's quite an appealing offer and I would likely accept. It's free money, right? I could even use a fresh Status account just for this instance if I am particularly skeptical. This would then provide them with one of my Ethereum addresses, at which point they could subpoena Infura for their IP logs associated with said address. Of course, this is a user error for trusting the wrong person – but a user error that could be mitigated if Infura didn't have this type of data to begin with.

This is not quite accurate, we never disclose your chat key to a mailserver.

I originally believed this to be the case due to the following portion of the Waku spec: "The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends)."

Perhaps this is the same possible de-anonymization route you were referring to with the 2 pieces of information, or perhaps it's entirely unrelated – I am not quite sure.

But I take the recommendation is strong e2e encryption over tor, which looks like a sound one.

That is correct, good encryption + Tor is always a safe bet. A bonus is the fact that many XMPP users exclusively connect to servers that are only accessible through onion services – essentially guaranteeing a Tor-only route.

And thanks @corpetty for the input on simply connecting to a desktop full node from mobile – I'll edit that in to the issue to make it a more encompassing view of all the possibilities.

[cammellos]

Although I was aware the two are technically decoupled, I do believe that there is an indirect threat here.

Yes, definitely an issue

I originally believed this to be the case due to the following portion of the Waku spec: "The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends)."

That's correct, there's a bit of confusion about naming, as discussed here :) https://discuss.status.im/t/wherefore-art-thou-mailserver-treatise-on-waku-terminology/1664/4

Basically they will be able to access to your message (waku envelope) and understand that that particular envelope originated from your node, but they won't be able to access the signature, so they won't know the pk of the author. (they need to have access to a clear text message as described above to correlate the two).

[cammellos]

Probably this is best for the waku/specs repo, closing for now https://github.com/vacp2p/specs

[cyanlemons]

I do not particularly agree with the closing of this issue. Half of the issue has no relation to vac, being the usage of Infura which exposes the user's IP address. This is strictly tied to the Status app itself, not the protocol.

As for the potential privacy concerns when communicating with Waku nodes, this still seems like an overarching "Status problem" to me. Anonymity is one of the core principles of the project, and this is one of the areas where I believe Status is currently falling short. I feel like this should be clearly documented until it is addressed.

[cammellos]

That's a fair point, I will reopen, thanks for your input.

[nahuhh]

Possible to add a socks5 proxy option? So you can point it at a local tor instance

Im currently running orbot/invizable (android) in vpn mode, tunneling all status traffic through tor without issue. No noticable delay, but have not tested extensively.

Id imagine calls are a ways out but this seems ideal

 one could initiate a request to call over Tor

Via chat protocol, similar to a payment request

and if the other party accepts, it would switch over to direct IP communication between the two users. This way, you could conceal your IP address from Status whilst revealing it to individual contacts that you trust.

Regarding tor - I would not implement orbots auto enabling features, as using them is pretty buggy in practice. socks5 proxy support, defaulting to 127.0.0.1:9050, should suffice.