Add "Remote Node" Wallet Classifications

[bitjson]

Edit: 7/1/2015

I think the choose-your-wallet page is missing an opportunity to promote better security practices. I'd like to fix this by clarifying some wording and improving two descriptions with an additional sentence:

You can eliminate this requirement by connecting the wallet to a remote node you control.

and

To avoid leaking information, you can connect the wallet to a remote node you control.

---

Please see discussion in #888.

This pull request adds validation and privacy classifications for "remote node" wallet architectures.

Wallets with open-sourced server software and an in-app option to use a user-controlled server would fit these classifications.

This pull request initially marks Copay with the added classifications.

---

Remote Validation

checkfailvalidationremote (currently displays in yellow)

Payments are validated by a remote node rather than the wallet itself. By default, this requires trust in the remote node to not hide or simulate payments. You can eliminate this requirement by connecting the wallet to a remote node you control. However, it is not as secure as a full node like <a href="#download#">Bitcoin Core.

Discloses information to a remote node

checkfailprivacydisclosureremote (currently displays in yellow)

By default, this wallet uses central servers which are able to associate your payments together, log your IP address, and retain records of metadeta your wallet shares with the node. To avoid leaking information, you can connect the wallet to a remote node you control.

[bitjson]

#888 (comment)

If we want to make changes to the scoring criteria that will affect other wallets I believe we should have a separate PR with a subject that publicly indicates our intent. (My guess without checking is that the majority of the wallets that are currently scored to use a central server will tell you that you can set up your own if you want.)

I believe these additional classifications are relevant for the following wallets:

• Coinomi – Android
• Ninki – Android, iOS
• Airbitz – Android, iOS
• Hive – Android
• Mycelium – Android
• BitGo – Windows, Mac OS, Linux
• GreenAddress – Windows, Mac OS, Linux

To fit the classifications, wallets must:

• use an open source remote node
• allow users to connect the wallet to a user-controlled remote node

After reviewing each of these wallets, I believe none of the above wallets match these criteria.

[bitjson]

@crwatkins @Coderwill @saivann @harding, could I get your feedback on this PR? Thanks!

[harding]

@bitjson thanks for opening a separate PR!

I'm mildly against this. In the past, we've had the policy that we score wallets based on their default settings. This has caused plenty of disagreements before, but it feels like the best choice for our current simple page design and our target audience of new Bitcoin users.

This PR seems to score wallets based on what's reasonably possible for a power user to do, not what newbies get from a default installation.

Does that make sense? I do note that I think we'd all like to better address configuration options / multiple wallet modes when we next redesign the page, as more and more wallets are like Copay in offering significant extensibility.

Thank you again for your active participation on both PRs! (And, by the way, Copay is pretty friggin' awesome.)

[bitjson]

Thanks for chiming in.

In the past, we've had the policy that we score wallets based on their default settings.

I agree with this policy. 👍

This PR seems to score wallets based on what's reasonably possible for a power user to do

I'd like to clarify – this PR does not score Copay based on what's possible for a power user to do, it scores the wallet based on it's default settings.

If we assumed all users would take advantage of the possibility to self-host the remote node, we could give the wallet a checkpass. Instead, this PR gives Copay a checkfail in both the validation and privacy categories. (For those reading along, this currently displays in yellow rather than green.)

---

I don't think I made it very clear in the PR description – right now, I think this page is missing an opportunity to promote better security practices.

I'd like to fix this by clarifying some wording and improving two descriptions with an additional sentence:

You can eliminate this requirement by connecting the wallet to a remote node you control.

and

To avoid leaking information, you can connect the wallet to a remote node you control.

These descriptions are not visible until the user first reveals the popup for the wallet, then reveals the popup for the scoring items in question. (So they don't add complexity for new users and will only be seen by those trying to deeply understand the topic.)

There are also already 35 descriptions like these (a number of which are only applied to a single wallet), so it seems (and I would agree) that accuracy and promoting security are more valuable to us than maintaining regularity between descriptions.

---

I think it's also worth mentioning again – the existence of these classifications might encourage future wallet developers to consider open-sourcing the remote nodes to which their wallets connect; that would be a very positive step for security in the bitcoin ecosystem.

[bitjson]

@harding thank you for keeping this site so well-maintained!

[harding]

@bitjson

Instead, this PR gives Copay a checkfail in both the validation and privacy categories.

Indeed it does. I had misunderstood someone else's objection and not looked closely enough to notice that. Sorry.

I searched for the word "can" in our current score descriptions and found four that seem to make the kind of suggestions your PR makes:

• Using a browser extension or mobile app, if available, can reduce that risk.
• Encrypting your mobile and backing up your wallet can reduce that risk.
• Securing your computer, using a strong passphrase, moving most of your funds to cold storage, or enabling two-factor authentication can make it harder to steal your bitcoins.
• Tor can be used

So I think there's definitely precedence for this kind of text. On the other hand, I'm still hesitant: for every negative score we give, there's probably some possible work around. Should we list them all, list none of them, or list only the ones we think are important?

[saivann]

@harding I think we don't have much choice but to pick what seems to be most relevant advices after outlining a problem in the scores. However, that doesn't always mean the features we're talking about are all directly supported by the wallet (e.g. cold storage, 2FA)

I would perfectly understand why one would prefer to put this PR on hold until the page is reworked instead of accumulating scores one over the other. That's nearly becoming too much work. I wouldn't be shocked either if these scores were considered good enough and merged for Copay alone, and eventually applied to other wallets later (and maybe edited to fit more wallets at once) when wallets get re-reviewed or someone suddenly start working on optimizing scores.

[crwatkins]

I have to agree with @harding in that I'm mildly against this. As I mentioned in a bit more detail in #888 I've recently been reviewing more suggested changes to the scoring system than I have been reviewing wallets themselves, and I just don't think this differentiation is compelling enough at this time (lazy reviewer syndrome). I might find this more compelling if it were easier and more straightforward to invoke the option of running a remote node. Even in the Copay/BWS situation in which the server is very well documented and very well maintained, it still takes significant effort to install development tools, install, run, and maintain a separate database product, install the server, secure it, and run and maintain it. This is all very difficult, at least compared to clicking on a wallet in an app store which is our difficulty baseline here.

At this point I pretty much need to be overwhelmed with the need for a change for me to actively recommend it.