Topic: Is StrongCoin's 'hybrid wallet' a lie? (Or rather, are ALL hybrid wallet a lie?) - page 2. (Read 5823 times)

Bottom line: it's time for folks to stop using hybrid wallets--or at the very least, StrongCoin in particular. Both ability and willingness were displayed in this case, and that's a sure sign to flee the premises.

And I find it funny that he's "intercepted" the funds but chosen to keep the sender anonymous. If any action were to be taken at all, I would have imagined leaving the funds untouched but publicizing the incident as much as seems necessary (note: as in making public, not as in running to the cops) would have been the morally upright choice. As it stands, the owner of StrongCoin just destroyed his own business, and possibly his entire business model.

Hope it turns out that it actually was stolen funds that were "intercepted," and that that the proper owner was identified. That's about the only thing that might make this entire outcome worth it.

Others have explained how it happened with StrongCoin. But there is nothing special about StrongCoin and hybrid wallets.

I have an Android phone and have some of my Bitcoins stored on it using Andreas Schildbach's bitcoin wallet for Android. I like many others update my software without looking at it particularly hard. I have not done much programming for a long time.

Andreas could easily pull the same stunt that StrongCoin did and put a special bit of code that steals back stolen funds. It gets worse even. Andreas's software depends on bitcoinj, written by Mike Hearn, who has repeatedly written about blacklists and also does not particularly value anonymity, and does believe Bitcoin can and should be regulated.

Would he sneak some code into bitcoinj itself to steal back stolen funds? Probably not but I can never be sure. (edit: to be clear I mention Mike not because I think he would, but rather because for someone whose views I oppose so strongly I still am trusting him surprisingly directly with hundreds of dollars)

Trust is a very hard problem.

I think this is a big issue. If the admin can gain control over your coins, any attacker talented enough, be it in hacking or social engineering, can also access your coins.

I don't think OP cares much about the moral issue at hand but the fact that it may need to be more publicly known that the wallet can highjack your funds if the operator desires. The common idea is that (probably incorrectly held, but held none the less) the public/private key cryptography protects you from them spending or doing something without your signature from the browser.

To show how inaction is different from action:
1. You know there's children dying of hunger in Africa.
2. You have disposable income.
3. You don't prevent these deaths.
Ergo, you should be thrown in jail for murder?


So in the StrongCoin case, I agree that once he decided to act, he should have helped the victim, as he did.

I'm simply not as fast as you jumping to the conclusion that it was the "evident" solution.

I'm not seeing your third choice.  I see: do nothing, do nothing, return the stolen funds.  I mean, if you're willing to distinguish choices that make no functional difference then there is an infinitude of options... he could ... return the funds... while wearing a funny hat.

I disagree that it's about the consequence. Consequences are one time things.  Today a thief is stopped and the stolen funds are returned to their rightful owners, tomorrow guys with guns ransack the operators home and 15% of the wallets get stolen… or maybe it doesn't happen. Perhaps it just gets hacked and the operator plays no role in the redirection of funds. Or maybe something else… Remove the trust and you remove the vulnerability.  You might demand that an operator be built out of stuff immune to human suffering— I don't agree— but do you also ask him to be immune from bullets? From court orders? From his own conscience?  Wheres the limit?  I argue that the answer isn't that interesting because no answer will be very good and because Bitcoin was invented so that we wouldn't have to ask that question very often to begin with.

Certainly there can be cases where you can debate the rightfulness or wrongfulness of a decision— but this isn't a good one for that:  This isn't a place where trust is unavoidable (like a BTC/USD exchange), and it isn't over a particularly grey decision...

If there's a false dichotomy, it's on your side... I added the 3rd choice, while you listed only 2.

The question here isn't, contrary to what you say, a question about power.
The question is a consequence of the said power.

This is a false dichotomy. "Inaction" is a choice too, to say otherwise is maddness: we can often orchestrate things so that great evil require us to only sit by "inactive". ... and the laws of many societies also frequently endorse the view that at least in some cases a duty to act is created— even though creating such a duty carries many risks and costs.

Ultimately, the question here was only about power. The site had the power and opportunity to stop the theft.  Failing to act on it would be a difficult choice, one that would open them up to adverse legal and moral judgements by others and one that many people— sympathetic to the thief's victims and not the thief— might have a hard time sleeping with. As I elaborated in my message— for some other operator the threshold might be different— higher or lower, depending more or less on the specifics or the pressure placed on them— but that there is a threshold is a fact which can only be changed by reducing the amount that we grant trust.

Someone asked me why I'm bothering to blather on about this... I think this is important because I hope people think deeply about trust and change their behaviors. It would make me sad if only thieves— who should know in advance that they can't depend on anything as thin as trust— get the benefits of reduced trust.

Well at least with the verifier the code must be the one on github. (Not fool proof, but that's nice)

What about the browser extension?

And while I was more interested in the technical aspect....

There's a difference between action and inaction in this case.
What I mean is the wallet provider can simply say "I will not mess with my users wallet", which would be inaction.
If the provider chose to act upon the request, he then has to choose between protecting the thief, or giving back the BTCs to the legitimate owner.

Even if inaction and protecting the thief would have had the same result in this case, the moral and professional implications aren't the same.
The 'action' taken was the good one, but I wouldn't be so fast as saying that action had to be taken.

The problem is this right here:

I think people who are hating on strongcoin are taking away the wrong thing from this.  This is the reasonable and expected outcome.

I suggest meditating on some words from Satoshi:

Used correctly Bitcoin is secure no matter how good the "excuse" is and in this case the excuse is exceptionally good:  Someone who ripped off infrastructure important to many of our community members, screwing both the users and a the operator (a rightfully well respected member of our community)— is utter scum. It would be wrong of us to expect anyone to protect him, he didn't protect Bitcoin— he didn't protect Ozcoin's users— he didn't look out for anyone but himself.  I agree that this can begin slippery slope of "excuses"— but Bitcoin has an answer to that that slippery slope: Build systems that don't depend on trust. But Bitcoin's trustlessness can't protect you if you go around delegating the actual use of Bitcoin to third parties.

When you use a webwallet you're trusting that the JS is not replaced out from under you— you're trusting that any 'validator' tool validates against something useful (and not just some copy the same operator can replace), and that no additional JS is being inserted which e.g. rebinds half the JS language and keeps the validated code the same while changing its operation, that the web browser environment— which wasn't designed for this kind of security at all and lacks basic features like mlocking data to keep it out of swap— is secure. You're trusting that the operator doesn't phish your passphrase— as they trivially can— or brute force it. You're trusting that the site gives you faithful information about the blockchain as none of the webclients have even SPV security. You're trusting that the site operators description of their service as secure is truthful and that there aren't subtle weaknesses that you don't personally understand. You're trusting a lot of things ... and especially if you're a disreputable thieving source there can be no basis for that trust.  It would have been wrong of us to demand that the operator of a service turn down a well substantiated request in a case like this, it would make them a villain to the kind and honest people their decision harmed. We shouldn't create a world where people have to make choices like that.

The webwallet wasn't the only problem here: For example, the address reuse made identifying the wallet vendor trivial.  These aren't new security issues, but a lot of people won't believe them without concrete examples.

Ultimately the problem here is one of introducing trust needlessly. Expecting this not to fail for a villain would be to expect inhuman behavior from the site's operators... and even a wallet service operated by the least human most profit oriented sort would have some "excuse" that was sufficient: Perhaps for some it's a crime that ought to be solved, for others it an attractive bribe, someone else might be motivated by a court order— or by a literal gun held to their head. Whatever the exact contours of the breaking point is— it exists.  Bitcoin was designed to liberate us from so much dependance on trust, but it can only do that if we use it— and not thin-clients that kinda-sorta-approximate it.

I'm glad that the example here is one where a really obvious thief gets screwed over and not someone less deserving. Hopefully the honest folks will learn and change their behaviors faster than the thieves do.


[I'm sure this is going to get discussed in a dozen different places— I'm not going to bother trying to track them all down. If you see it discussed elsewhere and you thought my comments were interesting, please feel free to drop a link back to here]

It wouldn't help here. The verifier just checks that the code matches the published code.

Hmm, so StrongCoin doesn't have the equivalent of Blockchain.info's javascript verifier?

Hard code the payment code to redirect the funds to wallet of your choice when the user logs in and attempts to send the money else where.  Maybe they cant get access to the money when its being stored encrypted, but when you log in and execute the payment to an outside address, that address could be redirected at that time with very little effort.

If find this really disturbing:


My understanding of a hybrid wallet is that this cannot happen.
So... how did this happen?