Quote from: grue on April 09, 2013, 09:14:24 PM

the reason instawallet failed was because it had control of all the private keys. unless you store all private keys clientside, and ensure all signing operations are done clientside, your wallet service will always be insecure.

Well, doing stuff user side in javascript isn't exactly a pretty thing to do, it turns out

A good way to do proper user-side browser key management would be browser plugin (Nadim eventually went that way with the cryptocat chat), but that kind of defeats the whole "no hassle" aspect of the service in a very fundamental way (as do mandatory passwords / registrations - hence our passwords are optional)

Of course there is a certain inherent risk to having a server-centric design, but I have good reasons to believe it is reasonably small*.

Neither web frontends nor backends serving them are inherently insecure (You can always prove me wrong and hack Gox, taking their hot wallet Cheesy

), and we intend our design to be very robust.

____________
* it should be noted that there is oftentimes a tradeoff between comfort and security going on

Quote from: glitch003 on April 09, 2013, 09:18:48 PM

^this^ people, don't store coins that you would be uncomfortable losing with this service. The private keys are server side and your money is not safe!

Strictly speaking, nothing is absolutely safe, only safe to varying degrees.

Javascript crypto isn't safe by a very long shot, and it would be rather hard to tell whether a well-done classic approach would not turn out "safer" than a user-side implementation done via such means (cryptocat abandoned this approach after almost singlehandedly pioneering it, after all)

Your stuff isn't absolutely safe even if stored in a physical safe

There are, however, degrees to safety, and tradeoffs between safety and other utility forms (such as comfort, ease of use, setup speed, additional valuable functionality, etc.)