The reference client being in-browser is a very deliberate choice: most users aren't going to download a client to play around with a new currency. It's certainly our hope that people will start building non-browser clients, and because everything is open-source and available it should be easy to do so.
As soon as you're in-browser, you have a choice: do it server-side, which means you have access to people's funds (at least while they're logged in), or do it via client-side JS, in which case you don't. The choice there for Stellar ended up being pretty straightforward, though the simple implementation leads to some UX surprises such as: https://www.stellar.org/faq/#_Why_do_I_need_to_authenticate_....
> or do it via client-side JS, in which case you don't.
Of course you do, it just takes a teeny bit more work--you swap the contents of crypto.js with the contents of malicious-crypto.js. The threat model is exactly the same (users either trust the server or they don't) but the browser crypto option adds a layer of (respectfully, because I know you're a very intelligent person who means well) bullshit.
Ah, so certainly malicious JS code could misbehave and gain access to your account. But this is true also for someone publishing a desktop client — in practice, people aren't going to check the code going into each release, any more than they're going to inspect the JS running on their page before entering the password.
I think the question of where your password by design will go is very important. If it's transiting the server, suddenly there's a lot more surface area to worry about. Logfiles, databases, and the like suddenly can be called into scope, and an attacker might be able to steal credentials even without being able to substitute out code.
In any case, the great thing about an open ecosystem is that, if you don't like the choices someone else has made, you are more than welcome to make your own implementation with choices you prefer!
Comments
The reference client being in-browser is a very deliberate choice: most users aren't going to download a client to play around with a new currency. It's certainly our hope that people will start building non-browser clients, and because everything is open-source and available it should be easy to do so.
As soon as you're in-browser, you have a choice: do it server-side, which means you have access to people's funds (at least while they're logged in), or do it via client-side JS, in which case you don't. The choice there for Stellar ended up being pretty straightforward, though the simple implementation leads to some UX surprises such as: https://www.stellar.org/faq/#_Why_do_I_need_to_authenticate_....
> or do it via client-side JS, in which case you don't.
Of course you do, it just takes a teeny bit more work--you swap the contents of crypto.js with the contents of malicious-crypto.js. The threat model is exactly the same (users either trust the server or they don't) but the browser crypto option adds a layer of (respectfully, because I know you're a very intelligent person who means well) bullshit.
Ah, so certainly malicious JS code could misbehave and gain access to your account. But this is true also for someone publishing a desktop client — in practice, people aren't going to check the code going into each release, any more than they're going to inspect the JS running on their page before entering the password.
I think the question of where your password by design will go is very important. If it's transiting the server, suddenly there's a lot more surface area to worry about. Logfiles, databases, and the like suddenly can be called into scope, and an attacker might be able to steal credentials even without being able to substitute out code.
In any case, the great thing about an open ecosystem is that, if you don't like the choices someone else has made, you are more than welcome to make your own implementation with choices you prefer!