`signTypedData_v4` encoding problems on mobile

[Gudahtt]

Describe the bug Our signTypedData_v4 implementation has various problems that make it easy to produce non-standard and/or non-portable encodings unintentionally. There are three main problems: our array encoding is not spec-compliant, we don't perform enough input validation, and we don't clearly document how each Solidity type should be encoded in the input data.

Steps to reproduce (REQUIRED) See the eth-sig-util test suite for examples of nonsense inputs that we still accept or interpret in silly ways, and see this issue for an explanation of the array encoding problem.

Expected behavior We should ensure our eth_signTypedData implementation is spec-compliant, and that it does not produce non-standard/non-portable encodings, and that there is no remaining ambiguity in how data is interpreted. We can't accomplish these goals without breaking compatibility, so this will have to be released as signTypedData_v5.

See the eth-sig-util `signTypedData_v5 milestone for a list of related issues.

---

to be added after bug submission by internal support / PM Severity

• How critical is the impact of this bug on a user?
• Add stats if available on % of customers impacted
• Is this visible to all users?
• Is this tech debt?

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity. If you feel this was closed in error please reopen and provide evidence on the current production app. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 7 days. Thank you for your contributions.

[github-actions[bot]]

This issue was closed because there has been no follow activity in 7 days. If you feel this was closed in error please provide evidence on the current production app in a new issue or comment in the existing issue to a maintainer. Thank you for your contributions.