Security and the Javascript bindings

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?

Comments

  • obscurenobscuren Member Posts: 38 ✭✭
    edited October 2014
    That's certainly not the idea. Think of the JavaScript API in it current form to _support_ our Proof of Concept. It's an idea of what is to become, but certainly not in such an insecure way as it is right now.

    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.
  • SemielSemiel Member Posts: 15
    That seems like a reasonable model. Thanks!
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    That is the DApp point of view, but what is the website point of view? Some project might want anyone be able to put a button on their website, however trust is low in that case. Perhaps the website could ask the DApp -as-in- client-side software (the user trusts) to do some (particular)action, and then the DApp handles it from there displaying the action and asking the user whether to transact it. (perhaps indicating an estimate of the importance, to ensure people look at it properly)

    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.
Sign In or Register to comment.