desktop-wallet icon indicating copy to clipboard operation
desktop-wallet copied to clipboard

Transfer view - encrypted message improvements

Open cryptoBeliever opened this issue 4 years ago • 3 comments

Right now when user put some text into the message and tick "Encrypt the message":

  • it's asked for a password
  • text is changed to the encrypted string

My proposition:

  • present to user always unencrypted text (don't change to encrypted string)
  • if possible don't ask the user for a password. User need to put anyway password when sending transaction.

cryptoBeliever avatar Feb 16 '21 19:02 cryptoBeliever

The only possibility of not requiring a user password is to store the user password in a session or any other storage, which can weaken user protection.

boldchains avatar Feb 16 '21 20:02 boldchains

Yes, saving the password is bad.

But why don't we encrypt the message right before sending, after the user enters his password in confirmation modal?

This would also solve another issue: Right now you can enter a message, check "encrypt", then edit the message but this edit is not going to the TX.

myxmaster avatar Feb 16 '21 23:02 myxmaster

we have to have the user password to encrypt the message, there is no way around that.

But I agree with other comments, could that encryption be done at the signing the transaction stage when the user has already entered their password?

I think the problem around this is trying to calculate the fee or maybe know how much space is left in the message?

But basically the little checkbox that one clicks when the click "encrypted message" is kind of a faux encrypt checkbox, meaning it isn't encrypted in real time, but instead put on the list to do later after confirmation. Like I said, the biggest problem I can think of in this case is that it some how messes with the message length or fee structure because of that.

jabo38 avatar Feb 17 '21 17:02 jabo38