Web wallets said to give users control over their money

[luke-jr]

It is impossible for web wallets to meet this criteria...

[ABISprotocol]

@luke-jr Agreed. (I had previously thought a notable exception to this might be Coinkite, but when I examined it some more I realized that no web wallet could realistically be said to give users control over their money.)

[harding]

@luke-jr this score is only applied to web wallets that are believed to give users exclusive access to their private keys and which allow users to backup their private keys in a format that can be independently recovered. E.g., we're talking about Blockchain.info-style wallets that theoretically provide a secure front-end that prevents the server from accessing decrypted private keys.

For comparison, see Coinbase which has a score of "Money controlled by a third party."

We're all agreed that remote apps have additional security problems, which is why all web wallets have a yellow "remote app" score. For this reason, I think "control over your money" and "shared control over your money" are reasonably applied to web wallets.

[ghost1542]

The point is to make these distinctions so the user can know about them and take them into consideration. Technically, it is possible for any developer of any wallet to take control of users' coins at the moment users get or update the app. Closed source code, non-deterministic builds, auto-updates, live apps only increase that likeliness. This is why these points are also granted scores.

[crwatkins]

@luke-jr I agree with your sentiment, but I believe @harding explained the scoring well in that it describes the intent of the wallet function, not how easily it can be subverted (that's a different score).

[ABISprotocol]

I've thought about what @harding said and I still side with @luke-jr on this one. My two bits.

[ghost1542]

@ABISprotocol For what reason? Taking Hive Web and Bitcoin Wallet for Android as an example. The first one is a live web app, the second one is an Android app that auto-updates. In both cases, the developer can (willingly or not) issue malicious code that steals users bitcoins. Worse, now that I think of it, Hive Web cannot send an update into the users wallet while it's not in use, while BW4A can. It's not at all simple and it seems quite important to me that this kind of information is presented to the user, having exclusive control over the private keys being a crucial one (this is what this score is about).

[schildbach]

Bitcoin Wallet dosn't have any auto updates. Only if the user choses to install via an app store like Google Play s/he'll get apps auto-updated by default. If you install Bitcoin Wallet via direct download, there are no auto-updates.

[ABISprotocol]

@saivann I think that you are echoing at some level what I am trying to say. However, I would go further. To be quite clear, there is not a single example of a web wallet that can possibly offer users control over their money.
You mentioned Hive wallet. Let me hover for a moment on Hive. When you look at the message on bitcoin.org about it, it tells you that "This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds. You are however still responsible for securing and backing up your wallet."

This message (as shown from bitcoin.org about Hive) is incorrect. Why is this incorrect? For a variety of reasons. For example, the wallet simply does not - and I repeat, does not - give you full control over your bitcoins. A third party can in fact cause your funds to be frozen. Why? In part, because, as the bitcoin.org messages to querying users correctly state, there is "centralized validation" and it is a "remote app." That is enough right there. But going further, there are many more reasons why the statement that "this wallet gives you full control over your bitcoins... no third party can freeze... your funds" is incorrect.

Some of the reasons are due to the amount and type of regulation that affects web-based business organizations, in particular, any organization that uses the web as a platform to store or transmit money on behalf of users. Other reasons are directly due to the problems inherent in the design of the web itself and the failure inherent in choosing it for provisioning wallet technology to a largely unsuspecting public. While some of these problems and failures are accidental, other corporate failures have been entirely intentional - an elaborate exercise intended to foist modern forms of slavery and genocide on people (while masking it in the cloak of convenience of the 'web wallet') in perpetuity.

To sum up:

As @luke-jr said, simply and briefly, regarding this issue of 'control over your bitcoins,'

"It is impossible for web wallets to meet this criteria..."

And he is right.

So in conclusion, I don't think that it's right to put out a message on any of the web wallets that states "This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds." That portion of the message, at least (for web wallets), needs to be removed, and replaced with something more cautionary, like, "This wallet cannot guarantee full control over your bitcoins. Access to your bitcoins may or may not be available depending upon third party policy or regulation."

[harding]

@ABISprotocol I gave up reading your post when it implied web wallets promoted genocide. Nothing I read before that changed my opinion that the Control Over Your Money score is correctly applied.

Technical commentary from other people such as Luke is still welcome, but in the absence of such commentary (or Luke closing the issue himself), I suggest we close this issue a week from now (Wednesday the 12th).

[luke-jr]

@harding At the very least, the colour implications are very wrong. Coinbase-style webwallets are much more secure than Blockchain.info-style webwallets. Both systems essentially give the webwallet complete unrestricted access to your funds (which is why the current label is wrong), but at least Coinbase-style makes an effort to keep them secure from attackers by having an offline wallet. People are objectively getting the wrong message from this mislabel, as seen from comments on social media like reddit. Closing this issue while it is still a problem is not appropriate.

[harding]

Both systems essentially give the webwallet complete unrestricted access to your funds

I think there's a lot of uncertainty in that "essentially". A BC.i-style wallet that uses strong symetric encryption and reasonable key stretching should not have access to the private keys of users who use strong passwords.

We imply the need for using a strong password in the Control hover message: "You are however still responsible for securing and backing up your wallet."

Coinbase-style makes an effort to keep them secure from attackers by having an offline wallet.

Banks can have a number of advantages over other wallets if you trust the bank, and it's true that the scoring system doesn't convey most of those advantages. However, a large number of people don't trust banks, so this score exists to tell them whether or not using a particular wallet requires trusting the bank.

As such, I continue to think that the score is correctly applied.

[luke-jr]

Passwords do nothing to help in the case of a remote app.

[harding]

@luke-jr if the app was secure yesterday when you received your bitcoins, your bitcoins are safe even if the site gets hacked today as long as you don't login. (You can use your backup to securely recover the coins.)

[ghost1542]

@luke-jr It's impossible to predict if a remote app is secure in the backend. What we can show is how much the app requires trust. Giving outright access to your private key is what implies the highest level of trust. Not all remote apps store users private keys remotely either (Hive Web being an example again). I fail to see your point...

Maybe Coinbase have demonstrated that they deserve trust (although an absence of major incident isn't a garantee that none will happen), but this does not equally apply to any web wallet. The sad thing with web wallets is that it's impossible to verify if their claims about their internal security model is true, otherwise we could provide much more information here.

[luke-jr]

@saivann I think you're missing the point. Even if we take a completely anonymous third-party webwallet, it's still more secure if they use the "Coinbase-model" (aka best practices) than if they use the "blockchain.info-model".

[ghost1542]

@luke-jr The "blockchain.info-model" is not used by the majority of web wallets on the site. But regardless, could you elaborate? I think last David comment gives a strong argument as to why "Bitcoin banks" indeed involve more third-party risk. By "more secure", perhaps you are thinking about user-side problems (malware / disk failure / wallet deletion)?

[luke-jr]

No, I am thinking about "webwallet server gets compromised". With the Coinbase-model, they get the hot wallet; with the blockchain.info-model, they get everything.

[ghost1542]

@luke-jr That is assuming their cold wallet is really what's it's claimed it is, and isn't otherwise vulnerable to critical flaws, or easy to compromise by n employees. That's a lot of things nobody can verify. In the case of the BC.i model at least, wallets with a strong enough password would remain uncompromised for long enough for users to move their funds.

At the same time comparing only the BC.i security model isn't really a good representation of web wallets on bitcoin.org, since only AirBitz uses that model. Other wallets either only store the encryption key, but not the wallet (IIRC), or use multisig, both of which seem quite interestingly strong security models.

[luke-jr]

No, because as soon as the user accesses the wallet, the infected JS code will just send it all to the attacker.

[ghost1542]

@luke-jr This argument drags down to David's point. Infected JS would not affect users not currently using the wallet, while compromised Coinbase servers would affect all users Edit: while compromised Coinbase server would at the very best do the same, and at worse a compromised cold wallet would affect all users.

[ghost1542]

Note; if that makes everyone happy, I wouldn't have any issue with using a more accurate (but more technical) "Control of your private keys" instead of "Control over your money".

[luke-jr]

I would say there are generally more users using their wallet, than there are funds in a hot wallet...

[harding]

@luke-jr I think we've fully discussed this issue and Saïvann, Craig, and I all believe that the wallets are currently scored appropriately. It is my intention to close this issue in a few days if there is no further useful discussion. Thank you.

[luke-jr]

So the intention is to encourage bad practices over best practices? If not, this should remain open until it is addressed.

[ABISprotocol]

First and foremost, when I see that "It is my intention to close this issue in a few days," I often see an issue in the repository closed in a couple days; even if it should be open longer. I take issue with that and I request that this issue be held open longer for more public comment. This is obviously an issue that needs more thorough vetting and consideration.

As with other issues in the bitcoin.org repository, sometimes the maintainers might consider them to be unremarkable, and would conclude that they should be closed quickly, but holding them open longer obtains useful public input. This is certainly one of those cases.

Specifically to the issue of the language:

The current language for web wallets is incorrect. Even if one's opinion is that the wallets are scored appropriately, or if your opinion is that the current language does not specifically encourage bad practices, still, the language itself that one applies (that the user sees on bitcoin.org after the scoring is completed) is factually incorrect and needs to be changed.

How then should it be changed?

The existing language depends on the wallet, and appears as one of the following depending upon the scoring:

"This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds. You are however still responsible for securing and backing up your wallet."
(As an example, this language is displayed for Hive.)

(or)

"This wallet requires every transaction to be authorized both by you and this third party. Under normal circumstances, you can regain full control over your bitcoins using your initial backup or pre-signed transactions sent by email."
(As an example, this language is displayed for BitGo.)

(or)

"This service has full control over your bitcoins. This means you need to trust this service will not lose your funds in an incident on their side. As of today, most web wallets don't insure their deposits like a bank, and many such services have suffered from security breaches in the past."
(As an example, this language is displayed for Coinbase.)

Let's examine each language displayed (resulting from the scoring) in turn.

The first one ("This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds." (...)) is factually incorrect. It does not mean that the scoring is flawed per se, but that the language itself does need change.

Suggested replacement language:

"While you retain control over your private keys, this wallet cannot guarantee full control over your bitcoins. With this wallet, access to your bitcoins may or may not be available depending upon third party policy or country regulation."

Moving on to the second (which is applied to BitGo and others, which states in part) "Under normal circumstances, you can regain full control over your bitcoins", I would suggest alternative language to be applied there as well, to be:
"You may be able to regain control over your bitcoins using your initial backup or pre-signed transactions sent by email, depending upon third party policy or country regulation."
(Note the absence of use of "full control" in my suggested language."

In the third example provided (such as that language which is applied to Coinbase), I do not suggest changing the language.

[ghost1542]

@luke-jr I haven't found a concrete proposition for improvement in this discussion, nor a clear definition of a bad practice we can reasonably agree with. I am not sure if you have fully appreciated that the cases you are mentioning are already covered by other scores, or if you have considered other arguments. So I also agree that this issue can be closed for now.

@ABISprotocol I read your suggestion, and I think I see what you want to add here, but I don't really see extra value in mentioning that the wallet service can go offline or suddenly refuse you as a user, because that has no real consequences beside frustration, you can just switch to another wallet and you indeed kept control over your bitcoins all along. As for multisig wallets, they have been verified to make sure the recovery tools work, so you can indeed get your bitcoins out with no authorization from the third party.

[ABISprotocol]

@saivann As I see that my comments are being ignored in this discussion despite that I have presented valuable contributions and a reasonable presentation, I ask that the discussion be held open for at least a week for further input. I also ask that the maintainers of this repository publish here input they are receiving offline on this matter, if any, from web wallet authors or representatives, since it appears that logical arguments are being ignored and refuted. This makes me wonder whether there are other business interests (perhaps the web wallet authors themselves) who have suppressed necessary changes in the language. My requested changes are reasonable and necessary.

Again, I ask that this be held open for a week for further public input.

[Giszmo]

(off topic on web wallet issue)

@schildbach if the user does not allow auto update, which I would recommend anybody with bitcoins on his phone and think any bitcoin wallet should remind its users, BW doesn't auto-update neither if you got it from the play store. On the other hand it's near to impossible to tell for a regular user if an update or the original app is what the tagged version in git claims it to be.

[sunnankar]

@saivann Perhaps a brief usable classification based on the following definitions could be added for the wallets like:

Private keys: Sole control OR Shared control OR No control

Sole control - The user is able to prove they are in sole possession of the private keys during generation and storage.

Shared control - The user is in possession of the private keys but is cannot be proven that they have sole possession.

No control - The user does not have access to the private keys required to transfer bitcoins.

Of course, this requires some training on what private keys are and I thought it was the policy of bitcoin.org to not discuss them since the pull request I did previously for that was not accepted on the grounds that it was too technical for new users. I am still of the opinion that educating potential users on what private keys are and why they are so important would be good policy. This can likely be done in one paragraph.

[luke-jr]

@saivann Lack of a clear resolution is a reason to keep the issue open, not to close it. Closing it should only be done when it is resolved. These cases may be covered by other scores, but the current overall display is de facto confusing users and encouraging bad practices. It is a bad practice to keep all active funds in a webwallet online, which is what these webwallets are doing.

Note the real problem is not services going offline, but shipping you malicious code to steal your funds. There is no possible recovery from this, and makes it clear you do NOT have exclusive control over your money.

[ghost1542]

@luke-jr This point is covered by the transparency score, which gets a clear fail for web apps, while the first score is about who controls the key. What do you suggest? Edit: There could be resolution if we could agree that there is an issue in the first place, or otherwise a good suggestion for improvement.

[luke-jr]

@saivann I suggest making it clear that the webservice servers do in fact have control of the key, despite the obfuscation.

[harding]

@luke-jr I don't believe that's an accurate description of the situation, and I don't think we should change the text to say that.

However, I'm done commenting on this issue and will leave it to whomever continues commenting to find the appropriate resolution. As requested, I'm not going to close it (but one of the other maintainers may choose to close it). I will tag it as Help Needed so I can filter it out from the other issues and PRs that I feel I can actually do something about.

[ABISprotocol]

Reading from @Giszmo's comment (8/06/2015 forward) ~

My additional thoughts are that, there has been additional evidence in the form of web wallet or website based bitcoin service compromises since the time of my last comments (BitPay and the 5,000 stolen bitcoins being just one example ~ Sept. 17, also there is an example of Dispenser.tf [trade Steam items for Bitcoin] being robbed of 100 bitcoins, resulting in the site shutting down as reported in August.

It should be plain to see that there are serious problems with web wallets and that the arguments that I've posed previously are valid. There's no need to restate them.

I'll go back however to some suggestions that were made by @sunnankar ~ who suggested the following definitions:

"Private keys: Sole control OR Shared control OR No control

Sole control - The user is able to prove they are in sole possession of the private keys during generation and storage.

Shared control - The user is in possession of the private keys but is cannot be proven that they have sole possession.

No control - The user does not have access to the private keys required to transfer bitcoins."

Since the concern here should be whether or not the user has control over the private keys (if user doesn't, then they certainly don't have control of their money) then I can suggest the following based on the definitions above:

The current language for web wallets is incorrect. Even if one's opinion is that the wallets are scored appropriately, still, the language itself that one applies (that the user sees on bitcoin.org after the scoring is completed) is factually incorrect and needs to be changed.

How then should it be changed?

The existing language depends on the wallet, and appears as one of the following depending upon the scoring:

"This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds. You are however still responsible for securing and backing up your wallet."
(As an example, this language was displayed for Hive at the time I made my earlier remarks, but Hive has been pulled due to concerns about that wallet, and it no longer appears in the list of wallets on bitcoin.org at this time.)

(or)

"This wallet requires every transaction to be authorized both by you and this third party. Under normal circumstances, you can regain full control over your bitcoins using your initial backup or pre-signed transactions sent by email."
(As an example, this language is displayed for BitGo.)

(or)

"This service has full control over your bitcoins. This means you need to trust this service will not lose your funds in an incident on their side. As of today, most web wallets don't insure their deposits like a bank, and many such services have suffered from security breaches in the past."
(As an example, this language is displayed for Coinbase.)

Let's examine each language displayed (resulting from the scoring) in turn.

The first one ("This wallet gives you full control over your bitcoins. This means no third party can freeze or lose your funds." (...)) was factually incorrect. It does not mean that the scoring is flawed per se, but that the language needed change. As it so turns out, this particular subject (language for Hive) is presently moot because Hive is presently not displayed on bitcoin.org.

However, here's my replacement language if Hive were to be shown again on bitcoin.org:

"While you retain control over your private keys, this wallet cannot guarantee full control over your bitcoins. With this wallet, access to your bitcoins may or may not be available depending upon third party policy or country regulation."

Moving on to the second (which is applied to BitGo and others, which states in part) "Under normal circumstances, you can regain full control over your bitcoins", I would suggest alternative language to be applied there as well, to be:
"You may be able to regain control over your bitcoins using your initial backup or pre-signed transactions sent by email, depending upon third party policy or country regulation."
(Note the absence of use of "full control" in my suggested language."

In the third example provided (such as that language which is applied to Coinbase), I do not suggest changing the language.

The language suggestions I have made could be further refined by addition of @sunnankar's definitions, which clarify levels of control over private keys and matters such as P2SH (shared control).