Render personal_sign messages as utf-8 text

[danfinlay]

Calls to personal_sign are now:

• When hex encoded, preserved as hex encoded, but displayed as utf-8 text.
• When not hex encoded, decoded as utf-8 text as hex for signing.
• The messages proposed for signing are displayed as UTF-8 text.
• When the message cannot be rendered as UTF-8 text, it is displayed as hexadecimal.

Fixes #1173

[kumavis]

When not hex encoded

I think we should hard fail here, as hex encoding is a valid utf8 encoding

[danfinlay]

Sample exception: 0x1 is valid hex but is not utf8 decodable.

[danfinlay]

What would a hard fail look like here? Throw an error to the sign request, and not show it to the user?

[kumavis]

throw an error to the sign request

[kumavis]

One example of unexpected behavior would be signing a number (e.g. a unix timestamp) -- in this implementation it would be interpreted as hex instead of utf8

[danfinlay]

The old eth_sign implementation hard-requires a hex-prefix 0x, and otherwise interpretes as utf8. That also seemed weird. What if a utf8 string started with 0x?

The safest move would maybe be to only allow hex input, try to decode it, but fall back to the original input.

[kumavis]

plz remove

[kumavis]

The safest move would maybe be to only allow hex input, try to decode it, but fall back to the original input.

this isnt safe if the developer is expecting the fallback case but (accidently) ends up with valid hex

[danfinlay]

This is what MIME types are for, and what I was originally postponing this feature for. Maybe we should just wait for that, I don't see a correct way forward here.

[kumavis]

my philosophy here is:
for developer input, have one correct way of doing things
for user input, be flexible

[kumavis]

I look forward to the MIME type spec - but that feature actually happens "after" this intial decoding

we are dealing with the first layer of this stack:

• decode raw RPC params
• parse for MIME type
• display message signing UI

[chafey]

In many cases, a timestamp will be included in the message to be signed to prevent replay attacks. The timestamp is not necessarily something we want to display to the user though - yet this scheme would do so. I would love to be able to pass a "display string" that is presented to the user in the confirmation window to help guide them through the process. For example "Please press "Confirm" if you would like to do X". We can make the actual message available to the user for inspection if they so desire, but it may not be meaningful to them

[danfinlay]

I think mime content headers would adequately allow specifying portions of the signed text to render vs to hide: #925