Hi @danfinlay
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.