Android Studio Build:

Android Studio 4.0 Canary 2
Build #AI-192.6817.14.36.5984562, built on November 3, 2019
Runtime version: 1.8.0_212-release-1586-b4-5784211 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 5.0.0-32-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 1981M
Cores: 8
Registry: ide.new.welcome.screen.force=true, debugger.watches.in.variables=false
Non-Bundled Plugins: CheckStyle-IDEA

Version of Gradle Plugin: gradle:4.0.0-alpha02
Version of Gradle: 5.6.1
Version of Kotlin: 1.3.60-eap-25
OS: Ubuntu 19.04

Steps to Reproduce: Look at the EditorModel in TextField.kt from androidx.ui:ui-framework:0.1.0-dev02

Expected Results: EditorModel to use a CharSequence or some other text representation that can be cleared from memory

Actual Results: EditorModel uses a String, which is immutable in the JVM

---

While String is super-convenient, one big flaw is that it is immutable. That is not a problem in most situations, but it is a substantial issue in password fields. It's generally recommended to try to remove all traces of a password as soon as those traces are no longer needed. This includes wiping out whatever text is held by the text entry widget used for the password. See for example:

https://www.sjoerdlangkemper.nl/2016/05/22/should-passwords-be-cleared-from-memory/
https://stackoverflow.com/q/8881291/115145

In the Android view-based system, EditText uses an Editable, which is a sub-type of CharSequence. We can clear those, setting their contents to all zeros (or whatever). So, once the user is done entering the password, we can get the Editable, use it for our secure situation (e.g., send it to the server), and then clear its contents.

EditorModel not only uses an immutable String, but it does so for each intermediate step in the text input. Now we have N-1 partial passwords (or more) for an N-character password, represented as String objects. Those will remain in the heap until the memory get reused, and that is a risk for certain types of attacks.

Ideally, EditorModel would use a different text representation, one that we can clear, the way we can with Editable in an EditText. If the vision is that this is handled by a separate composable (e.g., PasswordField) with its own model, that's fine (though you'll want to move the visualTransformation over to this other composable, as otherwise developers will use TextField for passwords).

Thanks for considering this!