Can anyone on the core team give us a sense of what security measures are going to be implemented regarding the Javascript bindings? Right now, as I understand it, any page you visit in an EtherBrowser can get unrestricted access to your private key. This is of course terrifying. Will this be locked down more by 1.0?
1 ·
Comments
It's likely that as a DApp developer you won't have to bother with private keys (though they'll be used under the hood). Now nothing is set in stone but I think that each DApp will have it's own private key (requested or otherwise) so that as a user you can limit and restrict a DApp in resources.
EDIT: Users should have full control over their private keys and their use and should be able to manage them at all times.
Also there is the concept of multiple levels of security. I.e. lowest security, you decrypt the private keys when you start doing stuff. Higher than that, you use a more secure computer, or trezor-like device, or have multichannel authentication. Latter is that you use a contract that requires two Ethereum accounts to agree to send a message in order to send it. It could be SMS verification, or shouting accross the street to your friend that can verify with the contract. Higher security than that yet you might use paper wallets, N-out-of-M with family/friends.
You might use multiple levels of security with DAOs/contracts. I think the best approach is probably to just have different Ethereum accounts represent them, that gives people full freedom to arrange their security themselves.