EIP 1024 is starting to settle down and finalize, and so we just about have a solid technical foundation on which to build encryption and decryption into web3 browsers.
You can read the technical aspects of the proposal here:
In this thread I’d like to open the discussion to issues related to the user experience of encryption and decryption in web3 browsers.
A few questions I have, with my current opinions stated after them:
Should users be prompted before their encryption public key is exposed to the dapp via web3.eth.getEncryptionPublicKey?
I think especially with improved “explicit sign in” that this could be unnecessary, and associated keys could be revealed with a single “sign in” request.
Should we prompt users to encrypt?
This probably isn’t necessary, since encryption doesn’t require their private key material at all, could be performed without a web3 browser.
Eventually if/when we add a “sign and encrypt” method, we can prompt the user in one place there.
Should we prompt users to decrypt and download a file?
I don’t think this is necessary, since it does not expose the decrypted data to anyone but the user’s own hard disk.
Should we return decrypted data to the requesting Ðapp?
This is the behavior that I think would require a prompt and user authorization.
For the sake of keeping decryption-heavy dapps practical and usable, we probably want to introduce a batch requestPersistentUsageOfDecryptionKeyForAccount( account ) method.
The Dapp should provide a user a way of revoking this decryption method if it can be extended.
I am just jumping in with my 3 proposals in context (explained here)
On that note I posted a new topic on UX ring to bring discussion on these proposals, see here
One thing I did not mention and that you touch upon here is “encryption and the use of public key”.
So as to answer your point : 1. Should users be prompted before their encryption public key?
We could either
consider the public key as “already public” in the context of the wallet, or
we provide an api for encryption that do not reveal the public key.
In regard to 1), this is not too far fetched for most web3 browser as it is expected of the user to sign messages or transactions at some point. If not, are we going to explain to them that their public key will be public after their first transactions?
I think unless, the user is knowledgeable of what is happening, it would scare most user and most would simply accept such warning.
At the same time, 2) allow us to simply bypass the need for revealing the public key.
2. Should we prompt users to encrypt?
As you mentioned, this would be unnecessary if they have access to the public key
4. Should we return decrypted data to the requesting Ðapp?
As you understood from the article if the application encode the origin(s) allowed to decrypt the web3 browser could check the origin of the document attempting to decrypt and make sure they match before revealing the decrypted data.
This would also allow to safeguard from other application asking to decrypt data without the web3 browser having context to explain to the user where that data came from.
Hi! I have a need to implement new signature algorithms and made a proposal for extensible cryptography in wallets. It can also be used to implement encryption.
It’s stil draft. In particular it is not specified how the user confirmation would work. My original use case is for signing, but I’d like it to be general enough to solve all future needs for cryptography, including what EIP2¹⁰: Encrypt/Decrypt covers. My hope is to make it so good that it can be merged with EIP1024 into one proposal that covers all our wallet crypto needs.