Wallet should not generate network traffic before asking the user for proxy settings

[JeremyRand]

It's generally considered good practice in software that might want to use Tor, to prompt the user for proxy settings on the first run, before generating any network traffic. That way, the user doesn't accidentally connect over clearnet. Giving visual feedback once clearnet traffic has begun isn't necessarily sufficient; the user should be given a choice of proxy settings (on first run) before the wallet connects to the network.

[kristovatlas]

Agreed. The way that we currently include this in the ratings is by counting the number of clicks to perform various operations that protect network-level privacy. The ideal wallet has this turned on by default with no configuration required by the user, and would prompt the user during setup whether they want to disable these protections. They might also allow the user to disable these protections in a settings area of the app, as well.

[kristovatlas]

Let me know what you think of this approach so I can decide whether this issue needs to stay open or can be closed.

[JeremyRand]

My opinion is that the number of clicks doesn't really capture the real metric, which is how likely the user is to accidentally connect over clearnet. If it takes a lot of clicks, but the user is always safe, I think that's preferable over taking only one click but the user might get deanonymized. There is some correlation between clicks and likelihood of network leaks, but I don't think they're really the same thing.

Imagine the following two wallets:

Wallet A prompts the user on first boot to choose a proxy and a port, or to choose clearnet (and remembers this going forward). The extra clicks/typing of entering those settings make it more than one click. However, the wallet never connects to the network until the user finishes on this dialog.

Wallet B connects to the network immediately on first boot, but has a toggle button which when pressed once, disconnects from clearnet and reconnects via Tor (and remembers this going forward). It automatically guesses the Tor port, so it's just one click.

I think it's pretty clear that Wallet A has a major safety advantage over Wallet B, which is not reflected in click count.

[kristovatlas]

Both hypothetical wallets A and B are not going to get very many users connecting through Tor.

Most users are going to be baffled by a prompt for proxy information, and will go with the path of least resistance.

The proper design IMHO is to connect through Tor by default without asking the user, and prompt the user to disable this feature if they wish.

I agree that wallet B is marginally better than wallet A, but honestly this is an academic distinction at present since no wallet allows Tor connection in just a few clicks. Note that we include in this metric the number of clicks required to download and configure a Tor proxy, since the ideal wallet packages this software in the wallet client.

[JeremyRand]

I suppose you're correct that the distinction is theoretical at best. Feel free to close this issue if you think making changes to the criteria isn't a significant benefit in this case.

[justusranvier]

The way our criteria are currently written, the only way for a wallet to get a score of 100 would be if it never sends traffic over the clear net unless explicitly told to by the user (zero clicks needed to enable Tor support), so I think the criteria as written already achieve the intent of this issue.

[JeremyRand]

Rethinking this, I think that this is an issue of feedback rather than (or perhaps in addition to) number of clicks. However, it's hard for me to be certain, because I don't see the three categories of criteria explicitly defined somewhere. Are they defined somewhere that I missed?