Warn about non-ASCII characters in passphrase

[sime]

User story

As a Trezor Suite user I want to protect my privacy So that my funds are safe when my seed is compromised

As a Trezor Suite user I want to create a hidden wallet passphrase on suite And I want to confirm it on my device So that I can trust I have create a hidden wallet securely

As a Trezor Suite user I want to access my hidden wallet And I want to enter my passphrase on a device I trust (Model T) So that I can access my funds

Design: Figma

Spec: Notion

Acceptance criteria

Given I am on 'Select wallet type' When I type '€' Then I should see a 'Unable to create a wallet with this passphrase' And the 'Access Hidden wallet' button should be disabled And the 'Enter passphrase on Trezor' link should be disabled

Caveat: Backwards compatibility issue, potentially blocking users with UTF-8 characters in passphrases.

Mockup

Screenshots

Passphrase 'Š'

Passphrase '€'

[prusnak]

Caveat: Backwards compatibility issue, potentially blocking users with UTF-8 characters in passphrases.

There should probably be some way how to override this and get back to the old behaviour?

[sime]

Caveat: Backwards compatibility issue, potentially blocking users with UTF-8 characters in passphrases.

There should probably be some way how to override this and get back to the old behaviour?

My current thinking is to inform (warn) the user when they enter a passhrase with non-sanctioned characters, on-device entry is then impossible.

This way there is no 'go back feature', and suite remains backwards compatible.

[Hannsek]

I would put there only warning that you won't be able to type the passphrase directly on device. That's it.

[Hannsek]

Let's put there this:

ℹ️ Special characters cannot be entered on the device.

"Learn more" button with the link: tps://trezor.io/learn/a/trezor-suite-settings#ASCII-chars

[Hannsek]

@Hermez-cz consider bumping a prio or put it into some of the upcoming releases.

[AdamSchinzel]

A bit related to #9044

[andrewkozlik]

FTR, although the BIP 39 spec allows any unicode characters in the passphrase, the SLIP 39 spec (Shamir backup) allows only printable ASCII, which is the character set that can be entered on Trezor. Unfortunately the firmware does not enforce this restriction for SLIP 39, which means that some users may have created passphrases that are incompatible with the spec.

[andrewkozlik]

After realizing the discrepancy between the SLIP-39 spec and Suite behavior, I think that we should prioritize this issue.

1. If a user with a SLIP-39 backup enters a character into the passphrase field that is not printable ASCII, then Suite should warn them: "Non-standard passphrase. Passphrases should only contain ASCII characters. Using this passphrase may lead to compatibility issues in the future." The user should be allowed to continue though, so that those who are already using a non-standard passphrase can still access their wallet.
2. If a user with a SLIP-39 backup enters a non-standard passphrase and Suite discovers that all wallets for the passphrase are empty and have no history, then instead of offering the user to open the wallet and continue to the "Confirm passphrase" dialog, Suite should force them to use a printable ASCII passphrase. For example: "This wallet is empty and hasn't been used before. To create a new wallet please use a passphrase with ASCII characters only."

FTR, these are printable ASCII: A - Z, a - z, 0 - 9, space, !, ", #, $, %, &, \, ', (, ), *, +, ,, -, ., /, :, ;, <, =, >, ?, @, [, \, ], ^, _, `, {, |, }, ~.

[Hermez-cz]

After realizing the discrepancy between the SLIP-39 spec and Suite behavior, I think that we should prioritize this issue.

1. If a user with a SLIP-39 backup enters a character into the passphrase field that is not printable ASCII, then Suite should warn them: "Non-standard passphrase. Passphrases should only contain ASCII characters. Using this passphrase may lead to compatibility issues in the future." The user should be allowed to continue though, so that those who are already using a non-standard passphrase can still access their wallet.
2. If a user with a SLIP-39 backup enters a non-standard passphrase and Suite discovers that all wallets for the passphrase are empty and have no history, then instead of offering the user to open the wallet and continue to the "Confirm passphrase" dialog, Suite should force them to use a printable ASCII passphrase. For example: "This wallet is empty and hasn't been used before. To create a new wallet please use a passphrase with ASCII characters only."

FTR, these are printable ASCII: A - Z, a - z, 0 - 9, space, !, ", #, $, %, &, \, ', (, ), *, +, ,, -, ., /, :, ;, <, =, >, ?, @, [, \, ], ^, _, `, {, |, }, ~.

Hi, the part of "Suite discovers that all wallets for the passphrase are empty and have no history" might become tricky if the user might have some funds on a coin that is currently not enabled. Otherwise all sounds like the right solution, thanks.

[Hannsek]

Therefore this should be done together with the idea of silent discovery of all coins. But we must think it through from the privacy pov.

[Hermez-cz]

Design and short spec

Since only the Printable ASCII character set is fully compatible with SLIP-39 backups, we’ve prepared two slightly different designs: a less strict one for BIP-39 and a more strict one for SLIP-39. Therefore, we’ll need to display the appropriate version based on the user’s current backup type.

Common for both versions If the user uses only Printable ASCII characters, don't bother the user with any extra instructions. Keep the current interface design please.

BIP-39 combination If the user writes any non-Printable ASCII character:

• show a blue recommending element as per design
  • Copywriting TBD
• change the CTA copy to "Confirm (with non-recommended "[unsupporrted character]")"
  • Or "Confirm (with non-recommended characters)" if there's more than one

If the user deletes the non-recommended character(s):

• keep the recommending element, so it doesn't hop in and out, and keeps providing instructions what characters can the user use.
• Turn the "Confirm" CTA back to normal as per design

In case of an error message shown together with the recommending element, it should look like this. The button should be inactive and carry the same copywriting as when active according to the situation.

SLIP-39 combination It's basically the same as for BIP-39, only the informational element and the non-recomended CTA are in a yellow warning state:

• Non-recommended character(s) present design

• Non-recommended character(s) deleted design (please mind the CTA returning to green)

• Error state combination design

Note: Users won’t be blocked in any of the non-error states described above, as they may already have such a passphrase. We will enhance this in a future Passphrase UX, where we’ll consider the user’s mental model—whether they expect funds in the passphrase or if it’s new for them. Another improvement opportunity will come with the potential for automatic coin discovery and activation for wallets where funds are expected. (another issue related to it: https://github.com/trezor/trezor-suite/issues/14229)