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:
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
I wonder if these ideas can also work with the one about the universal login:
