qml: use in-app virtual keyboard for entering seed? unclear if system keyboard is safe.

[SomberNight]

I think we should use an in-app virtual keyboard on the seed-entry screen on Android, in the qml app.
kivy did the same.
At the very least I want a discussion to take place about this, hence this issue :)

pics

The user might have installed any kind of custom keyboard app (swiftkey/etc), that might exfiltrate entered text either accidentally or maliciously. In general I don't think we can trust the external keyboard app for this.

Alternatively, I wonder if there are flags we can set for Android so that it brings up some trusted barebones default keyboard.

Relatedly, when testing on Android using a keyboard app that has "predictive text" features, I see that on most text fields such as setting a tx label or naming a wallet file the keyboard has predictive text enabled, but on the seed-entry screen the keyboard seems to have predictive text disabled (which is promising). I am curious, how exactly does this work / where is it set?

Re what other wallets are doing, e.g.
Phoenix uses a virtual keyboard,
but bluewallet and SBW use the system keyboard.

[accumulator]

Qt can set hints for the virtual keyboard, see

electrum/electrum/gui/qml/components/controls/SeedTextArea.qml

Line 80 in 231ea5d

inputMethodHints: Qt.ImhSensitiveData | Qt.ImhLowercaseOnly | Qt.ImhNoPredictiveText

This is passed to android and eventually to the virtual keyboard implementation. I don't know if or how it is enforced.

[ecdsa]

from the Qt docs:

Qt.ImhSensitiveData - Typed text should not be stored by the active input method in any persistent storage like predictive user dictionary.

I don't think that ensures that the keyboard will not misbehave.
It would be better if there was a flag that imposes the system's default keyboard, and not a custom one.

[accumulator]

Instead of implementing our own in-app keyboard, there's also the Qt Virtual Keyboard, which if I understand it correctly is pure-Qt and doesn't use the android virtual keyboard.

Pros:

• known implementation
• user input is kept within the application
• more advanced than we can reasonably implement, e.g. other keyboard layouts, other input methods (?) like chinese, korean, japanese etc
• probably better control of the GUI elements to flow around the keyboard, e.g. don't let keyboard overlap buttons or parts of dialogs

Cons:

• application wide, so we have to use this keyboard for all text input and can't use the android vkbd
• needs some effort to integrate all dependencies in P4A Qt5 bootstrap, might not be very straightforward
• unknown limitations?

[SomberNight]

more advanced than we can reasonably implement, e.g. other keyboard layouts, other input methods (?) like chinese, korean, japanese etc

We only really need the Latin alphabet (26 chars), space and backspace. We don't need fancy features.
E.g. it is ok not to be able to restore the "9dk" seed (despite being useful for testing).
The kivy app only ever allowed restoring from"English" seeds, and it's fine to keep that restriction.
But yes, in general it would be nice not to have to implement our own - just keep in mind if we decided to do it anyway, we should keep it simple, and it probably would not end up being too difficult.

application wide, so we have to use this keyboard for all text input and can't use the android vkbd

It is a pity we can't restrict it to the seed-entry screen :/ I think for general-purpose textedits, users would normally expect to use the system keyboard they are used to.

[ecdsa]

fixed in #8275