Password fields should not use third-party IMEs' cloud candidate services, which can leak plaintext

What it is

Third-party IMEs often send key sequences to the cloud for ranking and correction. If a password box still uses that service, the passphrase or PIN leaves the device as plaintext or a recoverable keystroke stream. The system can force a local, non-learning keyboard on secure-text fields; an app that leaves the user's current cloud IME in place hands the password to the IME vendor. This is about whether data leaves the device, not whether a candidate bar is drawn—candidates can be off and keystrokes still upload.

Why it happens

The IME process sees keys in the field before the app paints dots. A cloud API ships context and the current string in exchange for candidates. Platform policy for secure fields is to ignore the user-selected third-party IME, or to sandbox it without network. On the Web, type=password usually triggers that policy in mobile browsers; a custom widget that is not a password does not. Enterprise and parental-control keyboards may also have a network path. Once upload logs are breached or used for training, the password enters a corpus.

Studying it

Install an IME with network logging and compare a secure field with a normal field: on password focus, are there still requests to the IME server, and do bodies contain keystrokes? Compare a system-forced local keyboard with an app that never declared secure semantics. Certificate pinning or a proxy can capture plaintext. Do not use real passwords; use a throwaway fake. Store policies that forbid IME upload should still be checked on a test device for actual compliance.

Where it stops holding

A fully offline third-party IME has no cloud path; risk degrades to on-device logs. System IMEs may have their own cloud toggle; with it off they match an offline third party. Password-manager fill does not go through the IME keystroke stream; it is another injection and still needs origin isolation. Dictating a password sends audio to recognition—another cloud path that should be forbidden or made local.

Applying it

• Use the platform secure-text type on password, PIN, and unlock fields so the system replaces the cloud IME.
• Do not fake dots on ordinary text, which leaves the current IME in place.
• If the app must use a WebView, ensure password inputs are not rewritten to text.
• Verify by installing a logging IME on a test device: password focus should produce empty IME-server logs (or only unrelated traffic); a chat field should show contrast traffic.

Related

• Same group: C6.29.1 Some systems pop a randomized number pad on password fields to block position-based shoulder surfing · C6.29.2 Password keyboards usually turn off autocorrect and candidates so input is not leaked · C6.29.3 Randomized pads sacrifice touch-typing speed; that is a security–efficiency tradeoff
• Adjacent: C6.25 IME state and switching · C6.12 IME candidates
• Search: cloud IME · password field · keystroke upload