Web3 object privacy and dapps unique keys

Hello everyone,
I would like to start a discussion about how we can improve privacy while using dapps. I don’t have a solution for that but just a couple of ideas that we could discuss about.

At the moment when users open a dapp, the web3 object is immediately available, and any website visited can check the user’s address and balance and track it.
I think it would be nice if we can avoid this and give the user the ability to give permissions to the web3 object on a site basis.

I was thinking about 2 things we could implement or start thinking about:

1 - Ask for permissions to use the web3 object
2 - Generate unique deterministic keys based on the dapp hostname

Ask for permission to use the web3 object

When a dapp calls the web3 object for the first time, we can show a popup to the user asking for permissions.
Based on the user action the web3 will be available or not.

There is already a similar idea with EIP 1102
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1102.md

https://ethereum-magicians.org/t/eip-1102-opt-in-web3-access/414/

Generate unique deterministic keys/wallets based on the dapp hostname

Status already implements the Hierarchical Deterministic wallet, so we could use it to derive unique deterministic keys based on the hash of the dapps hostname.

The main address of an account in Status uses the derivation path determined in the BIP44. This derivation path is:

m/44'/60'/0'/0/0

here is the description of each part of the path:

m / purpose’ / coin_type’ / account’ / change / address_index

Here is the implementation in Status:

https://github.com/status-im/status-go/blob/develop/extkeys/hdkey.go#L217

The master key is never saved on the device. It’s only used at the account creation to derive the first account key.

What we could do is saving another extended key that we can call Dapp Root Key, and then use it to derive keys based on the dapp hostname deterministically.
Given the hash of a dapp hostname, we can split it into groups of 31 bits and each group would be a part of the derivation path:

m/DappRootKeyDerivationPath/first_31_bits_group/second_31_bits_group/...

This means that users will use a different wallet for each dapp, so it will be more difficult to track a user based on one address.
Users could leave the dapp wallet empty and move some value into it only when they trust the dapp and want to start using it.
Moving value to the dapp wallet means creating a transaction. Since the transaction is on the blockchain it will be again easy to associate the dapp wallet to the main wallet of a user. I’m not sure if there is a proper way to avoid it, or if zksnarks could be useful here.

The geth version we use has already been patched to save another extended key that can be used for sub-accounts:

https://github.com/status-im/status-go/blob/develop/vendor/github.com/ethereum/go-ethereum/accounts/keystore/key.go#L51

In the current implementation we extended the keystore to save the first and second child keys, m/44'/60'/0'/0/0 and m/44'/60'/0'/0/1

https://github.com/status-im/status-go/blob/develop/vendor/github.com/ethereum/go-ethereum/accounts/keystore/key.go#L153

I wonder if these ideas can also work with the one about the universal login:

4 Likes

Such a great topic!

Yeah, I think we should treat all the web3 permissions as strictly as web browsers treat location or notifications or other sensitive settings. At least, an unknown DApp or a website shouldn’t be able to read anything about web3 if a user doesn’t give his consent.

Regarding transactions, it might be a bit tricky to avoid the wallet disclosure though. By itself, it is not a big issue, but leaving our public key somewhere linked to your real address or name or anything might be a concerning topic. But I’m not sure about the majority of the users.

1 Like

Regarding ERCs of Signed Messages, is not exactly the case but more the keys you add to your identity.
I explained in the Identity topic, and will just quote it here…

1 Like

Love that this discussion is taking place! I think Ðapps should actively discourage signups from addresses that have been used, and every wallet or web3 providers such as Metamask or Status should default to a new key for every hostname that the user interacts with – it’s the only way to guarantee privacy until Ðapps stop the (bad) practice of injecting web3 by default. This means Metamask and Status will have a password-manager-like interface.

There are some UX challenges that come with this approach – how do we keep this usable? I’m exploring this as a personal project, hit me up if you have any comments or suggestions!

2 Likes

@gravityblast MetaMask team is considering to disable web3 access by default. See https://ethereum-magicians.org/t/eip-1102-opt-in-web3-access/414/17. It would be useful also if we decide to provide status specific APIs.

We should align with others DApp browser to come up with some kind of standard.

@gravityblast Sorry just realized you mentioned this :slight_smile:

1 Like

Just created a new topic focusing on EIP 1062 and how it applies to us: Status web DApps API

2 Likes