cammellos
commented
4 years ago 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
cyanlemons
nahuhh
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:
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:
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.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
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.
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.
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.
(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:
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.