New layout for the "Choose your wallet" page

[saivann]

Live preview: http://bitcoinwallet.us.to/en/choose-your-wallet

This new layout is addressing many issues and feedback, with a focus on the following points:

• Providing increased transparency about security and the zero trust model.
  (making it a better education material and providing incentives to developers to improve their wallets over time.)
• Easing the selection process for the visitor.
  (by simplifying the page and allowing users to filter wallets by platform, with access to clear information and screenshots.)
• Allowing the page to scale with the increasing diversity of wallets.
  (by not isolating wallets into single categories anymore and introducting anticipated hardware wallets.)
• Encourage diversity and decentralization.
  (by not recommending a single wallet anymore, and by rotating wallets daily by « zero trust levels » - full nodes followed by SPV wallets followed by hybrid & multisig wallets followed by web wallets.)

The following points are reviewed for all wallets:

• Private keys
  What control the user has over his bitcoins?
• Block chain
  How secure and « zero trust » is payment processing?
• Transparency
  How transparent and « zero trust » is the source code?
• Environment
  How secure is the environment of the wallet?
• Privacy
  Does the wallet implement change addresses properly? (for now)

Web wallets controling users private keys were previously hidden behind a strong warning.

The new page is displaying the same warnings and a few others from the wallet bubble. Web wallets are sandboxed out of all categories unless they provide control over private keys to the user and a native app that signs transactions locally. Future certification standards could possibly allow web wallets to provide enough transparency to be listed outside of the sandbox in the future.

Bitcoin Core previously had a complete paragraph inviting users to adopt full nodes.

The new page instead always displays Bitcoin Core as the first wallet and the reasons why users should choose Bitcoin Core are better outlined by its good zero trust score. Bitcoin Core is also contextually linked from other wallets' disclaimers.

This layout has been tested on recent and older versions of CH, FF, OP, IE, SA, Android & iPhone. A few small bugs exist for older browsers, IE6-7 isn't supported for now.

[schildbach]

Thanks for this good work, @saivann ! I like it.

Daily random positions have been tried 2-3 years ago, but disliked by the majority. I'm for example confuzed if things change positions, because my brain works "geometrically".

When scrolling with an open bubble on an Android device, the bubble closes. I would expect it to stay open.

I think it should be possible to open the details of a greyed out entry. Maybe make it need a click on the icon.

Generally the list is now less nice to the eyes, because it has less structure. Of course that was one of the intended goals, so its hard to prevent. Just keep in mind how the page would look with 20 or 30 entries.

[schildbach]

What is the "Hardware" category for? If you think of Trezor, its a supplement to potentially all other wallets rather than a complete wallet. Also I think the lock icon is not a good choice for hardware, because it's not any more secure just because it's hardware.

[harding]

@schildbach for your "bubble closes on scroll", could you post device/browser details? On my Motorola Droid 2 running Android 2.3.5 and the default browser, I don't have the problem you describe. Thanks!

[gmaxwell]

Hm. It's easy when you're looking for a desktop option to get recommendations for mobiles, this is bad (among other reasons) because the security story is substantially different in some of the cases.

[gmaxwell]

"minimum privacy" sounds worse than "weak privacy". Maybe "Basic privacy"?

WRT privacy electrum sends your address list to servers you connect to (and bitcoinj based wallets send a bloom filter to all its peers which is almost as non-private).

[harding]

@gmaxwell good catch on minimum privacy sounding worse than weak privacy. Thanks! (@saivann, sorry I didn't catch that.) I'm not sure whether basic privacy sounds less or more private than weak privacy, so maybe a better solution is just to swap the two: use minimum privacy for address-reuse wallets and weak privacy for non-internal-reuse wallets.

As for combating the logo effect where users assume a good wallet in one category will be a good wallet in another category, perhaps we could add a sentence to the descriptions of multi-category wallets that says something like, "Other versions of this wallet may have more or less security and privacy."

Edit: or put a warning above the list of wallets: "Warning: Wallets that offer good security and privacy on one platform may not offer the same benefits on another platform."

[gmaxwell]

Or break out privacy into a couple bullet points:

• Avoids Address reuse
• Avoids disclosing address information to peers
• Supports Tor Hidden Services
• Avoids address linkage
• Unlinks transaction histories

(the last being things like CoinJoin / Coinswap, which none of the popular wallets implement yet.)

Maybe too long for the page, but it could go into the privacy over and the front page could say "3/5".

[harding]

@gmaxwell I like it!

@saivann I think if we do what @gmaxwell is suggesting, we'll fill up the privacy bubble with just the score list---so we won't have enough room to describe what each item means. Would you like me to type up a short page for newbies describing, in one paragraph each, what the five items mean? We could then link to it from the privacy bubble or from the text at the bottom of the page.

[schildbach]

@harding It was the browser included in Feedly. Standard Chrome doesn't show this behaviour. So I guess its not important.

[saivann]

@schildbach, Thanks for your feedback!

Rotating: I am not aware of previous discussions, what was the reasoning against rotating? The purpose of this change was to adopt better neutrality when promoting wallets. This implementation is particular though, as it still keeps wallets in a defined order "Full node -> SPV -> Hybrid/Multisig -> Web", and is rotating only on a daily basis so the average visitor don't notice the change. Thus far I haven't seen negative feedback about this, maybe we can give it a try?

Click on greyed entries: I'll try to allow this!

Scalability: Yes that's a good point. I have imagined that if we have too much wallets in the future, we could just hide some instead of greying them out (this is already how the mobile layout works). But for now at least, this layout is generally more scalable.

Hardware wallets: I must admit I am confused, don't you think hardware wallets will be a huge step forward for increasing security? Given how positively they have been received and since it appears most people will use them as a cold storage safe (which is not accessible to most people without these devices), it seemed to me we couldn't reasonably ignore them even though they are just signing devices, so I have used the "lock" icon accordingly. Can you give me more details about your opinion / suggestions for a different way of presenting them?

@gmaxwell, Thanks for your feedback!

Desktop / Mobile: At the very least, each "Download" button links to the app directly for this purpose. I'm not sure we should go down the path of displaying more disclaimers because so far only the "Environment" score is really different between platforms. The "Transparency" score is changing because I'm concerned that people often don't use the browser extensions, yet we still link to these extensions so technically these apps may deserve an equivalent score both on "Desktop" and "Mobile". But I would be fine either with keeping current "Transparency" score, or giving a bad score to any wallet which can be accessed from a webpage without requiring an app.

Privacy: (..And avoids logging your activity & identity on a central server.. and..). These are certainly all relevant, I was afraid the "Privacy" score would become complicate. Suggested changes aren't small or simple ones, so I think this might be better done seperately (I don't mind merging this pull request without the "Privacy" score for now if it is considered too limited).

But as for what I had in mind, I though we could start with clear priorities and requirements everyone seems to be agreeing with and later raise the bar while experimental privacy features are maturing. Although I am not strongly opposed to making more complex bubbles with more detailed technical information, I wished we could present this information in a more palatable way to the final user just like other bubbles. So, basically, present a good score (bold green) to wallets supporting a defined set of advanced privacy features like those mentioned above, and a passing score (normal green) to wallets supporting privacy features all wallets should be supporting. Keep it simple.

It's also worth making a difference between a feature and a default feature, all other scores are based on default features affecting the user without requiring an action from the user (e.g. CoinJoin as an option is completely different to CoinJoin by default). IMO optional features should always go in the wallet description and not in the score.

[schildbach]

@saivann I have no idea where the discussion was, but here are the commits:
6850fc8 and
bc720e8 (revert)
Maybe @gmaxwell remembers why the commit was reverted.

Hardware wallets: Once again,what devices are you thinking of? Are there actually any hardware wallets?

[gmaxwell]

IIRC someone made a pile of changes including a number of ones I would have strenuously opposed without any comment at all— just a direct commit to the repo, I reverted them all as a group. I recall there was some "omg wtf" discussion, but I don't recall where it is (if anyone really cares I can go find it).

I don't have any issue with rotation so long as it preserves intentional structure to the extent that there is intentional structure. (e.g. if we've listed an almost unusably bad application (why would we do that these days?) but put it last, it should stay there).

[saivann]

@schildbach

Hardware wallets: Sorry, yes, Trezor, BitSafe and the like. Being open-sourced and using the "push model" (user must be able to authorize transactions on the device screen) would be the basic requirements I had in mind for hardware wallets.

@gmaxwell @schildbach

Rotation: Thanks for the explanation. Well, yes, there is an intentional structure with the current rotation, so wallets cannot be displayed in a controversial order IMHO (e.g. web wallets will accumulate at the end of the list, but none of them will be promoted more than the others). It is also possible to implement rules such as the example suggested by @gmaxwell if necessary. Of course if someone notice negative feedback or good reasons to disable rotation, it's fairly easy to do so.

My impression is that Amir's commits weren't well received mostly because he was adding blockchain.info and also allowing this app to be displayed prominently with wallet rotation without proper discussion. I've searched quite a bit but didn't find these discussions on bitcoin-dev / Google. So I don't know if digging out these discussions is worth the effort and may reveal useful arguments.

[saivann]

@gmaxwell WRT privacy, I really appreciate your feedback. I'll ponder about it more, maybe your suggestions will be the only feasible one, in which case I'll try to change the general structure to make it possible (probably in a seperate pull request if you don't mind).

[schildbach]

@saivann I still think Trezor is not a wallet on its own. It's a co-signing device, isn't it? You always need one supporting wallet. MultiBit plans to support ist for example. Afaik, currently there is only one web wallet to support Trezor.

[harding]

@schildbach I'm not quite sure what you mean by co-signing. Trezor doesn't appear to use multisig by default. (Their FAQ says, "3. Once the wallet software asks for the master public key, it will show your addresses and their balances.")

On the other hand, you do need a network-connected wallet to create the unsigned txes and broadcast the signed txes.

@saivann I think @schildbach brings up an interesting point. Trezor with Multibit has the security of Trezor but the network privacy of Multibit---which is different than the combination of Trezor with the MyTrezor web wallet. I'm not sure how we should present that information to the user.

[schildbach]

Of course you can use Trezor also for single signing, but I think cosigning makes more sense since you already need to use two devices. My point is that Trezor alone is not functional -- you always need to pair it with a wallet. Thus, the hardware wallet category doesn't make sense.

[harding]

@schildbach I'm not sure cosigning making more sense in this case, but that seems to be off-topic here.

Armory requires a local bitcoind for its online mode, yet we list it---so I think its reasonable to list wallet-like-things which depend on other wallet-like-things. To me the question seems to be how do we list a variety of different wallet-like-things on one page?

I think that's the problem @saivann set out to solve with this update, and I think he's done a good job categorizing a diverse set of wallets. I see no reason he can't also fit Trezor-like devices in his taxonomy.

[schildbach]

Afaik Armory comes with bitcoind, so for the user it's a complete wallet.

[saivann]

Since Trezor does not connect to the network and requires a separate app, I thought we could simply mention it in the description and use this as the "Decentralized" score : https://github.com/bitcoin/bitcoin.org/blob/wallets/_translations/en.yml#L136

It's absolutely right to say Trezor is a signing device and needs another wallet for payment verification, just like the Armory watching wallet. But is this an issue or just a feature? To me, giving access to specialized devices for cold storage to the user was the greatest priority.

[schildbach]

Yes, mentioning Trezor support in the individual apps that support it makes sense. And of course it's a feature.

[harding]

@schildbach From Armory's website "The first time you start Armory, you will notice that you need Bitcoin Core (or bitcoind) installed..."

@saivann It sounds like you're proposing that software wallets list in their bubble whether or not they support hardware wallets, and that hardware wallets list in their bubble which software wallets support them. That sounds good to me. Perhaps hardware wallets should list for the relevant parts of their score, "Privacy depends on connected software wallet" or "Decentralization depends on connected software wallet".

[saivann]

@harding Your suggested titles sound very good to me, but they need to be much shorter to fit in the layout. Maybe I could assign a grey color code and we could use "Neutral decentralization/privacy" or similar.

Unless Trezor-like devices become popular, I think it's easier to list compatible wallets only in the Trezor description, and let each wallet developers choose if they want to mention Trezor in their descriptions.

[saivann]

@gmaxwell I just updated the layout to address your feedback regarding privacy, in case you have time to take a look at the updated the live preview. I didn't include CoinJoin for now but this can be easily added when there are wallets supporting these features.

[harding]

@saivann the privacy update looks great!

I like the grey color idea. Maybe instead of "neutral privacy" we could say "privacy varies" and then use the details bubble to explain: "Privacy features are provided by the software wallet you use with this device. Please see the Privacy score for the software wallet you plan to use." The same for decentralization.

[saivann]

@harding I just included your suggestion, thanks! Here's a screenshot of what it would look like when Trezor is added.

[saivann]

This pull request is now a week old, feedback has been very positive thus far on reddit, bitcointalk, GitHub, email, and there doesn't seem to be blocking issues, so I think we could merge it and submit additional improvements using issues or pull requests.

So! In the absence of critical feedback, this pull request will be merged on July 25th.

Thanks for your review and feedback, this is much appreciated!

[schildbach]

It's you choice, but I certainly would not add an empty "Hardware wallet" tab. That even more confusing than the entire idea of a "hardware wallet". So I'd at least wait with merging until there is content, or strip the tab.

[harding]

I think @saivann had a plan to hide the hardware wallet tab for now; I agree it should be implemented.

Otherwise, merging sounds good to me. Great work, @saivann!

[saivann]

@schildbach Agreed, I'll just hide this menu for now. I guess Trezor should start accepting orders very soon, but regardless, a seperate pull request will need to be open, just like other wallets.

@harding Thanks!