Clear-signing dialog dismisses on Approve, leaving nothing to compare against the device's digest screens

[illithics]

Environment: Vault v1.4.10, KeepKey firmware v7.14.1, macOS

Summary

When a paired app requests POST /eth/sign-typed-data, Vault shows an excellent
clear-signing dialog: decoded EIP-712 fields, "Known Pattern" badge, requesting-app
attribution. But clicking Approve immediately dismisses the dialog — and then
the device asks the user to confirm two hash digests ("TYPED DATA DOMAIN — confirm
hash digest" and "TYPED DATA MESSAGE — confirm hash digest").

At the exact moment the user is asked to verify those digests, the host screen shows
nothing to verify them against. The device confirmation degrades into a blind
"press OK to continue," which defeats the purpose of the firmware displaying digests
at all.

Steps to reproduce

1. Pair any app via /auth/pair.
2. Send an eth_signTypedData request for any typed struct.
3. Vault shows the decoded clear-signing dialog → click Approve.
4. Dialog closes. Device now shows the domain digest and message digest and asks
   for confirmation.
5. There is no longer anything on the host screen to compare the digests with.

Why this matters

The firmware's typed-data path (EthereumSignTypedHash) has the host compute
domainSeparator and hashStruct and the device sign the EIP-712 digest. The
device screens exist so a user (or an auditor) can check that what the device is
about to sign corresponds to the request they reviewed. That check requires the
reference values to be visible during the device-confirm phase — which is
precisely when Vault currently hides them.

(During development of a pendant-display dapp we recomputed the digests
independently and confirmed they match what the device shows — the comparison is
entirely feasible; the UI just doesn't support it.)

Expected behavior

1. On Approve, the dialog should not unmount. It should transition to a
   "Waiting for device confirmation…" state with all decoded fields still
   visible.
2. That state should additionally display the two host-computed digests, labeled
   to match the device's wording:
   • TYPED DATA DOMAIN — <domainSeparator hex>
   • TYPED DATA MESSAGE — <hashStruct(primaryType, message) hex>
     so the user can compare character-for-character with the device screen.
3. The dialog dismisses only when the device confirms or rejects (or the request
   times out), and shows the outcome.

Notes

• Both digests are already computed host-side to build the
  EthereumSignTypedHash message, so this is purely a presentation change — no
  protocol or firmware work.
• Same applies to the address-verification step (VERIFY ADDRESS screen): keep
  the expected address visible on the host while the device shows it.
• Nice-to-have: a copy button on each digest for out-of-band verification.

[illithics]

Reproduced in the wild with a plain Uniswap swap — the Permit2 typed-data signature triggers the exact sequence: clear-signing dialog → Approve → dialog gone → device asking to confirm two digests with nothing left on screen to compare them against.

On "contracts change too often to clear-sign": agreed, and that's a real constraint — but it's a different problem than this issue. Two separate tracks:

1. This issue needs no decoding at all

The requested fix is not "decode more structs." It's: keep the dialog mounted after Approve, in a waiting-for-device state, and print the two digests Vault already computes for every request — it has to compute domainSeparator and hashStruct(primaryType, message) to build the EthereumSignTypedHash message in the first place. Rendering them is presentation-only and works for 100% of typed-data requests, decodable or not.

The key inversion: the less decodable a struct is (Uniswap/Permit2 being the prime example), the more the digest comparison matters — for an unknown struct, those two hashes are the only verification the user has, and the current UX discards them at the exact moment the device asks about them. Blind digest confirmation is precisely the surface typed-data drainers exploit (malicious Seaport orders etc.), and it hits hardware-wallet users hardest because they've been trained to trust the device confirm.

2. Decode coverage has an ecosystem answer: ERC-7730

For growing the "Known Pattern" set without maintaining it alone: Ledger's clear-signing metadata standard (ERC-7730) has an open registry of display metadata for exactly these high-churn protocol structs. Consuming that registry as a data source for the clear-signing dialog would ride the ecosystem's maintenance instead of KeepKey's. Worth a separate issue if there's appetite.

Minimal repro (no dapp needed)

BASE=http://localhost:1646
KEY=$(curl -s -X POST $BASE/auth/pair -H "Content-Type: application/json" \
  -d '{"name":"Issue 385 Repro"}' | python3 -c "import json,sys;print(json.load(sys.stdin)['apiKey'])")
# approve pairing in Vault, then:
ADDR=$(curl -s -X POST $BASE/addresses/eth -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"address_n":[2147483692,2147483708,2147483648,0,0],"show_display":false}' \
  | python3 -c "import json,sys;print(json.load(sys.stdin)['address'])")
curl -s -X POST $BASE/eth/sign-typed-data -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" -d "{
  \"address\": \"$ADDR\",
  \"typedData\": {
    \"types\": {
      \"EIP712Domain\": [{\"name\":\"name\",\"type\":\"string\"},{\"name\":\"version\",\"type\":\"string\"},{\"name\":\"chainId\",\"type\":\"uint256\"}],
      \"Mail\": [{\"name\":\"from\",\"type\":\"address\"},{\"name\":\"to\",\"type\":\"address\"},{\"name\":\"contents\",\"type\":\"string\"}]
    },
    \"primaryType\": \"Mail\",
    \"domain\": {\"name\":\"Issue385\",\"version\":\"1\",\"chainId\":1},
    \"message\": {\"from\": \"$ADDR\", \"to\": \"0x0000000000000000000000000000000000000000\", \"contents\": \"reproducing issue 385\"}
  }}"

Click Approve in the Vault dialog, then look at the host screen while the device shows the domain/message digest confirms. (Reject on-device to finish — no signature needed to see the gap.)